- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
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.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
Click here to view the history of this requirement: SWE-121 History
1.3 Applicability Across Classes
Key: - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Sometimes Safety Critical; E - F = Never Safety Critical.
So that everyone working the project understands what is required to be done and understands 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.
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 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:
- Develop a compliance matrix for the software requirements per the software classification.
- 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.
- Add the compliance matrix and the software assurance and software safety tailoring matrix requirements in a software plan(s).
Per NPR 7150.2, “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 "Class A-E Authority" column and "Class F Authority" column of Appendix C [of the NPR]. The SMA 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. The NASA CIO has co-approval on any waiver or deviation that involves the cybersecurity software requirements.
[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.” 083
“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.” 083
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).
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 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.
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 566: 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 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
Confirm that any requirement tailoring in the Requirements Mapping Matrix has the required approvals.
Develop a tailoring matrix of software assurance and software safety requirements.
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
Definition of objective evidence
- Evidence of confirmation for software NPR 7150.2 Requirements Mapping Matrix tailoring and approvals, including any risks or issues.
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 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.
- # 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 projects tailoring each requirement (*organizational measure)
- % of requirements tailored per project (*organizational measure)
- 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 278 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 in 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 in the NASA-STD-8739.8 requirements if needed.