03.00 Software Requirements Activity Overview

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.01 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.01.01 - Human Rated Requirements - Product Requirements

• HR-31 - Single Failure Tolerance - 4.3.1 The space system shall provide at least single failure tolerance to catastrophic events, with specific levels of failure tolerance and implementation (similar or dissimilar redundancy) derived via an integration of the design and safety analysis (required by NPR 8705.2).
• HR-33 - Inadvertent Operator Action - 4.3.3 The space system shall be designed to tolerate inadvertent operator action (minimum of one inadvertent action), as verified by a human error analysis, without causing a catastrophic event.
• HR-34 - Operator Action With Single System Failure - 4.3.4 The space system shall tolerate inadvertent operator action, as described in Section 4.3.3, in the presence of any single system failure.

• HR-35 - Mitigate Hazardous Behavior Of Critical Software - 4.3.5 The space system shall provide the capability to mitigate the hazardous behavior of critical software where the hazardous behavior would result in a catastrophic event.

• HR-36 - Detect And Annunciate Faults - 4.3.6 The space system shall provide the capability to detect and annunciate faults that affect critical systems, subsystems, or crew health.
• HR-37 - Fault Recovery - 4.3.7 The space system shall provide the capability to isolate and recover from faults identified during system development or mission operations that would result in a catastrophic event.
• HR-38 - Data Analysis - 4.3.8 The space system shall provide the capability to utilize health and status data (including system performance data) of critical systems and subsystems to facilitate anomaly resolution during and after the mission.
• HR-39 - Autonomous Operation - 4.3.9 The crewed space system shall provide the capability for autonomous operation of system and subsystem functions which, if lost, would result in a catastrophic event.
• HR-41 - Crew Operations - 
  4.4.1 The crewed space system shall provide the capability for the crew to monitor, operate, and control the crewed space system and subsystems, where: 

  1. 1. The capability is necessary to execute the mission; or
     2. The capability would prevent a catastrophic event; or
     3. The capability would prevent an abort.
• HR-42 - Crew Override - 4.4.2 The crewed space system shall provide the capability for the crew to manually override higher level software control and automation (such as automated abort initiation, configuration change, and mode change) when the transition to manual control of the system will not cause a catastrophic event.
• HR-43 - Crew Control - 
  4.4.3 The space system shall provide the capability for humans to remotely monitor, operate, and control the crewed system elements and subsystems, where:

  1. 1. The remote capability is necessary to execute the mission; or
     2. The remote capability would prevent a catastrophic event; or
     3. The remote capability would prevent an abort.
• HR-51 - Crew Flight Control - 4.5.1 The crewed space system shall provide the capability for the crew to manually control the flight path and attitude of their spacecraft, with the following exception: during the atmospheric portion of Earth ascent when structural and thermal margins have been determined to negate the benefits of manual control.
• HR-7142 - Ground Initiate Ascent Abort Sequence - 4.7.1.4.2 The space system shall provide the capability for the ground control to initiate the Earth ascent abort sequence.
• HR-715 - Interface With Range Safety Destruct System - 4.7.1.5 If a range safety destruct system is incorporated into the design, the space system shall automatically initiate the Earth ascent abort sequence when range safety destruct commands are received onboard, with an adequate time delay prior to destruction of the launch vehicle to allow a successful abort.

03.02 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 - SA Requirements Analysis Checklist

03.03 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 Quality - The goal of software quality is to assure that Software performs consistently as desired, when operating within specified conditions. This topic covers additional basic information on software quality.
• 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.04 Related SPAN Links