...

...

NASA-Wide Software Classifications

Class A      Human-Rated Space Software Systems  

Class B      Non-Human Space-Rated Software Systems or Large-Scale Aeronautics Vehicles

Class C      Mission Support Software or Aeronautic Vehicles, or Major Engineering/Research Facility Software   

Class D      Basic Science/Engineering Design and Research and Technology Software

Class E       Design Concept, Research, Technology, and General Purpose Software   

...

Notes: It is not uncommon for a project to contain multiple systems and subsystems having different software classes. 

c. For existing Class A through E programs and projects, the software engineering requirements of this NPR apply to their current and future phases as determined by the responsible Mission Directorate as approved by the NASA Chief Engineer (or as delegated).

d. For existing Class F programs and projects, the software engineering requirements of this NPR apply to their current and future phases as determined by the Center Chief Information Officer (CIO) and approved by the NASA CIO (or delegate).

e. This NPR can be applied to other NASA investments at the discretion of the responsible manager or the NASA Associate Administrator. This NPR is not retroactively applicable to software development, maintenance, operations, management, acquisition, and assurance activities started before the effective date of this NPR (i.e., existing systems and subsystems containing software for the International Space Station, Hubble, Chandra, etc.).

f. This NPR does not supersede more stringent requirements imposed by individual NASA organizations and other Federal Government agencies or by Federal law.

g. In this NPR, all mandatory actions (i.e., requirements) are denoted by statements containing the term “shall,” followed by a software engineering (SWE) requirement number. The terms “may” or “can” denote discretionary privilege or permission, “should” denotes a good practice and is recommended but not required, “will” denotes expected outcome, and “are/is” denotes descriptive material.
h. In this NPR, all document citations are assumed to be the latest version unless otherwise noted.

P.3 AUTHORITY

a. The National Aeronautics and Space Act, as amended, 51 U.S.C. § 20113(a).
b. NPD 1000.0, NASA Governance and Strategic Management Handbook.
c. NPD 1000.3, The NASA Organization.
d. NPD 1000.5, Policy for NASA Acquisition.
e. NPD 7120.4, NASA Engineering and Program/Project Management Policy.

P.4 APPLICABLE DOCUMENTS AND FORMS

a. NPD 1210.2, NASA Surveys, Audits, and Reviews Policy.
b. NPD 1600.2, NASA Security Policy.
c. NPD 2091.1, Inventions Made By Government Employees.
d. NPD 2800.1, Managing Information Technology.
e. NPR 1600.1, NASA Security Program Procedural Requirements.
f. NPR 2800.2, Information and Communication Technology Accessibility.
g. NPR 2810.1, Security of Information Technology.
h. NPR 7120.5, NASA Space Flight Program and Project Management Requirements.
i. NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements.
j. NPR 7120.8, NASA Research and Technology Program and Project Management Requirements.
k. NPR 8705.2, Human-Rating Requirements for Space Systems.
l. NPR 8705.4, Risk Classification for NASA Payloads.
m. NPR 8715.3, NASA General Safety Program Requirements.
n. NASA-STD-1006, Space System Protection Standard.
o. NASA-STD-8739.8, Software Assurance and Software Safety Standard.
p. NASA-HDBK-2203, NASA Software Engineering Handbook.

P.5 MEASUREMENT/VERIFICATION

Implementation of this directive is defined as implementing all the identified processes, activities, and requirements in accordance with the software classification and approved software tailoring. Compliance with this NPR is verified by submission of the completed Requirements Mapping Matrix(ces) to responsible NASA officials, including any approved tailoring (see Appendix C) and by internal and external controls. Internal controls processes are defined in NPD 1200.1, NASA Internal Control. Internal controls include surveys, audits, and reviews conducted in accordance with NPD 1210.2, NASA Surveys, Audits, and Reviews Policy. External controls may include external surveys, audits, and reporting or contractual requirements.

P.6 CANCELLATION

a. NPR 7150.2C, NASA Software Engineering Requirements, dated August 02, 2019.

b. NASA Interim Directive 7150-113: NASA Interim Directive for Software License Management, dated June 13, 2017.

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.).

...

c. For existing Class A through E programs and projects, the software engineering requirements of this NPR apply to their current and future phases as determined by the responsible Mission Directorate as approved by the NASA Chief Engineer (or as delegated).

