Invalid license: Your evaluation license of Refined expired.
bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D

SWE-150 - Review Changes To Tailored Requirements
This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.

1. Requirements

2.2.10 Technical Authorities for requirements in this NPR shall review any tailored requirements whenever changes in project software plans or technical scope are made.

1.1 Notes

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

2. Rationale

Software projects that have approved tailored requirements, but at some point after project start have a change in project technical scope or planned activities, need to have those tailored requirements re-assessed to determine if the basis for the tailoring approval remains valid. If the changes to the project scope or plans invalidate the rationale for the tailored requirements, Technical Authorities for the NPR 7150.2 requirements need to perform a re-assessment to determine the best set of requirements to prevent safety or other critical issues with the delivered product.

3. Guidance

“The request for relief from a requirement includes the rationale, a risk evaluation, and reference to all material that provides the justification supporting acceptance.” 082 When a project has changes (10% or more) in its technical scope or significant elements of the project plans, the Technical Authorities for NPR 7150.2 are to re-assess the rationale, risk evaluation (updated as necessary based on the project changes), and other supporting material included in the justification for approved tailored requirements. If multiple Technical Authorities were involved in the review and approval process, those Technical Authorities are consulted during the re-assessment.

While not all-inclusive, the following list shows the types of changes to consider as triggers for re-assessing approved tailored requirements.  The significance of the impact of each change will differ by project, so project management and the Technical Authority need to work together to determine if the change impact requires a review of the project’s tailored requirements.

  • Change in selected providers or suppliers.
  • Significant changes in the schedule, including development and delivery of new technologies.
  • Significant changes in the project budget.
  • Addition or deletion of key features and functions.
  • Changes in the application environment.
  • Changes in safety criticality and/or project risk.
  • Change in software classification.
  • Change in system and/or software complexity.
  • Change in planned software reuse (i.e., use on a future mission).
  • Availability of key tools, models, simulations, and/or facilities.
  • Changes to any element of the justification for a tailored requirement.

Following the re-assessment, the following actions need to be performed:

  • Any updates to justifications associated with tailored requirements are captured in the project records and configuration managed. 
  • Project plans and associated program/project documentation are updated, as necessary, to reflect any changes in approved tailored requirements.
  • The project’s NPR 7150.2 compliance matrix is updated, as necessary, to reflect the results of the re-assessment.
  • The project team and relevant stakeholders are informed of any changes in tailored requirements (to ensure they comply with and implement those changes).

Additional guidance related to tailoring, waivers, and deviations may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects.


5. Resources

Renew your license to continue

Your evaluation license has expired. Contact your administrator to renew your Reporting for Confluence license.


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

No lessons learned have currently been identified for this requirement.


  • No labels