1. Introduction

The Software Requirements Analysis product focuses on analyzing the software requirements that have been developed from the system requirements. This topic describes some of the methods and techniques Software Assurance and Software Safety personnel may use to evaluate the quality of the software requirements that were developed.

The software requirements process begins with a good understanding of the operational concept, system architecture, and system design. From there, software engineering can begin to derive the requirements for the application, component, feature, etc.

Since the software requirements provide the roadmap for software engineering to build a correct, robust software system/application that meets or exceeds the operational needs of the system, it is key that the requirements adequately reflect what is being requested. It is the role of the Software Assurance and Software Safety (if applicable) Teams to ensure the documented set of requirements is the “best set” of requirements that can be defined by performing a software requirements analysis.

During the software requirements analysis activity, all aspects of the requirements are examined carefully to determine if any improvements are needed before design and implementation begin. There are many tools and techniques that may be used to perform a thorough analysis of the requirements and these are discussed on the various tabs of this topic. NPR 7150.2⁰⁸³  and NASA-STD-8739.8²⁷⁸ require some specific methods be used for the analysis. Those are listed in the table below.

Many other techniques are available and aid in locating various types of requirements problems. The Software Engineering, Software Assurance, and Software Safety teams should use some of those techniques/methods to supplement the required methods by choosing any of the techniques listed that would benefit their project. Note: Safety Analysis during the requirements development phase is an important part of the requirements analysis for safety-critical systems and as such, it is included in this topic (see tab 3.) Each team performs the required SWEs or SA/Safety activities and then should choose other listed techniques/methods that would help the team do a more thorough job of analyzing the requirements. The results of the analysis and the techniques/methods used are documented in a Software Requirements Analysis Report (including the Software Safety Requirements Analysis).

For safety-critical software, the requirements portion of the Software Safety Analysis should be done in conjunction with the Software Requirements Analysis. See tab 3. Safety Analysis During Requirements for items to be included.

Many characteristics of the software requirements are considered. Requirements should be: complete, correct, understandable, unambiguous, testable, traceable to the higher-level requirements, consistent, able to meet the user’s expectations, and detailed enough to include boundary conditions, constraints, desired controls, etc.

The information in this topic is divided into several tabs as follows:

• Tab 1 – Introduction
• Tab 2 – SW Requirements Analysis Techniques – lists required and some other possible methods/techniques for requirements analysis
• Tab 3 – Safety Analysis During Requirements – provides additional guidance when safety-critical software is involved with analysis emphasis on safety features
• Tab 4 – Requirements Analysis Report – guidance on reporting the results of the requirements analysis performed
• Tab 5 – Resources for this topic

The following is a list of the applicable SWE requirements that relate to the generation of the Software Requirements Analysis product:

1.1 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

2. SW Requirements Analysis Techniques

NASA Missions go through a logical decomposition in defining their requirements. Software Requirements Analysis addresses a system’s or application’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.  

There are several techniques that may be used by either Software Assurance or Software Safety personnel to aid in analyzing these software requirements. NPR 7150.2 ⁰⁸³  and NASA-STD-8739.8 ²⁷⁸  requires some specific techniques be used for the analysis and those are listed in the table on Tab 1. Introduction. It is recommended that at least one other method or technique be selected to supplement the required techniques. Consider the areas where the software requirements are typically weak or where  issues have been found previously and tailor the approach.

This tab contains some checklists and guidance for Software Requirements Analysis. Other guidance to consider while analyzing requirements may be found in this SWE Handbook in tabs 3 and 7 of the following requirements: 

• SWE-052 - Bidirectional Traceability
• SWE-134 - Safety-Critical Software Design Requirements
• SWE-050 - Software Requirements
• SWE-051 - Software Requirements Analysis
• SWE-184 - Software-related Constraints and Assumptions

Some methods and techniques are:

2.1 Walk-throughs 

Walk-throughs establish a common understanding of the system/software requirements and/or operations concept.

1. The following roles are recommended for attendance/participation in the walk-throughs: System Engineers, Software Developers, Software Testers (including IV&V), Software Assurance, Software Safety, System Safety, Operations people, and users.
2. Walk-throughs are intended to give participants a good understanding of the expected data flows through the system/software and the activities to be performed for each operational scenario. This helps determine whether the correct requirements are in place to support all the operational scenarios, data management needs, and helps identify potential system/software hazards.
3. Walk-throughs also provide an opportunity for open discussion of the requirements. These in-depth discussions may lead to the identification of additional requirements as the requirements and their intent are better understood.

2.2 Peer Reviews or Formal Inspections

