Error formatting macro: alias: java.lang.NullPointerException

Unknown macro: {div3}

1. Requirements

6.3.5 When the requirement and software class are marked with a "P (Center)," Centers and projects shall meet the requirement with an approved non-null subset of the "shall" statement (or approved alternate) for that specific requirement.

1.1 Notes

Note: The use of partial Center (i.e., "P (Center)") requirements allows for local adaptations to suit Center and application unique needs. Although the NASA Headquarters' Office of the Chief Engineer is the review and concurrence authority for the Center defined "P (Center)" requirements, this approval does not constitute a deviation nor a waiver. The project or Center is responsible for flowing down all applicable NPR 7150.2 requirements, including "P (Center)" requirements, to contracted software development activities. "P (Center)" requirements are typically documented in Center-level directives.

1.2 Applicability Across Classes

This requirement applies to all classes and safety criticalities

Class	A_SC	A_NSC	B_SC	B_NSC	C_SC	C_NSC	D_SC	D_NSC	E_SC	E_NSC	F	G	H
Applicable?

Key:    A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not Safety-Critical | ... | - Applicable | - Not Applicable
^X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

Unknown macro: {div3}

2. Rationale

NPD 1000.0A, NASA Governance and Strategic Management Handbook, ²⁶¹ provides the top-level basis for establishing a

<ac:macro ac:name="unmigrated-wiki-markup">
<ac:plain-text-body><![CDATA[

non-null set

]]></ac:plain-text-body>
</ac:macro>

of requirements in its paragraph 3.4.2.2.2: "Good requirements that are properly managed are essential to any successful undertaking. Part of establishing the proper set of requirements is the adjustment of prescribed requirements to the specific task (e.g., a program or project)."

The "P (Center)" approach was put in place to recognize the variety of NASA projects, applications, and existing Center directions on software engineering, e.g., "one size doesn't necessarily fit all." The use of "P (Center)" allows flexibility in the implementation of over 60 per cent of requirements in NPR 7150.2 for one or more classes of software. The flexibility provided by these locally designated subsets of Agency software requirements enables tailoring of the original SWE requirements.  The

<ac:macro ac:name="unmigrated-wiki-markup">
<ac:plain-text-body><![CDATA[

OCE

]]></ac:plain-text-body>
</ac:macro>

expects this tailoring to be guided by "risks vs. resources" trades that are performed by the Center engineering organizations or by the Engineering Technical Authority (TA). NPR 7150.2, Appendix D, Requirements Mapping Matrix, indicates which requirements can be tailored using the "P (Center)" approach.

The stipulation that the implementation include a non-null set of the stated requirement indicates that projects are required to include some part of the requirement to assure the safe and efficient execution of software for the project. Because NASA projects' software products have wide variations in risk and scope, it is the responsibility of the Center's engineering organization or Engineering TA to develop and approve the best implementation of the non-null set. The Headquarters' OCE reviews and concurs/non-concurs on a Center's P (Center) process approach and requirements subsets during periodic OCE surveys conducted at each Center. See [SWE-127] and [SWE-129] for guidance on the OCE concurrence process and appraisal surveys.

Unknown macro: {div3}

3. Guidance

NPR 7150.2 provides general guidance for the implementation of the P (Center) concept but delegates the development of the actual approach and process steps down to each Center.  Because of this delegation, Centers are able to develop subsets of requirements using the P (Center) approach that result in local adaptations to suit Center- and application-unique needs. This general approach assures that Centers develop the requirements for their systems and work products to match the goals and objectives of their program and projects.

The following paragraphs present two examples of approaches for implementing the P (Center) construct.

Centers may develop uniform interpretations (individual descriptions, process steps, and work product definitions) for P (Center) requirement for each class of software. Software engineering process groups (SEPGs) may be assigned to develop the approach and/or the subsets of requirements. The process groups typically record their work products, i.e., the minimally acceptable subsets, in Center-level directives. The peer and senior management review of these directives assures a Center-wide agreement and implementation of these P (Center) adaptations. This approach is well suited for Centers with a large number of similar software applications. A variation on this approach could involve the definition of specific P (Center) requirement subsets by major application area, e.g., space-based systems, aeronautics, facilities.

