Book A.

Book B.
7150 Requirements Guidance

Book C.

References, & Terms

(NASA Only)

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
{tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned}


h1. 1. Requirements The Software Development or Management Plan shall contain:
     a. Project organizational structure showing authority and responsibility of each organizational unit, including external organizations (e.g., Safety and Mission           Assurance, Independent Verification and Validation (IV&V), Technical Authority, NASA Engineering and Safety Center, NASA Safety Center).
     b. The safety criticality and classification of each of the systems and subsystems containing software.
     c. Tailoring compliance matrix for approval by the designated Engineering Technical Authority, if the project has any waivers or deviations to this NPR.
     d. Engineering environment (for development, operation, or maintenance, as applicable), including test environment, library, equipment, facilities, standards,           procedures, and tools.
     e. Work breakdown structure of the life-cycle processes and activities, including the software products, software services, non-deliverable items to be performed,           budgets, staffing, acquisition approach, physical resources, software size, and schedules associated with the tasks.
     f. Management of the quality characteristics of the software products or services.
     g. Management of safety, security, privacy, and other critical requirements of the software products or services.
     h. Subcontractor management, including subcontractor selection and involvement between the subcontractor and the acquirer, if any.
     i. Verification and validation.
     j. Acquirer involvement.
     k. User involvement.
     l. Risk management.
     m. Security policy.
     n. Approval required by such means as regulations, required certifications, proprietary, usage, ownership, warranty, and licensing rights.
     o. Process for scheduling, tracking, and reporting.
     p. Training of personnel, including project unique software training needs.
     q. Software life-cycle model, including description of software integration and hardware/software integration processes, software delivery, and maintenance.
     r. Configuration management.
     s. Software documentation tree.
     t. Software peer review/inspection process of software work products.
     u. Process for early identification of testing requirements that drive software design decisions (e.g., special system level timing requirements/checkpoint restart).
     v. Software metrics.
     w. Content of software documentation to be developed on the project.
     x. Management, development, and testing approach for handling any commercial-off-the-shelf (COTS), government-off-the-shelf (GOTS), modified-off-the-shelf           (MOTS), reused, or open source software component(s) that are included within a NASA system or subsystem.

h2. {color:#003366}{*}1.1 Notes{*}{color}

Verification includes: 

     a. Identification of selected software verification methods and         criteria across the life cycle (e.g., software peer review/inspections procedures, re-review/inspection          criteria, testing procedures). 
     b. Identification of selected work products to be verified. 
     c. Description of software verification environments that are to be established for the project (e.g., software testing environment, system testing environment,          regression testing environment). 
     d. Identification of where actual software verification records and analysis of the results will be documented (e.g., test records, software peer review/inspection          records) and where software verification corrective action will be documented. 

Validation includes: 

     a. Identification of selected software validation methods and criteria across the life cycle (e.g., prototyping, user groups, simulation, analysis, acceptance testing, operational demonstrations). 
     b. Identification of selected work products to be validated. 
     c. Description of software validation environments that are to be established for the project (e.g., simulators for operational environment). 
     d. Identification of where actual software validation records and analysis of the results will be documented (e.g., user group records, prototyping records, and acceptance testing records) and where software validation corrective action will be documented. 

h2. 1.2 Applicability Across Classes

Appendix D of NPR 7150.2A does not include any notes for this requirement.



h1. 2. Rationale



h1. 3. Guidance



h1. 4. Small Projects



h1. 5. Resources

# add
# add

h2. 5.1 Tools



h2. 6. Lessons Learned