1. Requirements

4.1.2 The project manager shall establish, capture, record, approve, and maintain software requirements, including requirements for COTS, GOTS, MOTS, OSS or reused software components, as part of the technical specification. 

1.1 Notes

The software technical requirements definition process is used to transform the baselined stakeholder expectations into unique, quantitative, and measurable technical software requirements that can be used for defining a design solution for the software end products and related enabling products. This process also includes validation of the requirements to ensure that the requirements are well-formed (clear and unambiguous), complete (agrees with customer and stakeholder needs and expectations), consistent (conflict free), and individually verifiable and traceable to a higher level requirement. Recommended content for a software specification can be found in NASA-HDBK-2203. 

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Requirements are the basis for a software product. They identify the needs to be addressed, the behavior of the system, the desired quality of the software, and the constraints under which the problem is to be solved. They specify the product the provider is to deliver to a customer.  Requirements serve as the basis for verification activities allowing the developing organization and the customer to judge the completeness of the product.

3. Guidance

Software requirements have their basis in customer requirements, system-level parent requirements, and operational concepts. The decomposition of these higher-level requirements and concepts is required to develop and document the requirements for the software. Clearly defined, well-written, and accurately captured requirements reduce "costly redesign, remanufacture, recoding, and retesting in later life-cycle phases." ²⁷³ Well-written requirements also provide "a realistic basis for estimating project costs and can be used to evaluate bids or price estimates" and "provide the stakeholders with a basis for acceptance of the system." ²⁷³

The requirements definition activity provides an understanding of the derived technical requirements baseline, a logical decomposition model, traceability to technical requirements, and an understanding of the stakeholder's expectations.

A general process flow for capturing, approving, and maintaining software requirements is shown below:

According to 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's 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 the 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 buildup of the system. Refer to reputable life-cycle reference documents for further discussion of this type of requirement development.

Requirements identification, development, documentation

Requirements are typically documented in a Software Requirements Specification (SRS) and a Data Dictionary document. Additionally, software interface requirements may be captured in an Interface Control Document (ICD) or an Interface Requirements Document (IRD), along with hardware interface requirements. If an ICD or IRD is used, the SRS references that document. 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 topic 7.18 - Documentation Guidance.

The following roles may be involved in establishing and documenting software requirements, including quality requirements, as appropriate for the project:

• Project stakeholders, including customers and senior management.
• Software Lead.
• Software Requirements Engineer.
• Systems Engineer.
• Software Architects.
• Software Assurance Engineer.

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." ²⁹²

Requirements documentation includes bidirectional traceability through the software life-cycle phases. See guidance in SWE-052 for discussion of requirements traceability.

• Document key decisions and the person(s) who made them, for example:
  • Which requirements are "must-have."
  • Prioritization of requirements.
  • Stakeholder decisions form the basis for requirements.
  • Resolutions to conflicting requirements.
  • High-level design choices that affect low-level requirements.
• Develop requirement rationales, for example:
  • Reasons why one feature or performance requirement was chosen over another.
  • Originating document or basis for a requirement, e.g., operational concepts document, trade study, parent requirement.
  • Stakeholder expectations.
  • Risks which are the basis for a requirement.
  • Technology limitations.
  • Time constraints.
  • Regulations, laws.
• Define assumptions, for example:
  • Environmental or any other constraints.
  • Mission type (e.g., human-rated vs. robotic).
  • Assumed technology availability.
  • Preset budgetary restrictions.
• Logically decompose the requirements.
• Document requirements for COTS, GOTS, MOTS, OSS, or reused software components, as part of the technical specification.