d. For existing Class F programs and projects, the software engineering requirements of this NPR apply to their current and future phases as determined by the Center Chief Information Officer (CIO) and approved by the NASA CIO (or delegate).

e. This NPR can be applied to other NASA investments at the discretion of the responsible manager or the NASA Associate Administrator. This NPR is not retroactively applicable to software development, maintenance, operations, management, acquisition, and assurance activities started before the effective date of this NPR (i.e., existing systems and subsystems containing software for the International Space Station, Hubble, Chandra, etc.).

f. This NPR does not supersede more stringent requirements imposed by individual NASA organizations and other Federal Government agencies or by Federal law.

h. In this NPR, all document citations are assumed to be the latest version unless otherwise noted.

P.3 AUTHORITY

a. The National Aeronautics and Space Act, as amended, 51 U.S.C. § 20113(a).
b. NPD 1000.0, NASA Governance and Strategic Management Handbook.
c. NPD 1000.3, The NASA Organization.
d. NPD 1000.5, Policy for NASA Acquisition.
e. NPD 7120.4, NASA Engineering and Program/Project Management Policy.

P.4 APPLICABLE DOCUMENTS AND FORMS

a. NPD 1210.2, NASA Surveys, Audits, and Reviews Policy.
b. NPD 1600.2, NASA Security Policy.
c. NPD 2091.1, Inventions Made By Government Employees.
d. NPD 2800.1, Managing Information Technology.
e. NPR 1600.1, NASA Security Program Procedural Requirements.
f. NPR 2800.2, Information and Communication Technology Accessibility.
g. NPR 2810.1, Security of Information Technology.
h. NPR 7120.5, NASA Space Flight Program and Project Management Requirements.
i. NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements.
j. NPR 7120.8, NASA Research and Technology Program and Project Management Requirements.
k. NPR 8705.2, Human-Rating Requirements for Space Systems.
l. NPR 8705.4, Risk Classification for NASA Payloads.
m. NPR 8715.3, NASA General Safety Program Requirements.
n. NASA-STD-1006, Space System Protection Standard.
o. NASA-STD-8739.8, Software Assurance and Software Safety Standard.
p. NASA-HDBK-2203, NASA Software Engineering Handbook.

P.5 MEASUREMENT/VERIFICATION

Implementation of this directive is defined as implementing all the identified processes, activities, and requirements in accordance with the software classification and approved software tailoring. Compliance with this NPR is verified by submission of the completed Requirements Mapping Matrix(ces) to responsible NASA officials, including any approved tailoring (see Appendix C) and by internal and external controls. Internal controls processes are defined in NPD 1200.1, NASA Internal Control. Internal controls include surveys, audits, and reviews conducted in accordance with NPD 1210.2, NASA Surveys, Audits, and Reviews Policy. External controls may include external surveys, audits, and reporting or contractual requirements.

P.6 CANCELLATION

a. NPR 7150.2C, NASA Software Engineering Requirements, dated August 02, 2019.

b. NASA Interim Directive 7150-113: NASA Interim Directive for Software License Management, dated June 13, 2017.

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.

Chapter 2. Roles, Responsibilities, and Principles Related to Tailoring of the Requirements

2.1 Roles and Responsibilities Associated with this Directive

2.1.1 The NASA Office of the Chief Engineer (OCE).

