bannerd


SWE-126 - Tailoring Considerations

1. Requirements

2.1.8.2 The technical and institutional authorities for requirements in this directive shall: 

a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by:

(1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D.
(2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification.
(3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied.
(4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable.
(5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility.
(6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see column titled “Authority” in Appendix C).
(7) Include the SAISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition, and assurance activities.
(8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.

b. Indicate the Technical Authority or Technical Authorities approval by signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s).

1.1 Notes

a. To effectively assess projects’ requirements mapping matrices, the designated Center Engineering Technical and Institutional Authorities for this NPR are recognized NASA software engineering experts or utilize recognized NASA software engineering experts in their decision processes. NASA-HDBK-2203 contains valuable information on each requirement, links to relevant NASA Lessons Learned, and guidance on tailoring. Center organizations or branches may also share frequently used tailoring and related common processes.

b. The Requirements Mapping Matrix documents the requirements that the project plans to meet, “not applicable” requirements, and any tailoring approved by designated Authorities with associated justification. If a project wants to tailor a requirement marked as HQ TA, then the project is required to get NASA HQ approval (e.g., OCE, OSMA, OCIO, or OCHMO) on a tailored request or a software Requirements Mapping Matrix.

1.2 History

SWE-126 - Last used in rev NPR 7150.2D

RevSWE Statement
A

6.3.3 The Engineering Technical Authority(s) for this NPR shall consider the following information when assessing waivers and deviations from requirements in this NPR:

    1. The NASA software inventory data on the project.
    2. The classification of systems and subsystems containing software, as defined in Appendix E.
    3. Applicable Center-level software directives that meet the intent of this NPR.
    4. Applicable contractor and subcontractor software policies and procedures that meet the intent of this NPR.
    5. Potential impacts to NASA missions.
    6. Potential impacts to health, medical concerns, or safety.
Difference between A and BRe-write of the requirement
B

2.1.3.6  Serving as Technical Authorities for requirements in this directive, Center Directors, or designees shall:

a. Assess project’s compliance matrices, tailoring, waivers, and deviations from requirements in this directive by:  

(1)  Checking the accuracy of the project’s classification of software components against the definitions in Appendix D.

(2)  Evaluating the project’s compliance matrix for commitments to meet applicable requirements in this directive, consistent with software classification.

(3)  Confirming that requirements marked “Not-Applicable” in the project’s compliance matrix are not relevant or not capable of being applied.

(4)  Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C, are reasonable and acceptable.

(5) Coordinate with the Center S&MA organization that the compliance matrix implementation approach does not impact safety and mission assurance on the project.

(6)  Approving/disapproving request for relief from requirements designated with “X” in Appendix C, which fall under this Technical Authority’s scope of responsibility.

(7)  Facilitating the processing of projects’ tailoring/compliance matrices, tailoring, waivers, or deviations from requirements in this directive, which fall under the responsibilities of a different Technical Authority (see column titled “Technical Authority” in Appendix C).

(8)  Ensuring that approved compliance matrices, including any waivers and deviations against this directive, are archived as part of retrievable project records.

Difference between B and C- Added Institutional Authority(s) to the requirement; Changed "compliance" to "Requirements Mapping" matrix / matrices (RMM) everywhere;
- Removed "waivers, and deviations" in items a., (7) and (8);
- Removed item (5) in Rev B which is "Coordinate with the Center S&MA organization that the compliance matrix implementation approach does not impact safety and mission assurance on the project.";
- Removed "Technical" in Rev B items (6) and (7), which are items (5) and (6) in Rev C;
- Added requirement item (7) in Rev C;
- Changed "waivers, and deviations" to "tailoring rationale" in item (8);
- Added requirement b. which requires the Technical Authority to approve tailoring of the RMM by signature - this merges SWE-145 into this SWE #.
C

2.1.5.6 Serving as technical and institutional authorities for requirements in this directive, Center Director, or designee, shall:  

a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by: 

(1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D. 

(2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification. 

(3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied. 

(4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable. 

(5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility. 

(6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see the column titled “Authority” in Appendix C). 

(7) Include the Center CIO and CISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition and assurance activities. 

(8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.


b. Indicate the Technical Authority or Technical Authorities approval by the signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s).

Difference between C and DThis requirement was moved to section 2.1.8 in the document, and item b. was added
D

2.1.8.2 The technical and institutional authorities for requirements in this directive shall: 

a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by:

(1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D.
(2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification.
(3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied.
(4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable.
(5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility.
(6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see column titled “Authority” in Appendix C).
(7) Include the SAISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition, and assurance activities.
(8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.

b. Indicate the Technical Authority or Technical Authorities approval by signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s).





2. Rationale

To reduce the risk and cost associated with the software development and use on NASA projects.

3. Guidance

3.1 Request for Deviation or Waiver

NPR 7150.2 contains the basic set of requirements for software developed by or for the agency. Any request for a "Deviation" (a documented authorization releasing a program or project from meeting a requirement before the requirement is put under configuration control at the level the requirement will be implemented) or a "waiver" (a documented authorization intentionally releasing a program or project from meeting a requirement after the requirement is put under configuration control at the level the requirement will be implemented) from a particular requirement is made to the appropriate level and type of Technical Authority (TA) as listed in Appendix C in NPR 7150.2. When assessing the requests, the designated TA considers a number of relevant factors in deliberation. It is not uncommon for a waiver/deviation to require approval from TAs from two different organizations, e.g., Engineering TA (ETA) as well as Safety & Mission Assurance TA. 

NPR 7150.2 NASA Software Engineering Requirements

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


Requests for relief from software requirements can take a variety of forms, including tailoring, compliance matrices, waivers, and deviations. Per NPR 7150.2D,

NPR 7150.2 NASA Software Engineering Requirements
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

See also SWE-140 - Comply with Requirements, SWE-216 - Internal Software Sharing List

3.2 Preparing Deviation or Waiver Requests

General directions for preparing NASA "deviation" and "waiver" requests can be found in NPR 7120.5.  Direction specific to software is provided in Chapter 2 of NPR 7150.2.

If the project or software lead engineer submits a request for relief, the Engineering Technical Authority (ETA) performs specific actions to assess those submissions.

  • Check project’s classification of software components: Appendix D of NPR 7150.2 gives definitions and examples of systems that typically have the listed software classification. Relief from requirements for higher-level software classes (A and B) or with safety-critical aspects is evaluated with increased rigor. Additional classifications, such as human-rated systems and payload classifications, also imply the degree to which a waiver/deviation would be acceptable. The TA checks to ensure the correct classification of the system, subsystem, and software, as requirements can vary significantly across classifications. Consideration is given to the software classification associated with these systems or subsystems to assure the level of risk accepted by granting the waiver or deviation is consistent with the overall importance of the system under development.
  • Evaluate project’s compliance matrix: Comparing the project’s completed NPR 7150.2 compliance matrix against Appendix C in the NPR helps provide an objective review early in the life cycle to confirm that the project is planning to meet all requirements for the appropriate software classification for which the project has not received approval for relief. 
  • Confirm requirements marked “Not-Applicable” are not relevant or not capable of being applied:  Accuracy of the project’s compliance matrix is important to help ensure that the correct set of requirements is included in project plans. Requirements that are marked as “not applicable” in the compliance matrix should have corresponding project justification, risk assessments, and/or rationale to assist the ETA in confirming that those requirements are not relevant to the project or that the project cannot meet them.
  • Determine whether the project’s risks, mitigations, and related request for relief are reasonable and acceptable:  Justification, risk assessments, and/or rationale provided to assist the ETA in confirming that the requirements for which the project is seeking relief are not relevant to the project or that the project cannot meet them should be clear, complete, reasonable, and build the case which allows the ETA to deem them an acceptable basis upon which to grant the waiver or deviation.  Additionally, consideration is given to how waiving this requirement could impact this mission as well as subsequent missions. It is not uncommon for software to be reused on future missions or to evolve to a more critical role in the current mission. A relevant factor is that waivers and deviations and other relief from requirements are not granted on a permanent basis, because software developed under relief from requirements can negatively impact its reuse.
  • Coordinate approach with the Center S&MA organization: Coordination is needed with the Center SMA organization (CSMA) that the set of requirements in the compliance matrix allows the assurance of robust safety and mission assurance processes and activities for this mission and that any waived or deviated requirements do not negatively impact the safety or completion of the mission. Any disagreements should be handled by the Center-defined technical authority process.
  • Approve/disapprove the request for relief: Requirements in this NPR are invoked by software classification in Appendix C.  Requirements marked with an “X” in Appendix C are required (see SWE-139 - Shall Statements). Appendix C also lists the TA who has the responsibility for approving or disapproving waivers and deviations for each requirement.
  • Facilitate processing of requests for relief from requirements in this NPR which fall under a different Technical Authority:  Potential impact on health, medical concerns, or safety directly affects the risk consideration when evaluating a request for relief from a requirement. When these factors are relevant, it is very likely that the involvement of the Safety TA and/or the Health and Medical TA will be necessary. It is not uncommon for a waiver/deviation request to come up through one TA chain but not another. When this occurs, it is the ETA's responsibility to coordinate with counterparts.
  • Ensure approved compliance matrices, waivers and deviations, are archived: Archiving as part of the project’s records the approved compliance matrices and any waivers and deviations associated with NPR 7150 is important so that compliance decisions, notes, rationale are maintained for use by future projects as well as to justify or explain those decisions on the current project. As the project is reviewed throughout the life cycle, recalling the reasons for waivers, deviations, and approved requirements can be difficult unless they are captured and archived in a retrievable manner in a project repository.

See also 7.16 - Appendix C. Requirements Mapping and Compliance Matrix. SWE-150 - Review Changes To Tailored Requirements

3.3 ETA Considerations

The ETA who is assessing the projects’ tailoring/compliance matrices, waivers, or deviations from requirements in this NPR should also consider the impacts found by others considering the following areas:

  • Impacts on health and safety, e.g., medical TA.
  • Results of Failure Mode Effects Analysis (FMEA).
  • Findings in Hazard reports.
  • Other risk evaluations, e.g., Safety and Mission Assurance (SMA) Technical Authority (TA).  
  • Overall considerations for mission success. 

The ETA's considerations should include the interests of systems stakeholders, support organization functions, and other interested parties.

See also Topic 8.05 - SW Failure Modes and Effects Analysis

3.4 Deviation and Waiver Tracking

Information and results for deviation and waiver request activities are recorded and tracked in the project's configuration management system. Information on configuration management systems is available throughout the NASA literature. This documentation typically includes request procedures, configuration control techniques, general instructions for evaluating impacts, and guidelines for completing the necessary forms. Project development activities typically draw upon these resources to develop project-specific documentation. The request packages are typically processed through management chains, through project control boards, and to higher administrative and management levels, e.g., the Headquarters' OCE, when appropriate.

Additional guidance on deviations and waivers related to contracts may be found in the following related topic in this Handbook: 7.04 - Flow Down of NPR Requirements on Contracts and to Other Centers in Multi-Center Projects.

3.5 Compliance Matrix

The project’s compliance matrices, including tailoring, waivers, and deviations from requirements in this directive recorded in them, are a part of the software release requirements for software developed or procured by NASA per NPR 2210.1C 373.  The compliance matrices contain the information required for the release activity by the Software Release Authority. Appropriate planning by the TA and the software team can assure the availability of documentation that satisfies both NPR compliance and software release needs.

See also SWE-125 - Requirements Compliance Matrix

3.6 Record Retention

Record retention and deletion procedures contained in the configuration management process are performed in accordance with Center record management directives, as well as NPD 1440.6, NASA Records Management, 268 and NPR 1441.1D, NASA Records Retention Schedules. 037

See also SWE-121 - Document Tailored Requirements

3.7 Additional Guidance

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

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

SPAN Links

4. Small Projects

This requirement applies to all projects regardless of size.

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

  • Columbia Accident Investigation Board, Report Vol 1 144, Aug 2003, Recommendation R7.5-1: "Establish an independent Technical Engineering Authority that is responsible for technical requirements and all waivers to them, and will build a disciplined, systematic approach to identifying, analyzing, and controlling hazards throughout the life of the Shuttle System."

6.2 Other Lessons Learned

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

  • No labels