IEEE standards documents are developed within the IEEE Societies and Standards Coordinating Committees of the Standards Committee of the IEEE Standards Association (IEEE-SA). The existence of an IEEE standard does not mean that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE standard. A careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle, when these problems are easier to correct.
The description of the product to be developed, as given in the SRS, is a realistic basis for project cost estimation and can be used to obtain approval for bids or price estimates. As part of the development contract, the SRS provides a baseline against which compliance can be measured. Because the SRS addresses the product, not the project that developed it, the SRS serves as a basis for later improvement of the finished product.
This recommended practice was prepared by the Lifecycle Data Harmonization Working Group of the Software Engineering Standards Committee of the IEEE Computer Society.
Overview
Scope
The SRS may be written by one or more representatives of the supplier, one or more representatives of the customer, or both. It is important to consider the part that SRS plays in the total project plan, which is defined in IEEE Std. Since SRS has a special role to play in the software development process, the SRS writer(s) must be careful not to overstep the bounds of that role.
The SRS should be compared to any applicable higher specification, such as the system requirements specification, other project documentation, and other applicable standards to ensure agreement. Alternatively, the customer or user can determine whether the SRS correctly responds to current needs. The SRS should be unambiguous to both those who create it and those who use it.
Each claim in the SRS should be identified to make these distinctions clear and distinct. Whenever redundancy is needed, the SRS should include clear cross-references to make it editable. This depends on each request in the SRS having a unique name or reference number.
The forward traceability of the SRS is particularly important when the software product enters the operation and maintenance phase. Additional changes may occur as defects, deficiencies and inaccuracies in the SRS are discovered. Approved changes in requirements must be incorporated into the SRS in such a way as to 1) provide an accurate and complete audit trail of changes;.
The customer may be more likely to see and respond to the prototype than to read and respond to the SRS. The SRS writer(s) must clearly distinguish between identifying required design constraints and projecting a specific design. 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 conditions regarding the production of software and should therefore not be included in the SRS.
Definitions
Considerations for producing a good SRS
- 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
An SRS is a specification for a particular software product, program or set of programs that performs certain functions in a specific environment. The software may contain essentially all of the functionality of the project or may be part of a larger system. Other standards, such as those listed in point 2, relate to other parts of the software life cycle and thus may meet software requirements.
An SRS is an important part of the software life cycle requirements process and is used in design, implementation, project monitoring, verification and validation, and training as described in IEEE Std 1074-1997. One way to avoid the ambiguity inherent in natural language is to write the SRS in a special requirements specification language. The extent to which such tools and methods can be useful in preparing an SRS depends on the size and complexity of the program.
Let developers make correct design decisions and devote appropriate levels of effort to the various parts of the software product. For example, a requirement can only be changed in one of the places where it appears. The SRS must specify which functions should be performed on which data to produce which results in which location for whom.
The parts of an SRS
Introduction (Section 1 of the SRS)
Be consistent with similar statements in higher-level specifications (eg, the system requirements specification) if they exist. This subsection should include the definitions of all terms, acronyms, and abbreviations necessary to properly interpret the SRS. This information can be provided by reference to one or more annexes in the SRS or by reference to other documents. a) Provide a complete list of all documents referred to elsewhere in the SRS.
This information may be provided by reference to an appendix or to another document. a) Describe what the rest of the SRS contains;
Overall description (Section 2 of the SRS)
This should list each system interface and identify the functionality of the software to meet the system requirement and interface description that matches the system. This should specify the logical characteristics of each interface between the software product and the hardware components of the system. This subsection of the SRS should provide an overview of the main functions that the software will perform.
This subsection of the SRS should describe the general characteristics of the intended users of the product, including education level, experience and technical expertise. It should not be used to specify specific requirements, but rather should indicate the reasons why certain specific requirements are later specified in Section 3 of the SRS. This subsection of the SRS should provide a general description of all other elements that will limit the developer's options.
This subsection of the SRS must list each of the factors that affect the requirements stated in the SRS. This subsection of the SRS should identify requirements that may be delayed until future versions of the system. This section of the SRS should contain all software requirements at a level of detail sufficient to enable designers to design a system to meet those requirements and testers to test whether the system meets those requirements.
This should specify the factors necessary to establish the required reliability of the software system at the time of delivery. This should define the attributes of the software that relate to the ease of maintenance of the software itself. Different classes of systems are suitable for different organizations of the requirements in Section 3 of the SRS.
Some systems are best organized by describing all the functions that support the generation of a response. When considering a new SRS, more than one of the organizational techniques given in 5.3.7.7 may be appropriate. In such cases, organize the specific requirements into multiple hierarchies tailored to the specific needs of the system under specification.
Any additional requirements can be included in a separate chapter at the end of the SRS. Where attachments are included, the SRS should explicitly state whether or not the attachments should be considered part of the requirements. The Software Engineering Standards Committee (SESC) of the IEEE Computer Society has endorsed the policy of adopting international standards.
Specific requirements (Section 3 of the SRS)
Supporting information
Both this recommended practice and IEEE/EIA have similar semantics for the key terms of software, requirements, specification, vendor, developer, and maintainer. IEEE/EIA uses a process-oriented approach to describe the definition of a set of requirements for software. This recommended practice uses a product-oriented approach, where the product is a Software Requirements Description (SRD).
The difference is that this recommended practice is focused on software requirements development, while IEEE/EIA provides an overall life cycle view and mentions Software Requirements Analysis as part of its development process. This recommended practice provides a greater level of detail about what is involved in preparing an SRD. IEEE/EIA takes the view that the software requirements are derived from the system requirements.
This clause provides details regarding the claim that an SRS conforming to this recommended practice would also achieve Òdocument conformanceÓ with the SRD described in IEEE/EIA. Document conformance requirements are summarized in one line of IEEE/EIA Table 1. Ñ B.3.2 addresses compliance with the generic content guideline (the "type" of the document) listed in column 3 of Table B.1 as the "description". General guidelines on the content of the ÒdescriptionÓ are shown in 5.1 IEEE/EIA.
Ñ B.3.3 addresses compliance with the specific requirements for the description of software requirements listed in column 4 of Table B.1 as prescribed in IEEE/EIA 6.22. Any IEEE/EIA compliant description or specification must meet the general content requirements specified in 5.1.2 of this standard. Subclause 6.22.1 IEEE/EIA: Purpose: Specify the requirements for an item of software and the methods to be used to ensure that each requirement is met.
An SRS that adheres to this recommended practice and meets the additional requirements in Table B.3 of this recommended practice would achieve the stated purpose. An SRD specified in accordance with the requirements stated or referenced in Table B.3 of this Recommended Practice shall be evaluated taking into account the criteria in 5.3.4.2 of IEEE/EIA a) Generic description information See Table B.2 Ñ. In addition to the content requirements, lifecycle data must be managed in accordance with the objectives of Appendix H of the IEEE/EIA.
The analysis indicates that any SRS that complies with this recommended practice and the additions shown in Table B.2 and Table B.3 also meets the requirements of an SRD in IEEE/EIA.
