bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

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


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


Div
idtabs-1

1. Requirements

2.5.7 The project shall document software acquisition planning decisions.

1.1 Notes

This may be in an acquisition plan or in another project planning document.

1.2 Applicability Across Classes

Class F is labeled as "X (not OTS)" which means that the project is required to meet this requirement for all software that is not considered off-the-shelf.

Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.


applicable
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnsc1
dsc1
f*
gp



Div
idtabs-2

2. Rationale

There are many reasons to document acquisition planning decisions, not the least of which is to have a record of those decisions for future reference.

Documentation of software acquisition planning decisions is essential to project management and is important when changes to initial project formulation assumptions require renegotiation of acquisition activities. Records of decisions also serve as confirmations or reminders to project participants should any misunderstandings or conflicts arise as the project progresses. Lengthy projects with multiple development groups, including subcontractors, with the potential for changing personnel make it important to document decisions so that everyone continues to work toward the same goals using the same guidelines.


Div
idtabs-3

3. Guidance

When capturing acquisition planning decisions, be sure to include any related analysis that led to those decisions as that information could be important for lessons learned and future acquisition activities. The analysis typically includes the alternatives considered, the selection or evaluation criteria used to arrive at the decision, and any process used to arrive at the decision. If the team used a documented process to arrive at the decision, a reference to the process document including its location in a Center or NASA Process Asset Library (PAL), if applicable, is captured as background for the decision. Additionally, it may be useful to include the name or role of the person making or approving the acquisition planning decision for the project. All of this information will be useful to those who need to make similar decisions in the future.

When determining the information to capture, consider the following, as appropriate for the project:

  • Decisions and related analysis and/or justification regarding project scope.
  • Make vs. buy analysis and resulting decisions, see SWE-033.
  • Information needs for monitoring the management and technical performance on the contract.
  • Division of responsibilities between government and contractor.
  • Selection process, including evaluation criteria, and award decision for acquired software development services, see SWE-035.
  • Negotiated contract decisions and justification, including, but not limited to, negotiated decisions related to:
    • Requirements included or excluded from the contract, including tailoring of requirements.
    • Processes, activities, and tasks included or excluded from the contract or Statement of Work (SOW), see SWE-036.
    • Standards to be followed.
    • Cost and budget.
    • Risk and risk management.
    • Schedule, including milestones and reviews, see SWE-037.
    • Deliverables.
    • Acceptance criteria for deliverables, including software, see SWE-034.
    • Support from developer such as maintenance, operations, and retirement support.
  • Stakeholder commitments.

Capture this information as accurately as possible in the project acquisition plan.

The following Center guidance may provide insights into acquisition planning decisions that are documented in the acquisition plan:

  • Acquisition.
  • Planning.
  • Process Monitoring and Control (PMC).

See the Topic 7.3 - Acquisition Guidance in this Handbook for additional guidance on acquisition activities and related decisions.

When considering which decisions are important enough to document:

  • Consult experienced project management personnel for advice.
  • Consider the impact of the decision on the project; the higher the degree of impact on cost, schedule, safety, technical outcome, software performance, etc. the more important it is to document the decision.
  • Be sure to capture controversial decisions and "command" decisions.


Div
idtabs-4

4. Small Projects

If an acquisition plan does not exist for the project, another project planning document, such as the Project Plan or Software Development Plan, may be used to document acquisition planning decisions.


Div
idtabs-5

5. Resources


refstable



toolstable


Div
idtabs-6

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.