• Notes on decomposition:
• System requirements are general requirements; allocated, flowed down requirements are more detailed as the levels progress.
• Decompose or partition the system into finer and finer (more detailed) elements (into a functional, physical, data-driven, or object-oriented hierarchy); each element in this hierarchy has its requirements that work together to meet the higher-level requirements allocated to that requirement. ¹⁷⁸
• All top-level requirements must be allocated to at least one element at the next level and have at least one flowed down requirement associated with it at that lower level. ¹⁷⁸
• The Software lead works with the Systems lead to identify system requirements that are allocated to the software development effort.
• Examine each top-level requirement to identify the software requirements necessary to accomplish that requirement and fulfill the function it describes.
• After systems engineers allocate system requirements to subsystems, such as the software subsystem, software engineers develop the requirements for those elements.
• Identify input, output, and processing needed to satisfy the high-level requirements using an analysis method focusing on what the software needs to do rather than specific 'how-to' details.
• Decompose requirements into a "set of make-to, buy-to, code-to, and other requirements from which design solutions can be accomplished." ²⁷³
• The lowest level may be the module level for software. ¹⁷⁸
• Typically an iterative process as successive lower-level functional and performance requirements are defined at ever-increasing levels of detail; this can point out additions, changes, deletions that need to occur in parent requirements. ¹⁷⁸
• Iteratively repeat allocation and requirements development (flow-down) at each successively lower level.
• May need to revise parent requirements as new information is obtained at the lower, more detailed levels ¹⁷⁸
• Maintain a link to parent requirement (i.e., lower-level requirements need to support requirements at the next higher level and it may be helpful to document in the rationale what the lower-level requirement does to support the parent requirement).
• Derived requirements will be created during this process; derived requirements are requirements that differ from the parent requirement, but state a capability the lower-level element (subsystem or lower) must have to meet the parent requirement. ¹⁷⁸
• Consider constraints (e.g., cost, standards, regulations).
• Decomposition may be based on or influenced by a project hierarchy for the software subsystem.
• Resolve requirements conflicts.
• Lessons learned from previous decomposition activities may be helpful; the Requirements Engineering  ¹⁷⁸ article also provides a good overview of requirements allocation and flow-down.

Information Sources

Defining software requirements involves eliciting, generating, and analyzing customer, product, and product component requirements. Inputs to this process may include:

• System and subsystem requirements documents, hardware schematics, and specifications.
• System architecture.
• System models and simulations.
• System safety analyses, including the preliminary hazard analysis (PHA), subsequent system hazard analyses, and software safety analyses.
• Environmental requirements, including operations and hardware requirements, vehicle, or facility requirements.
• Standards.
• External regulations.
• Program/project specification.
• Operational concepts document.
• Interface requirements.
• Legacy products.
• Organizational requirements.
• Quality attributes (e.g., reliability, availability, security, safety, maintainability, portability, usability).
• Structured interviews with customers, users (may include the development of scenarios, the examination of reports, analysis of competing products), other subsystem engineers (e.g., electrical/electronic and data; thermal; Guidance, Navigation, and Control (GN&C); mechanical).
• Brainstorming sessions with customers, users, developers.
• Stakeholder input or user needs (provided or elicited via interviews, prototypes, questionnaires, surveys, or other techniques).

General Guidance
Some general guidelines to follow when establishing and documenting software requirements includes:

• Provide a unique identifier for each requirement.
• Express requirements as "shall" statements (avoiding words like "could," "should," "must," and "will").
• Identify software safety requirements.
• Structure requirements so they are:
  

  • Complete, correct, consistent.

  • Traceable.

  • Independent.

  • Unambiguous. Remove any ambiguity.

  • Modifiable.

  • Understandable.

  • Necessary.

  • Measurable. Make the detailed software requirements measurable.

  • Quantitative.

  • Make the software requirements finite, establish limits or bounds in the requirement.
  • Testable.
  • Maintainable.

  • Feasible.

