Sample Selection from IEEE Software Engineering Standards and Examples: Guide for Implementing a Software Requirements Specification
6.1 Role of software requirements specifications
As stated in earlier paragraphs, the SRS provides the foundation for the software project. It describes the system to be delivered. Where possible, it separates the essential, desirable, and optional requirements so sufficient resources are allocated to the more important requirements. A good SRS identifies those items that are stable and others that might be volatile. By segregating the volatile requirements from the more stable requirements, changes to the requirements can more readily be accommodated.
The SRS should state problems, not solutions. Solutions to these problems are developed and documented in the software design description. In general, the SRS states what the problem is, not how to solve it. These concepts are often stated as: the requirements specification documents the "what," and the design description documents the "how."
Design can be very important in some environments. For example, a case exists in which the requirements analyst (the person making the "what" decision) was not a labor union member nor covered by the union contract and the designers (the individuals making the "how" decision) were union members covered under the contract. The issue as to what was a requirement and what was a design became a union contract issue. [1]
Al Davis addresses the "what vs. how" issue in one of his excellent texts about software requirements [2]. Davis points out that whether a given statement describes a "what" or a "how" very much depends on its position within the software development hierarchy. Figure 1.6 concisely illustrates this concept: the early phases of the software system development life cycle consist of alternating steps of requirements analysis and design. At the top level, the system or software system requirements are documented; then the top level of design is done, defining the major components of the system, the functions of each, and the interfaces between them. That level of design becomes the requirements for the next level, which in turn leads to the next level of design. Thus, "one person’s requirement is the next person’s design and vice versa."
The SRS serves as a basis of understanding between the customer/user and developer. It provides for the writing of the preliminary version of the users’ manual. The SRS supports the development of the acceptance test plan. Lastly, its development is the first step in project planning.
6.2 Contents of a software requirements specification
In the IEEE Recommended Practice for Software Requirements Specifications [2], the format of the software requirements specification is structured according to the requirements types discussed in Sections 3.3 and 5.1 above:
- Software functions -- what the system is supposed to do.
- Performance -- speed, availability, accuracy, response time, and recovery time.
- External interfaces -- with people, special-purpose hardware, other systems, software from other projects.
- Design constraints -- required implementation language, database integrity, limits on usage of resources such as memory, and others.
- Quality attributes -- considerations of reliability, maintainability, portability, security, and so on.
- Other -- database, operations, site adapting, and so on.
6.3 What the software requirements specifications should not contain
The SRS should specify valid design constraints, not needless designs. This particular issue is very hard to enforce or even identify. Any design that is absolutely required by the customer or acquirer must be included under the category "design constraint."
Other things that should NOT be specified in a project requirement are programmatics: (In the US these items go in the project plan or other plans, but in Europe the SRS often contains these items.)
- project cost and schedule
- software quality assurance procedures
- software development methods
- acceptance test procedures
- project reporting procedures
Finally, an SRS does not specify a service. An SRS describes a software product to be built.
---------------------------------------------------
[1] Personal knowledge of the author.
[2] A.M. Davis, Software Requirements: Objects, Functions, and States (revision), Prentice Hall, Englewood Cliffs, NJ, 1993.
Purchase, Product Description, Author Bios, Table of Contents