1. Requirements

3.1.1.2 The project shall identify, develop, document, approve, and maintain software requirements based on analysis of customer and other stakeholder requirements and the operational concepts.

1.1 Notes

NPR 7150.2,  NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

2. Rationale

Software requirements have their basis in customer requirements, system level parent requirements and operational concepts.  Decomposition of these higher-level requirements and concepts is required to develop and document the requirements for software (see the SWE-049 section of this Handbook for decomposition guidance).  Once the team identifies and documents software requirements, review and approval is necessary to ensure that they accurately capture user needs and project goals and objectives. Maintenance of software requirements is needed because they typically change (SWE-053)  throughout the project based on information and experiences obtained during the project life cycle.

3. Guidance

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.

Requirements approval

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.

Requirements maintenance

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.

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." ²⁷³

Additional guidance related to documenting, analyzing, and maintaining software requirements may be found in the following related requirements in this handbook:

4. Small Projects

Guidance specific to small projects may be found in the following related requirements in this handbook:

5. Resources

6. Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to software requirements identification, development, documentation, approval, and maintenance based on analysis of customer and other stakeholder requirements and the operational concepts:

• Software Requirements Management (Customer role in requirements definition.) Lesson Number 3377: One lesson learned is that "Additionally, a collaborative relationship between the customer using the software and the developer providing the software is paramount to the success of the software project. More specifically, the users/customers must effectively define and accurately communicate their requirements to the developer. For example, the user's defined requirements should be clearly stated and unambiguous, concise, complete, autonomous, able to be implemented, and testable." ⁵⁷⁶
• The Pitfalls of "Engineering-by-Presentation" (2005) (Formal requirements documentation.) Lesson Number 1715:  The Abstract (in part) states: "Formal documentation of requirements, resolutions, and decisions -- including maintaining records of the basis and justification for each engineering decision -- was once a standard NASA practice. The increased use of informal records such as presentation slides and e-mail may be inhibiting the ability of NASA programs and projects to reference technical decisions and to validate or verify engineering designs." ⁵⁶⁶
• Risk Assessment in Software Development Projects (Uncertainty caused by changing requirements.) Lesson Number 1321:  The Description of Driving Event states: "Even with expert and experienced programmers, each new software program presents new technical challenges. Changing methodology and requirements during the design phase of a software project adds uncertainty to the project." ⁵⁴⁹