• Refine the initial set of requirements into a manageable set (e.g., remove duplicates, remove unnecessary requirements, combine requirements, clarify requirements, keep "must-haves", drop some "nice-to-haves").
• Have requirements reviewed by stakeholders (to identify and address ambiguous, conflicting, incomplete requirements; peer reviews/inspections is one technique).
• Capture software requirements in the required documents and a requirements management tool for easy access, manipulation, and management; some tools may allow for the generation of the requirements documents directly from the tool.
• State the requirements, not how to fulfill them.
• State only one requirement per statement (i.e., avoid compound requirements). Use short, direct, complete sentences.
• Make requirements internally and externally consistent
• Define a testing strategy for each requirement as soon as it's specified

Common Problems

Establishing and documenting requirements is not a simple task. According to Kandt, Ronald Kirk, Jet Propulsion Lab, "Software Quality Improvement, Software Requirements Engineering: Practices and Techniques", (JPL Document D-24994, 2003) ⁰⁶¹, common problems that occur during or because of this activity and which are to be avoided, include:

• Failing to define needed requirements, including safety requirements.
• Writing requirements inconsistently or ambiguously.
• Using inexperienced personnel to define the requirements.
• Incorrect understanding of underlying assumptions or constraints.
• Including unneeded features or capabilities.
• No clear method for allocating requirements to software subsystems.
• Choosing solutions before defining the requirements and/or user needs.
• Failing to spend enough time or resources on requirements definition.

Guidance for baselining and updating the SRS in preparation for life-cycle milestone reviews can be found in topic 7.08 - Maturity of Life-Cycle Products at Milestone Reviews in this Handbook.

Requirements approval

Requirements review and approval is necessary to ensure that they accurately capture user needs and project goals and objectives.  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 the 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 (SwRR),  a Technical Exchange Meeting (TIM), or both, is conducted; if both are performed, the TIM should precede the SwRR.

Changes from any of these reviews or approval processes should be 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

Maintenance of software requirements is needed because they typically change throughout the project based on information and experiences obtained during the project life cycle.

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 changes throughout the project and guidance for SWE-054 addresses correcting inconsistencies among requirements and project products.

Requirements must 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  ²⁷³

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

NASA-specific software requirements process information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. 

Additional guidance related to documenting, analyzing, and maintaining software requirements may be found in topic 7.18 - Documentation Guidance and the following related requirements in this Handbook:

4. Small Projects

"Any project with resource limitations must establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project management plan for staged releases, make trade-off decisions, and respond to requests for adding more functionality. It can also help you avoid the traumatic 'rapid de-scoping phase' late in the project when you start throwing features overboard to get a product out the door on time."  ³⁵⁸

Additional guidance specific to small projects may be found in the following related requirements in this Handbook:

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA 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 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."
• Flight Software Engineering Lessons (Developing a complete set of requirements.) Lesson Number 2218 ⁵⁷²: Recommendation No. 7 states: "Development of a complete and consistent set of engineering requirements requires a robust systems engineering process that defines performance and resource utilization requirements, traces requirements to higher and lower-level requirements, ensures review of requirements by key stakeholders and by parties independent of the engineering of the requirements, and assesses the requirements using a checklist of questions that address quality concerns." 
• Lessons Learned From Flights of "Off the Shelf" Aviation Navigation Units on the Space Shuttle, GPS (COTS/GOTS/MOTS software.) Lesson Number 1370 ⁵⁵¹: "Define 'must meet,' 'highly desirable' and 'nice to have' requirements. The ability of the unit to meet those requirements, and at what cost, will be a major deciding factor in the COTS decision." 
• Probable Scenario for Mars Polar Lander Mission Loss (1998) (Include hardware requirements.) Lesson Number 0938 ⁵²⁹: As part of the probable scenario for Mars Polar Lander Mission Loss, a lesson learned was that "All known hardware operational characteristics, including transients and spurious signals, must be reflected in the software requirements documents and verified by test."
• Chandra X-ray Observatory (CXO) Development Program Programmatic "Lessons Learned" (Stable requirements key to program stability.) Lesson Number 0987 ⁵³¹: A lesson learned was that "Stable Requirements are key to program stability. Do not allow requirements to creep. One step in this process is to involve all stakeholders in developing and finalizing requirements. Stakeholders may include potential development and operations contractors, engineering and other organizations, and NASA Headquarters." One recommendation is to "Include operations in requirements definition and early design...Do not overlook the need for strong systems engineering involvement in requirements and verification traceability."

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Confirm that all software requirements are established, captured, and documented as part of the technical specification, including requirements for COTS, GOTS, MOTS, OSS, or reused software components. 

