1. Requirements

3.1.12 Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and 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 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Everyone working on the project has to understand what is required to be done and understand the risk associated with not performing an activity. This action assures the proper implementation of the alternate requirement throughout the various stages of the software life cycle.

3. Guidance

3.1 Record Tailored Requirements

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 show accepted risks and assures that all affected software engineers are informed of the approved changes. This action assures the proper implementation of the alternate requirement throughout the various stages of the software life cycle. 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.

The project should generate:

1. Develop a compliance matrix for the software requirements per the software classification.
2. Develop a tailoring matrix of the software assurance and software safety requirements as needed and document the software assurance, and software safety approach in the software assurance plan and schedule.  
3. Add the compliance matrix and the software assurance and software safety tailoring matrix requirements in a software plan(s).

Project personnel records 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).

See also, 7.16 - Appendix C. Requirements Mapping and Compliance Matrix. SWE-139 - Shall Statements, 

3.2 Updates to the Compliance Matrix

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, the 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 tailoring from specific requirements are appropriately mitigated, NASA established Technical Authority (TA) governance.  The Technical and Institutional Authority for each requirement in this NPR is documented in the “Authority” column of Appendix C (see topic 7.16 - Appendix C. Requirements Mapping and Compliance Matrix). The responsible program, project, or operations manager needs to formally accept the tailoring risk.

General guidelines for SWE requirements, except for SWE-032 - CMMI Levels for Class A and B Software and SWE-141 - Software Independent Verification and Validation:

1. Each requirement marked ‘X’ for the project’s software classification(s) should be addressed in the Requirements Mapping Matrix.
2. All requirements can be tailored per the guidance in this directive.
3. Requirements Mapping Matrix with tailored requirements, deleted requirements, or requirements marked as N/A or not applicable need the approval of the Center Director’s designated Engineering Technical Authority and the Center Director’s designated SMA Technical Authority. 
4. If the project is a CHMO Health and Medical project, then CHMO designated Technical Authority approval is also required.
5. If the project marks any of the requirements in Section 3.11 as a tailored requirement, a deleted requirement, or a requirement marked as N/A or not applicable then the project is required to get the NASA CIO approval on the Requirements Mapping Matrix, in addition to the technical authorities in item 3 and 4.
6. The NASA CIO, or the designee, has institutional authority on all Class F software projects.

In the case of changes to SWE-032 - CMMI Levels for Class A and B Software and SWE-141 - Software Independent Verification and Validation, these steps are followed:

1. The Project Manager fills out the compliance matrix and indicates their tailoring to  SWE-032 or SWE-141.
2. The Project Manager sends the Compliance Matrix to the appropriate Center TA’s and requests approval of the changed requirements.
3. The Project Manager communicates the proposed request to tailor SWE-032 and SWE-141 to the OCE and OSMA for an initial discussion.
4. Appropriate Center TA’s approve the proposed changes to SWE-032 or SWE-141.
5. The Project Manager and Center TA’s communicate the proposed changes and rationale on either SWE-032 or SWE-141 to the OCE and OSMA for discussion. 
6. After OCE and OSMA approval, the Project Manager stores all related records and updated Compliance Matrix into project records.

See also SWE-150 - Review Changes To Tailored Requirements, 

3.3 Baselined Tailoring

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. 

3.4 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.5 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

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 References

5.2 Tools

6. Lessons Learned

6.1 NASA 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 what was done. Office of the Chief Engineer (OCE) personnel and future projects or Center personnel will be able to avoid reevaluating this 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.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

• Software Assurance and Software Safety Requirements Mapping Matrix for the Software Assurance and Safety Standard (SASS) requirements, including any approved tailoring

  
  

  Objective Evidence

  • NPR 7150.2 and NASA-STD-8739.8 requirements mapping matrices signed by the engineering and SMA technical authorities for each development organization.
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

• # of safety-related non-conformances identified by life cycle phase over time
• Identify the specific requirements in NASA-STD-8739.8 that are being tailored by the projects (*organizational metric) 
  • % of requirements tailored per project (*organizational measure)
  • # of projects tailoring each requirement (*organizational measure)

See also Topic 8.18 - SA Suggested Metrics. 

7.4 Guidance

• Confirm the tailoring approvals are contained in the Software Engineering Requirements Mapping Matrix. - confirm that the engineering and software assurance technical authorities have signed or approved any NPR 7150.2 and NASA-STD-8739.8 ²⁷⁸ requirements tailoring and that any changes have been communicated to engineering and the project  Confirm that the center CIO has approved any NPR 7150.2 cybersecurity requirements, section 3.11, tailoring. Identify any issues or risks associated with the decision(s) to tailor to the NPR 7150.2 and NASA-STD-8739.8 requirements if needed. Update the SA plan to reflect the tailoring approach as well as the tailored software assurance, software safety, and IV&V requirements used for this project. 
• Analyze plans and procedures to confirm that any approved tailored requirements are documented and adequately reflected., as well as any tailored software assurance, software safety, and IV&V requirements - assure that any approved tailoring is included in the software plans and software requirements specification(s) as required. Confirm that any development products (e.g., schedules, design documents, test artifacts, etc.) impacted by the tailored requirements accurately reflect the tailoring.
• Develop a tailoring matrix of the software assurance and software safety requirements, contained in NASA-STD-8739.8, as needed, and document the approved software assurance, software safety, and IV&V tailoring approach in the SA plan and schedule. Confirm that the software assurance technical authority has signed or approved any NASA-STD-8739.8 requirements tailoring and that any changes have been communicated to engineering and the project.  Identify any issues or risks associated with the decision to tailor to the NASA-STD-8739.8 requirements if needed.

See also Topic 8.51 - Software Assurance Plan, 

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: