bannerd


SWE-121 - Document Tailored Requirements

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

SWE-121 - Last used in rev NPR 7150.2D

RevSWE Statement
A

6.1.2 Where approved, the requesting Center or project shall document the approved alternate requirement in the procedure controlling the development, acquisition, and/ or deployment of the affected software.

Difference between A and B

No change

B

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

Difference between B and CChanged "and/or" to "and".
C

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.

Difference between C and DNo change
D

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.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

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).


NPR7150.2D - Para 2.2.1

2.2.1 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 tailoring from specific requirements are appropriately mitigated, NASA established TA governance. Tailoring from requirements in this directive are governed by the following requirements, as well as those defined in NPD 1000.3, The NASA Organization NPD 2800.1, NPR 2810.1, NPR 7120.5, NPR 7120.7, NPR 7120.8, NPR 7120.11 and NPR 8715.3 for all of the Agency’s investment areas. The Technical and Institutional Authority for each requirement in this NPR is documented in the “Authority” column of Appendix C. The responsible program, project, or operations manager need to formally accept the tailoring risk. Tailoring decided at the Center level are to consult the Center ETA, Center SMA TA, Center Health and Medical TA, and the NASA CIO’s Center IT Authority designee as defined in the requirements mapping matrix. The OSMA has co-approval on any tailoring decided at the HQ level that involves software. The Office of the Chief Medical Officer (OCHMO) has co-approval on any tailoring decided that involves software with health and medical implications. The SAISO, or designee, has co-approval on any tailoring of the cybersecurity requirements in Section 3.11. For tailoring involving human safety risk, the actual risk taker(s) (or official spokesperson[s] and appropriate supervisory chain) need to formally agree to assume the risk. ’ 083

NPR7150.2D - Para 2.2.2
2.2.2 This directive establishes a baseline set of requirements to reduce software engineering risks on NASA projects and programs. Appendix C defines the default applicability of the requirements based on software classification. 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
NPR7150.2D - Para 2.2.6

2.2.6 Requests for software requirements relief at either the Center or HQ TA level (i.e., partial or complete relief) may be submitted in the streamlined form of a Requirements Mapping Matrix. The required signatures from engineering, NASA CIO, and SMA authorities are to be obtained. A required signature from designated SAISO is required for relief of cybersecurity requirements. If the Requirements Mapping Matrix is completed and approved in accordance with NPR 7120.5’s direction on Authority and this directive, it meets the requirements for requesting tailoring. 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).

See also, 7.16 - Appendix C. Requirements Mapping and Compliance Matrix

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.


Exactly how each Center implements NPR 7150.2D is up to them. The Handbook is intentionally non-prescriptive, allowing Centers to develop processes for their projects to implement the requirements of the NPR. See SWE-126 - Tailoring Considerations, and SWE-125 - Requirements Compliance Matrix.

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

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki  197

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

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

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 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

SWE-121 - Document Tailored 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.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Confirm that any requirement tailoring in the Requirements Mapping Matrix has the required approvals.

2. 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


    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.

    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 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 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.

7.5 Additional Guidance

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

  • No labels