Peer Reviews or Formal Inspections can be used to focus on small sections of concern or to look at potential problem areas of the requirements. For example, a peer review could focus on just correctness or consistency. Here is what is meant by these terms:

Determine correctness

Requirements are considered correct if they "respond properly to situations" ⁰⁰¹  and are appropriate to meet the objectives of higher-level requirements. A technique for determining correctness is to compare the requirements set against operational scenarios developed for the system/software.

Determine consistency

Requirements are consistent if they do not conflict with each other within the same requirements set and if they do not conflict with system (or higher-level) requirements. It is helpful to have at least one person read through the entire set of requirements to confirm the use of consistent terms/terminology throughout.

Peer reviews or formal inspections are particularly important for the areas where software requirements are typically weak and where there is a history of issues found previously. See also Topic 7.10 - Peer Review and Inspections Including Checklists, SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures

2.3 Checklists

Several checklists can be used to help analyze requirements. It is often useful to consider using one or more of these to supplement other analysis methods.

2.3.1 SA Requirements Analysis Checklist (formerly SAANALYSIS)

PAT-034 - SA Requirements Analysis Checklist shown below (previously located in 7.18) is a good general checklist that covers many areas to be considered when performing a requirements analysis. 

See also Topic 8.01 - Off Nominal Testing.

Additional checklists below may be used to assist in checking for content, editorial issues and other general requirements issues. Each checklist maybe downloaded by clicking on the thumbnail.

2.3.2 Requirements Quality Checklist (PAT-079)

Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

2.3.3 Requirements Contents Checklist (PAT-080)

PAT-080 - Requirements Contents Checklist shown below contains questions on various requirements attributes (e.g., clarity, completeness, compliance, consistency, traceability, correctness, feasibility, functionality, performance, interfaces, maintainability, reliability, and verifiability) for consideration. Click on the thumbnail to view the entire set of questions.  

Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

2.3.4 Requirements Editorial Checklist (PAT-081)

PAT-081 - Requirements Editorial Checklist contains questions on the proper usage of terms in requirements and some of the common editorial issues in requirements. Click on the thumbnail to view the entire set of questions.

Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

2.3.5 Additional Requirements Checklists

When evaluating the software requirements, consider using these additional checklists:

• PAT-003 - Functional Requirements Checklist
• PAT-004 - Safety Requirements Analysis Checklist
• PAT-007 - Checklist for General Software Safety Requirements
• PAT-013 - Software Requirements Checklist

2.4 Bidirectional Traceability

For the basic requirements on bi-directional traceability, see SWE-052 - Bidirectional Traceability in NASA-STD-8739.8 ²⁷⁸. Software Assurance should be confirming that the bi-directional trace is complete and includes traces for all the levels specified in SWE-052.

The requirements traceability matrix identifies all of the system-level and higher-level requirements assigned to the software to be coded. It will also identify the parent requirements.  If a software requirement doesn’t have a parent, it may not be necessary. Traceability is important throughout the full life cycle tracing the requirements allocation to the design, implementation, and test phases. Traceability is particularly important in support of the system/software change or configuration management process. For example, if there is a requirement change during code development, the traceability matrix will help identify the design impacts in the code. The traceability between the requirements and the tests determines whether all the requirements in the system/software are being tested. Similarly, the traceability between the system and software hazards to the software requirements will help determine whether all the hazards are being addressed.

2.5 Verify Accuracy of Mathematical Specifications

During the requirements analysis process, the algorithms and mathematical specifications need to be verified to ensure that the inputs to the system/software are computed correctly, and that the specifications and algorithms produce the correct values.

• Ensure that correct units have been specified for all components in the specifications/algorithms.
• Any type conversion limitations should be identified.
• The range of values that are valid for inputs should be specified.

2.6 Models and Diagrams

Models and diagrams are techniques that can be used in requirements analysis to assist in getting the best requirements set possible from both the end-user, customer and product perspective. Some are:

• Modeling of inputs and outputs
• Activity Diagram
• Data Flow Diagrams,
• Control Flow Diagrams,
• Scenario-Based/Use Case Models,
• Behavioral-Based Modeling
• Architectural Diagram
• State/Mode Diagram

2.7 Reviewing Requirements in Agile - Use Cases, User Stories

(Typically used in Agile)

When using Agile Methodologies, use cases and user stories are used to generate and build the system/software requirements. The user stories/use cases are analyzed to extract the requirements to ensure all of the details are captured. Well written user stories/use cases will contain information that may be used to build the software as well as the Software Requirements Specification (SRS). It is assumed the Product Owner will not provide an SRS. Their mechanism for providing requirements is via user stories/use cases. Note: NASA organizations may develop their higher level requirements in a more traditional Waterfall fashion with the lower-level requirements generated using Agile methodologies.

a. To analyze the requirements in an Agile software development environment, it is important to understand the relationship between user stories and requirements and where use cases fit in.

i. Agile User Stories:

The Agile Alliance describes a user story as work to be done divided into functional increments.

A more simplified definition can be attributed to Atlassian: “A user story is an informal, general explanation of a software feature written from the perspective of the end-user. Its purpose is to articulate how a software feature will provide value to the customer.”

User stories are often used to plan the work in an Agile software development environment. They usually consist of one or two sentences in a specific structure to identify the user, what they want, and why. User stories are all about providing value to the customer. It’s what the user wants (the “results”). Typically, the low-level details will be derived from conversations at Sprint Planning and/or scrum meetings. These details should be captured in the SRS.

ii. Agile Use Cases

Per Wikipedia, a use case is a list of actions or event steps typically defining the interactions between a role and a system to achieve a goal.

Use cases are often more detailed than user stories. They are all about the “behavior” that is built into the software to meet the customer/user’s needs/goals. Use cases focus on all of the ways the system/software will be used and describe the process/procedures the user takes to accomplish the goal.

iii. When Agile use stories/use cases are used, analysis is still required but may take on a different flavor. They give context to the requirements. When doing requirements analysis in Agile systems, include the following activities:

-Ensure the User Stories are well formulated. To convey the appropriate information, User Stories are commonly in the form of:

-As a <role>,

-I want <requirement>

-so that <rationale/goal>.

-Ensure that the set of user stories/use cases capture all of the information that may exist in the more traditional forms of requirements.

-Consider how the user stories can be tested and ensure that all the required capabilities can be tested through the user stories.

-Perform bidirectional traces between the traditional Waterfall requirements and the user stories/use cases. Ensure that all safety-critical hazard controls trace to user stories and use cases.

-Review Appendix A in NASA-STD-8739.8 to ensure that all applicable software hazard causes have been considered for inclusion in the user stories and use cases.

b. Requirements have been traditionally used for the NASA systems and software development.

Requirements describe the features of the system being built and convey the user’s expectations. They tend to be very specific and go into detail on how the software should work. Traditionally, the requirements are written by the product manager, the systems engineer, software engineer, or the technical lead. Projects using many of the traditional development methodologies use the written requirements and go directly into the design phase after their requirements analysis. In Agile development where they are provided with high-level NASA requirements, the Product Owner typically breaks the requirements into agile user stories and/or use cases. It is up to Software Engineering to work with the Product Owner to derive the detailed requirements and develop an SRS.

2.8 Requirements Analysis Tools

The use of requirements analysis tools (e.g., Innoslate, DOORS) or requirements modeling tools (e.g., Xplenty, IBM Rational, SQL DBM) may be helpful in some analysis activities. Some tools can be used to check the attributes being reviewed.

In FY21, the Software Assurance Research Program (SARP) has two projects researching different aspects of doing requirements analysis including the development of tools. This research may be available for NASA use shortly.

2.9 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

3. SW Safety Analysis During Requirements

There are requirements analysis activities that apply specifically to software with safety-critical components. The safety team needs to focus on safety considerations while the requirements analysis is being performed and ensure that these safety-critical aspects have been addressed. The safety requirements analysis portion should be done in conjunction with the software requirements analysis and the results combined in reporting on the analyses results. For additional information on identifying safety related requirements, see the 8.58 - Software Safety and Hazard Analysis topic. See also SWE-192 - Software Hazardous Requirements,

Software Safety personnel should:

1. Ensure that the requirements analysis discussed in Topic 8.09 - Software Safety Analysis has been performed.
2. Consider using the Safety Requirements Analysis Checklist  ^PAT-004  below, in addition to the other requirements analysis methods/techniques listed on Tab 2 of this page,  during the safety requirements analysis.  

3. Perform a Fault Tree Analysis (See Topic 8.07 - Software Fault Tree Analysis for information on performing a Fault Tree Analysis))

4. Consider performing a Software Failure Modes and Effects Analysis (SFMEA)or a Software Failure Modes, Effects and Criticality (SFMECA). (See Topic 8.05 - SW Failure Modes and Effects Analysis for information on performing a SFMEA.)

See also PAT-007 - Checklist for General Software Safety Requirements, Topic 6.2 - Checklist for General Software Safety Requirements, 

3.1 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

4. Requirements Analysis Report

5. Resources 

5.1 References

5.2 Tools

5.3 Process Asset Templates

5.4 Checklists and Guidance 

5.5 Additional Guidance

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

5.6 Center Process Asset Libraries

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