1. Introduction

The primary purpose of the Software Requirement Analysis is to ensure that the documented set of requirements is the “best set” of requirements that can be defined. The documented set of requirements will guide the software developers to build a correct, robust software system that meets or exceeds all the operational needs of the system. Thus, during the software requirements analysis phase, all the various aspects of the requirements are examined carefully to see where any improvements might be needed before design and implementation begin.

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 are many tools and techniques that can be used to do a thorough requirements analysis. The requirements in NPR 7150.2 and NASA-STD-8739.8 specify some methods that are required and those are listed in the tab 2 on techniques. There are also many other techniques that are available and are helpful in locating various other types of requirements problems. Both the software team and the software assurance/safety personnel should be involved in the requirements analyses activities. Both the software and the safety teams should not only use the analysis techniques that are required by NPR 7150.2 and NASA-STD-8739.8, but they should also choose as many of the other listed techniques as they think would be useful for their project. Note that the requirements analysis portion of the Software Safety Analysis is an important part of the requirements analysis for safety critical systems and, as such, is included in this topic. (See tab 3) Each team should do any required  SWEs or SA/Safety required activities and then choose other listed techniques that they think would help their team do a more thorough job of requirements analysis. Results of whatever techniques are used will be documented in a Software Requirements Analysis Report (including the Safety Requirements Analysis).

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

Tab 4 of this topic has some guidance on reporting out on the requirements analysis performed.

2. SW Requirements Analysis Techniques

This section lists several different techniques that can be used by either software personnel or safety personnel to aid in analyzing the software requirements. The few techniques that are required for software assurance or safety personnel are noted below. It is recommended that at least one other method is chosen for inclusion in the requirements analysis. Consider the areas where the project requirements seem weak or where most of the requirements issues have been found previously and tailor your approach. Checklists and guidance found here and, in this Handbook in the software or software assurance guidance sections (tabs 3 and 7) of requirements SWE-052, SWE-134, SWE-050, SWE-051 and SWE-184, provide other good information to consider while analyzing 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.  

1. Requirements/and or Operations Concepts Walkthroughs to provide an understanding of the system
   1. The following roles will need to have a good understanding of the requirements and should attend the walkthroughs: System Engineers, Software Developers, Software Testers, Software Assurance Personnel, Software and System Safety Personnel, Operations People
   2. Generally, these types of walkthroughs give the participants a good view of the expected flows through the system to perform the necessary operations as well as the data flow that is needed for each operation. This can help determine whether all the correct requirements are in place to support all the operational scenarios as well as whether the necessary data has been defined. These walkthroughs can also provide a good background understanding of the system’s operations that will be helpful in identifying potential system hazards.
2. Peer Reviews or Formal Inspections
   1. Peer Reviews or Formal Inspections can be used to focus on smaller areas of concern or to look at potential problem areas of the requirements.
   2. For example, a peer review could focus on just correctness, consistency, or verification of interfaces:

Determine correctness

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

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.

Another focus could be: Verify Interfaces

Peer reviews or formal inspections should be targeted for the areas where the requirements seem the weakest or where the organization typically finds the most problems with requirements.

3. Checklists: There are a number of checklists that can be used to help in analyzing requirements. It is often useful to consider using one or more of these to supplement other analysis methods.

The checklist SAANALYSIS shown below (previously located in 7.18) is a good general checklist that covers many areas to be considered in your analysis:

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

1. 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? Are the requirements complete enough to avoid the introduction of unintended features? 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?
   5. Is this requirement necessary?
   6. Are the requirements understandable?
   7. Are the requirements organized in a manner such that additions and changes can be made easily?
   8. Are the requirements unnecessarily complicated?
   9. Has system performance been captured as part of the requirements?
   10. Are the system boundaries (or perhaps operational environment) well defined?
   11. Is a requirement realistic given the current technology?
   12. 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)
   13. Within each requirement level, are requirements at an appropriate and consistent level of abstraction?
   14. In the traceability, are the parent requirements represented in appropriate child requirements?
   15. 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
   16. 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 to 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
       • Qualification provisions (e.g., demonstration, test, analysis, inspection).
       • Bidirectional requirements traceability.
       • Requirements partitioning for phased delivery.
       • Testing requirements that drive software design decisions (e.g., special system level timing requirements/checkpoint restart).
       • Supporting requirements rationale.
   17. Is there bidirectional traceability between parent requirements, requirements, and preliminary design component?
   18. Do the detail 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)).
   19. Are trace links of high quality (e.g., avoidance of widows and orphans, circular traces, traces within a requirements level, etc.)?
   20. 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.
   21. 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.
   22. 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?
   23. Has a fault tolerance strategy for fault detection, identification, and recovery (FDIR) from faults been provided, and is it reasonable?
   24. Is the role of software as part of the FDIR understood?
   25. Are software related activities associated with the fault tolerance strategy for fault detection and identification and recovery captured as requirements?
   26. Is human safety addressed through the requirements?
   27. Have hazards and hazard causes been adequately identified, with associated software detection and mitigations captured as requirements?
   28. Are must-work and must-not-work requirements understood and specified?
   29. 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)
   30. Do requirements define appropriate security controls to the system and software
   31. Can the requirement(s) be efficiently and practically tested?
   32. Do the requirements address the configuration of, and any associated constraints, associated with COTS, GOTS, MOTS, and Open Source software?
   33. Do the requirements appropriately address operational constraints?
   34. Does the requirement conflict with domain constraints, system constraints, policies, or regulations (local and governmental)?
   35. Have users/operators been consulted during requirements development to identify any potential operational issues?
   36. Have the software requirements been peer reviewed?

3. SW Safety Requirements Analysis 

4. Requirements Analysis Report

5. Resources 

5.1 References

5.2 Tools