7.2 Software Assurance Products

• The results of the independent SA analysis performed on the detailed software requirements, including any corrective actions.

Note: Independent SA requirements analysis techniques are detailed in Topic 8.16, including Software Requirements Analysis on the Detailed Software Requirements. 

7.3 Metrics

• # of Software Requirements (e.g. Project, Application, Subsystem, System, etc.)
• # of Software Requirements that do not trace to a parent requirement   
• # of detailed software requirements vs. # of estimated SLOC to be developed by the project

7.4 Guidance

Software assurance and software safety perform an independent SA analysis on the detailed software requirements as they are developed.  Use the guidelines in the Software Requirements Analysis.

Make sure that the detailed software requirements include or point to requirements for COTS, GOTS, MOTS, OSS, or reused software components that are part of the software.  An example is the detailed software requirements for functions done by a real-time operating system that should be captured in the detailed software requirements.  

NASA Missions go through a logical decomposition in defining their requirements. Requirements analysis addresses a system’s software requirements including analysis of the functional and performance requirements, hardware requirements, interfaces external to the software, and requirements for qualification, quality, safety, security, dependability, human interfaces, data definitions, user requirements, installation, acceptance, user operation, and user maintenance.  

When evaluating the software requirements, consider the list of items below:

1. Is the approach to requirements decomposition reasonable, appropriate, and consistent?
2. Are the system’s software requirements both individually and in aggregate of high quality (correct, consistent, complete, accurate, unambiguous, and verifiable)?
3. Will requirements adequately meet the needs of the system and expectations of its customers and users?
4. Do requirements consider the operational environment under nominal and off-nominal conditions? Specifically:

• • Do the requirements specify what the system is supposed to do?
  • Do requirements guard against what the system is not supposed to do?
  • Do the requirements describe how the software responds under adverse conditions?

1. Is this requirement necessary?
2. Are the requirements understandable?
3. Are the requirements unnecessarily complicated?
4. Has system performance been captured as part of the requirements?
5. Are the system boundaries (or perhaps operational environment) well defined?
6. Is a requirement realistic given the current technology?
7. Is the requirement singular in nature, or could it be broken down into several requirements? (looking at grammar not whether it can be decomposed or not)
8. Within each requirement level, are requirements at an appropriate and consistent level of abstraction?
9. In traceability, is the parent requirements represented in the appropriate child requirements?
10. Do the software requirements include requirements for COTS, GOTS, MOTS, OSS, or reused software components, as part of the technical specification
11. Do the parent requirements include outside sources such as:

• • Hardware specifications
  • Computer\Processor\Programmable Logic Device specifications
  • Hardware interfaces
  • Operating system requirements and board support packages
  • Data\File definitions and interfaces
  • Communication interfaces including bus communications Software interfaces
  • Derived from Domain Analysis
  • Fault Detection, Isolation and Recovery requirements
  • Models
  • Commercial Software interfaces and functional requirements
  • Software Security Requirements
  • User Interface Requirements
  • Algorithms
  • Legacy or Reuse software requirements
  • Derived from Operational Analysis
  • Prototyping activities
  • Interviews
  • Surveys
  • Questionnaires
  • Brainstorming
  • Observation
  • Software Test Requirements
  • Software Fault Management Requirements
  • Hazard Analysis
  • COTS, GOTS, MOTS, OSS or reused software components, as part of the technical specification

     11. Does the Software Requirements Specification contain the following information:

