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 by the software, its functionality and behavior within the system where it executes, the desired quality of the software, and the constraints under which the request 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 assess the completeness and acceptability of the product.

3. Guidance

3.1 Requirements Definition

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 a common understanding of the derived technical requirements, a logical decomposition model, traceability to technical requirements, and an understanding of the stakeholder's expectations.

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 this NASA-HDBK-2203 under Topic 7.18 - Documentation Guidance.

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

Requirements are allocated or derived.

Allocated requirements: A requirement that is established by analyzing and decomposing a high-level requirement into multiple lower-level requirements.

Derived Requirements: Requirements arising from constraints, consideration of issues implied but not explicitly stated in the high-level direction provided by NASA Headquarters and Center institutional requirements, factors introduced by the selected architecture, and the design. These requirements are finalized through requirements analysis as part of the overall systems engineering process and become part of the program or project requirements baseline. (NASA/SP-2016-6105)

3.2 Requirements Decomposition and Flowdown

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, programs, NASA Agency, customers, 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 allocated and 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 can result in a design that does not meet objectives/expectations and is, therefore, not valid. Conversely, lower-level requirements that are not traceable to higher-level requirements may result in an overdesign that is not justified (i.e., the term “gold plating”).   The figure below from the NASA Systems Engineering Handbook illustrates this hierarchical flow down.

NASA/SP-2016-6105: NASA Systems Engineering Handbook - FIGURE 4.2-3 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 a spiral/incremental/agile fashion), especially when software plays a key role in the integration and buildup of the system. 

Tips for the decomposition of requirements – Figure # below illustrates some of the concepts presented here:

• 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.  ¹⁷⁸
• 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 identifying 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, and 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; SEI’s Requirements Engineering ¹⁷⁸ article also provides a good overview of requirements allocation and flow down.

Figure #: Requirements Decomposition Process

3.3 Requirements identification, development, documentation

Requirements are typically documented in a Software Requirements Specification (SRS) and a Software Data Dictionary (SDD) document. Additionally, software interface requirements may be captured in an Interface Control Document (ICD) or an Interface Design Document (IDD), along with hardware interface requirements. If an ICD or IDD 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.

• 5.09 - SRS - Software Requirements Specification
• 5.07 - SDD - Software Data Dictionary
• 5.02 - IDD - Interface Design Description

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

Note: For small projects, an engineer or software developer may fulfill multiple roles.

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. 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 - Bidirectional Traceability for a 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 that form the basis for requirements.
  • Resolutions to conflicting requirements.
  • How High-level design choices affect low-level requirements.
• Develop and document 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 that are the basis for a requirement.
  • Technology limitations.
  • Time constraints.
  • Regulations and laws.
• Define assumptions and limitations, for example:
  • Environmental or any other constraints (e.g., O/S – Unix/Linux vs PC, endianness)
  • Mission type (e.g., human-rated vs. robotic).
  • Assumed technology availability (e.g., hardware – PLDs, PC; O/S; programming language; simulators)
  • Preset budgetary restrictions and schedule constraints.
• Logically decompose the requirements.
• Document requirements for COTS, GOTS, MOTS, OSS, or reused software components, as part of the technical specification.

3.4 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).
• Stakeholder input or user needs (provided or elicited via interviews, brainstorming sessions, prototypes, questionnaires, surveys, or other techniques).
  • Structured interviews with customers, users, and other subsystem engineers (e.g., electrical/electronic and data; thermal; Guidance, Navigation, and Control (GN&C); mechanical). may include the development of scenarios, the examination of reports, and analysis of competing products.

See also Topic 7.15 - Relationship Between NPR 7150.2 and NASA-STD-7009

3.5 General Guidance

Some general guidelines to follow when establishing and documenting software requirements include:

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

• • Complete, correct, and consistent
  • Traceable
  • Independent
  • Unambiguous
  • Modifiable
  • Understandable
  • Necessary
  • Measurable
  • Quantitative
  • 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", and drop some "nice-to-haves").
• Have requirements reviewed by stakeholders (to identify and address ambiguous, conflicting, incomplete requirements; peer reviews/inspections are one technique that can be used for this purpose).
• Capture software requirements in the required documents and a requirements management tool for easy access, modification, 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 is specified.

See also SWE-207 - Secure Coding Practices, SWE-157 - Protect Against Unauthorized Access, 

See also PAT-013 - Software Requirements Checklist, 

3.6 Common Problems

To help detect and avoid some of these common problems, there are tools available to aid in the detection of requirements quality issues. One such tool that NASA has acquired licensing for is QVScribe. QVScribe analyzes the requirements (Word, Excel, or Doors) and provides feedback to the user on their quality. Access to QVScribe is available via a NAMS request.

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.

3.7 Benefits of Well-Written Requirements

A well-written requirements document provides several specific benefits to both the stakeholders and the technical team as shown in TABLE 4.2-1 from NASA SP-2016-6105 Rev2: Systems Engineering Handbook. 

3.8 Requirements Metadata

It is useful to capture information about each of the requirements, called metadata, for future reference and use. Many requirements management tools will request or have options for storing this type of information. TABLE 4.2-2 from NASA SP-2016-6105 Rev2: Systems Engineering Handbook provides examples of the types of metadata that may be useful.

Recommended practice is to include a rationale for each requirement or group of requirements. The rationale should be captured to ensure the reason and context of the requirement is understood. The following reasoning was captured from NASA SP-2016-6105 Rev2: Systems Engineering Handbook:

A requirements database (e.g., DOORS) 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. For small projects, an acceptable alternative would be to use a spreadsheet.

3.9 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 - Software Requirements Analysis), 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.
• Customer/Stakeholders: Approve formalized requirements.
• Systems engineering: Reviews software requirements under the direction of project management.
• Software Assurance: Analyzes the requirements and assesses their quality, and audits the requirements document(s) against software engineering 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 work product 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. The approved requirements establish the agreement between the developing organization and customer on what the software must do when it is delivered.

See also PAT-034 - SAANALYSIS Checklist, 

3.10 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 - Manage Requirements Changes addresses managing requirements changes throughout the project and guidance for SWE-054 - Corrective Action for Inconsistencies 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). 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.

3.11 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.12 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

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."  ³⁵⁸

For small projects, an engineer or software developer may fulfill multiple roles. The assignment of the specific roles is at the discretion of the Project Manager.

Also, for small projects, it may be advantageous to combine the software engineering work products into a single document to eliminate the overhead associated with generating multiple documents.  However, the document sections would still need to cover the recommended content (Topic 7.18 - Documentation Guidance) for each required document type. A simple document may be used in lieu of database system such as DOORS.

A 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. For small projects, an acceptable alternative to a database would be to use an Excel spreadsheet or Word file.

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

5.3 Process Asset Templates

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

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 8.54 - 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

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Software Assurance and software safety perform an independent SA analysis of the detailed software requirements as they are developed.  Use the guidelines in Topic 8.16, 8.54 - Software Requirements Analysis. (See tab 2, SW Requirements Analysis Techniques.)

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 system.  

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, use the list of items in the SA Requirements Analysis Checklist. ^PAT-034:

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 - Software Requirements Analysis 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."

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: