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: Removed reference to "Classification Tool" in tab 3 and replaced table of SWEs and topics
{alias:SWE-020} {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.2.8.1

The

project

shall

classify

each

system

and

subsystem

containing

software

in

accordance

with

the

software

classification

definitions

for

Classes

A,

B,

C,

D,

E,

F,

G,

and

H

software

in

Appendix

E.

h2. {color:#003366}{*}

1.1

Notes{*}{color} The applicability of requirements in this NPR \

Notes

The applicability of requirements in this NPR [7150.2,

NASA

Software

Engineering

Requirements

\

]

to

specific

systems

and

subsystems

containing

software

is

determined

through

the

use

of

the

NASA-wide

definitions

for

software

classes

in

Appendix

E

\

[Software

Classifications

\

]

and

the

designation

of

the

software

as

safety-critical

or

non

safety-critical

in

conjunction

with

the

Requirements

Mapping

Matrix

in

Appendix

D.

These

definitions

are

based

on

(1)

usage

of

the

software

with

or

within

a

NASA

system,

(2)

criticality

of

the

system

to

NASA's

major

programs

and

projects,

(3)

extent

to

which

humans

depend

upon

the

system,

(4)

developmental

and

operational

complexity,

and

(5)

extent

of

the

Agency's

investment.

The

NPR

\

[7150.2

\

]

allows

software

written

to

support

development

activities

(e.g.,

verification

software,

simulations)

to

be

classified

separately

from

the

system

under

development;

however,

such

support

software

is

usually

developed

in

conjunction

with

the

system

and

not

as

a

separate

project.

Projects

may

decide

to

reuse

processes

and

work

products

established

for

the

development

of

the

system

to

satisfy

NPR

7150.2

requirements

for

the

support

software.

The

software

assurance

organization

will

perform

an

independent

classification

assessment

and

the

results

will

be

compared

as

per

NASA-STD-8739.8,

Software

Assurance

Standard.

Software

management

and

software

assurance

must

reach

agreement

on

classification

of

systems

and

subsystems.

Disagreements

are

elevated

via

both

the

Engineering

Technical

Authority

and

Safety

and

Mission

Assurance

Technical

Authority

chains.

The

classification

decision

is

documented

in

the

Software

Development

or

Management

Plan

as

defined

in

Chapter

5

\

["Software

Documentation

Requirements\]. h2.

Requirements", section 5.1.1].

1.2

Applicability

Across

Classes Appendix D of NPR 7150.2 does not include any notes for this requirement. {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} {div3:id=tabs-2} h1. 2. Rationale The definitions of the different classes of software which are defined in Appendix E of NPR 7150.2, along with the Requirements Mapping Matrix in Appendix D, provide a built-in method of tailoring software requirements. Classifying software essentially provides pre-tailoring of software engineering requirements, software safety requirements, software assurance requirements, and other software requirements for different types and levels of software.  While every requirement may be applicable to the highest classification (Class A), not every requirement will be applicable to lower-level classifications. {div3} {div3:id=tabs-3} h1. 3. Guidance Complete classifying software as soon as it has been determined that a project includes software. Both the project and software assurance independently classify software and, as stated in the NPR 7150.2 note for this requirement, "Software management and software assurance must reach agreement on classification of systems and subsystems. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains. The classification decision is documented in the Software Development or Management Plan ..." NASA has two significant +independent+ classification schemas for software: (1) A software engineering lettered definitions "A" through "H" as described in NPR 7150.2, Appendix E; and (2) A software safety definition

Classes


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

2. Rationale

The definitions of the different classes of software which are defined in Appendix E of NPR 7150.2, along with the Requirements Mapping Matrix in Appendix D, provide a built-in method of tailoring software requirements. Classifying software essentially provides pre-tailoring of software engineering requirements, software safety requirements, software assurance requirements, and other software requirements for different types and levels of software.  While every requirement may be applicable to the highest classification (Class A), not every requirement will be applicable to lower-level classifications.

Div
idtabs-3

3. Guidance

Complete classifying software as soon as it has been determined that a project includes software. Both the project and software assurance independently classify software and, as stated in the NPR 7150.2 note for this requirement, "Software management and software assurance must reach agreement on classification of systems and subsystems. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains. The classification decision is documented in the Software Development or Management Plan ..."

NASA has two significant independent classification schemas for software: (1) A software engineering lettered definitions "A" through "H" as described in NPR 7150.2, Appendix E; and (2) A software safety definition "Safety-Critical"/"Not

Safety-Critical"

as

described

in

NASA-STD-8739.8,

Appendix

A.

These

are

independent

from

one

another

to

avoid

placing

an

unnecessary

requirements

burden

on

software

efforts

that

may

not

be

highly

critical

from

a

NASA

spaceflight

perspective,

but

happen

to

be

safety

critical.

An

example

of

this

situation

is

a

simple

lab

experiment

that

involves

class

"D"

software,

but

controls

apparatus

which

presents

a

hazard.

The

safety

hazards

need

to

be

fully

addressed,

but

the

non

safety-related

engineering

and

management

requirements

can

be

relatively

few

in

number.

NPR

7150.2

treats

NASA

software

classification

essentially

as

an

ordered

pair

(Lettered

Classification

X

Safety-Criticality).

For

a

given

system

or

subsystem,

software

is

expected

to

be

uniquely

defined

within

a

single

classification

pair.

Knowing

this

pair

determines

the

minimal

set

of

software

requirements

from

NPR

7150.2

needing

to

be

addressed

(via

Appendix

D

of

NPR

7150.2)

by

the

project's

software

team.

When

classifying

software

be

sure

to

consider:

*

  • All
  • software
  • for
  • the
  • system
  • or
  • subsystem
  • (classification
  • may
  • need
  • to
  • be
  • assessed
  • separately).
{sweref:278} * How the software is intended to be used. * Relevance to major programs and projects. * Interaction with humans. * Safety criticality (see "Safety-Critical Software Determination" in
  • sweref
    278
    278
  • How the software is intended to be used.
  • Relevance to major programs and projects.
  • Interaction with humans.
  • Safety criticality (see "Safety-Critical Software Determination" in NASA-STD-8739.8).
{
  • sweref
:271} * Complexity
  • 271
    271
  • Complexity (developmental
  • and
  • operational
  • complexity
  • is
  • woven
  • into
  • the
  • class
  • definitions).
* Investment. A no-cost classification tool is available to help organizations classify software.  [Topic 7.2 - Classification Tool and Safety-Critical Assessment Tool|7.2 - Classification Tool and Safety-Critical Assessment Tool] of this Handbook contains an introduction to the tool and its current Web address. This tool is just a first step in classifying software, but can be useful when starting the process because the results from the tool and the supporting rationale can be printed and included in classification documentation. Final classification of software occurs through project agreement with the independent check performed by the Software Assurance organization (see [SWE-132|SWE-132]). In the event of a conflict, the designated Software Engineering Technical Authority facilitates a resolution between the project and the Center Safety and Mission Assurance Organization, if possible. Care should be taken to properly classify software, since misclassification will result in missed requirements that will eventually be discovered (at reviews, during testing, etc.), resulting in greater cost and/or the submission of waivers to the Engineering Technical Authority. As a project progresses, the software classification is revisited since design and usage decisions may be revised which alter the original classification (see [SWE-021|SWE-021]). For example, a research project may be so successful during development and testing that a decision is made to take the system out of the research laboratory and directly to the field for use in a real-world environment. This decision alters the software classification and the associated engineering, safety, and assurance requirements needed to fulfill the increased level of rigor and ensure delivery of a safe, quality product.    {panel}When questions arise regarding software classification, consult the Engineering Technical Authority (TA). {panel} {note}Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to classifying software. {note} Additional guidance related to classifying software may be found in the following related requirement in this Handbook: | [SWE-021|SWE-021] | Transition to a Higher Class | | [SWE-132|SWE-132] | Independent Software Classification Assessment | | [SWE-133|SWE-133] | Software Safety Determination | | [Topic 7.2 - Classification Tool and Safety-Critical Assessment Tool|7.2 - Classification Tool and Safety-Critical Assessment Tool] | Classification Tool and Safety Criticality Assessment Tool | \\ {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  No Lessons Learned have currently been identified for this requirement.{div3} {tabclose}
  • Investment.

Final classification of software occurs through project agreement with the independent check performed by the Software Assurance organization (see SWE-132). In the event of a conflict, the designated Software Engineering Technical Authority facilitates a resolution between the project and the Center Safety and Mission Assurance Organization, if possible. Care should be taken to properly classify software, since misclassification will result in missed requirements that will eventually be discovered (at reviews, during testing, etc.), resulting in greater cost and/or the submission of waivers to the Engineering Technical Authority.

As a project progresses, the software classification is revisited since design and usage decisions may be revised which alter the original classification (see SWE-021). For example, a research project may be so successful during development and testing that a decision is made to take the system out of the research laboratory and directly to the field for use in a real-world environment. This decision alters the software classification and the associated engineering, safety, and assurance requirements needed to fulfill the increased level of rigor and ensure delivery of a safe, quality product.   


Panel

When questions arise regarding software classification, consult the Engineering Technical Authority (TA).

Note

Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to classifying software.


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


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

 No Lessons Learned have currently been identified for this requirement.