Topics / Standards and assurance
NPR 7150.2D: NASA software engineering requirements
NPR 7150.2D defines NASA Software Engineering Requirements for managing, developing and maintaining software. Start with software classification and the applicable requirements, then record how the project meets them and which tailoring decisions are authorized.
What does NPR 7150.2D cover?
The directive covers software management, development and maintenance, supporting activities such as configuration and risk management, and required documentation. Its classification and requirements-mapping appendices help establish applicability. The official directive lists an effective date of 8 March 2022 and expiration date of 8 March 2027; check the current NASA record before setting a project basis.
For external organizations, determine whether requirements are incorporated through a contract or another applicable obligation. Publishing a NASA-shaped document does not make a commercial product NASA-compliant.
Build the applicability record before the checklist
- Classify the software. Use the directive’s criteria and record the rationale and responsible authority.
- Map applicable requirements. Keep exact references and authorized tailoring decisions rather than copying every clause into a generic task list.
- Assign owners and artifacts. Link each obligation to the plan, requirement, design, test or review that addresses it.
- Inspect the observations. A planned test, generated document and executed result are different records.
- Review changed assumptions. Update affected records when the software or governing basis changes.
Read NASA-STD-8739.8B for the complementary assurance and software safety requirements. Use the verification-report template for the executed-result portion of the record.
Establish applicability before mapping evidence.
NASA’s NPR 7150.2D sets software-engineering requirements. Its classification and tailoring framework determines which obligations apply and which authorities may approve tailoring. The requirements are not a universal checklist for every software repository.
Source: NASA: NPR 7150.2D, classification and tailoring. Scope and edition reviewed 9 October 2026.
Keep the adopted version, scope and applicability rationale with the project. If the software’s role changes, reassess the basis rather than carrying forward an unexplained green matrix.
Connect one obligation to real work.
Illustrative example
A requirement changed, but the verification plan did not.
A software change adds a recovery behavior. The requirement record is updated, yet the planned tests still cover only normal operation. A useful evidence view connects the requirement delta to its planned check, actual execution and any untested failure condition.
| Record | Purpose |
|---|---|
| Applicable provision | Identifies the source and responsible authority |
| Project requirement | States what the software or process must do |
| Work and evidence | Shows the action performed and observed outcome |
| Review and gaps | Retains the decision and remaining obligations |
Use Proof as part of the evidence workflow.
Proof can connect requirements, implementation, hazards and verification records and generate views from that data. The project still needs to establish complete applicability, required review and acceptance of its evidence.
For a pilot, choose one engineering obligation already causing repeated preparation work. Ask the responsible reviewer to compare the connected record with the current process. Do not infer NASA approval from the use of a NASA-inspired technique.
Try it on your software
Demonstrate one applicable obligation end to end.
Bring the project’s mapping and a real change with evidence your reviewer needs.