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:SWE-047} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1. Requirements
Wiki Markup
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


Div
idtabs-1

1. Requirements

2.6.2.5

The

project

shall

require

the

software

supplier(s)

to

make

available,

electronically,

the

software

traceability

data

for

the

project's

review.

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

Classes

C

through

E

and

Safety

Critical

are

labeled

with

"SO

if

D-E."

 

  This

means

that

for

Classes

D

through

E,

this

requirement

applies

only

to

the

safety-critical

aspects

of

the

software.

Class

G

is

labeled

with

"P

(Center)."

 

  This

means

that

an

approved

Center-defined

process

that

meets

a

non-empty

subset

of

the

full

requirement

can

be

used

to

achieve

this

requirement.

{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=*|cnsc=1|dsc=*|dnsc=0|esc=*|ensc=0|f=1|g=p|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale Traceability records help ensure that project requirements are carried through design, implementation, and verification to ensure they are implemented to produce the intended product. Traceability helps identify where requirements may be missing


applicable
f1
gp
h0
ansc1
asc1
bnsc1
csc*
bsc1
esc*
cnsc1
dnsc0
dsc*
ensc0



Div
idtabs-2

2. Rationale

Traceability records help ensure that project requirements are carried through design, implementation, and verification to ensure they are implemented to produce the intended product. Traceability helps identify where requirements may be missing (i.e.,

dropped

from

the

design

or

implementation),

and

where

functionality

does

not

have

an

originating

requirement

(i.e.,

a

reason

for

being

in

the

product).

 

  The

preferred

traceability

approach

is

bidirectional

traceability,

which

traces

work

products

forward

to

the

next

life

cycle

phase

as

well

as

backward

to

the

preceding

phase,

keeping

a

continuous

link

from

beginning

to

end.

Reviewing

traceability

records

allows

the

acquirer

(NASA)

to

ensure

that

requirements

given

to

the

supplier

are

being

implemented

and

verified

and

provides

a

level

of

assurance

that

the

resulting

product

will

fulfill

its

goals

and

objectives.

 

  Traceability

records

also

allow

the

acquirer

to

assess

the

impact

of

changes

to

work

products

when

a

requirement

changes

or

an

issue

is

found

that

must

be

addressed.

Electronic

access

to

traceability

data,

or

any

supplier

records,

can

save

time

and

cost

for

both

the

supplier

and

the

acquirer

because

they

do

not

have

to

duplicate

records

and

the

acquirer

can

use

search

utilities

to

review

the

records.

{div3} {div3:id=


Div
idtabs-3
} h1.

3.

Guidance

Include

requirements

for

suppliers

to

provide

electronic

access

to

traceability

data

as

part

of

the

solicitation

(e.g.,

{term:RFP}) as well as the resulting contract. Access could be as simple as an account on the supplier (provider) system that contains the traceability records. Alternatively, access could be granted by providing electronic copies of the records through email or via electronic media, such as a USB drive or DVD, making sure to follow the appropriate NASA IT security policies for electronic media.    Factors which could affect the actual method by which the supplier provides electronic access to traceability data include: * The supplier's traceability tools. * Acquirer preference for receipt of the data. * Ease of accessing the supplier's systems. * Other factors specific to the project. Before starting the traceability activity, it is assumed that the documents being traced (e.g., requirements, design, code, test data, etc.)  have been approved. \\ When reviewing traceability data, the following tasks may be included, as appropriate for the life cycle phase or the needs of the project: * Confirm that every software requirement is included. * Confirm the elements in the traceability data are clearly identifiable and distinguishable from each other. ** Unique identifiers for each requirement, design element, code element, test procedure or test case. * Confirm bidirectional traceability is between: ** Software requirements and higher-level requirements. ** Design elements and software requirements. ** Source code and software design. ** Test procedures and the software requirements they verify (confirm during {term:FCA}/{term:PCA}audits). * Confirm there are no "holes" in the traceability data. ** Indicating missing elements in the software requirements, design, code, tests. ** Indicating elements with no reason ("parent" or requirement) for being part of the product (scope "creep" or "gold-plating"). * Determine if traceability data is being maintained and kept up to date. * Assess impact of known changes and issues. ** Identify affected work products via the links in the traceability data. * Assess test coverage. ** Determine if sufficient tests are used for safety-critical or other key functionality\* Plan testing strategy. * Plan testing strategy: ** Identify where requirements are implemented in the design. ** Requirements implemented in multiple design elements may require high-level testing. ** Requirements implemented in a single design element or code module may be tested at a lower level. ** Determine order of testing, especially when time is short. * Determine maintenance tasks. ** Areas affected by a change are identified in the traceability data. * Determine who to notify when a change occurs (owner/author of traced work products). See [Topic 7.3 - Acquisition Guidance|7.3 - Acquisition Guidance] in this Handbook for guidance on acquisition activities which include considerations and requirements for solicitations and contracts as well as monitoring activities such as access to and review of project records. Guidance related to bidirectional traceability, including what suppliers include in their software traceability data, may be found in the following related requirements in this Handbook: | [SWE-052|SWE-052] | Bidirectional Traceability Between Higher Level Requirements and Software \\ | | [SWE-059|SWE-059] | Bidirectional Traceability Between Software Requirements and Software Design \\ | | [SWE-064|SWE-064] | Bidirectional Traceability Between Software Design and Software Code \\ | | [SWE-072|SWE-072] | Bidirectional Traceability Between Software Test Procedures and Software | {div3} {div3:id=tabs-4} h1. 4. Small Projects No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph. {div3} {div3:id=tabs-5} h1. 5. Resources {refstable} {toolstable} {div3} {div3:id=tabs-6} h1. 6. Lessons Learned The NASA Lessons Learned database contains the following lessons learned related to traceability data: *Orbital Space Plane - Technical Rigor & Integrity. Lesson Number 1504:* A documented lesson from the NASA Lessons Learned database notes that life cycle milestone reviews can be affected by poor requirement traceability.  The project milestone review deliverables for the project described in the Lesson Learned did not effectively communicate the work performed by the contractors to the reviewers. Contractor requirements traceability matrices did not fully address the issues of requirement rationale and allocation. The number of documents delivered and the lack of clear organization for traceability of requirements hampered the milestone ((Software Requirements Review (SRR), Software Design Review (SDR)) review process{sweref:560}. *Software Requirements Management. Lesson Number 3377:* A second lesson from the NASA Lessons Learned database notes that the "ability to manage and trace software requirements is critical to achieve success in any software project and to produce software products in a cost-effective and timely fashion... Manual methods for management of software requirements are ineffective and inefficient, contributing to excessive costs as well as schedule delays. Aspects of the management of software requirements include the elicitation/specification, analysis, development, tracking, and changing of software requirements used during the implementation and sustaining phases of the software life cycle. Management and traceability of software requirements are critical to the success of producing reliable, high-quality, and safe software products that meet end-users requirements and needs in a cost-effective and timely fashion."{sweref:576} {div3} {tabclose}

RFP (Request for Proposal)) as well as the resulting contract.

Access could be as simple as an account on the supplier (provider) system that contains the traceability records. Alternatively, access could be granted by providing electronic copies of the records through email or via electronic media, such as a USB drive or DVD, making sure to follow the appropriate NASA IT security policies for electronic media.   

Factors which could affect the actual method by which the supplier provides electronic access to traceability data include:

  • The supplier's traceability tools.
  • Acquirer preference for receipt of the data.
  • Ease of accessing the supplier's systems.
  • Other factors specific to the project.

Before starting the traceability activity, it is assumed that the documents being traced (e.g., requirements, design, code, test data, etc.)  have been approved.
When reviewing traceability data, the following tasks may be included, as appropriate for the life cycle phase or the needs of the project:

  • Confirm that every software requirement is included.
  • Confirm the elements in the traceability data are clearly identifiable and distinguishable from each other.
    • Unique identifiers for each requirement, design element, code element, test procedure or test case.
  • Confirm bidirectional traceability is between:
    • Software requirements and higher-level requirements.
    • Design elements and software requirements.
    • Source code and software design.
    • Test procedures and the software requirements they verify (confirm during FCA (Functional Configuration Audit) / PCA (Physical Configuration Audit) audits).
  • Confirm there are no "holes" in the traceability data.
    • Indicating missing elements in the software requirements, design, code, tests.
    • Indicating elements with no reason ("parent" or requirement) for being part of the product (scope "creep" or "gold-plating").
  • Determine if traceability data is being maintained and kept up to date.
  • Assess impact of known changes and issues.
    • Identify affected work products via the links in the traceability data.
  • Assess test coverage.
    • Determine if sufficient tests are used for safety-critical or other key functionality.
  • Plan testing strategy:
    • Identify where requirements are implemented in the design.
    • Requirements implemented in multiple design elements may require high-level testing.
    • Requirements implemented in a single design element or code module may be tested at a lower level.
    • Determine order of testing, especially when time is short.
  • Determine maintenance tasks.
    • Areas affected by a change are identified in the traceability data.
  • Determine who to notify when a change occurs (owner/author of traced work products).

See Topic 7.3 - Acquisition Guidance in this Handbook for guidance on acquisition activities which include considerations and requirements for solicitations and contracts as well as monitoring activities such as access to and review of project records.

Guidance related to bidirectional traceability, including what suppliers include in their software traceability data, may be found in the following related requirements in this Handbook:


SWE-052

Bidirectional Traceability Between Higher Level Requirements and Software

SWE-059

Bidirectional Traceability Between Software Requirements and Software Design

SWE-064

Bidirectional Traceability Between Software Design and Software Code

SWE-072

Bidirectional Traceability Between Software Test Procedures and Software



Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.


Div
idtabs-5

5. Resources


refstable

toolstable


Div
idtabs-6

6. Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to traceability data:

Orbital Space Plane - Technical Rigor & Integrity. Lesson Number 1504: A documented lesson from the NASA Lessons Learned database notes that life cycle milestone reviews can be affected by poor requirement traceability.  The project milestone review deliverables for the project described in the Lesson Learned did not effectively communicate the work performed by the contractors to the reviewers. Contractor requirements traceability matrices did not fully address the issues of requirement rationale and allocation. The number of documents delivered and the lack of clear organization for traceability of requirements hampered the milestone ((Software Requirements Review (SRR), Software Design Review (SDR)) review process

sweref
560
560
.

Software Requirements Management. Lesson Number 3377: A second lesson from the NASA Lessons Learned database notes that the "ability to manage and trace software requirements is critical to achieve success in any software project and to produce software products in a cost-effective and timely fashion... Manual methods for management of software requirements are ineffective and inefficient, contributing to excessive costs as well as schedule delays. Aspects of the management of software requirements include the elicitation/specification, analysis, development, tracking, and changing of software requirements used during the implementation and sustaining phases of the software life cycle. Management and traceability of software requirements are critical to the success of producing reliable, high-quality, and safe software products that meet end-users requirements and needs in a cost-effective and timely fashion."

sweref
576
576