bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Error formatting macro: alias: java.lang.NullPointerException
SWE-121-Document Alternate Requirements
Unknown macro: {div3}

1. Requirements

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.

1.1 Notes">1.1 Notes

NPR 7150.2 does not include any notes for this requirement.

1.2 Applicability Across Classes

This requirement applies to all classes and safety criticalities.

Class

  A_SC 

A_NSC

  B_SC 

B_NSC

  C_SC 

C_NSC

  D_SC 

D_NSC

  E_SC 

E_NSC

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

   

   

   

Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

Unknown macro: {div3}

2. Rationale

The Center is required to record the alternate requirements obtained through the use of [SWE-120] in Center or program/project documentation that controls the development, acquisition, and deployment of the affected software. Publication of the approved alternate requirements helps assure that all affected software engineers are informed of the approved changes. This action will assure the proper implementation of the alternate requirement throughout the various stages of the software life cycle (See [SWE-019] for information on the life cycle process.). The inclusion of these changes in a configuration managed system for the Center or program/project will inform current and future software product developers and project managers of the correct set of requirements and procedures.

Unknown macro: {div3}

3. Guidance

Project personnel record the appropriate information on any requirements changes resulting from the approval of a request made under [SWE-120] in the project-specific software requirements documents. This information is placed in the project plan, the software management plan, and the software requirements specification. The Center's compliance matrix to NPR 7150.2 will also include the results of the approval by the Headquarters Office of the Chief Engineer (OCE). The software team lead will include any updates in the compliance matrix that reflect approved alternate requirements. The software team lead also communicates this information to affected software Technical Authorities (TA). See [SWE-125] and [SWE-128] for information on the content and handling of a compliance matrix.
When approval is granted for an action from [SWE-120], the program/project also includes the results of the request, the rationale for the request, along with any approved alterations to the initial request, in the baselined program/project documentation (e.g. Constellation program Computing System Requirements). Typically, Center changes are reflected in the Center's local implementation of the flow down of NPR 7150.2 (Center Directives / Procedural Requirements covering software engineering/assurance). The Center-level procedure typically is stored in the Center's central documentation repository. As the alternate requirements generally affect processes, related process assets are updated in the process asset library for future use by software development teams within scope of the generic waiver.

Unknown macro: {div3}

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 (waived in accordance with [SWE-120] and documented under SWE-121) that will cover multiple small projects.

Unknown macro: {div3}

5. Resources

  1. Boeing, Boeing Software Configuration Management, HOU-EGP-322, October 28, 2002. This document discusses an approach for a software Configuration Control Board within a software configuration management system.
  2. United Space Alliance, PASS Software Management Plan, USAD02859, March 27, 2003. Discusses configuration control activities within a Software Management Plan for an actual project.
  3. Software Configuration Management Technologies and Applications, Software Technology Support Center, Hill AFB ( www.stsc.hill.af.mil ).The document is a good discussion of basic CM practices and indicates the importance for documenting new and revised requirements.
  4. NASA Systems Engineering Handbook , NASA/SP-2007-6105 Rev1, 2007
  5. NASA Directives Procedural Requirements, with Change 5 (11/19/2009), NPR 1400.1D, 2009
  6. NASA Headquarters Office of the Chief Engineer engineering deviations and waivers website
  7. NASA Engineering and Program/Project Management Policy, NPD 7120.4D, 2010
  8. NASA Space Flight Program and Project Management Requirements, NPR 7120.5D (NM-7120.81), 2009.

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

Unknown macro: {div3}

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database (http://www.nasa.gov/offices/oce/llis/imported_content/lesson_1715.html ) notes that 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. OCE personnel, future projects or Center personnel will be able to avoid reevaluating these 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.

  • No labels