bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

Alias
aliasSWE-121

...

Tabsetup
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
1. The Requirement
{div3:id=} h1.
Wiki Markup
Div
idtabs-1

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.

h2. {color:#003366}{*}

1.1

Notes{*}{color} NPR

Notes

NPR 7150.2,

NASA

Software

Engineering

Requirements,

does

not

include

any

notes

for

this

requirement.

h2.

1.2

Applicability

Across

Classes

This

requirement

applies

to

all

classes

and

safety

criticalities.

{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=1|esc=1||ensc=1|f=1|g=1|h=1} {div3}

Wiki Markup
{div3:id=tabs-2}

h1. 2. Rationale

The Center is required to record the alternate requirements obtained through the use of [SWE-120|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|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.
{div3}
Wiki Markup
{div3:id=tabs-3}

h1. 3. Guidance

Project personnel record the appropriate information on any requirements changes resulting from the approval of a request made under [SWE-120|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 (TAs). (See [SWE-125|SWE-125] and [SWE-128|SWE-128] for information on the content and handling of a compliance matrix.)

When approval is granted for an action from [SWE-120|SWE-120], the program/project also includes the results of the request and the rationale for the request, along with any approved alterations to the initial request, in the baselined program/project documentation. Typically, Center changes are reflected in the Center's local implementation of the flowdown of NPR 7150.2, e.g., Center Directives, Center Procedural Requirements covering software engineering, and software assurance plans. 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.


{div3}
Wiki Markup
{div3:id=tabs-4}

h1. 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|SWE-120] and documented under SWE-121) that will cover multiple small projects.
{div3}
Wiki Markup
{div3:id=tabs-5}

h1. 5. Resources

{refstable}

{toolstable}


{div3}
Wiki Markup
{div3:id=tabs-6} h1. 6. Lessons Learned A documented lesson from the NASA Lessons Learned database notes the following: *The Pitfalls of "Engineering-by-Presentation" (2005). Lesson Number 1715*: 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. {term:OCE} personnel and 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. {sweref:566} {div3}

applicable
f1
g1
h1
asc1
ansc1
bnsc1
csc1
bsc1
esc1
cnsc1
dsc1
dnsc1
ensc1
Div
idtabs-2

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.

Div
idtabs-3

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 (TAs). (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 and the rationale for the request, along with any approved alterations to the initial request, in the baselined program/project documentation. Typically, Center changes are reflected in the Center's local implementation of the flowdown of NPR 7150.2, e.g., Center Directives, Center Procedural Requirements covering software engineering, and software assurance plans. 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.

Div
idtabs-4

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.

Div
idtabs-5

5. Resources

refstable
toolstable
Div
idtabs-6

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

The Pitfalls of "Engineering-by-Presentation" (2005). Lesson Number 1715: 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.

Term
OCE
OCE
personnel and 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.
sweref
566
566