Book A.

Book B.
7150 Requirements Guidance

Book C.

References, & Terms

(NASA Only)

SWE-078 - As-built Documentation

1. Requirements

3.5.5 The project shall deliver to the customer the as-built documentation to support the operations and maintenance phase of the software life cycle.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

Classes F and G are 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

The goal of software development is to provide a software product to the customer. To ensure proper understanding, use, and maintenance of the delivered product, the project team needs to provide as-built documentation, i.e., documentation that matches the delivered product, to the customer.

NPR 7150.2 includes another, similar, requirement for delivered documentation. SWE-077 applies to almost all classes (see the guidance for SWE-077 in this Handbook) and has a lot of leeway regarding what documentation exists. This requirement, SWE-078, is oriented toward the higher classes and specifies as-built or final documentation.

3. Guidance

It is important that the Version Description Document (VDD), user documentation, and design documentation, in particular, describe the as-built and delivered software.

Documentation delivered to support operation and maintenance of a software product needs to match the actual delivered product, keeping in mind the documentation requirements for the classification of that software (SWE-020). The delivered product may not always be the designed product due to factors such as evolution of requirements, reworked code, unanticipated problems, etc. Regardless of any issues that alter the product during the development life cycle, the delivered documentation needs to be accurate and reflect the released version of the software. The VDD, in particular, describes the delivered product for the customer and provides other information to identify a specific release of software 276.

Once the project team establishes the set of documentation to be delivered with the software, the team keeps documents up-to-date throughout the project life cycle to avoid any delays in delivery. Near the end of the project life cycle the team updates any inconsistent documentation to ensure it includes the information needed to maintain the software in the future.

Before software delivery, "a physical examination is made of the configuration item (CI) to verify that ... [it] conforms as-built to its technical documentation." 212 When mismatches occur this close to software delivery, the project team updates the documentation to match the delivered software prior to delivery to the customer.

The project team needs to fully describe in the contract the delivery package content requirements for a contracted software provider to ensure the acquirer receives all critical information, including as-built documentation, required to operate and maintain the software.

Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to delivery of as-built software documentation.

Additionally, guidance related to software delivery, including as-built software documentation, may be found in the following related requirements in this Handbook:


Acquisition Planning


Deliver Software Products


Software Version Description

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.