1. Introduction

2. Recommended Content

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

3.1 References

3.2 Tools