bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Old Version 15

changes.mady.by.user [DISABLED] Dallas, Lisa (GSFC-5830)

Saved on

compared with

New Version 69

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


{alias:SWE-140} {tabsetup:1. The Requirement\|2. Rationale\|3. Guidance\|4. Small Projects\|5. Resources\|6. Lessons Learned}\\ {div3:id=tabs-1} h1. 1. Requirements
Wiki Markup
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


Div
idtabs-1

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.

h2. {color:#003366}{*}

1.1

Notes{*}{color}

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.

h2.

1.2

Applicability

Across

Classes

This

requirement

applies

to

all

classes

and

safety

criticalities

{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 [NASA Governance and Strategic Management Handbook|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPD&c=1000&s=0A], NPD 1000.0A, provides the top level basis for establishing a non-null set of requirements in its paragraph


applicable
f1
g1
h1
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnsc1
dsc1
ensc1


 Div
idtabs-2
2. Rationale
NPD 1000.0A, NASA Governance and Strategic Management Handbook,
sweref
261
261
 provides the top-level basis for establishing a "non-null set" (a set that must contain at least one member) 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 
 sixty 
60 per 
 
 cent 
 
 of 
 
 requirements 
 
 in 
 
 NPR 
 
 7150.
2A 
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 OCE 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. 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 Technical Authority 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|https://nasa7150.onconfluence.com/display/7150/SWE-127] and [SWE-129|https://nasa7150.onconfluence.com/display/7150/SWE-129] for guidance on the OCE concurrence process and appraisal surveys.
{div3}
{div3:id=tabs-3}

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

{panel}
!exclamation.gif! Centers are expected to document their approach for implementing the P (Center) requirements.
{panel}

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 (SEPG) 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, or the software TA. The [NASA Space Flight Program and Project Management Requirements|http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_005D_&page_name=Chapter3#3_4] document lists many of the basic duties of a TA. Being involved in the determination of the non-null set of requirements should assist the TA in the performance of these duties: "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 "{color:#0000ff}non-null set'{color} 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 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.2A through the use of [SWE-120] and [SWE-121] .  If the OCE 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 {color:#0000ff}"software acquisition process"{color}. (See the [Topic 7.7 - Acquisition Guidance |http://nasa7150.onconfluence.com/display/7150/7.7+-+Acquisition+Guidance] in Book 2).

Headquarters OCE will review each Center's P (Center) approach and documentation during periodic OCE surveys conducted at the Centers. The Center's approach should 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 should be documented in the Center's Engineering Technical Authority Implementation Plan. Individual projects should be aware, however, that the OCE may review their 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.

{panel}
!exclamation.gif! Consult Center directives, PALS, and Engineering Technical Authority Plans for information detailing local direction on implementing P (Center) subsets of the SWEs. Within a project, P (Center) subsets should be base lined in the software compliance matrix.
{panel}
{div3}
{div3:id=tabs-4}

h1. 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.2A are typical candidates for Center scrubbing on small projects.
{div3}
{div3:id=tabs-5}

h1. 5. Resources

# "[NASA Governance and Strategic Management Handbook|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPD&c=1000&s=0A]",  NPD 1000.0A, 2008
# "[NASA Space Flight Program and Project Management Requirements|http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_005D_&page_name=Chapter3#3_4]", NPR 7120.5D, 2009.
# "[NASA Engineering and Program/Project Management Policy|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPD&c=7120&s=4D]", NPD 7120.4D, 2010

h2. 5.1 Tools

{toolstable}
{div3}
{div3:id=tabs-6}
 

h2.  6. Lessons Learned
 

There are currently no lessons learned identified for this requirement.

{div3}
{tabclose}


requirements.  The OCE (Office of the Chief Engineer) 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.

 Div
idtabs-3
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.

 Panel
Image Added Centers are expected to document their approach for implementing the P (Center) requirements.

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 
sweref
082
082
, Chapter 3, lists many of the basic duties of a TA. Being involved in the determination of the non-null set 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 OCE 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 the Topic 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.

 Note
Consult Center directives, PALs (Process Asset Library), and Engineering Technical Authority Implementation Plans for information detailing local direction on implementing P (Center) subsets of the SWEs. Within a project, P (Center) subsets are baselined in the software compliance matrix.


 Div
idtabs-4
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.

 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

______________________________________________________________________________