2. SW Requirements Analysis TechniquesNASA 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: Some methods and techniques are: 2.1 Walk-throughs Walk-throughs establish a common understanding of the system/software requirements and/or operations concept. - 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.
- 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.
- 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 InspectionsPeer 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 ChecklistsSeveral 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. Click on the thumbnail to view the entire set of questions. From the viewer, download a copy for use. PAT-034 - SA Requirements Analysis Checklist 
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)PAT-079 - Requirements Quality Checklist contains a number of suggestions to improve the clarity, understandability, and general quality of the requirements. Click on the thumbnail to view the entire set of questions. From the viewer, download a copy for use.
2.3.3 Requirements Contents Checklist (PAT-080)PAT-080 - Requirements Contents Checklist 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. From the viewer, download a copy for use.  
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. From the viewer, download a copy for use. 
2.3.5 Additional Requirements ChecklistsWhen evaluating the software requirements, consider using these additional checklists: 2.4 Bidirectional TraceabilityFor 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 SpecificationsDuring 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 DiagramsModels 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 ToolsThe 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 GuidanceLinks to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the  in the Resources tab. |