Hello. Sign In
Standards Store


2013 Edition, June 17, 2013

Complete Document


Detail Summary

Active, Most Current

Price (USD)
Single User
In Stock
PDF + Print
In Stock
$65.10 You save 30%
Add to Cart

People Also Bought These:

ASME Y14.5
ANSI Z540.3

Product Details:

  • Revision: 2013 Edition, June 17, 2013
  • Published Date: June 17, 2013
  • Status: Active, Most Current
  • Document Language: English
  • Published By: National Air and Space Administration (NASA)
  • Page Count: 53
  • ANSI Approved: No
  • DoD Adopted: No

Description / Abstract:


The purpose of this Standard is to define the requirements for a software inspection process aimed at detecting and eliminating defects as early as possible in the software life cycle. This process can be used for any documented product, however, this Standard focuses on its use for software products—i.e., software code, plans, manuals, etc. The process provides for the collection and analysis of inspection data to improve the inspection process as well as the quality of the software.

This Standard provides a core set of requirements that are applicable whenever formal inspections are required. NASA-GB-A302, Software Formal Inspections Guidebook, provides additional information on approaches for implementing a software formal inspection process. The implementation and approach to meeting these requirements will vary to reflect the system to which they are applied.


This standard will be used to insure NASA maintains the rigor and benefits of software formal inspections, when Software Formal Inspections are to be performed on software as specified by agreement or project direction,. This Standard is applicable to formal inspections of software products during the development life cycle of software developed, maintained, or acquired by or for NASA, including the incorporation of open source, auto-generated code and test procedures, Commercial Off-The-Shelf (COTS), Government Off-The-Shelf (GOTS), or Modified Off-The- Shelf (MOTS) into NASA systems. Legacy and reuse software products are also covered with a focus on how they fit into the systems under current development. Projects need to choose which software products they will perform software formal inspection on, which will receive other kinds of peer reviews, and which will receive no peer review. These decisions should be documented in the program/project/facility software development or management plan.

This Standard is approved for use by NASA Headquarters and NASA Centers, including Component Facilities and Technical and Service Support Centers, and may be cited in contract, program, and other Agency documents as a technical requirement. This Standard may also apply to the Jet Propulsion Laboratory or to other contractors, grant recipients, or parties to agreements only to the extent specified or referenced in their contracts, grants, or agreements.

Requirements—i.e., mandatory actions—are denoted by statements containing the term "shall," are identified by "(Requirement)," and are numbered [SFI-###]. 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.

The project manager is usually called out as the responsible party for ensuring formal inspections are performed on their projects, and for the quality of the formal inspections. Project managers are not expected to personally perform nor run the actual Software Formal Inspections. It is recognized that these requirements and activities may either be delegated by the project manager to a software lead, Software Formal Inspection chief moderator, software assurance lead within the project; or it could be the responsibility of a division or Center Software Engineering Process Group, Software Assurance, or other responsible party assigned this role. The project manager is used within this standard as the one responsible for using Software Formal Inspections (SFIs) on a project and thus is responsible for supporting the principles of SFIs for their projects and the monitoring and improvement of SFI to achieve reduced software risks.