• • System overview.
  • CSCI requirements:
    • Functional requirements.
    • Required states and modes.
    • External interface requirements.
    • Internal interface requirements.
    • Internal data requirements.
    • Adaptation requirements (data used to adapt a program to a given installation site or given conditions in its operational environment).
    • Safety requirements.
    • Performance and timing requirements.
    • Security and privacy requirements.
    • Environment requirements.
    • Computer resource requirements:
      • Computer hardware resource requirements, including utilization requirements.
      • Computer software requirements.
      • Computer communications requirements.
    • Software quality characteristics.
    • Design and implementation constraints.
    • Personnel-related requirements.
    • Training-related requirements.
    • Logistics-related requirements.
    • Precedence and criticality of requirements.
    • FDIR requirements for system, hardware, and software failures
    • Software State transitions, state diagrams
    • Assumptions for design and operations are documented

Other considerations: 

1. Are there qualification provisions (e.g., demonstration, test, analysis, inspection)?
2. Has the bidirectional requirements traceability been done?
3. Are requirements partitioned for phased delivery?
4. Are there testing requirements that drive software design decisions (e.g., special system-level timing requirements/checkpoint restart)?
5. Is there a rationale for supporting requirements?
6. Is there bidirectional traceability between parent requirements, requirements, and preliminary design components?
7. Do the detailed software requirements trace to a reasonable number of parent requirements? (e.g., does the ratio between detail requirements and parent requirements look reasonable, do all of the software detail requirements trace to too few parent requirements (inadequate system requirement definitions)).
8. Are trace links of high quality (e.g., avoidance of widows and orphans, circular traces, traces within a requirements level, etc.)?
9. Have high-risk behaviors or functions been identified, and does SA agree with the identified behaviors? This should result in a list of critical activities to be performed by software and analyzed further by software assurance.
10. For critical activities, are associated requirements correct and complete against SA understanding of the system behavior? Note: consider additional analysis rigor to address critical activities.
11. Are interface requirements with the hardware, users, operators, or other systems adequate to meet the needs of the system concerning expectations of its customer and users, the operational environment, safety and fault tolerance, and both functional and non-functional perspectives?
12. Has a fault tolerance strategy for fault detection, identification, and recovery (FDIR) from faults been provided, and is it reasonable?
13. Is the role of software as part of the FDIR understood?
14. Are software-related activities associated with the fault tolerance strategy for fault detection and identification and recovery captured as requirements?
15. Is human safety addressed through the requirements?
16. Have hazards and hazard causes been adequately identified, with associated software detection and mitigations captured as requirements?
17. Are must-work and must-not-work requirements understood and specified?
18. Have requirements addressed the security threats and risks identified within the system concept specifications and the system security concept of operations (e.g., System Security Plan)
19. Do requirements define appropriate security controls to the system and software?
20. Can the requirement(s) be efficiently and practically tested?
21. Do the requirements address the configuration of, and any associated constraints, associated with COTS, GOTS, MOTS, and Open Source software?
22. Do the requirements appropriately address operational constraints?
23. Does the requirement conflict with domain constraints, system constraints, policies, or regulations (local and governmental)?
24. Have users/operators been consulted during requirements development to identify any potential operational issues?
25. Have the software requirements been peer-reviewed?

Consider if the requirements being analyzed are SMART requirements “specific, measurable, attainable (achievable/actionable/appropriate), realistic, time-bound (timely, traceable)”.

To confirm that the software requirements satisfy the conditions in SWE-051 make sure that the flowed-down and derived requirements are from the top-level systems engineering requirements, safety and reliability analyses, and the hardware specifications and design.

Software safety personnel need to be involved in the analysis of software requirements to determine their safety criticality. Any software requirements that trace are determined to have safety implications. Those requirements with safety implications are tracked as "safety-critical."