03. Software Requirements Activity Overview

Requirements are the basis for a software product.They identify the needs to be addressed, the behavior of the system, the desired quality of the software, and the constraints under which the problem 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 judge the completeness of the product.

Analyzing software requirements allows a team to ensure that they are properly formed and accurately and clearly describe the software system to be built.  The analysis provides a structured method of reviewing requirements to identify any issues with them individually or as a collected set.  The team can address identified issues before using the requirements for further project work.  This reduces the need for future rework, not only of the requirements but also of any work based on those requirements.

NASA-STD-8719.29 contains Human Rated Requirements for software products. They are summarized in Topic 7.24 - Human Rated Software Requirements and must be taken onto consideration and used just like other product requirements in the development cycle. 

Any inconsistencies among these three - requirements, project plans, and software products – will most likely result in a product that does not meet its requirements. Corrective actions address not only new or changed requirements, but also failures and defects in the work products (requirements, project plans, and software products). Corrective actions need to be analyzed to determine the impact that the change will have on the work product, related work products, budget, and schedule. Corrective actions need to be tracked until closure to ensure decisions regarding the closure of those actions are followed through and to prevent the problems described in those corrective actions from propagating through the project or recurring.

Validation is one way to ensure the requirements define the need completely, clearly, correctly, and consistently to give the software engineers the best chance to build the correct product. Validation is a process of evaluating artifacts to ensure that the right behaviors have been defined in the artifacts. The right behaviors adequately describe what the system is supposed to do, what the system is not supposed to do, and what the system is supposed to do under adverse conditions.  

Acceptance criteria synchronize the visions of the client and the development team. They ensure that everyone has a common understanding of the requirements: Developers know exactly what kind of behavior the feature must demonstrate, while stakeholders and the client understand what's expected from the feature.

Bidirectional traceability matrices help ensure that all the required software requirements (only what is required is developed) are addressed in software design and tested in the software testing activities. Bidirectional traceability matrices also make it less likely that requirements are misinterpreted as they are refined.

Frequency Of This Activity

Requirements change management helps ensure alignment between the software requirements and the project’s software plans and software work products. Collecting, analyzing, and managing requirements changes allow a project to control those changes and measure their impact. Requirements change management can also provide early insights into the impact of those changes to the overall project's budget and schedule, including the ability to plan how to address changes rather than simply reacting when a change is made.

03.1 Related SWEs

• SWE-034 - Acceptance Criteria - 3.1.5 The project manager shall define and document the acceptance criteria for the software. 
• SWE-050 - Software 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. 
• SWE-051 - Software Requirements Analysis - 4.1.3 The project manager shall perform software requirements analysis based on flowed down and derived requirements from the top-level systems engineering requirements, safety and reliability analyses, and the hardware specifications and design. 
• SWE-052 - Bidirectional Traceability - 3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: 

  Bi-directional Traceability	Class A, B, and C	Class D	Class F
  Higher-level requirements to the software requirements	X		X
  Software requirements to the system hazards	X	X
  Software requirements to the software design components	X
  Software design components to the software code	X
  Software requirements to the software verification(s)	X	X	X
  Software requirements to the software non-conformances	X	X	X

• SWE-053 - Manage Requirements Changes - 4.1.5 The project manager shall track and manage changes to the software requirements. 
• SWE-054 - Corrective Action for Inconsistencies - 4.1.6 The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products. 
• SWE-055 - Requirements Validation - 4.1.7 The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment. 
• SWE-134 - Safety-Critical Software Design Requirements - 3.7.3 If a project has safety-critical software or mission-critical software, the project manager shall implement the following items in the software: 

  a. The software is initialized, at first start and restarts, to a known safe state.
  b. The software safely transitions between all predefined known states.
  c. Termination performed by software functions is performed to a known safe state.
  d. Operator overrides of software functions require at least two independent actions by an operator.
  e. Software rejects commands received out of sequence when execution of those commands out of sequence can cause a hazard.
  f. The software detects inadvertent memory modification and recovers to a known safe state.
  g. The software performs integrity checks on inputs and outputs to/from the software system.
  h. The software performs prerequisite checks prior to the execution of safety-critical software commands.
  i. No single software event or action is allowed to initiate an identified hazard.
  j. The software responds to an off-nominal condition within the time needed to prevent a hazardous event.
  k. The software provides error handling.
  l. The software can place the system into a safe state.

• SWE-184 - Software-related Constraints and Assumptions - 4.1.4 The project manager shall include software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software in the software requirements documentation.

03.2 Related Work Products

• 5.01 - CR-PR - Software Change Request - Problem Report - Minimum recommended content for the Software Change Request - Problem Report. 
• 5.07 - SDD - Software Data Dictionary - Minimum recommended content for the Software Data Dictionary. 
• 5.09 - SRS - Software Requirements Specification - Minimum recommended content for the Software Requirements Specification. 
• Acceptance Criteria and Conditions
• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Requirements are good candidates for a Peer Review
• 7.19 - Software Risk Management Checklists - tab 3 Software Requirements Phase checklist

03.2.1 Related Process Asset Templates

• PAT-003 - Functional Requirements Checklist
• PAT-004 - Safety Requirements Analysis Checklist
• PAT-007 - Checklist for General Software Safety Requirements
• PAT-013 - Software Requirements Checklist
• PAT-033 - TASKS NEEDING OBJECTIVE EVIDENCE
• PAT-034 - SAANALYSIS Checklist

03.3 Related Topics

• 6.2 - Checklist for General Software Safety Requirements -  Provides a list of many of the requirements that should be included in a safety-critical software system.
• 7.24 - Human Rated Software Requirements - What requirements do you need to follow when you are developing or acquiring human-rated software?  The answer is NPR 7150.2 Class A requirements and some of the NASA-STD-8719.29 software requirements. 
• 8.01 - Off Nominal Testing - Guidance focusing on out of bounds parameters, failure scenarios, unexpected conditions, and capabilities that are typically considered as "must not work" functions.
• 8.02 - Software Reliability - The goal of SW reliability and maintainability is to assure that SW performs consistently as desired, when operating within specified conditions. This topic covers additional basic information on software reliability.
• 8.07 - Software Fault Tree Analysis - A top-down analysis method to help identify the causes of presupposed hazards.
• 8.54 - Software Requirements Analysis - The Software Requirements Analysis product focuses on analyzing the software requirements that have been developed from the system requirements. 

03.4 Related SPAN Links