| NODIS Library | Program Formulation(7000s) | Search |

NASA Ball NASA
Procedural
Requirements
NPR 7150.2D
Effective Date: March 08, 2022
Expiration Date: March 08, 2027
COMPLIANCE IS MANDATORY FOR NASA EMPLOYEES
Printable Format (PDF)

Subject: NASA Software Engineering Requirements

Responsible Office: Office of the Chief Engineer


| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL |

Chapter 1: Introduction

1.1 Overview

1.1.1 This directive imposes requirements on procedures, design considerations, activities, and tasks used to acquire, develop, maintain, operate, retire, and manage applicable software. This directive is a designed set of requirements for protecting the ’Agency’s investment in software engineering products and fulfilling our responsibility to the citizens of the United States (U.S.).

1.1.2 The requirements in this directive have been extracted from industry standards and proven NASA experience in software engineering. Centers and software developers may show that many of the requirements are satisfied through existing programs, procedures, and processes.

1.1.3 The Agency makes significant investments in software engineering to support the Agency’s investment areas: Space Flight, Aeronautics, Research and Technology, Information Technology (IT), and Institutional Infrastructure. NASA ensures that programs, projects, systems, and subsystems that use software follow a standard set of requirements. One of the goals of this directive is to bring the Agency’s engineering and software development and management communities together to optimize resources and talents across Center boundaries. For NASA to effectively communicate and work seamlessly across Centers, a common framework of generic requirements is needed. This directive fulfills this need for the Agency within the discipline of software engineering.

1.1.4 This directive does not require a specific software life cycle model. Where this NPR refers to phases and milestone reviews in the software life cycle, it uses the standard NASA life cycle models described in NPR 7120.5, NASA Space Flight Program and Project Management Requirements, NPR 7120.7, NASA Information Technology Program and Project Management Requirements, and NPR 7120.8, NASA Research and Technology Program and Project Management Requirements, as supported by milestone reviews described in NPR 7123.1, NASA Systems Engineering Processes and Requirements.

1.1.5 NASA is committed to instituting and updating these requirements to meet the Agency’s current and future challenges in software engineering. Successful experiences are codified in updated versions of this directive after experience has been gained through its use within the NASA software community, the collection of lessons learned from projects, and the implementation records of the Engineering Technical Authorities (ETAs).

1.2 Hierarchy of NASA Software-Related Engineering and Program/Project Documents

1.2.1 Agency-Level Software Policies and Requirements

NPD 7120.4, NASA Engineering and Program/Project Management Policy, is an overarching directive that establishes top-level policies for all software created, acquired, or maintained by or for NASA, including Commercial-off-the-shelf (COTS) software, Government-off-the-shelf (GOTS) software, and Modified-off-the-shelf (MOTS) software and open-source software, embedded software, reused software, legacy software, and heritage software. This directive supports the implementation of NPD 7120.4, and establishes the Agency set of software engineering requirements for software acquisition, development, maintenance, retirement, operations, and management. It provides a set of software engineering requirements in generic terms for use by NASA, contractors, grant recipients, or parties to agreements. Additional Agency-level project management requirements and systems engineering requirements exist that influence and affect the software development activities on a project. In the event of a conflict between an NPD and NPR, the NPD takes precedence.

1.2.2 Agency-Level Multi-Center and Product Line Requirements (non-software specific)

Existing Agency-Level NPDs and NPRs elaborate, tailor, and in some cases add requirements to those above to address the needs of major multi-Center projects, specific product lines, and specific focus areas. Examples of representative NPRs in this category are NPR 8705.2, Human-Rating Requirements for Space Systems, NPR 8715.3, NASA General Safety Program Requirements, NPR 8735.2, Hardware Quality Assurance Program Requirements for Programs and Projects, NPR 7120.5, NPR7123.1, NPD 2800.1, Managing Information Technology, NPR 2800.2, Information and Communication Technology Accessibility, and NPR 2810.1, Security of Information Technology.

1.2.3 Center-Level Directives or Requirements (related to software)

Center-level directives or requirements are developed by NASA Centers to document their local software policies, requirements, and procedures. These directives are responsive to the higher-level requirements while addressing the specific application areas and the Center’s mission within the Agency. In the event of a conflict between this NPR with a Center-level directive, the information provided in this NPR takes precedence.

1.3 Document Structure

1.3.1 Chapter 2 describes the roles, responsibilities, and institutional requirements relevant to the requirements in this directive. This chapter describes the responsibilities for maintaining and advancing organizational capability in software engineering practices to effectively meet the scientific and technological objectives of the Agency. It defines the roles and responsibilities of key officials in software engineering management, the software development and management processes, and the software life cycle management processes. Specific software classification applicability, if any, for the requirements in Chapter 2 are contained in the requirement wording. The requirements in Chapter 2 are not part of the Requirements Mapping Matrix in Appendix C. Approval of any tailoring of requirements designated in Chapter 2 can be done by the appropriate organization per the defined roles and responsibilities.

1.3.2 Chapter 3 establishes software management requirements. The software management activities define and control the many software aspects of a project from beginning to end. The software management activities include the required interfaces to other organizations, determination of deliverables, cost estimates, tracking of schedules, risk management, formal and informal reviews, as well as other forms of verification and validation, and determination of the amount of supporting services. The planned management of these activities is captured in one or more software or system plans.

1.3.3 Chapter 4 provides the software engineering life cycle requirements. This directive makes no recommendation for a specific software life cycle model. Each has its strengths and weaknesses, and no one model is best for every situation. Whether using the agile methods, spiral model, the iterative model, waterfall, or any other development life cycle model, each has its own set of requirements, design, implementation, testing, release to operations, maintenance, and retirement. Although this directive does not impose a particular life cycle model on each software project, it does support a standard set of life cycle phases. Use of the different phases of a life cycle allows the various products of a project to be gradually developed and matured from initial concepts through the fielding of the product and to its final retirement.

1.3.4 Chapter 5 provides supporting software life cycle requirements. Unlike development processes, support processes are not targeted primarily at a specific phase of the project life cycle but typically occur with similar intensity throughout the complete project or product life cycle. For example, normal configuration management baselines (e.g., requirements, code, and products) happen across the life cycle, as does cybersecurity. Support processes are software management and engineering processes that support the entire software life cycle: Software Configuration Management, Risk Management, Peer Reviews, Inspections, Software Measurement, and Non-conformance and Defect Management.

1.3.5 Chapter 6 provides a list of the recommended software records.

1.3.6 Appendix A provides definitions.

1.3.7 Appendix B provides acronyms used in this directive.

1.3.8 Appendix C contains the Requirements Mapping Matrix.

1.3.9 Appendix D contains software classifications.

1.3.10 Appendix E contains software references for this directive.



| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL |
 
| NODIS Library | Program Formulation(7000s) | Search |

DISTRIBUTION:
NODIS


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.