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 the following: - 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. - 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. - Should not describe any design or implementation details. - Should not impose additional constraints on the software. - 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.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.1.2 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. - The use of standard terminology and definitions promotes consistency. ### 2.3.2 Ranked for importance and/or stability #### 2.3.2.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.2.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. - See also ASTM E1340-96. - 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. - The prototype displays unanticipated aspects of the systems behavior. - 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 its interfaces with other subcomponents. - The SRS writer(s) should clearly distinguish between identifying required design constraints and projecting a specific design. - Every requirement limits design alternatives, but not 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 models - 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. - **Table of Contents:** - Introduction - Purpose - Scope - Definitions, acronyms, and abbreviations - References - Overview - Overall description - Product perspective - Product functions - User characteristics - Constraints - Assumptions and dependencies - Apportioning of requirements - Specific requirements (See 5.3.1 through 5.3.8 for explanations of possible specific requirements. See also Annex A for several different ways of organizing this section of the SRS.) - Appendixes ### 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 - Product functions - User characteristics - Constraints - Assumptions and dependencies - Apportioning of requirements #### 3.1.1 Product perspective (2.1 of the SRS) - 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 is a component of a larger system, 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. - A block diagram showing the major components of the larger system, interconnections, and external inter-faces 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 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. - Suclauses 5.3.6.1 through 5.3.6.5 provide a partial list of examples. ##### 3.1.3.1 Reliability - This should specify the factors required to establish the required reliability of the software system at time of delivery. ##### 3.1.3.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.1.3.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.1.3.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.1.3.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 ## Annex A (Informative) - **SRS templates** ### A.1 Template of SRS Section 3 organized by mode: Version 1 ``` 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2.1 Mode 1 3.2.1.1 Functional requirement 1.1 .... 3.2.1.n Functional requirement 1.n 3.2.2 Mode 2 .... 3.2.m Mode m 3.2.m.1 Functional requirement m.1 .... 3.2.m.n Functional requirement m.n 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements ``` ### A.2 Template of SRS Section 3 organized by mode: Version 2 ``` 3. Specific requirements 3.1 Functional requirements 3.1.1 Mode 1 3.1.1.1 External interfaces 3.1.1.1.1 User interfaces 3.1.1.1.2 Hardware interfaces 3.1.1.1.3 Software interfaces 3.1.1.1.4 Communications interfaces 3.1.1.2 Functional requirements 3.1.1.2.1 Functional requirement 1 .... 3.1.1.2.n Functional requirement n 3.1.1.3 Performance 3.1.2 Mode 2 .... 3.1.m Mode m 3.2 Design constraints 3.3 Software system attributes 3.4 Other requirements ``` ### A.3 Template of SRS Section 3 organized by user class ``` 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2.1 User class 1 3.2.1.1 Functional requirement 1.1 .... 3.2.1.n Functional requirement 1.n 3.2.2 User class 2 .... 3.2.m User class m 3.2.m.1 Functional requirement m.1 .... 3.2.m.n Functional requirement m.n 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements ``` ### A.4 Template of SRS Section 3 organized by object ``` 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Classes/Objects 3.2.1 Class/Object 1 3.2.1.1 Attributes (direct or inherited) 3.2.1.1.1 Attribute 1 .... 3.2.1.1.n Attribute n 3.2.1.2 Functions (services, methods, direct or inherited) 3.2.1.2.1 Functional requirement 1.1 .... 3.2.1.2.m Functional requirement 1.m 3.2.1.3 Messages (communications received or sent) 3.2.2 Class/Object 2 .... 3.2.p Class/Object p 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements ``` ### A.5 Template of SRS Section 3 organized by feature ``` 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 System features 3.2.1 System Feature 1 3.2.1.1 Introduction/Purpose of feature 3.2.1.2 Stimulus/Response sequence 3.2.1.3 Associated functional requirements 3.2.1.3.1 Functional requirement 1 .... 3.2.1.3.n Functional requirement n 3.2.2 System feature 2 .... 3.2.m System feature m 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements ``` ### A.6 Template of SRS Section 3 organized by stimulus ``` 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2.1 Stimulus 1 3.2.1.1 Functional requirement 1.1 .... 3.2.1.n Functional requirement 1.n 3.2.2 Stimulus 2 .... 3.2.m Stimulus m 3.2.m.1 Functional requirement m.1 .... 3.2.m.n Functional requirement m.n 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements ``` ### A.7 Template of SRS Section 3 organized by functional hierarchy ``` 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2.1 Information flows 3.2.1.1 Data flow diagram 1 3.2.1.1.1 Data entities 3.2.1.1.2 Pertinent processes 3.2.1.1.3 Topology 3.2.1.2 Data flow diagram 2 3.2.1.2.1 Data entities 3.2.1.2.2 Pertinent processes 3.2.1.2.3 Topology .... 3.2.1.n Data flow diagram n 3.2.1.n.1 Data entities 3.2.1.n.2 Pertinent processes 3.2.1.n.3 Topology 3.2.2 Process descriptions 3.2.2.1 Process 1 3.2.2.1.1 Input data entities 3.2.2.1.2 Algorithm or formula of process 3.2.2.1.3 Affected data entities 3.2.2.2 Process 2 3.2.2.2.1 Input data entities 3.2.2.2.2 Algorithm or formula of process 3.2.2.2.3 Affected data entities .... 3.2.2.m Process m 3.2.2.m.1 Input data entities 3.2.2.m.2 Algorithm or formula of process 3.2.2.m.3 Affected data entities 3.2.3 Data construct specifications 3.2.3.1 Construct 1 3.2.3.1.1 Record type 3.2.3.1.2 Constituent fields 3.2.3.2 Construct 2 3.2.3.2.1 Record type 3.2.3.2.2 Constituent fields .... 3.2.3.p Construct p 3.2.3.p.1 Record type 3.2.3.p.2 Constituent fields 3.2.4 Data dictionary 3.2.4.1 Data element 1 3.2.4.1.1 Name 3.2.4.1.2 Representation 3.2.4.1.3 Units/Format 3.2.4.1.4 Precision/Accuracy 3.2.4.1.5 Range 3.2.4.2 Data element 2 3.2.4.2.1 Name 3.2.4.2.2 Representation 3.2.4.2.3 Units/Format 3.2.4.2.4 Precision/Accuracy 3.2.4.2.5 Range .... 3.2.4.q Data element q 3.2.4.q.1 Name 3.2.4.q.2 Representation 3.2.4.q.3 Units/Format 3.2.4.q.4 Precision/Accuracy 3.2.4.q.5 Range 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements ``` ### A.8 Template of SRS Section 3 showing multiple organizations ``` 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2.1 User class 1 3.2.1.1 Feature 1.1 3.2.1.1.1 Introduction/Purpose of feature 3.2.1.1.2 Stimulus/Response sequence 3.2.1.1.3 Associated functional requirements 3.2.1.2 Feature 1.2 3.2.1.2.1 Introduction/Purpose of feature 3.2.1.2.2 Stimulus/Response sequence 3.2.1.2.3 Associated functional requirements .... 3.2.1.m Feature 1.m 3.2.1.m.1 Introduction/Purpose of feature 3.2.1.m.2 Stimulus/Response sequence 3.2.1.m.3 Associated functional requirements 3.2.2 User class 2 .... 3.2.n User class n .... 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements ```