| name | nasa-npr-7150 |
| description | Knowledge base from NASA NPR 7150.2D — NASA Software Engineering Requirements. Use for NASA's Agency-wide software-engineering requirements: the software classification scheme (Classes A–F), the Requirements Mapping Matrix and class-driven applicability, tailoring and Technical Authority governance, the SWE-### 'shall' requirements across software management (Ch 3) and the engineering life cycle (Ch 4), the supporting disciplines (configuration management, risk, peer reviews/inspections, measurement, non-conformance — Ch 5), safety-critical and cybersecurity requirements, IV&V applicability, traceability, and the Appendix A definitions. Does not cover detailed software-assurance/safety procedures (see NASA-STD-8739.8), implementation how-to and document content (see NASA-HDBK-2203), the systems-engineering process framework (see NPR 7123.1), or program/project management (see NPR 7120.5). |
NASA NPR 7150.2D — NASA Software Engineering Requirements
Source: NASA (US Government work, public domain) | Chapters: 8
When to use
Use this skill when you need to apply, explain, or assess NASA's Agency-wide software-engineering requirements: classifying software (Classes A–F), reading applicability from the Requirements Mapping Matrix, justifying and approving tailoring, working any of the numbered SWE-### "shall" requirements, planning the software life cycle, meeting safety-critical and cybersecurity obligations, deciding IV&V applicability, building bidirectional traceability, or resolving a definition. This is the normative software-engineering requirements directive for NASA programs and projects; it pairs with NASA-HDBK-2203 (the non-binding Software Engineering Handbook) for implementation guidance and NASA-STD-8739.8 for assurance, safety, and IV&V detail.
Prerequisites: none — plain Markdown; no MCP server, API key, or licence tier needed at runtime.
How to Use This Skill
- Without arguments — load the core frameworks below for an overview of classification, the Requirements Mapping Matrix, tailoring, and the requirement structure.
- With a topic — ask about a specific mechanism (e.g., "Class C definition", "tailoring approval chain", "safety-critical behaviors", "MC/DC requirement", "auto-generated code", "IV&V applicability").
- With a chapter — ask for
ch03 (software management), ch04 (life-cycle engineering), ch05 (supporting disciplines), ch07 (definitions), or ch08 (software classifications).
Supporting files: glossary.md, patterns.md, cheatsheet.md.
Core Frameworks & Mental Models
Software Classification (Classes A–F) — the master valve
Classification is the upstream decision that drives everything else. Each system or subsystem containing software is assigned a class (at the highest applicable class, SWE-020), and the class decides how many requirements bite and at what rigor. Five factors decide the class: how the software is used with/within a NASA system, the criticality of that system, the degree of human dependence, developmental/operational complexity, and the size of the Agency's investment. Venue (space, air, ground, desktop) narrows the branch; consequence and dependence pick the class.
- A — Human-Rated Space Software Systems (crew life, primary human-spaceflight objectives).
- B — Non-Human Space-Rated Systems or Large-Scale Aeronautics Vehicles (reliable non-human mission, large vehicle).
- C — Mission-Support, Smaller Aeronautics, or Major Facility Software (secondary objectives, mission support).
- D — Basic Science/Engineering Design and Research-and-Technology Software (development and research).
- E — Design Concept, Research, Technology, General-Purpose Software (throwaway exploration, desktop tools) — never safety-critical.
- F — General-Purpose Computing, Business, and IT Software (the separate Business/IT track).
Rules: one class per system/subsystem; round up on ambiguity; safety-critical software is Class D or higher; classification follows intended use and can be promoted over the life cycle; the NASA Chief Engineer is the final arbiter of definition disputes.
The Requirements Mapping Matrix (RMM) — applicability and proof
The RMM (Appendix C) is the operative artifact. It maps every NPR requirement against a project by class: an "X" cell means mandatory for that class, a blank means optional or not invoked. The RMM records what the project commits to, what it deems "Not-Applicable," and any approved tailoring with justification and authority signatures. Compliance is demonstrated by a completed RMM plus internal (NPD 1200.1) and external (NPD 1210.2) controls — a paper-backed claim, not an assertion.
Tailoring and Technical Authority
Tailoring is the governed route to relief from a requirement, consistent with objectives, acceptable risk, and constraints. A relief request is an evidence package: rationale + risk evaluation + mitigations, concurrence from impacted disciplines (safety, quality, cybersecurity, health), the signature of the authority named in Appendix C, and the responsible manager's formal acceptance of residual risk. Special cases: cybersecurity (Section 3.11) relief also needs the SAISO signature; IV&V (SWE-141) relief is the Chief of SMA's decision; human-safety risk needs the actual risk takers to agree to assume it. Engineering and SMA Technical Authority chains govern application; the Chief Engineer (A–E) and CIO (F) tracks own approval.
The Requirement Grammar (SWE-### and the verbs)
Every mandatory statement uses shall and carries a unique SWE-### identifier (e.g., SWE-013, SWE-141, SWE-219) used for traceability, RMM mapping, and tailoring. should = recommended; will = expected outcome; may/can = discretionary; is/are = descriptive. Nearly every "shall" is directed at the project manager as the single accountable owner.
The Life-Cycle Engineering Sequence (Chapter 4)
Requirements → architecture → design → implementation → testing → operations/maintenance/retirement, each carried by SWE-### requirements. Quality is built in early: requirements must be well-formed, complete, consistent, verifiable, and traceable; architecture is the costliest-to-reverse decision (architecture review mandated for Category 1 and Class A/B-payload Category 2 projects, SWE-143); static analysis (SWE-135) and unit testing run during implementation; testing verifies against requirements with target-platform validation; coverage gaps triage into four causes; regression, hazard, and uplink testing close the loop. Non-custom code (COTS/GOTS/MOTS/OSS/reused) is held to the same rigor as developed code, and critical tools must be validated and accredited before their output is trusted.
The Supporting Disciplines (Chapter 5) — the horizontal layer
Five practices run continuously alongside the phased work, each a set of "the project manager shall" obligations: Software Configuration Management (items, tools, and build environments under control with separated change authority and audits), Risk Management (with residual-risk awareness), Peer Reviews and Inspections (instrumented with entry/exit criteria, a reading technique, tracked actions, and recorded measures), Software Measurement (multi-level: project → Center → Chief Engineer, with margin and requirements-volatility tracking), and Non-conformance / Defect Management (severity-classified, closed-loop on high-severity issues, spanning acquired and reused software).
Safety-Critical and Cybersecurity Hardening (Chapter 3)
Safety-critical components carry behavioral safe-state requirements (SWE-134: safe init/restart, safe state transitions, two independent operator actions for overrides, out-of-sequence command rejection, memory-integrity and prerequisite checks, no single-event hazard, timely off-nominal response) reinforced by hard gates — 100% MC/DC coverage (SWE-219) and cyclomatic complexity ≤ 15 (SWE-220). Cybersecurity is woven through development: assessments including off-the-shelf risk (SWE-156), mitigations (SWE-154/159), secure coding (SWE-207), static-analysis verification against the secure coding standard (SWE-185), and adversarial-action data reporting (SWE-210). Coding defects are treated as security weaknesses, not just quality issues.
Chapter Index
| # | Section | Key content |
|---|
| ch01 | Introduction, Purpose, Structure | Whole-life scope, document hierarchy and precedence, class-driven applicability, RMM verification, requirement vocabulary, no mandated life-cycle model, authority chain |
| ch02 | Roles, Responsibilities, Tailoring | OCE/SMA/OCIO/CHMO/Center roles, Technical Authority governance, tailoring as evidence-backed relief, RMM signatures, co-approval chains, CMMI-DEV, delegation |
| ch03 | Software Management Requirements | Classification (SWE-020) + RMM as applicability engine, planning/cost/schedule/training, off-the-shelf and auto-generated discipline, CMMI levels, IV&V, MC/DC, cybersecurity, bidirectional traceability |
| ch04 | Software Engineering (Life Cycle) Requirements | Requirements → architecture → design → implementation → test → ops/maintenance/retirement, SWE-### per phase, static analysis, coverage four-cause triage, regression/hazard/uplink testing, tool accreditation |
| ch05 | Supporting Life Cycle Requirements | SCM, risk management, peer reviews/inspections, measurement (multi-level), non-conformance/defect management; IEEE 828, NASA-STD-8739.9, NASA-HDBK-2203 |
| ch06 | Recommended Software Records | Typical product menu vs. content; defers content/timing to NASA-HDBK-2203; SPAN templates; reader-first, tailor-the-menu, format-flexible, living-records principles |
| ch07 | Definitions (Appendix A) | Controlled vocabulary; off-the-shelf taxonomy; assure/ensure/accredit; defect/fault/failure; verification vs. validation; software assurance discipline set; MOTS and facility thresholds as policy switches |
Topic Index
- Acquired / off-the-shelf software (COTS/GOTS/MOTS/OSS) → ch03, ch07, patterns
- Architecture review → ch04
- Auto-generated code → ch03, ch04, patterns
- Bidirectional traceability → ch03, ch07, patterns
- Classification (Classes A–F) → ch08, ch01, ch03, cheatsheet
- CMMI-DEV maturity by class → ch02, ch03, cheatsheet
- Code coverage / four-cause triage → ch04, patterns
- Configuration management (SCM) → ch05, glossary, patterns
- Cost estimation / cost models → ch03, cheatsheet
- Cyclomatic complexity (≤ 15) → ch03, ch07, cheatsheet
- Cybersecurity requirements (Section 3.11) → ch03, patterns, cheatsheet
- Definitions / glossary → ch07, glossary
- Defect / fault / failure → ch05, ch07, glossary
- IV&V (Independent Verification and Validation) → ch02, ch03, ch07
- Life-cycle engineering phases → ch04, cheatsheet
- MC/DC coverage (100%) → ch03, ch04, ch07, cheatsheet
- Measurement program → ch05, patterns
- Non-conformance / defect management → ch05, patterns
- Peer reviews and inspections → ch05, patterns
- Project manager (accountable role) → ch03, ch04, ch05
- Records / software products → ch06, patterns
- Requirements Mapping Matrix (RMM) → ch01, ch02, ch03, cheatsheet
- Requirements (well-formed, traceable) → ch04
- Risk management (software) → ch05, patterns
- Roles and responsibilities → ch02
- Safety-critical software / safe states → ch03, ch08, patterns, cheatsheet
- SWE-### requirement identifiers → ch03, ch04, ch05, cheatsheet
- Static analysis → ch04, ch07
- Tailoring → ch02, ch03, patterns, cheatsheet
- Technical Authority (Engineering / SMA) → ch02, ch08
- Verification vs. validation → ch04, ch07, glossary
Supporting Files
- glossary.md — key NPR 7150.2D terms from Appendix A, alphabetical, with chapter references and source-standard notes
- patterns.md — 10 reusable techniques with When/How/Trade-offs structure (classify-first, tailor-through-the-RMM, developed-code bar, safety-critical layering, traceability spine, tools-as-CIs, coverage triage, cybersecurity-through-development, continuous supporting disciplines, reader-first records)
- cheatsheet.md — decision rules, the six classes, requirement-verb key, chapter map, quantitative gates/thresholds, high-traffic SWE numbers, companion documents, tells & smells
Scope & Limits
Covers: NASA's Agency-wide software-engineering requirements per NPR 7150.2D (Rev D, effective March 8, 2022) — the software classification scheme (Classes A–F, Appendix D); the Requirements Mapping Matrix and class-driven applicability (Appendix C); tailoring and Technical Authority governance (Ch 2); the SWE-### "shall" requirements for software management (Ch 3) and the engineering life cycle (Ch 4); the supporting disciplines of configuration management, risk, peer reviews/inspections, measurement, and non-conformance (Ch 5); safety-critical behavioral and quantitative requirements; cybersecurity requirements; IV&V applicability; bidirectional traceability; recommended software records (Ch 6); and the Appendix A definitions (Ch 7).
Thin on / does not cover in depth: detailed software-assurance, software-safety, and IV&V procedures (the directive invokes them but defers the substance to NASA-STD-8739.8); implementation how-to, record content, and timing (deferred to NASA-HDBK-2203 and the SPAN library); the systems-engineering process framework (NPR 7123.1); program/project management and project categories (NPR 7120.5/7/8); the full Appendix C matrix cell-by-cell (use the cheatsheet's class table and SWE list instead); the Appendix B acronym list and Appendix E references; and any specific life-cycle model (the NPR deliberately mandates none).
Jurisdiction: US Government public-domain work (17 U.S.C. § 105). NPR 7150.2D binds NASA Headquarters and Centers; it reaches JPL, contractors, grant recipients, and agreement parties only as incorporated through a contract, grant, or agreement. It is neither retroactive nor a ceiling on stricter requirements. Printed copies are uncontrolled — verify the current version in the NODIS Library before relying on a requirement.
