bannerb

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

Include Page
2B-Page Warning
2B-Page Warning

Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Div
idtabs-1

1. Requirements

3.5.5 If a software component is determined to be safety critical software then software component classification shall be Software Class D or higher.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

 Text

Applicable b
a1
b1
csc1
c1
d1
dsc1
e1
f1
g1
h1

Div
idtabs-2

2. Rationale

The level of rigor required to develop and assure safety-critical software requires that safety-critical software be classified at a sufficiently high level that the minimum set of applicable requirements help ensure the appropriate level of rigor is applied.

Div
idtabs-3

3. Guidance

Safety critical software is any condition, event, operation, process, equipment, or system that could cause or lead to severe injury, major damage, or mission failure if performed or built improperly, or allowed to remain uncorrected.  All safety-critical software development programs are to have a minimal set of required software engineering development requirements.

Once a software component is determined to be safety-critical (see SWE-133), the minimum software classification for that component is Class D.  There are no exceptions.  If the software is safety critical software, then the software development is expected to meet the requirements for Class D, at a minimum. 

Engineering Technical Authorities (ETA) check the accuracy of the project’s classification of software components, so they ensure this requirement is met. The Center ETA can also waive or tailor specific requirements if the project provides adequate justification (see SWE-126). 

During the software development life cycle, periodic re-evaluations of safety-criticality and classification occur (see SWE-021), so the project and Center ETA need to keep this classification “rule” in mind as those reviews occur.

Additional guidance related to safety critical classification may be found in the following related requirement in this Handbook:

SWE-021

Transition to a Higher Class

SWE-126

Waiver and Deviation Consideration

SWE-133

Software Safety Determination

Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects.

Div
idtabs-5

5. Resources

refstable
 


toolstable
 

Div
idtabs-6

6. Lessons Learned

There are currently no Lessons Learned identified for this requirement.