bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Old Version 13

changes.mady.by.user Malnick, Kathy D. (IVV-180.0)[Affiliate]

Saved on

compared with

New Version Current

changes.mady.by.user Haigh, Fred Douglas. (HQ-KA000)[PEROT]

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Wiki Markup
{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
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 to specific systems and subsystems containing software is determined through the use of the NASA-wide definitions for software classes in Appendix E 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 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 the 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

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. h2.

Chapter 5 ["Software Documentation 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 NPR 7150.2 Appendix E, along with the Requirements Mapping Matrix in NPR 7150.2 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 ..." 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 the NASA Software Safety Standard{sweref:271}) * Complexity (developmental and operational complexity is woven into the class definitions) * Investment A no-cost classification [tool|http://knox.optimle.com/softwareclasses] is available to help organizations classify software.  Section 7.2 - [Classification Tool and Safety Critical Assessment Tool|https://nasa7150.onconfluence.com/display/7150/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 mis-classification 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|http://nasa7150.onconfluence.com/display/7150/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 There is currently no guidance for this requirement specific to small projects. {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}

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
    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
    271
  • Complexity (developmental and operational complexity is woven into the class definitions).
  • 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:

SWE-021 - Transition to a Higher Class
SWE-132 - Independent Software Classification Assessment
SWE-133 - Software Safety Determination
Topic 7.02 - Classification and Safety-Critical Assessment
 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.



    
    






    
	

    
    
    



    




    
    

    
    
    






        



        

    

    



										
								
		        

		    



		
						
 











Page Editor: Tim Crumbley 

NASA Official: Tim Crumbley






NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer

 NASA Privacy Statement

______________________________________________________________________________