A general process flow for capturing and maintaining software requirements is shown below:
According the NASA Systems Engineering Handbook, requirements "...are decomposed in a hierarchical structure starting with the highest level requirements imposed by Presidential directives, mission directorates, program, Agency, and customer and other stakeholders. These high-level requirements are decomposed into functional and performance requirements and allocated across the system. These are then further decomposed and allocated among the elements and subsystems. This decomposition and allocation process continues until a complete set of design-to requirements is achieved. At each level of decomposition (system, subsystem, component, etc.), the total set of derived requirements must be validated against the stakeholder expectations or higher level parent requirements before proceeding to the next level of decomposition. The traceability of requirements to the lowest level ensures that each requirement is necessary to meet the stakeholder expectations. Requirements that are not allocated to lower levels or are not implemented at a lower level result in a design that does not meet objectives and is, therefore, not valid. Conversely, lower level requirements that are not traceable to higher level requirements result in an overdesign that is not justified." The figure below from the NASA Systems Engineering Handbook illustrates this hierarchical flow down.
The flow down of requirements
This flow addresses requirements development via the nominal system flow down process. However, software requirements can also be developed/matured with the system (i.e., in spiral/incremental/agile fashion), especially when software plays a key role in the integration and build up of the system. Refer to reputable life-cycle reference documents (see also SWE-019) for further discussion of this type of requirements development.
Requirements identification, development, documentation
Requirements are typically documented (SWE-049) in a Software Requirements Specification (SRS) (SWE-109) and a Data Dictionary document (SWE-110). Additionally, software interface requirements may be captured in an Interface Control Document (ICD) or an Interface Requirements Document (IRD), along with hardware interface requirements. Guidance for the content and development of these documents, including requirements identification and development based on operational concepts and customer and stakeholder requirements, is located in other parts of this Handbook. That guidance can be found by following the links included above.
Projects that use modeling and simulation as part of the development process may choose to develop and document requirements using models or both text and models. Requirements captured as "text descriptions cannot be computer interpreted because they are in natural language text. They will remain ambiguous because natural language is not precise. The use of models augments the text forms by providing computer executable and transformable information that is free from ambiguity and needed by the engineers who will design according to the specifications."
Additionally, requirements documentation includes bidirectional traceability through the software life cycle phases. See guidance for SWE-052, SWE-059, SWE-064, and SWE-072 for discussion of requirements traceability.
Once requirements are identified, developed, and documented, they are evaluated, analyzed (SWE-051) and approved in light of stakeholder requirements and operational concepts by one or more of the following, based on project procedures:
- Project management: Approves formalized requirements (as documented in the SRS, Data Dictionary, and/or ICD, IRD).
- Customer/Stakeholders: Approve formalized requirements.
- Systems engineering: Reviews software requirements under direction of project management.
- Software assurance: Audits the requirements document(s) against software assurance requirements.
- Review board: A milestone review, such as the Software Requirements Review (SRR), a Technical Exchange Meeting (TIM) or both, is conducted; if both are performed, the TIM precedes the SRR.
Changes from any of these reviews or approval processes are incorporated into the software requirements before they proceed to the next step in the project life cycle. Approved requirements are baselined and maintained in the project's configuration management system.
Managing requirements change is a critical aspect of requirements maintenance because changes to requirements can be an indicator of software instability and often mean increased costs, longer schedules, rework and can affect software safety. Guidance for SWE-053 addresses managing requirements change throughout the project and guidance for SWE-054 addresses correcting inconsistencies among requirements and project products.
It is important that requirements be updated in the requirements management tool (if one is used) as well as the requirements documents (e.g., SRS, Data Dictionary, ICD, IRD). Those updated requirements are made available to all stakeholders, including developers, testers, managers, and anyone else making decisions or performing work based on software requirements.
Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to software requirements identification, development, documentation, approval, and maintenance based on analysis of customer and other stakeholder requirements and the operational concepts.
Benefits of Well-Written Requirements
Recommended practice is to include a rationale with each requirement or group of requirements. "The rationale should be kept up to date and include the following information:
- "Reason for the Requirement: Often the reason for the requirement is not obvious, and it may be lost if not recorded as the requirement is being documented. The reason may point to a constraint or concept of operations. If there is a clear parent requirement or trade study that explains the reason, then reference it.
- "Document Assumptions: If a requirement was written assuming the completion of a technology development program or a successful technology mission, document the assumption.
- "Document Relationships: The relationships with the product's expected operations (e.g., expectations about how stakeholders will use a product). This may be done with a link to the Concept of Operations (ConOps).
- "Document Design Constraints: Imposed by the results from decisions made as the design evolves. If the requirement states a method of implementation, the rationale should state why the decision was made to limit the solution to this one method of implementation."
"The requirements database is an extremely useful tool for capturing the requirements and the associated metadata and for showing the bidirectional traceability between requirements. The database evolves over time and could be used for tracking status information related to requirements such as To Be Determined (TBD)/To Be Resolved (TBR) status, resolution date, and verification status. Each project should decide what metadata will be captured. The database is usually in a central location that is made available to the entire project team."
Additional guidance related to documenting, analyzing, and maintaining software requirements may be found in the following related requirements in this handbook:
Document Software Requirements
Software Requirements Analysis
Bidirectional Traceability Between Higher Level Requirements and Software
Manage Requirements Changes
Corrective Action for Inconsistencies
Software Requirements Specification