Effective Date: August 02, 2019
Expiration Date: August 02, 2024
|| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL ||
C.1 The rationale for the requirements is contained in the NASA-HDBK-2203. Programs/Projects may substitute a matrix that documents their mapping with their particular Center's implementation of NPR 7150.2, if applicable. See NASA-HDBK-2203 for requirements mapping matrices organized by class, tailoring field for each requirement, tailoring rationale, and approval signature lines.
C.2 The Requirements Mapping Matrix documents the program/project's mappings or intent to comply with the requirements of this NPR or justification for tailoring. The matrix lists:
a. The section reference.
b. The unique requirement identifier.
c. The NPR 7150.2 requirement statement.
d. The Authority Level responsible for assessing a project’s requirements mapping matrices and any requested tailoring from requirements in this NPR. The CIO, or the designee, has institutional authority on all Class F software projects and has joint responsibility on the cybersecurity requirements in section 3.11.
e. The applicability of the requirements in this NPR to specific systems and subsystems within the Agency’s investment areas, programs, and projects is determined through the use of the NASA-wide definition of software classes.
X - Indicates an invoked requirement by this NPR consistent with Software Classification (ref. SWE-139). May be tailored with Technical Authority approval (ref. Chapter 2.2).
Blank - Optional/Not invoked by this NPR.
Center - Center Director or the Center Director’s designated Engineering Technical Authority, the Center Director's designated SMA Technical Authority, and the CHMO designated for Health and Medical Technical Authority. The CIO, or the designee, has institutional authority on all Class F software projects and has joint responsibility on the cybersecurity requirements in section 3.11 per the direction in the Requirements Mapping Matrix.
CIO - The OCIO, or the designee Center CIO, has institutional authority on all Class F software projects and has joint responsibility on the cybersecurity requirements in section 3.11 per the direction in the Requirements Mapping Matrix.
Each requirement marked 'X' for the project's software classification(s) should be addressed in the Requirements Mapping Matrix. All requirements can be tailored per the guidance in this directive. Requirements that are not applicable to a given project, such as the IV&V requirements, should be tailored out in the Requirements Mapping Matrix with justification.
Table 2. Requirements Mapping Matrix
|Section||SWE #||Requirement Text||Class A - E Authority||A||B||C||D||E||Class F Authority||F|
|3.0||Software Management Requirements|
|3.1||Software Life Cycle Planning|
|3.1.2||033||The project manager shall assess options for software acquisition versus development.||Center||X||X||X||X||X||CIO||X|
|3.1.3||013||The project manager shall develop, maintain, and execute software plans that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring.||Center||X||X||X||X||X||CIO||X|
|3.1.4||024||The project manager shall track the actual results and performance of software activities against the software plans.a. Corrective actions are taken, recorded, and managed to closure. |
b. Including changes to commitments (e.g., software plans) that have been agreed to by the affected groups and individuals.
|3.1.5||034||The project manager shall define and document the acceptance criteria for the software.||Center||X||X||X||X||CIO||X|
|3.1.6||036||The project manager shall establish and maintain the software processes, software documentation plans, list of developed electronic products, deliverables, and list of tasks for the software development that are required for the project’s software developers, as well as the action required (e.g., approval, review) of the Government upon receipt of each of the deliverables.||Center||X||X||X||X||CIO||X|
|3.1.7||037||The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited.||Center||X||X||X||X||CIO||X|
|3.1.8||039||The project manager shall require the software developer(s) to periodically report status and provide insight into software development and test activities; at a minimum, the software developer(s) will be required to allow the project manager and software assurance personnel to: |
a. Monitor product integration.
b. Review the verification activities to ensure adequacy.
c. Review trades studies and source data.
d. Audit the software development processes and practices.
e. Participate in software reviews and technical interchange meetings.
|3.1.9||040||The project manager shall require the software developer(s) to provide NASA with software products, traceability, software change tracking information and nonconformances, in electronic format, including software development and management metrics.||Center||X||X||X||X||CIO||X|
|3.1.10||042||The project manager shall require the software developer(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format.||Center||X||X||X||X||X||CIO||X|
|3.1.11||139||The project manager shall comply with the requirements in this NPR that are marked with an ”X” in Appendix C consistent with their software classification.||Center||X||X||X||X||X||CIO||X|
|3.1.12||121||Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and deployment of the affected software.||Center||X||X||X||X||X||CIO||X|
|3.1.13||125||Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements.||Center||X||X||X||X||X||CIO||X|
|3.1.14||027||The project manager shall satisfy the following conditions when a COTS, GOTS, MOTS, or reused software component is acquired or used:
a. The requirements to be met by the software component are identified.
b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions).
c. Proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights have been addressed.
d. Future support for the software product is planned and adequate for project needs.
e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use.
f. The project has a plan to perform periodic assessments of vendor reported defects to ensure the defects do not impact the selected software components.
|3.2||Software Cost Estimation|
|3.2.1||015||To better estimate the cost of development, the project manager shall establish, document, and maintain: |
a. Two cost estimate models and associated cost parameters for all Class A and B software projects that have an estimated project cost of $2 million or more.
b. One software cost estimate model and associated cost parameter(s) for all Class A and Class B software projects that have an estimated project cost of less than $2 million.
c. One software cost estimate model and associated cost parameter(s) for all C and D software projects.
d. One software cost estimate model and associated cost parameter(s) for all Class F software projects.
|3.2.2||151||The project manager’s software cost estimate(s) shall satisfy the following conditions: |
a. Covers the entire software life cycle.
b. Is based on selected project attributes (e.g., assessment of the size, functionality, complexity, criticality, reuse code, modified code, and risk of the software processes and products).
c. Is based on the cost implications of the technology to be used and the required maturation of that technology.
d. Incorporates risk and uncertainty, including cybersecurity.
e. Includes the cost of the required software assurance support.
f. Includes other direct costs.
|3.2.3||174||The project manager shall submit software planning parameters, including size and effort estimates, milestones, and characteristics, to the Center measurement repository at the conclusion of major milestones.||Center||X||X||X||X|
|3.3.1||016||The project manager shall document and maintain a software schedule that satisfies the following conditions: |
a. Coordinates with the overall project schedule.
b. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
c. Reflects the critical dependencies for software development activities.
d. Identifies and accounts for dependencies with other projects and cross-program dependencies.
|3.3.2||018||The project manager shall regularly hold reviews of software schedule activities, metrics, status, and results with the project stakeholders and track issues to resolution.||Center||X||X||X||CIO||X|
|3.3.3||046||The project manager shall require the software developer(s) to provide a software schedule for the project's review and schedule updates as requested.||Center||X||X||X||X||CIO||X|
|3.4.1||017||The project manager shall plan, track, and ensure project specific software training for project personnel.||Center||X||X||X||CIO||X|
|3.5||Software Classification Assessments|
|3.5.1||020||The project manager shall classify each system and subsystem containing software in accordance with the highest applicable software classification definitions for Classes A, B, C, D, E, and F software in Appendix D.||Center||X||X||X||X||X||CIO||X|
|3.5.2||176||The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessments for the life of the project.||Center||X||X||X||X||X||CIO||X|
|3.6||Software Assurance and Software Independent Verification & Validation|
|3.6.1||022||The project manager shall plan and implement software assurance per NASA-STD-8739.8.||Center||X||X||X||X||X|
|3.6.2||141||For projects reaching Key Decision Point A, the program manager shall ensure that software IV&V is performed on the following categories of projects: |
a. Category 1 projects as defined in NPR 7120.5.
b. Category 2 projects as defined in NPR 7120.5 that have Class A or Class B payload risk classification per NPR 8705.4.
c. Projects selected explicitly by the NASA Chief of the Office of Safety and Mission Assurance to have software IV&V.
|3.6.3||131||If software IV&V is performed on a project, the project manager shall ensure an IPEP is developed, negotiated, approved, maintained, and executed.||Center||X||X|
|3.6.4||178||If software IV&V is performed on a project, the project manager shall ensure that IV&V is provided access to development artifacts, products, source code, and data required to perform the IV&V analysis efficiently and effectively.||Center||X||X|
|3.6.5||179||If software IV&V is performed on a project, the project manager shall provide responses to IV&V submitted issues and risks, and track these issues and risks to closure.||Center||X||X|
|3.7.1||205||The project manager, in conjunction with the SMA organization, shall determine if each software component is considered to be safety-critical per the criteria defined in NASA-STD-8739.8.||Center||X||X||X||X||X|
|3.7.2||023||If a project has safety-critical software, the project manager shall implement the safety-critical software requirements contained in NASA-STD-8739.8.||Center||X||X||X||X|
|3.7.3||134||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 of 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.
|3.8||Automatic Generation of Software Source Code|
|3.8.1||146||The project manager shall define the approach to the automatic generation of software source code including: |
a. Validation and verification of auto-generation tools.
b. Configuration management of the auto-generation tools and associated data.
c. Description of the limits and the allowable scope for the use of the auto-generated software.
d. Verification and validation of auto-generated source code using the same software standards and processes as hand-generated code.
e. Monitoring the actual use of auto-generated source code compared to the planned use.
f. Policies and procedures for making manual changes to auto-generated source code.
g. Configuration management of the input to the auto-generation tool, the output of the auto-generation tool, and modifications made to the output of the auto-generation tools.
|3.8.2||206||The project manager shall require the software developers and suppliers to provide NASA with electronic access to the models, simulations, and associated data used as inputs for auto-generation of software.||Center||X||X||X||X||CIO||X|
|3.9||Software Development Processes and Practices|
|3.9.3||032||The project manager shall acquire, develop, and maintain software from an organization with a non-expired CMMI-DEV rating as measured by a CMMI Institute Certified Lead Appraiser as follows: |
a. For Class A software: CMMI-DEV Maturity Level 3 Rating or higher for software.
b. For Class B software: CMMI-DEV Maturity Level 2 Rating or higher for software.
|3.10.1||147||The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for United States Government purposes.||Center||X||X||X||X||CIO||X|
|3.10.2||148||The project manager shall evaluate software for potential reuse by other projects across NASA and contribute reuse candidates to the NASA Internal Sharing and Reuse Software systems. However, if the project manager is a contractor, then a civil servant must pre-approve all such software contributions; all software contributions should include, at a minimum, the following information: |
a. Software Title.
b. Software Description.
c. The Civil Servant Software Technical Point of Contact for the software product.
d. The language or languages used to develop the software.
e. Any third party code contained therein and the record of the requisite license or permission received from the third party permitting the Government’s use, if applicable.
|3.11.2||156||The project manager shall perform a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.||Center and Center CIO||X||X||X||X||X||CIO||X|
|3.11.3||154||The project manager shall identify cybersecurity risks, along with their mitigations, in flight and ground software systems and plan the mitigations for these systems.||Center and Center CIO||X||X||X||X|
|3.11.4||157||The project manager shall implement protections for software systems with communications capabilities against unauthorized access.||Center and Center CIO||X||X||X||X|
|3.11.5||158||The project manager shall ensure that space flight software systems are assessed for possible cybersecurity vulnerabilities and weaknesses.||Center and Center CIO||X||X||X||X||CIO||X|
|3.11.6||155||The project manager shall address identified cybersecurity vulnerabilities and weaknesses.||Center and Center CIO||X||X||X||X||X||CIO||X|
|3.11.7||159||The project manager shall test the software and record test results for the required software cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses analysis.||Center and Center CIO||X||X||X||X||CIO||X|
|3.11.8||207||The project manager shall identify, record, and implement secure coding practices.||Center and Center CIO||X||X||X||X|
|3.11.9||185||The project manager shall verify that the software code meets the project’s secure coding standard by using the results from static analysis tool(s).||Center and Center CIO||X||X||X||X||CIO||X|
|3.12||Software Bi-Directional Traceability|
|3.12.1||052||The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: (See Table in 3.12.1)||Center||X||X||X||X||CIO||X|
|4.0||Software Engineering (Life-Cycle) Requirements|
|4.1.2||050||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.||Center||X||X||X||X||CIO||X|
|4.1.3||051||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.||Center||X||X||X|
|4.1.4||184||The project manager shall include software related safety constraints, controls, mitigations and assumptions between the hardware, operator, and software in the software requirements documentation.||Center||X||X||X|
|4.1.5||053||The project manager shall track and manage changes to the software requirements.||Center||X||X||X||X||CIO||X|
|4.1.6||054||The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products.||Center||X||X||X||X||CIO||X|
|4.1.7||055||The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment.||Center||X||X||X||X||CIO||X|
|4.2.3||057||The project manager shall transform the requirements for the software into a recorded software architecture.||Center||X||X||X|
|4.2.4||143||The project manager shall perform a software architecture review on the following categories of projects: |
a. Category 1 Projects as defined in NPR 7120.5.
b. Category 2 Projects as defined in NPR 7120.5 that have Class A or Class B payload risk classification per NPR 8705.4.
|4.3.2||058||The project manager shall develop, record, and maintain a software design based on the software architectural design that describes the lower-level units so that they can be coded, compiled, and tested.||Center||X||X||X|
|4.4.2||060||The project manager shall implement the software design into software code.||Center||X||X||X||CIO||X|
|4.4.3||061||The project manager shall select and adhere to software coding methods, standards, and criteria.||Center||X||X||X||X||CIO||X|
|4.4.4||135||The project manager shall use static analysis tools to analyze the code during the development and testing phases to detect defects, software security, and coding errors.||Center||X||X||X||X||CIO||X|
|4.4.5||062||The project manager shall unit test the software code.||Center||X||X||X||X||CIO||X|
|4.4.6||186||The project manager shall assure that the unit test results are repeatable.||Center||X||X||X||X||CIO||X|
|4.4.7||063||The project manager shall provide a software version description for each software release.||Center||X||X||X||X||CIO||X|
|4.4.8||136||The project manager shall validate and accredit the software tool(s) required to develop or maintain software.||Center||X||X||X|
|4.5.2||065||The project manager shall establish and maintain: |
a. Software test plan(s).
b. Software test procedure(s).
c. Software test report(s).
|4.5.3||066||The project manager shall test the software against its requirements.||Center||X||X||X||X||CIO||X|
|4.5.4||187||The project manager shall place software items under configuration management prior to testing.||Center||X||X||X||CIO||X|
|4.5.5||068||The project manager shall evaluate test results and record the evaluation.||Center||X||X||X||X||CIO||X|
|4.5.6||070||The project manager shall use validated and accredited software models, simulations, and analysis tools required to perform qualification of flight software or flight equipment.||Center||X||X||X|
|4.5.7||071||The project manager shall update the software test plan(s) and the software test procedure(s) to be consistent with software requirements.||Center||X||X||X||X||CIO||X|
|4.5.8||073||The project manager shall validate the software system on the targeted platform or high-fidelity simulation.||Center||X||X||X|
|4.5.9||189||The project manager shall ensure that the code coverage measurements for the software are selected, implemented, tracked, recorded, and reported.||Center||X||X||X||X|
|4.5.10||190||The project manager shall verify code coverage is measured by analysis of the results of the execution of tests.||Center||X||X||X|
|4.5.11||191||The project manager shall plan and conduct software regression testing to demonstrate that defects have not been introduced into previously integrated or tested software and have not produced a security vulnerability.||Center||X||X||X||CIO||X|
|4.5.12||192||The project manager shall verify through test the software requirements that trace to a hazardous event, cause, or mitigation technique.||Center||X||X||X||X|
|4.5.13||193||The project manager shall develop acceptance tests for loaded or uplinked data, rules, and code that affects software and software system behavior.||Center||X||X||CIO||X|
|4.5.14||211||The project manager shall test embedded COTS, GOTS, MOTS, OSS, or reused software components to the same level required to accept a custom developed software component for its intended use.||Center||X||X||X|
|4.6||Software Operations, Maintenance, and Retirement|
|4.6.2||075||The project manager shall plan and implement software operations, maintenance, and retirement activities.||Center||X||X||X||X||CIO||X|
|4.6.3||077||The project manager shall complete and deliver the software product to the customer with appropriate records, including as-built records, to support the operations and maintenance phase of the software’s life cycle.||Center||X||X||X||X||CIO||X|
|4.6.4||194||The project manager shall complete, prior to delivery, verification that all software requirements identified for this delivery have been met, that all approved changes have been implemented and that all defects designated for resolution prior to delivery have been resolved.||Center||X||X||X||X||CIO||X|
|4.6.5||195||The project manager shall maintain the software using standards and processes per the applicable software classification throughout the maintenance phase.||Center||X||X||X||X||CIO||X|
|4.6.6||196||The project manager shall identify the records and software tools to be archived, the location of the archive, and procedures for access to the products for software retirement or disposal.||Center||X||X||X||X||CIO||X|
|5.0||Supporting Software Life-Cycle Requirements|
|5.1||Software Configuration Management|
|5.1.2||079||The project manager shall develop a software configuration management plan that describes the functions, responsibilities, and authority for the implementation of software configuration management for the project.||Center||X||X||X||X||CIO||X|
|5.1.3||080||The project manager shall track and evaluate changes to software products.||Center||X||X||X||X||CIO||X|
|5.1.4||081||The project manager shall identify the software configuration items (e.g., software records, code, data, tools, models, scripts) and their versions to be controlled for the project.||Center||X||X||X||X||CIO||X|
|5.1.5||082||The project manager shall establish and implement procedures to: |
a. Designate the levels of control through which each identified software configuration item is required to pass.
b. Identify the persons or groups with authority to authorize changes.
c. Identify the persons or groups to make changes at each level.
|5.1.6||083||The project manager shall prepare and maintain records of the configuration status of software configuration items.||Center||X||X||X||X||CIO||X|
|5.1.7||084||The project manager shall perform software configuration audits to determine the correct version of the software configuration items and verify that they conform to the records that define them.||Center||X||X||X||X||CIO||X|
|5.1.8||085||The project manager shall establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable software products.||Center||X||X||X||X||CIO||X|
|5.1.9||045||The project manager shall participate in any joint NASA/developer audits.||Center||X||X||X||CIO||X|
|5.2||Software Risk Management|
|5.2.1||086||The project manager shall record, analyze, plan, track, control, and communicate all of the software risks and mitigation plans.||Center||X||X||X||CIO||X|
|5.3||Software Peer Reviews/Inspections|
|5.3.2||087||The project manager shall perform and report the results of software peer reviews or software inspections for: |
a. Software requirements.
b. Software plans.
c. Any design items that the project identified for software peer review or software inspections according to the software development plans.
d. Software code as defined in the software and or project plans.
e. Software test procedures.
|5.3.3||088||The project manager shall, for each planned software peer review or software inspection: |
a. Use a checklist or formal reading technique (e.g., perspective based reading) to evaluate the work products.
b. Use established readiness and completion criteria.
c. Track actions identified in the reviews until they are resolved.
d. Identify the required participants.
|5.3.4||089||The project manager shall, for each planned software peer review or software inspection, record necessary measurements.||Center||X||X||X||CIO||X|
|5.4.2||090||The project manager shall establish, record, maintain, report, and utilize software management and technical measurements.||Center||X||X||X|
|5.4.3||093||The project manager shall analyze software measurement data collected using documented project-specified and Center/organizational analysis procedures.||Center||X||X||X|
|5.4.4||094||The project manager shall provide access to the software measurement data, measurement analyses, and software development status as requested to the sponsoring Mission Directorate, the NASA Chief Engineer, the Center Technical Authorities, and Headquarters SMA.||Center||X||X||X|
|5.4.5||199||The project manager shall monitor measures to ensure the software will meet or exceed performance and functionality requirements, including satisfying constraints.||Center||X||X||X|
|5.4.6||200||The project manager shall collect, track, and report software requirements volatility metrics.||Center||X||X|
|5.5||Software Non-conformance or Defect Management|
|5.5.1||201||The project manager shall track and maintain software non-conformances (including defects in tools and appropriate ground software).||Center||X||X||X||X||CIO||X|
|5.5.2||202||The project manager shall define and implement clear software severity levels for all software non-conformances (including tools, COTS, GOTS, MOTS, OSS, reused software components, and applicable ground systems).||Center||X||X||X||CIO||X|
|5.5.3||203||The project manager shall implement mandatory assessments of reported non-conformances for all COTS, GOTS, MOTS, OSS, or reused software components.||Center||X||X||X|
|5.5.4||204||The project manager shall implement process assessments for all high severity software non-conformances (closed loop process).||Center||X||X|
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL |
|| NODIS Library | Program Formulation(7000s) | Search ||
This document does not bind the public, except as authorized by law or as incorporated into a contract. This document is uncontrolled when printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: https://nodis3.gsfc.nasa.gov.