Other Centers may choose to assign the interpretation of P (Center) requirements to the Center Chief Engineer, the Engineering Technical Authority (TA), or the software TA. NPR 7120.5, NASA Space Flight Program and Project Management Requirements ⁰⁸², Chapter3, lists many of the basic duties of a TA. Being involved in the determination of the

<ac:macro ac:name="unmigrated-wiki-markup">
<ac:plain-text-body><![CDATA[

non-null set

]]></ac:plain-text-body>
</ac:macro>

of requirements aids the TA in the performance of these duties, as stated in section 3.3.6 of NPR 7120.5: "The Engineering Technical Authority establishes and is responsible for the engineering design processes, specifications, rules, best practices, etc., necessary to fulfill programmatic mission performance requirements." This approach is well suited for Centers with a large number of dissimilar projects.  In a variation of this latter approach, Centers could have the software TA and the software team lead draft the P (Center) subsets together during the development of the project's compliance mapping matrix. This variation assures close and continuing interactions between the software TA and the software team lead. It also supports precise alignment between the project needs and the non-null subset of approved requirements. After a number of these software TA-software team lead interactions, the software TA will become more adept at matching non-null requirement subsets to projects. However, the approval of the P (Center) subset still resides with the software TA in this scenario, not the software team lead.

The use of the term "non-null set" indicates that the software team lead must consider the requirement as a whole but may implement a prudent portion of it on the project. The implementation may be the full extent of the stated requirement. It may be the aspects related to safety only. It may reflect just the elements of the requirement for the project in question.

The use of the phrase "(or approved alternate)" refers to the potential change that may occur to a requirement of NPR 7150.2 through the use of [SWE-120] and [SWE-121].  If the

<ac:macro ac:name="unmigrated-wiki-markup">
<ac:plain-text-body><![CDATA[

OCE

]]></ac:plain-text-body>
</ac:macro>

approves a request under SWE-120 for a specific alternate requirement, the intent of the non-null set portion of this requirement will still apply.

The development of these non-null subsets of the P (Center) requirements for use on contracted efforts are also considered during the execution of the software acquisition process. (See theTopic 7.3 - Acquisition Guidance in Book C).

The Headquarters' OCE will review each Center's P (Center) approach and documentation during periodic OCE surveys conducted at the Centers. The Center's approach is expected to indicate if it uses the uniform interpretations Center directives approach, the individually tailored engineering TA approach, or a different locally developed approach. The description of the Center approach is documented in the Center's Engineering Technical Authority Implementation Plan. For an individual project, the OCE may review its compliance matrix and specific implementation of P (Center) requirements outside of these periodic surveys.

Note that projects frequently elect to go beyond the minimal subset of P (Center) requirements to address specific risks.

Unknown macro: {div3}

4. Small Projects

The implementation of the P (Center) requirements might result in a very minimal set that is applicable to small projects. Documentation requirements from Chapter 5 in NPR 7150.2 are typical candidates for Center scrubbing on small projects.

Unknown macro: {div3}

5. Resources

• (SWEREF-083)
  NPR 7150.2 NASA Software Engineering Requirements,
  NPR 7150.2D, Effective Date: March 08, 2022, Expiration Date: March 08, 2027 https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2D Contains link to full text copy in PDF format. Search for "SWEREF-083" for links to old NPR7150.2 copies.
• (SWEREF-261)
  NASA Governance and Strategic Management Handbook,
  NPD 1000.0C, NASA Governance and Strategic Management Handbook, Effective Date: January 29, 2020, Expiration Date: January 29, 2025

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

Unknown macro: {div3}

6. Lessons Learned

No lessons learned have currently been identified for this requirement.