Book A.

Book B.
7150 Requirements Guidance

Book C.

References, & Terms

(NASA Only)

SWE-087 - Software Peer Reviews and Inspections for Requirements, Test Plans, Design, and Code

1. Requirements

4.3.1 The project shall perform and report on software peer reviews/inspections for:
     a. Software requirements.
     b. Software Test Plan.
     c. Any design items that the project identified for software peer review/inspections according to the software development plans.
     d. Software code as defined in the software and or project plans.

1.1 Notes

Software peer reviews/inspections are a recommended best practice for all safety and mission-success related design and code software components. Guidelines for software peer reviews/inspections are contained in NASA-STD-2202.93, NASA Software Formal Inspection Standard.

1.2 Applicability Across Classes

Class D through E and safety critical are labeled with "SO" (safety only). This means that the requirement applies to the safety-critical aspects of the software.

Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.

Class F is labeled with "X (not OTS)." This means that this requirement does not apply to off-the-shelf software for these classes.





























Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

2. Rationale

A key rationale for using software peer reviews/inspections is that they are one of the few V&V (Verification and Validation) approaches that can be applied in the early stages of software development, long before there is any code that can be run and tested. Moreover, when defects are found and fixed in these early stages rather than allowed to slip into later phases, it can have a huge impact on project budget. For this reason, software peer reviews/inspections of requirements documents are explicitly required.

As documented in NASA-GB-8719.13, NASA Software Safety Guidebook , "Formal Inspections have the most impact when applied early in the life of a project, especially the requirements specification and definition stages of a project. Impact means that the defects are found earlier, when it's cheaper to fix them....Formal Inspection greatly improves the communication within a project and enhances understanding of the system while scrubbing out many of the major errors and defects."

Test plans are another key artifact on which software peer reviews/inspections can be applied with the best return on investment. Software testing represents a substantial part of the effort of assuring software quality for most projects; so it is important to ensure that test cases are focused on the appropriate functional areas, cover all important usage scenarios, and specify the expected system behavior adequately and accurately. The best way to ensure these factors is via peer review/inspection, the application of human judgment and analysis.

Code and design artifacts also benefit from peer review/inspection. However, although important, inspections of such artifacts are less crucial than those of other life cycle activities because there are other effective verification and validation (V&V) options available for code and design (such as testing or simulation). It is important for a project to identify the most crucial design and code segments and deploy inspections on them to improve their quality. Projects also need to focus inspections of code and design on issues that cannot be verified using automated tools; i.e., projects need to be sure that human judgment is applied on appropriate issues and rely on automation where it is best suited.

3. Guidance

NASA-STD-2202, Software Formal Inspection Standard, is currently being updated and revised to include lessons that have been learned by practitioners over the last decade. Contained in the Standard are best practices related to performing inspections on different work products, including recommendations for the checklist contents, the minimum set of reference materials required, the needed perspectives to be included on the inspection team, and reasonable page rates that can help plan adequate time for the inspection, specially adapted for when inspecting:

  • Requirements.
  • Design documents.
  • Source code.
  • Software test plans.

The design and code segments selected for peer review/inspection need to be those that are the most critical, complex, have key interfaces, or otherwise represent areas where the concerns of multiple stakeholders overlap.

The presence and participation of project management in peer review/inspection meetings is usually not recommended due to the potential negative impact to the effectiveness of the inspections. Typically, management only receives summary level information on peer reviews/inspections.  

Both management and the inspectors must be aware that defects found during inspections are never to be used for evaluating the authors. Everyone involved in an inspection needs to have a vested interest in improving the product that is being inspected. This requires that everyone be willing to identify defects (including the author) and to help identify potential solutions.  

The Fraunhofer Center 421 in Maryland maintains a public website that collects checklists found from NASA and other contexts, which can be applied to the types of work products mentioned in these requirements.

Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources, such as templates, related to peer reviews and inspections.

Additional guidance related to peer reviews and inspections may be found in the following related requirements in this handbook:


Software Peer Reviews and Inspections - Checklist Criteria and Tracking


Software Peer Reviews and Inspections - Basic Measurements

4. Small Projects

While small projects are required to use peer reviews and/or inspection processes to evaluate key artifact types, they could make the task more manageable by varying the size of the inspection team, as long as key stakeholders are still represented. When it isn't possible to find all of the needed expertise from within the project team itself, consider whether the peer review/inspection team can leverage personnel from:

  • Areas that interface with the product being developed.
  • Related projects.
  • Other areas within the functional organization.
  • User organization.