2.1.1.1 The NASA OCE shall lead and maintain a NASA Software Engineering Initiative to advance software engineering practices. [SWE-

...

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.

Chapter 2. Roles, Responsibilities, and Principles Related to Tailoring of the Requirements

2.1 Roles and Responsibilities Associated with this Directive

2.1.1 The NASA Office of the Chief Engineer (OCE).

2.1.1.1 The NASA OCE shall lead and maintain a NASA Software Engineering Initiative to advance software engineering practices. [SWE-002]

2.1.1.2 The NASA OCE shall periodically benchmark each Center’s software engineering capability against requirements in this directive. [SWE-004]

...

2.1.4 Chief Health and Medical Officer (CHMO)

2.1.4.1 The CHMO is the TA for any requirements which impact health and medical aspects.

2.1.4.2 The CHMO has approval authority of tailoring of software with health and medical implications as documented in NPR 7120.11, Health and Medical Technical Authority Implementation.

2.1.5 Center Director

2.1.4.1 The CHMO is the TA for any requirements which impact health and medical aspects2.1.5.1 In this directive, the phrase “the Center Directors shall...” means that the roles and responsibilities of the Center Directors may be further delegated within the organization consistent with the scope and scale of the system.

2.1.5.2 Center Director, or designee, shall maintain, staff, and implement a plan to continually advance the Center’s in-house software engineering capability and monitor the software engineering capability of NASA’s contractors. [SWE-003]

...

4.2 The CHMO has approval authority of tailoring of software with health and medical implications as documented in NPR 7120.11, Health and Medical Technical Authority Implementation.

2.1.5

...

Center Director

...

2.1.5.4 Center Director, or designee, shall comply with the requirements in this directive that are marked with an “X” in Appendix C. [SWE-140]

Note

Note: The responsibilities for approving changes in the requirements for a project is listed for each requirement in the requirement mapping matrix. When the requirement and software class are marked with an “X,” the projects will record the risk and rationale for any requirement that is not completely implemented by the project. The projects can document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix. Project relief from the applicable cybersecurity requirements, Section 3.11, Software Cybersecurity, has to include an agreement from the SAISO or Center CISO, as designated by the SAISO. The NASA Agency CIO, or Center CIO designee, has institutional authority on all Class F software projects.

...

1 In this directive, the phrase “the Center Directors shall...” means that the roles and responsibilities of the Center Directors may be further delegated within the organization consistent with the scope and scale of the system.

2.1.5.2 Center Director, or designee, shall maintain, staff, and implement a plan to continually advance the Center’s in-house software engineering capability and monitor the software engineering capability of NASA’s contractors. [SWE-003]

Note
Note: The recommended practices and guidelines for the content of a Center Software Engineering Improvement Plan are defined in NASA-HDBK-2203, NASA Software Engineering Handbook. Each Center has a current Center Software Engineering Improvement Plan on file in the NASA Chief Engineer’s office.

2.1.5.6 3 Center Director, or designee, shall maintain a reliable list of their Center’s programs and projects containing Class A, B, C, and D software. The list should include: [SWE-006]

...

establish, document, execute, and maintain software processes per the requirements in this directive. [SWE-005]

2.1.5.4 Center Director, or designee, shall comply with the requirements in this directive that are marked with an “X” in Appendix C. [SWE-140]

Note

Note: The responsibilities for approving changes in the requirements for a project is listed for each requirement in the requirement mapping matrix. When the requirement and software class are marked with an “X,” the projects will record the risk and rationale for any requirement that is not completely implemented by the project. The projects can document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix. Project relief from the applicable cybersecurity requirements, Section 3.11, Software Cybersecurity, has to include an agreement from the SAISO or Center CISO, as designated by the SAISO. The NASA Agency CIO, or Center CIO designee, has institutional authority on all Class F software projects.

2.1.5.5 The Center Director, or designee, shall report on the status of the Center’s software engineering discipline, as applied to its projects, upon request by the OCE, OSMA, or OCHMO. [SWE-095]

2.1.5.6 7 For Class A, B, and C software projects, the Center Director, or designee, shall establish and maintain a software measurement repository for software project measurements containing at a minimumreliable list of their Center’s programs and projects containing Class A, B, C, and D software. The list should include: [SWE-091006]

a. Project/program name and Work Breakdown Structure (WBS) number. Software development tracking data.
b. Software functionality achieved data.
c. Software quality data.
d. Software development effort and cost data.

...

b. Software name(s) and WBS number(s).
c. Software size estimate (report in Kilo/Thousand Source Lines of Code (KSLOCs)).
d. The phase of development or operations.
e. Software Class or list of the software classes being used on the project.
f. Software safety-critical status.
g. For each Computer Software Configuration Item (CSCI)/Major System containing Class A, B,

...

or C software

...

, provide:
     (1) The name of the software development organization.
     (2) Title or brief description of the CSCI/Major System.
     (3) The estimated total KSLOCs, the CSCI/Major System, represents.
     (4) The primary programming languages used.
     (5) The life cycle methodology on the software project.
     (6) Name of responsible software assurance organization(s).

2.1.5.10 7 For Class A, B, and C software projects, each the Center Director, or designee, shall establish and maintain a software cost repository(ies) that contains at least the following measuresmeasurement repository for software project measurements containing at a minimum: [SWE-142091]

a. Planned and actual . Software development tracking data.
b. Software functionality achieved data.
c. Software quality data.
d. Software development effort and cost data.b. Planned and actual schedule dates for major milestones.
c. Both planned and actual values for key cost parameters that typically include software size, requirements count, defects counts for maintenance or sustaining engineering projects, and cost model inputs.
d. Project descriptors or metadata that typically includes software class, software domain/type, and requirements volatility.

2.1.5.8 For Class A, B, and C software projects, the Center Director, or designee, shall utilize software measurement data for monitoring software engineering capability, improving software quality, and to track the status of software engineering improvement activities. [SWE-092]

2.1.5.11 Each 9 Center Director, or designee, shall contribute applicable software engineering process assets in use at his/her Centers to the Agency-wide process asset library. [SWE-144]will maintain and implement software training to advance its in-house software engineering capabilities.

2.1.5.12 The designated ETA(s) shall define the content requirements for software documents or records. [SWE-153].

...

10 For Class A, B, and C software projects, each Center Director, or designee, shall establish and maintain software cost repository(ies) that contains at least the following measures: [SWE-142]

a. Planned and actual effort and cost.
b. Planned and actual schedule dates for major milestones.
c. Both planned and actual values for key cost parameters that typically include software size, requirements count, defects counts for maintenance or sustaining engineering projects, and cost model inputs.
d. Project descriptors or metadata that typically includes software class, software domain/type, and requirements volatility.

2.1.5.13 The 11 Each Center Director, or designee, shall ensure that the Government has clear rights in the software, a Government purpose license, or other appropriate license or permission from third party owners prior to providing the software for internal NASA software sharing or reusecontribute applicable software engineering process assets in use at his/her Centers to the Agency-wide process asset library. [SWE-215144]

2.1.5.14 The Center Director, or designee, shall ensure that all software listed on the internal software sharing or reuse catalog(s) conforms to NASA software engineering policy and requirements12 The designated ETA(s) shall define the content requirements for software documents or records. [SWE-216153]

2.1.5.15 The Center Director, or designee, (e.g., the Civil Servant Technical Point of Contact (POC) for the software product) shall perform the following actions: [SWE-217]

...

.

Note

Note: The recommended practices and guidelines for the content of different types of software activities (whether stand-alone or condensed into one or more project level or software documents or electronic files) are defined in NASA-HDBK-2203. The Center defined content should address prescribed content, format, maintenance instructions, and submittal requirements for all software related records. The designated TA for software approves the required software content for projects within their scope of authority. Electronic submission of data deliverables is preferred. “Software records should be in accordance with NPR 7120.5, NPD 2810.1, NASA Information Security Policy, NPD 2800.1, and NPR 2810.1.”

2.1.5.16 13 The Center Director, or designee (e.g., the Civil Servant Technical POC for the software product) shall perform the following actions for each type of internal NASA software transfer or reuse: [SWE-214], shall ensure that the Government has clear rights in the software, a Government purpose license, or other appropriate license or permission from third party owners prior to providing the software for internal NASA software sharing or reuse. [SWE-215]

2.1.5.14 The Center Director, or designee, shall ensure that all software listed on the internal software sharing or reuse catalog(s) conforms to NASA software engineering policy and requirements. [SWE-216]

2.1.5.15 The Center Director, or designee, (e.g., the Civil Servant Technical Point of Contact (POC) for the software product) shall perform the following actions: [SWE-217]

a. Keep a list of all contributors to the software product.
b. Ensure that the software product contains appropriate disclaimer and indemnification provisions (e.g., in a “README” file) stating that the software may be subject to U.S. export control restrictions, and it is provided “as is” without any warranty, express or implied, and that the recipient waives any claims against, and indemnifies and holds harmless, NASA and its contractors and subcontractors.

2.1.5.16 The Center Director or designee (e.g., the Civil Servant Technical POC for the software product) shall perform the following actions for each type of internal NASA software transfer or reuse: [SWE-214]

a. A NASA civil servant to a NASA civil servanta. A NASA civil servant to a NASA civil servant:
     (1) Verify the requesting NASA civil servant has requested and completed an Acknowledgment (as set forth in the note following paragraph 3.10.2e).
     (2) Provide the software to the requesting NASA civil servant.
b. A NASA civil servant to a NASA contractor:
     (1) Verify a NASA civil servant (e.g., a Contracting Officer (CO) or Contracting Officer Representative (COR)) has confirmed the NASA contractor requires such software for the performance of Government work under their NASA contract and that such performance of work will be a Government purpose. Center Intellectual Property Counsel should be consulted for any questions regarding what is or is not a Government purpose.
     (2) Verify a NASA civil servant (e.g., a CO or COR) has confirmed an appropriate Government Furnished Software clause (e.g., 1852.227-88, “Government-furnished computer software and related technical data”) is in the subject contract (or, if not, that such clause is first added); or the contractor may also obtain access to the software in accordance with the external release requirements of NPR 2210.1, Release of NASA Software.
     (3) Verify NASA contractor is not a foreign person (as defined by 22 CFR §120.16).
     (4) Verify there is a requesting NASA Civil servant (e.g., a CO or COR), and the requesting NASA civil servant has executed an Acknowledgment (as set forth in the note following paragraph 3.10.2e).
     (5) After items (1), (2), (3), and (4) are complete, provide the software to the requesting NASA civil servant. The requesting NASA civil servant is responsible for furnishing the software to the contractor pursuant to the subject contract’s terms.
c. A NASA civil servant to any NASA grantees, Cooperative Agreement Recipients or any other agreement partners or to any other entity under U.S. Government Agency Release, Open source Release, Public Release, U.S. Release, Foreign Release:
     (1) If the release is to any NASA grantees, Cooperative Agreement Recipients, or any other agreement (e.g., Space Act Agreement) partners or to any other entity under U.S. Government Agency Release, an Open source Release, a Public Release, a U.S. Release, or a Foreign Release, the software release is completed in accordance with the external release requirements of NPR 2210.1, Release of NASA Software – Revalidated w/change 1.

2.1.6 Center SMA Director

2.1.6.1 In this document, the phrase “the Center SMA Director will…” means that the roles and responsibilities of the Center SMA Directors may be further delegated within the organization consistent with the scope and scale of the system. The Center SMA Director designates SMA TAs for programs, facilities, and projects, providing direction, functional oversight, and assessment for all Agency safety, reliability, maintainability, and quality engineering and assurance activities, including Software Assurance.

2.1.6.2 The Center SMA Director will assure the project completes thorough hazard analyses which include software.

2.1.6.3 The Center SMA Director, will review the project’s IV&V ’Project Execution Plan (IPEP) to ensure it meets NASA IV&V criteria as defined in NASA-STD-8739.8.

2.1.6.4 The Center SMA Director will support the project to ensure that acquired, developed, and maintained software, as required by SWE-032, is developed by an organization with a non-expired CMMI®-DEV rating as measured by a CMMI® Institute Certified Lead Appraiser.

2.1.6.5 The Center SMA Director will support the Center organizations in obtaining and maintaining the NASA organization’s CMMI®-DEV ratings.

2.1.6.6 The Center SMA Director, or designee, will ensure that the project’s Requirements Mapping Matrix implementation approach does not impact SMA on the project.

2.1.6.7 The Center SMA Director will ensure that any disagreements between software engineering or the project office and software assurance are identified, reported, tracked, and if not resolved, elevated.

2.1.6.8 The designated SMA TA(s) will review, ensure, and concur on software products and processes throughout the project acquisition, development, delivery, operations, and maintenance.

2.1.7 Contracting Officers

2.1.7.1 Contracting Officers, as defined in FAR 2.101, or Agreement Managers as defined in NAII 1050.3, NASA Partnership Guide, in conjunction with Program/Project Managers shall ensure that the appropriate FAR, NFS, and other provisions/clauses based on this requirements document and NASA-STD-8739.8 are included for all NASA contracts, Space Act Agreements, cooperative agreements, partnership agreements, grants, or other agreements pursuant to which software is being acquired, developed, modified, operated, or managed for NASA. [SWE-218]

2.1.8 Technical Authorities

2.1.8.1 The TA(s) or Institutional Authority(s) for requirements in this NPR will be defined per NPR 7120.5, Section 3.3.

2.1.8.2 The technical and institutional authorities for requirements in this directive shall: [SWE-126]

a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by:
     (1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D.
     (2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification.
     (3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied.
     (4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable.
     (5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility.
     (6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see column titled “Authority” in Appendix C).
     (7) Include the SAISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition, and assurance activities.
     (8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.

b. Indicate the Technical Authority or Technical Authorities approval by signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s).

2.2 Principles Related to Tailoring Requirements

2.2.1 Software requirements tailoring is the process used to seek relief from NPR requirements consistent with program or project objectives, acceptable risk, and constraints. To accommodate the wide variety of software systems and subsystems, application of these requirements to specific software development efforts may be tailored where justified and approved. To effectively maintain control over the application of requirements in this directive and to ensure proposed tailoring from specific requirements are appropriately mitigated, NASA established TA governance. Tailoring from requirements in this directive are governed by the following requirements, as well as those defined in NPD 1000.3, The NASA Organization NPD 2800.1, NPR 2810.1, NPR 7120.5, NPR 7120.7, NPR 7120.8, NPR 7120.11 and NPR 8715.3 for all of the Agency’s investment areas. The Technical and Institutional Authority for each requirement in this NPR is documented in the “Authority” column of Appendix C. The responsible program, project, or operations manager need to formally accept the tailoring risk. Tailoring decided at the Center level are to consult the Center ETA, Center SMA TA, Center Health and Medical TA, and the NASA CIO’s Center IT Authority designee as defined in the requirements mapping matrix. The OSMA has co-approval on any tailoring decided at the HQ level that involves software. The Office of the Chief Medical Officer (OCHMO) has co-approval on any tailoring decided that involves software with health and medical implications. The SAISO, or designee, has co-approval on any tailoring of the cybersecurity requirements in Section 3.11. For tailoring involving human safety risk, the actual risk taker(s) (or official spokesperson[s] and appropriate supervisory chain) need to formally agree to assume the risk. ’

Verify the requesting NASA civil servant has requested and completed an Acknowledgment (as set forth in the note following paragraph 3.10.2e).
     (2) Provide the software to the requesting NASA civil servant.
b. A NASA civil servant to a NASA contractor:
     (1) Verify a NASA civil servant (e.g., a Contracting Officer (CO) or Contracting Officer Representative (COR)) has confirmed the NASA contractor requires such software for the performance of Government work under their NASA contract and that such performance of work will be a Government purpose. Center Intellectual Property Counsel should be consulted for any questions regarding what is or is not a Government purpose.
     (2) Verify a NASA civil servant (e.g., a CO or COR) has confirmed an appropriate Government Furnished Software clause (e.g., 1852.227-88, “Government-furnished computer software and related technical data”) is in the subject contract (or, if not, that such clause is first added); or the contractor may also obtain access to the software in accordance with the external release requirements of NPR 2210.1, Release of NASA Software.
     (3) Verify NASA contractor is not a foreign person (as defined by 22 CFR §120.16).
     (4) Verify there is a requesting NASA Civil servant (e.g., a CO or COR), and the requesting NASA civil servant has executed an Acknowledgment (as set forth in the note following paragraph 3.10.2e).
     (5) After items (1), (2), (3), and (4) are complete, provide the software to the requesting NASA civil servant. The requesting NASA civil servant is responsible for furnishing the software to the contractor pursuant to the subject contract’s terms.
c. A NASA civil servant to any NASA grantees, Cooperative Agreement Recipients or any other agreement partners or to any other entity under U.S. Government Agency Release, Open source Release, Public Release, U.S. Release, Foreign Release:
     (1) If the release is to any NASA grantees, Cooperative Agreement Recipients, or any other agreement (e.g., Space Act Agreement) partners or to any other entity under U.S. Government Agency Release, an Open source Release, a Public Release, a U.S. Release, or a Foreign Release, the software release is completed in accordance with the external release requirements of NPR 2210.1, Release of NASA Software – Revalidated w/change 1.

2.1.6 Center SMA Director

2.1.6.1 In this document, the phrase “the Center SMA Director will…” means that the roles and responsibilities of the Center SMA Directors may be further delegated within the organization consistent with the scope and scale of the system. The Center SMA Director designates SMA TAs for programs, facilities, and projects, providing direction, functional oversight, and assessment for all Agency safety, reliability, maintainability, and quality engineering and assurance activities, including Software Assurance.

2.1.6.2 The Center SMA Director will assure the project completes thorough hazard analyses which include software.

2.1.6.3 The Center SMA Director, will review the project’s IV&V ’Project Execution Plan (IPEP) to ensure it meets NASA IV&V criteria as defined in NASA-STD-8739.8.

2.1.6.4 The Center SMA Director will support the project to ensure that acquired, developed, and maintained software, as required by SWE-032, is developed by an organization with a non-expired CMMI®-DEV rating as measured by a CMMI® Institute Certified Lead Appraiser.

2.1.6.5 The Center SMA Director will support the Center organizations in obtaining and maintaining the NASA organization’s CMMI®-DEV ratings.

2.1.6.6 The Center SMA Director, or designee, will ensure that the project’s Requirements Mapping Matrix implementation approach does not impact SMA on the project.

2.1.6.7 The Center SMA Director will ensure that any disagreements between software engineering or the project office and software assurance are identified, reported, tracked, and if not resolved, elevated.

2.1.6.8 The designated SMA TA(s) will review, ensure, and concur on software products and processes throughout the project acquisition, development, delivery, operations, and maintenance.

2.1.7 Contracting Officers

2.1.7.1 Contracting Officers, as defined in FAR 2.101, or Agreement Managers as defined in NAII 1050.3, NASA Partnership Guide, in conjunction with Program/Project Managers shall ensure that the appropriate FAR, NFS, and other provisions/clauses based on this requirements document and NASA-STD-8739.8 are included for all NASA contracts, Space Act Agreements, cooperative agreements, partnership agreements, grants, or other agreements pursuant to which software is being acquired, developed, modified, operated, or managed for NASA. [SWE-218]

2.1.8 Technical Authorities

2.1.8.1 The TA(s) or Institutional Authority(s) for requirements in this NPR will be defined per NPR 7120.5, Section 3.3.

2.1.8.2 The technical and institutional authorities for requirements in this directive shall: [SWE-126]

a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by:
     (1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D.
     (2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification.
     (3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied.
     (4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable.
     (5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility.
     (6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see column titled “Authority” in Appendix C).
     (7) Include the SAISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition, and assurance activities.
     (8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.

b. Indicate the Technical Authority or Technical Authorities approval by signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s).

2.2 Principles Related to Tailoring Requirements

2.2.3 In this directive, the phrase “the project manager shall...” means the roles and responsibilities of the project manager may be further delegated within the organization to the scope and scale of the system.

...

2.2.7 The engineering, CIO, and SMA authorities shall review and agree with any tailored NPR 7150.2 requirements per the requirements mapping matrix authority column. [SWE-150]

...

3.11.3 The project manager shall identify cybersecurity risks, along with their mitigations, in flight and ground software systems and plan the mitigations for these systems. [SWE-154]

3.11.4 The project manager shall implement protections for software systems with communications capabilities against unauthorized access per the requirements contained in the NASA-STD-1006, Space System Protection Standard. [SWE-157]

3.11.5 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. [SWE-159]

3.11.6 4 The project manager shall identify, record, and implement secure coding practicesimplement protections for software systems with communications capabilities against unauthorized access per the requirements contained in the NASA-STD-1006, Space System Protection Standard. [SWE-207157]

3.11.7 5 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). [SWE-185]

3.11.8 The project manager shall identify software requirements for the collection, reporting, and storage of data relating to the detection of adversarial actions. [SWE-210test the software and record test results for the required software cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses analysis. [SWE-159]

3.12 Software Bi-Directional Traceability

3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: [SWE-052]

...

3.11.6 The project manager shall identify, record, and implement secure coding practices. [SWE-207]

3.11.7 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). [SWE-185]

3.11.8 The project manager shall identify software requirements for the collection, reporting, and storage of data relating to the detection of adversarial actions. [SWE-210]

3.12 Software Bi-Directional Traceability

3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: [SWE-052]

Chapter 4: Software Engineering Life Cycle Requirements

4.1 Software Requirements

4.1.1 The requirements phase is one of the most critical phases of software engineering. Studies show that the top problems in the software industry are due to poor requirements elicitation, inadequate requirements specification, and inadequate management of changes to requirements. Requirements provide the foundation for the entire life cycle, as well as for the software product. Requirements also provide a basis for planning, estimating, and monitoring. Requirements are based on customer, user, and other stakeholder needs and design and development constraints. The development of requirements includes elicitation, analysis, documentation, verification, and validation. Ongoing customer validation of the requirements to ensure the end products meet customer needs is an integral part of the life cycle process. Customer validation can be accomplished via rapid prototyping and customer-involved reviews of iterative and final 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-050]

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-051]

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. [SWE-184]

4.1.5 The project manager shall track and manage changes to the software requirements. [SWE-053]

4.1.6 The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products. [SWE-054]

4.1.7 The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment. [SWE-055]

4.2 Software Architecture

4.2.1 Experience confirms that the quality and longevity of a software-reliant system is primarily determined by its architecture. The software architecture underpins a system’s software design and code; it represents the earliest design decisions, ones that are difficult and costly to change later. The transformation of the derived and allocated requirements into the software architecture results in the basis for all software development work.

4.2.2 A software architecture:

a. Formalizes precise subsystem decompositions.
b. Defines and formalizes the dependencies among software work products within the integrated system.
c. Serves as the basis for evaluating the impacts of proposed changes.
d. Maintains rules for use by subsequent software engineers that ensure a consistent software system as the work products evolve.
e. Provides a stable structure for use by future groups through the documentation of the architecture, its views and patterns, and its rules.
f. Follows guidelines created by the NASA Space Asset and the Enterprise Protection Program to protect mission architectures.
g. Documents the valid and invalid modes or states of operation within the software requirements.

4.2.3 The project manager shall transform the requirements for the software into a recorded software architecture. [SWE-057]

4.2.4 The project manager shall perform a software architecture review on the following categories of projects: [SWE-143]

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 Software Design

...

Chapter 4: Software Engineering Life Cycle Requirements

4.1 Software Requirements

4.1.1 The requirements phase is one of the most critical phases of software engineering. Studies show that the top problems in the software industry are due to poor requirements elicitation, inadequate requirements specification, and inadequate management of changes to requirements. Requirements provide the foundation for the entire life cycle, as well as for the software product. Requirements also provide a basis for planning, estimating, and monitoring. Requirements are based on customer, user, and other stakeholder needs and design and development constraints. The development of requirements includes elicitation, analysis, documentation, verification, and validation. Ongoing customer validation of the requirements to ensure the end products meet customer needs is an integral part of the life cycle process. Customer validation can be accomplished via rapid prototyping and customer-involved reviews of iterative and final 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-050]

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-051]

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. [SWE-184]

4.1.5 The project manager shall track and manage changes to the software requirements. [SWE-053]

4.1.6 The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products. [SWE-054]

4.1.7 The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment. [SWE-055]

4.2 Software Architecture

4.2.1 Experience confirms that the quality and longevity of a software-reliant system is primarily determined by its architecture. The software architecture underpins a system’s software design and code; it represents the earliest design decisions, ones that are difficult and costly to change later. The transformation of the derived and allocated requirements into the software architecture results in the basis for all software development work.

4.2.2 A software architecture:

a. Formalizes precise subsystem decompositions.
b. Defines and formalizes the dependencies among software work products within the integrated system.
c. Serves as the basis for evaluating the impacts of proposed changes.
d. Maintains rules for use by subsequent software engineers that ensure a consistent software system as the work products evolve.
e. Provides a stable structure for use by future groups through the documentation of the architecture, its views and patterns, and its rules.
f. Follows guidelines created by the NASA Space Asset and the Enterprise Protection Program to protect mission architectures.
g. Documents the valid and invalid modes or states of operation within the software requirements.

4.2.3 The project manager shall transform the requirements for the software into a recorded software architecture. [SWE-057]

4.2.4 The project manager shall perform a software architecture review on the following categories of projects: [SWE-143]

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 Software Design

4.3.1 Software design is the process of defining the software architecture, components, modules, interfaces, and data for a software system to satisfy specified requirements. The software architecture is the fundamental organization of a system embodied in its components, their relationships to each other and the environment, and the principles guiding its design and evolution. The software architectural design is concerned with creating a strong overall structure for software entities that fulfill the allocated system and software-level requirements. Typical views captured in an architectural design include the decomposition of the software subsystem into design entities, computer software configuration items, definitions of external and internal interfaces, dependency relationships among entities and system resources, and finite state machines. The design should be further refined into lower-level entities that permit the implementation by coding in a programming language. Typical attributes that are documented for lower-level entities include the identifier, type, purpose, function, constraints, subordinates, dependencies, interface, resources, processing, and data. Rigorous specification languages, graphical representations, and related tools have been developed to support the evaluation of critical properties at the design level. Projects are encouraged to take advantage of these improved design techniques to prevent and eliminate errors as early in the life cycle as possible. Software, developed or purchased, has additional requirements to comply with from Section 508 of the Rehabilitation Act, as defined inNPR 2800.2.

4.3.2 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. [SWE-058]

4.4 Software Implementation

...