1. Requirements

2.2.4 Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and/or deployment of the affected software. 

1.1 Notes

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

1.2 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

The project is required to record tailored requirements in program/project documentation that controls the development, acquisition, and deployment of the affected software. Publication of the approved alternate requirements helps clearly show accepted risks and assures that all affected software engineers are informed of the approved changes. This action will assure the proper implementation of the alternate requirement throughout the various stages of the software life cycle (see SWE-019). The inclusion of these changes in a configuration managed system for the program/project will inform current and future software product developers and project managers of the correct set of requirements and procedures.

3. Guidance

Per NPR 7150.2B, “Software requirements tailoring is the process used to seek relief from NPR requirements consistent with program or project objectives, acceptable risk, and constraints. To accommodate the wide variety of software systems and subsystems, application of these requirements to specific software development efforts may be tailored where justified and approved. To effectively maintain control over the application of requirements in this directive and to ensure proposed variants from specific requirements are appropriately mitigated, NASA established Technical Authority governance. Waivers and deviations from requirements in [NPR 7150.2] are governed by the following requirements, as well as those established in NPD 1000.3, NPR 7120.5, NPR 7120.7, and NPR 7120.8 for all of the Agency’s investment areas. The Technical Authority for each requirement in [NPR 7150.2] is documented in the "Technical Authority" column of Appendix C [of the NPR]. The NASA CSMA has co-approval on any waiver or deviation decided at the Headquarters level that involves software. The NASA CHMO has co-approval on any waiver or deviation decided at the Headquarters level that involves software with health and medical implications. Waivers or deviations decided at the Center level are to follow similar protocol when software criticality or health and medical issues are involved. ...

[NPR 7150.2] establishes a baseline set of requirements to reduce software engineering risks on NASA projects and programs. NPR 7150.2 Appendix C defines the default applicability of the requirements based on software classification and safety criticality. Tailoring is the process used to adjust or seek relief from a prescribed requirement to accommodate the needs of a specific task or activity (e.g., program or project). The tailoring process results in the generation of waivers or deviations depending on the timing of the request (see [NPR 7150.2] Appendix A for relevant definitions). Each project has unique circumstances, and tailoring can be employed to modify the requirements set appropriate for the software engineering effort. Tailoring of requirements is based on key characteristics of the software engineering effort, including acceptable technical and programmatic risk posture, Agency priorities, size, and complexity. Requirements can be tailored more broadly across a group of similar projects, a program, an organization, or other collection of similar software development efforts in accordance with NPR 7120.5, Section 3.5.5.” ⁰³⁹

“Requests for software requirements relief at either the Center or Headquarters Technical Authority level (i.e., partial or complete relief) may be submitted in the streamlined form of a compliance matrix. The required signatures from the responsible organizations and designated Technical Authorities, engineering and safety and mission assurance, are to be obtained. If the compliance matrix is completed and approved in accordance with NPR 7120.5’s direction on Technical Authority and this directive, it meets the requirements for requesting tailoring and serves as a waiver or deviation.” ⁰³⁹

Project personnel record the appropriate information on any requirements changes resulting from the approval of a tailoring request in the project-specific software requirements documents. The Center's compliance matrix to NPR 7150.2 will also include approval of tailored requirements from the Office of the Chief Engineer (OCE).

The software team lead will include any updates in the compliance matrix that reflect approved tailored requirements. The software team lead also communicates this information to affected software Technical Authorities (TAs) (see SWE-126). (See SWE-125 and SWE-145 for information on the content and handling of a compliance matrix.)

When approval is granted, the program/project includes the results of the tailoring request and the rationale for the request, along with any approved alterations to the initial request, in the baselined program/project documentation. 

4. Small Projects

Small projects may lack the resources and schedule to individually apply for waiver relief from specific sets of NPR 7150.2 requirements. Centers can request a generic waiver that will cover multiple small projects.

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

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

• The Pitfalls of "Engineering-by-Presentation" (2005). Lesson Number 1715: Without documenting and, thereby, capturing details of the rationale for decisions affecting systems designs (requirements) "...project staff found themselves repeatedly revisiting the same technical issues. "Now why did we decide..."" This is a good indication that why it was done is as important, at times, as to what was done. Office of the Chief Engineer (OCE) personnel and future projects or Center personnel will be able to avoid reevaluating these general exclusion or alternate requirement approvals if they have appropriate access to the rationale so they can properly understand the basis on which the exclusions were granted in the first place. ⁵⁶⁶