Small teams also determine whether quality assurance personnel from the Center participate, for example by providing a trained moderator to oversee the inspection logistics.

5. Resources

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

Tool nameTypeOwner/SourceLinkDescriptionUser


JPL Owned

JPL ...

SCRUB is a code review tool that supports both large, team-based software development efforts (e.g., for mission software) as well as individual tasks.




Phaedrus Systems ...

Proprietary language parsing engines to statically analyze your source code. They identify problems caused by language usage that's dangerous, overly complex, non-portable, or difficult to maintain. Plus, they include the basic building blocks for coding standard enforcement.




MathWorks ...

Polyspace® static code analysis products use formal methods to prove the absence of critical run-time errors under all possible control flows and data flows. They include checkers for coding rules, security vulnerabilities, code metrics, and hundreds of additional classes of bugs.



Open Source

PMD ...

PMD is a source code analyzer. It finds common programming flaws like unused variables, empty catch blocks, unnecessary object creation, and so forth. It supports Apex, Java, JavaScript, XML, XSL.




Gimpel Software ...

Also PC-Lint and FlexeLint. It will thoroughly check your C/C++ source code for bugs, glitches, inconsistencies, non-portable constructs, and much more, so you can find and fix your bugs more quickly, and more economically, than with traditional debugging procedures


JPL C Coding Standard

SPAN - Accessible to NASA users via SPAN tab in this Handbook. By Request - Non-NASA users, contact User for a copy of this tool.



An example of a coding standard for programming in c. Search in SPAN: JPL__ST_20090303_C_Coding_STD




GitLab Inc. ...

Provides repository management, code reviews, issue tracking, activity feeds and wikis. GitLab itself is also free software.




Gimpel Software ...

FlexeLint are powerful static analysis tools that will check your C/C++ source code and find bugs, glitches, inconsistencies, non-portable constructs, redundant code, and much more. It looks across multiple modules, and so, enjoys a perspective your compiler does not have.



Open Source

University of Maryland ...

FindBugs, a program which uses static analysis to look for bugs in Java code. It is free software, distributed under the terms of the Lesser GNU Public License. The current version of FindBugs is 3.0.1, released on 13:05:33 EST, 06 March, 2015.

GRC (EVA Sim; EVA-Informatics), ARC, JPL, KSC

Coverity® Prevent and Extend™


Synopsys ...

Static code analysis




Smart Bear ...

Collaborator is a code review tool that helps development, testing and management teams work together to produce high quality code. It allows teams to peer review code, user stories and test plans in a transparent, collaborative framework — instantly keeping the entire team up to speed on changes made to the code.




Grammatech ...

By analyzing both source code and binaries, CodeSonar enables teams to analyze complete applications, enabling you to take control of your software supply chain and eliminate the most costly and hard-to-find defects early in the SDLC.

IV&V, ARC (NanoSat), JPL

CodeHawk C Analyzer


Kestrel Technology ...

CodeHawk C analyzer is a software assurance tool capable of proving the absence of all memory access vulnerabilities in C source code by leveraging KT’s abstract interpretation engine, a static analysis technology able to mathematically model program behavior.




Scientific Toolworks, Inc. ...

Understand is a static analysis tool for maintaining, measuring, & analyzing critical or large code bases.


6. Lessons Learned

A substantial body of data and experience justifies the use of inspections on requirements. Finding and fixing requirements problems during requirements analysis is cheaper than doing so later in the life cycle, and is substantially cheaper than finding and fixing the same defects after delivery of the software. Data from NASA as well as numerous other organizations (such as IBM, Toshiba, the Defense Analysis Center for Software) all confirm this effect. 319

The effectiveness of inspections for defect detection and removal in any artifact has also been amply demonstrated. Data from numerous organizations have shown that a reasonable rule of thumb is that a well-performed inspection typically removes between 60 percent and 90 per cent of the existing defects, regardless of the artifact type. 319

A documented lesson from the NASA Lessons Learned database notes the following:

Deficiencies in Mission Critical Software Development for Mars Climate Orbiter (1999). Lesson Number 0740: Experience at NASA has also shown that a lack of software reviews can result in loss of spacecraft: "1) Non-compliance with preferred software review practices may lead to mission loss. 2) To identify mission critical software, require concurrent engineering and thorough review by a team of systems engineers, developers, and end users. 3) For all mission critical software (or software interfaces between two systems or two major organizations), systems engineers, developers, and end users should participate in ... walk-throughs of requirements, design, and acceptance plans." 521