3. GuidanceComplete 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).
 - 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).
 - 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.
When questions arise regarding software classification, consult the Engineering Technical Authority (TA). |
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:
|