Note: Lists below contain SWEs from both "B. Institutional Requirements" and "C. Project Software Requirements".
All SWEs in Numeric Order
SWE-002 - Software Engineering Initiative
SWE-003 - Center Improvement Plans
SWE-004 - OCE Benchmarking
SWE-005 - Software Processes
SWE-006 - Center Software Inventory
SWE-013 - Software Plans
SWE-015 - Cost Estimation
SWE-016 - Software Schedule
SWE-017 - Project and Software Training
SWE-018 - Software Activities Review
SWE-020 - Software Classification
SWE-021 - Transition to a Higher Class
SWE-022 - Software Assurance
SWE-023 - Software Safety-Critical Requirements
SWE-024 - Plan Tracking
SWE-027 - Use of Commercial, Government, and Legacy Software
SWE-032 - CMMI Levels for Class A and B Software
SWE-033 - Acquisition vs. Development Assessment
SWE-034 - Acceptance Criteria
SWE-036 - Software Process Determination
SWE-037 - Software Milestones
SWE-039 - Software Supplier Insight
SWE-040 - Access to Software Products
SWE-042 - Source Code Electronic Access
SWE-045 - Project Participation in Audits
SWE-046 - Supplier Software Schedule
SWE-050 - Software Requirements
SWE-051 - Software Requirements Analysis
SWE-052 - Bidirectional Traceability
SWE-053 - Manage Requirements Changes
SWE-054 - Corrective Action for Inconsistencies
SWE-055 - Requirements Validation
SWE-057 - Software Architecture
SWE-058 - Detailed Design
SWE-060 - Coding Software
SWE-061 - Coding Standards
SWE-062 - Unit Test
SWE-063 - Release Version Description
SWE-065 - Test Plan, Procedures, Reports
SWE-066 - Perform Testing
SWE-068 - Evaluate Test Results
SWE-070 - Models, Simulations, Tools
SWE-071 - Update Test Plans and Procedures
SWE-073 - Platform or Hi-Fidelity Simulations
SWE-075 - Plan Operations, Maintenance, Retirement
SWE-077 - Deliver Software Products
SWE-079 - Develop CM Plan
SWE-080 - Track and Evaluate Changes
SWE-081 - Identify Software CM Items
SWE-082 - Authorizing Changes
SWE-083 - Status Accounting
SWE-084 - Configuration Audits
SWE-085 - Release Management
SWE-086 - Continuous Risk Management
SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures
SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking
SWE-089 - Software Peer Reviews and Inspections - Basic Measurements
SWE-090 - Management and Technical Measurements
SWE-091 - Establish and Maintain Measurement Repository
SWE-092 - Using Measurement Data
SWE-093 - Analysis of Measurement Data
SWE-094 - Reporting of Measurement Analysis
SWE-095 - Report Engineering Discipline Status
SWE-098 - Agency Process Asset Library
SWE-100 - Software Training Funding
SWE-121 - Document Tailored Requirements
SWE-125 - Requirements Compliance Matrix
SWE-126 - Tailoring Considerations
SWE-129 - OCE NPR Appraisals
SWE-131 - Independent Verification and Validation Project Execution Plan
SWE-134 - Safety-Critical Software Design Requirements
SWE-135 - Static Analysis
SWE-136 - Software Tool Accreditation
SWE-139 - Shall Statements
SWE-140 - Comply with Requirements
SWE-141 - Software Independent Verification and Validation
SWE-142 - Software Cost Repositories
SWE-143 - Software Architecture Review
SWE-144 - Software Engineering Process Assets
SWE-146 - Auto-generated Source Code
SWE-147 - Specify Reusability Requirements
SWE-148 - Contribute to Agency Software Catalog
SWE-150 - Review Changes To Tailored Requirements
SWE-151 - Cost Estimate Conditions
SWE-152 - Review Requirements Mapping Matrices
SWE-153 - ETA Define Document Content
SWE-154 - Identify Security Risks
SWE-156 - Evaluate Systems for Security Risks
SWE-157 - Protect Against Unauthorized Access
SWE-159 - Verify and Validate Risk Mitigations
SWE-174 - Software Planning Parameters
SWE-176 - Software Records
SWE-178 - IV&V Artifacts
SWE-179 - IV&V Submitted Issues and Risks
SWE-184 - Software-related Constraints and Assumptions
SWE-185 - Secure Coding Standards Verification
SWE-186 - Unit Test Repeatability
SWE-187 - Control of Software Items
SWE-189 - Code Coverage Measurements
SWE-190 - Verify Code Coverage
SWE-191 - Software Regression Testing
SWE-192 - Software Hazardous Requirements
SWE-193 - Acceptance Testing for Affected System and Software Behavior
SWE-194 - Delivery Requirements Verification
SWE-195 - Software Maintenance Phase
SWE-196 - Software Retirement Archival
SWE-199 - Performance Measures
SWE-200 - Software Requirements Volatility Metrics
SWE-201 - Software Non-Conformances
SWE-202 - Software Severity Levels
SWE-203 - Mandatory Assessments for Non-Conformances
SWE-204 - Process Assessments
SWE-205 - Determination of Safety-Critical Software
SWE-206 - Auto-Generation Software Inputs
SWE-207 - Secure Coding Practices
SWE-208 - Advancing Software Assurance and Software Safety Practices
SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities
SWE-210 - Detection of Adversarial Actions
SWE-211 - Test Levels of Non-Custom Developed Software
SWE-212 - NASA-STD-8739 Mapping Matrices
SWE-214 - Internal Software Sharing and Reuse
SWE-215 - Software License Rights
SWE-216 - Internal Software Sharing List
SWE-217 - List of All Contributors and Disclaimer Notice
SWE-218 - Contracting Officers
SWE-219 - Code Coverage for Safety Critical Software
SWE-220 - Cyclomatic Complexity for Safety-Critical Software
SWE-221 - OSMA NPR Appraisals
SWE-222 - Software Assurance Training
SWE-223 - Tailoring IV&V project selections
All SWEs and Requirements in Numeric Order
SWE-002 - Software Engineering Initiative
2.1.1.1 The NASA OCE shall lead and maintain a NASA Software Engineering Initiative to advance software engineering practices.
SWE-003 - Center Improvement Plans
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-004 - OCE Benchmarking
2.1.1.2 The NASA OCE shall periodically benchmark each Center's software engineering capability against requirements in this directive.
SWE-005 - Software Processes
2.1.5.3 Center Director, or designee, shall establish, document, execute, and maintain software processes per the requirements in this directive.
SWE-006 - Center Software Inventory
2.1.5.6 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:
a. Project/program name and Work Breakdown Structure (WBS) number.
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).
SWE-013 - Software Plans
3.1.3 The project manager shall develop, maintain, and execute software plans, including security plans, that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring.
SWE-015 - Cost Estimation
3.2.1 To better estimate the cost of development, the project manager shall establish, document, and maintain:
- 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.
- 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.
- One software cost estimate model and associated cost parameter(s) for all Class C and Class D software projects.
- One software cost estimate model and associated cost parameter(s) for all Class F software projects.
SWE-016 - Software Schedule
3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:
- Coordinates with the overall project schedule.
- Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
- Reflects the critical dependencies for software development activities.
- Identifies and accounts for dependencies with other projects and cross-program dependencies.
SWE-017 - Project and Software Training
3.4.1 The project manager shall plan, track, and ensure project specific software training for project personnel.
SWE-018 - Software Activities Review
3.3.2 The project manager shall regularly hold reviews of software schedule activities, status, performance metrics, and assessment/analysis results with the project stakeholders and track issues to resolution.
SWE-020 - Software Classification
3.5.1 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.
SWE-021 - Transition to a Higher Class
2.2.8 If a system or subsystem development evolves to meet a higher or lower software classification as defined in Appendix D, then the project manager shall update their plan(s) and initiate modifications to any supplier contracts to fulfill the applicable requirements per the Requirements Mapping Matrix in Appendix C with approved tailoring.
SWE-022 - Software Assurance
3.6.1 The project manager shall plan and implement software assurance, software safety, and IV&V (if required) per NASA-STD-8739.8, Software Assurance and Software Safety Standard.
SWE-023 - Software Safety-Critical Requirements
3.7.2 If a project has safety-critical software, the project manager shall implement the safety-critical software requirements contained in NASA-STD-8739.8.
SWE-024 - Plan Tracking
3.1.4 The project manager shall track the actual results and performance of software activities against the software plans.
- Corrective actions are taken, recorded, and managed to closure.
- Changes to commitments (e.g., software plans) that have been agreed to by the affected groups and individuals are taken, recorded, and managed.
SWE-027 - Use of Commercial, Government, and Legacy Software
3.1.14 The project manager shall satisfy the following conditions when a COTS, GOTS, MOTS, OSS, 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, transfer rights, and conditions of use (e.g., required copyright, author, and applicable license notices within the software code, or a requirement to redistribute the licensed software only under the same license (e.g., GNU GPL, ver. 3, license)) have been addressed and coordinated with Center Intellectual Property Counsel.
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.
SWE-032 - CMMI Levels for Class A and B Software
3.9.2 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:
- For Class A software: CMMI-DEV Maturity Level 3 Rating or higher for software.
- For Class B software (except Class B software on NASA Class D payloads, as defined in NPR 8705.4): CMMI-DEV Maturity Level 2 Rating or higher for software.
SWE-033 - Acquisition vs. Development Assessment
3.1.2 The project manager shall assess options for software acquisition versus development.
SWE-034 - Acceptance Criteria
3.1.5 The project manager shall define and document the acceptance criteria for the software.
SWE-036 - Software Process Determination
3.1.6 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.
SWE-037 - Software Milestones
3.1.7 The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited.
SWE-039 - Software Supplier Insight
3.1.8 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:
- Monitor product integration.
- Review the verification activities to ensure adequacy.
- Review trade studies and source data.
- Audit the software development processes and practices.
- Participate in software reviews and technical interchange meetings.
SWE-040 - Access to Software Products
3.1.9 The project manager shall require the software developer(s) to provide NASA with software products, traceability, software change tracking information, and non-conformances in electronic format, including software development and management metrics.
SWE-042 - Source Code Electronic Access
3.1.10 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.
SWE-045 - Project Participation in Audits
5.1.9 The project manager shall participate in any joint NASA/developer audits.
SWE-046 - Supplier Software Schedule
3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested.
SWE-050 - Software Requirements
4.1.2 The project manager shall establish, capture, record, approve, and maintain software requirements, including requirements for COTS, GOTS, MOTS, OSS, or reused software components, as part of the technical specification.
SWE-051 - Software Requirements Analysis
4.1.3 The project manager shall perform software requirements analysis based on flowed down and derived requirements from the top-level systems engineering requirements, safety and reliability analyses, and the hardware specifications and design.
SWE-052 - Bidirectional Traceability
3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements:
Bi-directional Traceability | Class A, B, and C | Class D | Class F |
Higher-level requirements to the software requirements | X | X | |
Software requirements to the system hazards | X | X | |
Software requirements to the software design components | X | ||
Software design components to the software code | X | ||
Software requirements to the software verification(s) | X | X | X |
Software requirements to the software non-conformances | X | X | X |
SWE-053 - Manage Requirements Changes
4.1.5 The project manager shall track and manage changes to the software requirements.
SWE-054 - Corrective Action for Inconsistencies
4.1.6 The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products.
SWE-055 - Requirements Validation
4.1.7 The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment.
SWE-057 - Software Architecture
4.2.3 The project manager shall transform the requirements for the software into a recorded software architecture.
SWE-058 - Detailed Design
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-060 - Coding Software
4.4.2 The project manager shall implement the software design into software code.
SWE-061 - Coding Standards
4.4.3 The project manager shall select, define, and adhere to software coding methods, standards, and criteria.
SWE-062 - Unit Test
4.4.5 The project manager shall unit test the software code.
SWE-063 - Release Version Description
4.4.7 The project manager shall provide a software version description for each software release.
SWE-065 - Test Plan, Procedures, Reports
4.5.2 The project manager shall establish and maintain:
a. Software test plan(s).
b. Software test procedure(s).
c. Software test(s), including any code specifically written to perform test procedures.
d. Software test report(s).
SWE-066 - Perform Testing
4.5.3 The project manager shall test the software against its requirements.
SWE-068 - Evaluate Test Results
4.5.5 The project manager shall evaluate test results and record the evaluation.
SWE-070 - Models, Simulations, Tools
4.5.6 The project manager shall use validated and accredited software models, simulations, and analysis tools required to perform qualification of flight software or flight equipment.
SWE-071 - Update Test Plans and Procedures
4.5.7 The project manager shall update the software test and verification plan(s) and procedure(s) to be consistent with software requirements.
SWE-073 - Platform or Hi-Fidelity Simulations
4.5.8 The project manager shall validate the software system on the targeted platform or high-fidelity simulation.
SWE-075 - Plan Operations, Maintenance, Retirement
4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.
SWE-077 - Deliver Software Products
4.6.3 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.
SWE-079 - Develop CM Plan
5.1.2 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.
SWE-080 - Track and Evaluate Changes
5.1.3 The project manager shall track and evaluate changes to software products.
SWE-081 - Identify Software CM Items
5.1.4 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.
SWE-082 - Authorizing Changes
5.1.5 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.
SWE-083 - Status Accounting
5.1.6 The project manager shall prepare and maintain records of the configuration status of software configuration items.
SWE-084 - Configuration Audits
5.1.7 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.
SWE-085 - Release Management
5.1.8 The project manager shall establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable software products.
SWE-086 - Continuous Risk Management
5.2.1 The project manager shall record, analyze, plan, track, control, and communicate all of the software risks and mitigation plans.
SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures
5.3.2 The project manager shall perform and report the results of software peer reviews or software inspections for:
a. Software requirements.
b. Software plans, including cybersecurity.
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.
SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking
5.3.3 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.
SWE-089 - Software Peer Reviews and Inspections - Basic Measurements
5.3.4 The project manager shall, for each planned software peer review or software inspection, record necessary measurements.
SWE-090 - Management and Technical Measurements
5.4.2 The project manager shall establish, record, maintain, report, and utilize software management and technical measurements.
SWE-091 - Establish and Maintain Measurement Repository
2.1.5.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 minimum:
a. Software development tracking data.
b. Software functionality achieved data.
c. Software quality data.
d. Software development effort and cost data.
SWE-092 - Using Measurement Data
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-093 - Analysis of Measurement Data
5.4.3 The project manager shall analyze software measurement data collected using documented project-specified and Center/organizational analysis procedures.
SWE-094 - Reporting of Measurement Analysis
5.4.4 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, HQ SMA, and other organizations as appropriate.
SWE-095 - Report Engineering Discipline Status
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-098 - Agency Process Asset Library
2.1.1.6 The NASA OCE shall maintain an Agency-wide process asset library of applicable best practices and process templates for all size projects.
SWE-100 - Software Training Funding
2.1.1.5 The NASA OCE and Center training organizations shall provide training to advance software engineering practices.
SWE-121 - Document Tailored Requirements
3.1.12 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.
SWE-125 - Requirements Compliance Matrix
3.1.13 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.
SWE-126 - Tailoring Considerations
2.1.8.2 The technical and institutional authorities for requirements in this directive shall:
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).
SWE-129 - OCE NPR Appraisals
2.1.1.4 The NASA OCE shall authorize appraisals against selected requirements in this NPR to check compliance.
SWE-131 - Independent Verification and Validation Project Execution Plan
3.6.3 If software IV&V is required for a project, the project manager, in consultation with NASA IV&V, shall ensure an IPEP is developed, approved, maintained, and executed in accordance with IV&V requirements in NASA-STD-8739.8.
SWE-134 - Safety-Critical Software Design Requirements
3.7.3 If a project has safety-critical software or mission-critical software, the project manager shall implement the following items in the software:
a. The software is initialized, at first start and restarts, to a known safe state.
b. The software safely transitions between all predefined known states.
c. Termination performed by software functions is performed to a known safe state.
d. Operator overrides of software functions require at least two independent actions by an operator.
e. Software rejects commands received out of sequence when execution of those commands out of sequence can cause a hazard.
f. The software detects inadvertent memory modification and recovers to a known safe state.
g. The software performs integrity checks on inputs and outputs to/from the software system.
h. The software performs prerequisite checks prior to the execution of safety-critical software commands.
i. No single software event or action is allowed to initiate an identified hazard.
j. The software responds to an off-nominal condition within the time needed to prevent a hazardous event.
k. The software provides error handling.
l. The software can place the system into a safe state.
SWE-135 - Static Analysis
4.4.4 The project manager shall use static analysis tools to analyze the code during the development and testing phases to, at a minimum, detect defects, software security, code coverage, and software complexity.
SWE-136 - Software Tool Accreditation
4.4.8 The project manager shall validate and accredit the software tool(s) required to develop or maintain software.
SWE-139 - Shall Statements
3.1.11 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.
SWE-140 - Comply with Requirements
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-141 - Software Independent Verification and Validation
3.6.2 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, Risk Classification for NASA Payloads.
c. Projects selected explicitly by the Mission Directorate Associate Administrator (MDAA) to have software IV&V.
SWE-142 - Software Cost Repositories
2.1.5.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:
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.
SWE-143 - Software Architecture Review
4.2.4 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.
SWE-144 - Software Engineering Process Assets
2.1.5.11 Each 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-146 - Auto-generated Source Code
3.8.1 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.
SWE-147 - Specify Reusability Requirements
3.10.1 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 U.S. Government purposes.
SWE-148 - Contribute to Agency Software Catalog
3.10.2 The project manager shall evaluate software for potential reuse by other projects across NASA and contribute reuse candidates to the appropriate NASA internal sharing and reuse software system. However, if the project manager is not a civil servant, then a civil servant will 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 POC 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 and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
f. Release notes.
SWE-150 - Review Changes To Tailored Requirements
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-151 - Cost Estimate Conditions
3.2.2 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., programmatic assumptions/constraints, 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 end state risk and threat assessments for cybersecurity.
e. Includes the cost of the required software assurance support.
f. Includes other direct costs.
SWE-152 - Review Requirements Mapping Matrices
2.1.1.3 The NASA OCE shall periodically review the project requirements mapping matrices.
SWE-153 - ETA Define Document Content
2.1.5.12 The designated ETA(s) shall define the content requirements for software documents or records.
SWE-154 - Identify Security Risks
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-156 - Evaluate Systems for Security Risks
3.11.2 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.
SWE-157 - Protect Against Unauthorized Access
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-159 - Verify and Validate Risk Mitigations
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-174 - Software Planning Parameters
3.2.3 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.
SWE-176 - Software Records
3.5.2 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.
SWE-178 - IV&V Artifacts
3.6.4 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.
SWE-179 - IV&V Submitted Issues and Risks
3.6.5 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.
SWE-184 - Software-related Constraints and Assumptions
4.1.4 The project manager shall include software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software in the software requirements documentation.
SWE-185 - Secure Coding Standards Verification
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-186 - Unit Test Repeatability
4.4.6 The project manager shall assure that the unit test results are repeatable.
SWE-187 - Control of Software Items
4.5.4 The project manager shall place software items under configuration management prior to testing.
SWE-189 - Code Coverage Measurements
4.5.9 The project manager shall ensure that the code coverage measurements for the software are selected, implemented, tracked, recorded, and reported.
SWE-190 - Verify Code Coverage
4.5.10 The project manager shall verify code coverage is measured by analysis of the results of the execution of tests.
SWE-191 - Software Regression Testing
4.5.11 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.
SWE-192 - Software Hazardous Requirements
4.5.12 The project manager shall verify through test the software requirements that trace to a hazardous event, cause, or mitigation technique.
SWE-193 - Acceptance Testing for Affected System and Software Behavior
4.5.13 The project manager shall develop acceptance tests for loaded or uplinked data, rules, and code that affects software and software system behavior.
SWE-194 - Delivery Requirements Verification
4.6.4 The project manager shall complete, prior to delivery, verification that all software requirements identified for this delivery have been met or dispositioned, that all approved changes have been implemented, and that all defects designated for resolution prior to delivery have been resolved.
SWE-195 - Software Maintenance Phase
4.6.5 The project manager shall maintain the software using standards and processes per the applicable software classification throughout the maintenance phase.
SWE-196 - Software Retirement Archival
4.6.6 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.
SWE-199 - Performance Measures
5.4.5 The project manager shall monitor measures to ensure the software will meet or exceed performance and functionality requirements, including satisfying constraints.
SWE-200 - Software Requirements Volatility Metrics
5.4.6 The project manager shall collect, track, and report software requirements volatility metrics.
SWE-201 - Software Non-Conformances
5.5.1 The project manager shall track and maintain software non-conformances (including defects in tools and appropriate ground software).
SWE-202 - Software Severity Levels
5.5.2 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).
SWE-203 - Mandatory Assessments for Non-Conformances
5.5.3 The project manager shall implement mandatory assessments of reported non-conformances for all COTS, GOTS, MOTS, OSS, and/or reused software components.
SWE-204 - Process Assessments
5.5.4 The project manager shall implement process assessments for all high-severity software non-conformances (closed-loop process).
SWE-205 - Determination of Safety-Critical Software
3.7.1 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.
SWE-206 - Auto-Generation Software Inputs
3.8.2 The project manager shall require the software developers and custom software suppliers to provide NASA with electronic access to the models, simulations, and associated data used as inputs for auto-generation of software.
SWE-207 - Secure Coding Practices
3.11.6 The project manager shall identify, record, and implement secure coding practices.
SWE-208 - Advancing Software Assurance and Software Safety Practices
2.1.2.2 The NASA Chief, SMA shall lead and maintain a NASA Software Assurance and Software Safety Initiative to advance software assurance and software safety practices.
SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities
2.1.2.3 The NASA Chief, SMA shall periodically benchmark each Center’s software assurance and software safety capabilities against the NASA-STD-8739.8, NASA Software Assurance and Software Safety Standard.
SWE-210 - Detection of Adversarial Actions
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-211 - Test Levels of Non-Custom Developed Software
4.5.14 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.
SWE-212 - NASA-STD-8739 Mapping Matrices
2.1.2.4 The NASA Chief, SMA shall periodically review the project’s requirements mapping matrices.
SWE-214 - Internal Software Sharing and Reuse
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:
a. 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.
SWE-215 - Software License Rights
2.1.5.13 The 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 reuse.
SWE-216 - Internal Software Sharing List
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-217 - List of All Contributors and Disclaimer Notice
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:
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.
SWE-218 - 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-219 - Code Coverage for Safety Critical Software
3.7.4 If a project has safety-critical software, the project manager shall ensure that there is 100 percent code test coverage using the Modified Condition/Decision Coverage (MC/DC) criterion for all identified safety-critical software components.
SWE-220 - Cyclomatic Complexity for Safety-Critical Software
3.7.5 If a project has safety-critical software, the project manager shall ensure all identified safety-critical software components have a cyclomatic complexity value of 15 or lower. Any exceedance shall be reviewed and waived with rationale by the project manager or technical approval authority.
SWE-221 - OSMA NPR Appraisals
2.1.2.5 The NASA Chief, SMA shall authorize appraisals against selected requirements in this NPR to check compliance.
SWE-222 - Software Assurance Training
2.1.2.6 The NASA Chief, SMA shall provide for software assurance training.
SWE-223 - Tailoring IV&V project selections
2.1.2.7 The NASA Chief, SMA shall make the final decision on all proposed tailoring of SWE-141, the Independent Verification and Validation (IV&V) requirement.