Explanations should take around 40 words. Some slack will be given to 50 or 60 word explanations (however, don't press your luck too many times on this); explanations a page or more long will lose five points.

1. Describe how problems of scale brought about the need for software requirements.

   ---

   In two ways. First, larger problems meant larger and more varied development staffs, making informal methods of problem description less effective due to uncertain delivery and varied audiences. Second, understanding more complex problems required greater amounts of information than could be successfully handled by informal problem description techniques.

   ---

2. Suppose a software development organization has the resources to create two system requirements specifications (SRSs), one for its client and the other for its developers. Explain how and why the two SRSs differ from one another in terms of their levels of abstraction.

   ---

   A client SRS would describe the problem at a higher level of abstraction, concentrating more on what the problem is than the how the problem should be solved. A developer SRS would describe the problem at a lower level of abstraction, expanding some of the customer's hows as whats at the next lower level.

   ---

3. Explain how to specify (or model) the requirements

   1. A group that's created will eventually be deleted.

   2. A group may be created only if it doesn't exist.

   using regular expressions.

   ---

   Let create_i represent the creation of some particular group i, and delete_i represent the deletion of some particular group i. Assuming that no groups exist to start, the first requirement can be specified as

   create_i delete_i

   According to the second requirement, once deleted, a group may be created again, at which point it will be deleted again, at which point it may be created again, and so on, leading to the regular expressions

   create_i delete_i
   create_i delete_i create_i delete_i
   create_i delete_i create_i delete_i create_i delete_i
   

   and so on, which can be properly represented as the regular expression

   (create_i delete_i)*

   ---

4. Explain how a system requirements specification (SRS) can prevent change from occurring during system development. Explain how an SRS can cause change to occur during system development.

   ---

   By having the client think about their problem, an SRS can help the client realize the system's capabilities early in development, where they can be included in the SRS, and reducing the need for the client to issue stream of change requests during system development.

   On the other hand, the SRS freezes any technology-related trade-offs in the system being built. As the system is developed, the technology may change and the trade-offs may no longer appear attractive, which may result in a sequence of changes during system development.

   ---

This page last modified on 7 February 2001.