IEEE Recommended Practice for Software Requirements Specifications PDF

## IEEE Recommended Practice for Software Requirements Specifications ### 1. Definitions In general the definitions of terms used in this recommended practice conform to the definitions provided in IEEE Std 610.12-1990. The definitions below are key terms as they are used in this recommended pract...

## IEEE Recommended Practice for Software Requirements Specifications ### 1. Definitions In general the definitions of terms used in this recommended practice conform to the definitions provided in IEEE Std 610.12-1990. The definitions below are key terms as they are used in this recommended practice. - **contract:** A legally binding document agreed upon by the customer and supplier. This includes the technical and organizational requirements, cost, and schedule for a product. A contract may also contain informal but useful information such as the commitments or expectations of the parties involved. - **customer:** The person, or persons, who pay for the product and usually (but not necessarily) decide the requirements. In the context of this recommended practice the customer and the supplier may be members of the same organization. - **supplier:** The person, or persons, who produce a product for a customer. In the context of this recommended practice, the customer and the supplier may be members of the same organization. - **user:** The person, or persons, who operate or interact directly with the product. The user(s) and the customer(s) are often not the same person(s). ### 2. Considerations for producing a good SRS This clause provides background information that should be considered when writing an SRS. This includes: - **Nature of the SRS;** - **Environment of the SRS;** - **Characteristics of a good SRS;** - **Joint preparation of the SRS;** - **SRS evolution;** - **Prototyping;** - **Embedding design in the SRS;** - **Embedding project requirements in the SRS.** #### 2.1 Nature of the SRS The SRS is a specification for a particular software product, program, or set of programs that performs certain functions in a specific environment. The SRS may be written by one or more representatives of the supplier, one or more representatives of the customer, or by both, Subclause 4.4 recommends both. The basic issues that the SRS writer(s) shall address are the following: - **Functionality.** What is the software supposed to do? - **External interfaces.** How does the software interact with people, the system's hardware, other hardware, and other software? - **Performance.** What is the speed, availability, response time, recovery time of various software functions, etc.? - **Attributes.** What are the portability, correctness, maintainability, security, etc. considerations? - **Design constraints imposed on an implementation.** Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.? The SRS writer(s) should avoid placing either design or project requirements in the SRS. For recommended contents of an SRS see Clause 5. #### 2.2 Environment of the SRS It is important to consider the part that the SRS plays in the total project plan, which is defined in IEEE Std 610.12-1990. The software may contain essentially all the functionality of the project or it may be part of a larger system. - In the latter case typically there will be an SRS that will state the interfaces between the system and its software portion, and will place external performance and functionality requirements upon the software portion. - Of course the SRS should then agree with and expand upon these system requirements. - IEEE Std 1074-1997 describes the steps in the software life cycle and the applicable inputs for each step. - Other standards, such as those listed in Clause 2, relate to other parts of the software life cycle and so may complement software requirements. Since the SRS has a specific role to play in the software development process, the SRS writer(s) should be careful not to go beyond the bounds of that role. This means the SRS: - **Should correctly define all of the software requirements.** A software requirement may exist because of the nature of the task to be solved or because of a special characteristic of the project. - **Should not describe any design or implementation details.** These should be described in the design stage of the project. - **Should not impose additional constraints on the software.** These are properly specified in other documents such as a software quality assurance plan. Therefore, a properly written SRS limits the range of valid designs, but does not specify any particular design. #### 2.3 Characteristics of a good SRS An SRS should be: - **Correct** - **Unambiguous** - **Complete** - **Consistent** - **Ranked for importance and/or stability** - **Verifiable** - **Modifiable** - **Traceable** #### 2.3.1 Complete An SRS is complete if, and only if, it includes the following elements: - All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated. - Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values. - Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure. #### 2.3.1.1 Use of TBDs Any SRS that uses the phrase "to be determined" (TBD) is not a complete SRS. The TBD is, however, occasionally necessary and should be accompanied by: - A description of the conditions causing the TBD (e.g., why an answer is not known) so that the situation can be resolved. - A description of what must be done to eliminate the TBD, who is responsible for its elimination, and by when it must be eliminated. #### 2.3.2 Consistent Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct (see 4.3.1). #### 2.3.2.1 Internal Consistency An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict. The three types of likely conflicts in an SRS are as follows: - **The specified characteristics of real-world objects may conflict.** For example: - The format of an output report may be described in one requirement as tabular but in another as textual. - One requirement may state that all lights shall be green while another may state that all lights shall be blue. - **There may be logical or temporal conflict between two specified actions.** For example: - One requirement may specify that the program will add two inputs and another may specify that the program will multiply them. - One requirement may state that “A” must always follow “B,” while another may require that “A and B” occur simultaneously. - **Two or more requirements may describe the same real-world object but use different terms for that object.** For example, a program's request for a user input may be called a "prompt" in one requirement and a "cue" in another. The use of standard terminology and definitions promotes consistency. #### 2.3.3 Ranked for importance and/or stability #### 2.3.3.1 Degree of Stability One method of identifying requirements uses the dimension of stability. Stability can be expressed in terms of the number of expected changes to any requirement based on experience or knowledge of forthcoming events that affect the organization, functions, and people supported by the software system. #### 2.3.3.2 Degree of Necessity Another way to rank requirements is to distinguish classes of requirements as essential, conditional, and optional. - **Essential.** Implies that the software will not be acceptable unless these requirements are provided in an agreed manner. - **Conditional.** Implies that these are requirements that would enhance the software product, but would not make it unacceptable if they are absent. - **Optional.** Implies a class of functions that may or may not be worthwhile. This gives the supplier the opportunity to propose something that exceeds the SRS. #### 2.4 Prototyping Prototyping is used frequently during the requirements portion of a project. Many tools exist that allow a prototype, exhibiting some characteristics of a system, to be created very quickly and easily. Prototypes are useful for the following reasons: - **The customer may be more likely to view the prototype and react to it than to read the SRS and react to it.** Thus, the prototype provides quick feedback. - **The prototype displays unanticipated aspects of the systems behavior.** Thus, it produces not only answers but also new questions. This helps reach closure on the SRS. - **An SRS based on a prototype tends to undergo less change during development, thus shortening development time.** A prototype should be used as a way to elicit software requirements. Some characteristics such as screen or report formats can be extracted directly from the prototype. Other requirements can be inferred by running experiments with the prototype. #### 2.5 Embedding design in the SRS A requirement specifies an externally visible function or attribute of a system. A design describes a particular subcomponent of a system and/or its interfaces with other subcomponents. The SRS writer(s) should clearly distinguish between identifying required design constraints and projecting a specific design. Note that every requirement in the SRS limits design alternatives. This does not mean, though, that every requirement is design. The SRS should specify what functions are to be performed on what data to produce what results at what location for whom. The SRS should focus on the services to be performed. The SRS should not normally specify design items such as the following: - Partitioning the software into modules - Allocating functions to the modules - Describing the flow of information or control between modules - Choosing data structures #### 2.6 Embedding project requirements in the SRS The SRS should address the software product, not the process of producing the software product. Project requirements represent an understanding between the customer and the supplier about contractual matters pertaining to production of software and thus should not be included in the SRS. These normally include items such as: - Cost - Delivery schedules - Reporting procedures - Software development methods - Quality assurance - Validation and verification criteria - Acceptance procedures Project requirements are specified in other documents, typically in a software development plan, a software quality assurance plan, or a statement of work. ### 3. The parts of an SRS This clause discusses each of the essential parts of the SRS. These parts are arranged in Figure 1 in an outline that can serve as an example for writing an SrS. While an SRS does not have to follow this outline or use the names given here for its parts, a good SRS should include all the information discussed here. ### 3.1 Overall description (Section 2 of the SRS) This section of the SRS should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3 of the SRS, and makes them easier to understand. This section usually consists of six subsections, as follows: - **Product perspective:** This subsection of the SRS should put the product into perspective with other related products. If the product is independent and totally self-contained, it should be so stated here. If the SRS defines a product that ia a component of a larger system, as frequently occurs, then this subsection should relate the requirements of that larger system to functionality of the software and should identify interfaces between that system and the software. - **Product functions:** - **User characteristics:** - **Constraints:** - **Assumptions and dependencies:** - **Apportioning of requirements:** ### 3.1.1 Product perspective (2.1 of the SRS): A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful. This subsection should also describe how the software operates inside various constraints. For example, these constraints could include: - **System interfaces** - **User interfaces** - **Hardware interfaces** - **Software interfaces** - **Communications interfaces** - **Memory** - **Operations** - **Site adaptation requirements** ### 3.1.2 Constraints (2.4 of the SRS): This subsection of the SRS should provide a general description of any other items that will limit the developer's options. These include: - **Regulatory policies:** - **Hardware limitations (e.g. signal timing requirements):** - **Interfaces to other applications:** - **Parallel operation:** - **Audit functions:** - **Control functions:** - **Higher-order language requirements:** - **Signal handshake protocols (e.g., XON-XOFF, ACK-NACK):** - **Reliability requirements:** - **Criticality of the application:** - **Safety and security considerations:** ### 3.1.3 Assumptions and dependencies (2.5 of the SRS): This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption may be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly. ### 3.2 Specific Requirements (Section 3 of the SRS) This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. Throughout this section, every stated requirement should be externally perceivable by users, operators, or other external systems. These requirements should include at a minimum a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output. As this is often the largest and most important part of the SRS, the following principles apply: - **Specific requirements should be stated in conformance with all the characteristics described in 4.3. Specific requirements should be cross-referenced to earlier documents that relate.** - **All requirements should be uniquely identifiable.** - **Careful attention should be given to organizing the requirements to maximize readability.** ### 3.2.1 Software system attributes There are a number of attributes of software that can serve as requirements. It is important that required attributes be specified so that their achievement can be objectively verified. ### 3.2.1.1 Reliability This should specify the factors required to establish the required reliability of the software system at the time of delivery. ### 3.2.1.2 Availability This should specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart. ### 3.2.1.3 Security This should specify the factors that protect the software from accidental or malicious access, use, modification, destruction, or disclosure. Specific requirements in this area could include the need to: - Utilize certain cryptographical techniques. - Keep specific log or history data sets. - Assign certain functions to different modules. - Restrict communications between some areas of the program. - Check data integrity for critical variables. ### 3.2.1.4 Maintainability This should specify attributes of software that relate to the ease of maintenance of the software itself. There may be some requirement for certain modularity, interfaces, complexity, etc. Requirements should not be placed here just because they are thought to be good design practices. ### 3.2.1.5 Portability This should specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems. This may include the following: - Percentage of components with host-dependent code - Percentage of code that is host dependent - Use of a proven portable language - Use of a particular compiler or language subset - Use of a particular operating system The document continues in this format discussing more details of the SRS breakdown.