You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

7.3 - Acquisition Guidance

1. Purpose

This topic discusses guidance for projects implementing those requirements in NASA Procedural Requirement (NPR) 7150.2, NASA Software Engineering Requirements that address software acquisition. This guidance is intended for all persons responsible for the software acquisition process, from the planning stages through contract closeout. Acquisition may involve procedures and regulations external to the software community, including variations by contract type; therefore, it is important to consult Center guidance and coordinate acquisition activities among the proper stakeholders, including, but not limited to, software engineering, procurement, finance, and contracts.

1.1 Roles



Project Manager

Approve procurement plan.

Software Lead Engineer

Prepare procurement plan; prepare statement of work (SOW) software requirements and software data requirements for the contract; monitor execution of contract; conduct trade studies, engineering analyses.

System Engineer

Conduct trade studies, engineering analyses.

Contracting Officer (CO)

Prepare acquisition approach, prepare solicitation, guide proposal evaluation, prepare contracts, prepare modifications to contracts.

Contracting Officer's Representative (COR)

Work with CO to plan acquisition approach, prepare SOW, evaluate proposals, determine the technical adequacy of proposed approach, monitor technical implementation.

Software Technical Authority

Before contract release, verify that the SOW includes the complete flowdown of the Agency and Center software requirements [recommended practice].

2. Planning

Before software acquisition can be carried out, a need must be identified for which a solution is required.  During the planning stage, various options to address the identified need are evaluated.  The following are possible options:

  • Acquire off-the-shelf (OTS) product.
  • Develop/perform service in-house (make/buy decision).
  • Contract development/service.
  • Use/enhance existing product/service (consider reuse of existing software components for applicability to project).

If the solution to the need will involve software, NPR 7150.2 applies, and the acquisition planning guidance below supports project success:

  1. Define the scope of the system of interest.
  2. Identify the goals and objectives for the software portion of the system.
  3. Identify key stakeholders.
  4. Perform “make or buy” market research/trade studies to determine if an

    <ac:macro ac:name="unmigrated-wiki-markup">



    solution exists.
  5. Establish criteria (and a plan) for the studies:
    • Technical requirements (functional, operational, performance):
    • NPR 7150.2 classification.
    • Constraints and limitations (cost, schedule, resources).
    • Use past studies, known alternatives, existing make/buy criteria.
    • Conduct studies:
      • Assess potential products and technologies.
      • Assess how well technical requirements are addressed.
      • Assess estimated costs, including support.
      • Assess safety criticality.
      • Identify risks (delivery, safety, development practices used by supplier, supplier track record, etc.).
      • Assess provider business stability, past performance, ability to meet maintenance requirements, etc.
      • Assess commercial off-the-shelf/government off-the-shelf/military off-the-shelf products for potential use. (See SWE-027.)
    • Identify in-house capabilities to meet the need:
      • Assess availability of existing products which could meet the need or be modified to meet the need.
      • Assess availability of qualified personnel for development or modification activities.
      • Assess estimated costs (time, personnel, materials, etc.), including support.
        • Use past projects as basis, where appropriate.
      • Identify risks.
    • Determine if solution will be custom made, an existing product, or a modified existing product.
  6. Identify any acquisition risks based on requirements and “make or buy” decisions.
  7. Create at least one government software cost estimate (SWE-015) for this work.
  8. Document analysis:
    • Expected classification of the software to be acquired.
    • Availability of in-house staff and funding resources.
    • Availability of the software product(s).
    • Projected licensing and support costs.
    • List of potential suppliers.
    • Security considerations.
    • Potential risks related to supplier’s viability and past performance.
  9. Document solution choice and basis for that choice:
    • Estimate of in-house versus acquisition costs (including OTS solutions and any associated costs for requirements not met by the OTS solution).
    • Comparison of cost estimates to available funding.
    • Risk assessment.
    • Assumptions, observations, rationale, determining factors.
    • Significant issues, impacts of each option.
    • If solution is in-house development/service, an acquisition is no longer required.
    • If solution is to acquire product/service, continue with this guidance as needed based on development under contract or purchase OTS solution.
    • Other planning decisions resulting in best overall value to NASA.
    • Description of chosen acquisition strategy.
  10. Identify

    <ac:macro ac:name="unmigrated-wiki-markup">

    relevant stakeholders


    based on requirements and “make or buy” decisions:
    • Those directly concerned with, or affected by, the acquisition decision. 
    • May include management, the project team, procurement, customers, end users, and suppliers.
  11. Ensure acquisition team includes organization from NASA (acquirer) with appropriate (see SWE-032) non-expired Capability Maturity Model Integration (CMMI®) rating as measured by a Software Engineering Institute (SEI) authorized or certified lead appraiser.*
  12. Report analysis and resulting decision to appropriate stakeholders.
  13. Document lessons learned for future acquisition activities.
  14. Develop acquisition schedule, including solicitation, supplier selection, supplier monitoring, and product acceptance and transition to operations, as appropriate.
  15. Develop acquisition plan using Center-specific template.

*Class A software acquisition guidance – When a project seeks to acquire a system that includes Class A software, the project's acquisition team is required to have support from personnel in an organization that has been rated at a Capability Maturity Model Integration for Development (CMMI®-DEV) Maturity Level 3 or higher or rated at CMMI®-DEV Capability Level 3 in at least the process areas of Supplier Agreement Management and Process and Product Quality Assurance. Evidence that a CMMI®-DEV Level 3 rated organization has participated in the acquisition activities could include direct support on the acquisition team and/or review and approval of the acquisition products by the CMMI®-DEV rated organization. The extent of the CMMI®-DEV Level 3 rated organization's support required for a Class A acquisition should be determined by the Center's Engineering Technical Authority responsible for the project. Identification of the appropriate personnel from an organization that has been rated at a CMMI®-DEV Level 3 or higher to support the project acquisition team is the responsibility of the designated Center Engineering Technical Authority and Center management.

Class B software acquisition guidance - In the case of the project's acquiring a system that includes Class B software, the project's acquisition team is required to have support from organizations that have been rated at CMMI®-DEV Level 2 or higher or rated at CMMI®-DEV Capability Level 2 in at least the process areas of Supplier Agreement Management and Process and Product Quality Assurance. Evidence that a CMMI®-DEV Level 2 rated organization has participated in the acquisition activities could include direct involvement in the development of supplier agreements or review and approval of these agreements. The support must also include review and approval of any software-related contract deliverables. The Center Engineering Technical Authority responsible for the project determines the extent of the CMMI®-DEV Level 2 rated organization's support required for a Class B acquisition. Identification of the appropriate personnel from an organization that has been rated at a CMMI®-DEV Level 2 or higher to support the project acquisition team is the responsibility of the designated Center Engineering Technical Authority and Center management.

Classes A and B general guidance - The Center Engineering Technical Authority has the responsibilities for ensuring that the appropriate and required NASA software engineering requirements are included in an acquisition. For those cases in which a Center or project desires a general exclusion from the NASA software engineering requirement(s) in this NPR or desires to generically apply specific alternate requirements that do not meet or exceed the requirements of this NPR, the requester shall submit a waiver for those exclusions or alternate requirements for approval by the NASA Headquarters' Chief Engineer with appropriate justification. 

3. Solicitation, Selection, and Award

Once the planning activities for software acquisition have been completed and the decision has been made to acquire the software or software development services, a selection process needs to be followed to choose the best provider for the project. This process typically begins with development of a Statement of Work (SOW).

Typically, solicitations are prepared by the procurement or contracts department with input from project management and engineering. Solicitations are as complete as possible to ensure potential providers are aware of all tasks and activities for which they will be held responsible.

Checklists (e.g., the NASA Process Asset Library (PAL) contains checklists for NPR 7150.2 requirements by class and safety criticality) and solicitations for similar projects help ensure that all required activities are included in the solicitation. Example solicitations,

<ac:macro ac:name="unmigrated-wiki-markup">



s, and work breakdown structures (

<ac:macro ac:name="unmigrated-wiki-markup">



s) that are considered "best practices" are also helpful starting points; using problematic examples will only carry forward the problems exhibited or caused by those documents.

The following is a list of useful practices when documenting tasks and activities in the solicitation:

  • Keep the task descriptions clear, concise, and in terms that providers will understand.
  • Avoid over-specifying (specifying every item to the smallest detail leaving no options).
  • Avoid under-specifying (providing insufficient or incomplete details).
  • Clearly mark mandatory versus optional/recommended tasks, activities, standards, etc.

The following recommendations should be considered as part of the SOW development process. Additionally, a SOW checklist reference is included in the Useful Practices, Activities and Templates section (tab 8) of this guidance document.

  1. Develop solicitation, including

    <ac:macro ac:name="unmigrated-wiki-markup">




*Acquisition should not simply levy NPR 7150.2 as a whole on a potential supplier, as it contains some NASA institutional requirements. If a project is acquiring software development services for Classes A through H software, the project should only levy the applicable minimal set of supplier requirements, plus additions that address specific risk concerns. Requirements that are the responsibility of the Agency, Center, or Headquarters should not be levied on a contractor, as they will cause confusion and unnecessary expense.

If the class of software and the safety-critical designation are known when the SOW is written, the project can levy, via a compliance matrix, the project-/system-specific set of NPR 7150.2 requirements to be satisfied by the contractor. If the class and/or safety-critical designation are not yet known, the SOW should list applicable requirements for each class and safety-critical designation with instructions to comply accordingly when a class and safety-critical designation are determined.

The full list of project-related requirements can be found in the compliance matrices found in the Software Engineering Community of Practice Document Repository on the NASA Engineering Network (NEN).

2. Ensure proper review of SOW before delivery to procurement/contracts official:

    • Technical Authority to ensure proper flowdown of NPR 7150.2 requirements.
    • Coordinate with the Safety and Mission Assurance Office to ensure all quality assurance requirements, clauses, and intended delegations are identified and included.

3. Identify potential suppliers.
4. Distribute solicitation package.
5. Evaluate proposals (typically an evaluation team), based on selection criteria established during the acquisition planning phase, including:

    • Cost estimation comparisons.
    • Evaluation of how well proposed solutions meet the requirements (including interface and technology requirements, NPR 7150.2 requirements).
    • Staff available.
    • Past performance.
    • Software engineering and management capabilities.
    • Prior expertise on similar projects.
    • Available resources (facilities, hardware, software, training, etc.).
    • Capability Maturity Model Integration (CMMI®) ratings.
      • Check the SEI Published Appraisal Results (PARs) to confirm non-expired rating ( $param0.
      • Be sure to check the scope of the organization holding the CMMI® rating to confirm the rating is held by the specific organization submitting the proposal.
    • Other factors relevant to the project.
    6. Select supplier/contractor and document basis for selection.
    7. Negotiate, finalize and document contract:
    • Based on SOW.
    • Management reviews and meetings, such as:
    • Consider for inclusion in contract provisions (description of the method to be used) for verification of:
      • Contractor handling of requirements changes.
      • Accuracy of contractor transformation of high-level requirements into software requirements and detailed designs.
      • Interface specifications between the contractor’s product and systems external to it.
      • Adequacy of contractor’s risk management plan and its implementation in accordance with the required activities in the project Software Risk Management Plan.
      • Adequacy of the contractor’s integration and test plan and its implementation in accordance with the required activities in the project Software Integration and Test Plan.
      • Adequacy of the contractor’s configuration management plan and its implementation in accordance with the required activities in the project Software Configuration Management Plan.
    • Consider for inclusion in the contract the content and frequency of progress reports and metrics submissions.
    • Consider for inclusion in the contract identification of quality records to be maintained by the supplier.
    • Consider for inclusion in the contract the delivery process and how it will be accomplished; if incremental development and delivery agreed upon, state how the validation process works, e.g., incremental validation, and whether it requires integration and test with software/hardware products developed by acquirer and/or other contractors or organizations (other institutes, universities, etc.).
    • Consider for inclusion in the contract a policy for maintaining the software after delivery: Who is responsible for maintenance of the software, tools, testbeds, and documentation updates.

4. Technical Monitoring and Quality Assurance

Once the provider has been chosen, the acquisition process moves into a technical monitoring role.  The following guidance should be included when establishing the process for provider monitoring and quality assurance:

  1. Provide technical requirements interpretation for contractor.
  2. Ensure contractor requirements documents meet original intent.
  3. Evaluate contractor progress with respect to cost.
  4. Periodically monitor contractor skill mix to ensure agreed-upon skills and experience levels are being provided.
  5. Oversee government-furnished equipment (GFE) to ensure equipment and information provided in timely manner.
  6. Periodically assess contractor processes to ensure conformance to process requirements stated in the contract.
  7. Review and assess adequacy of contractor-provided documentation and ensure contractor implementation of feedback, consider using Formal Inspections (SWE-087SWE-087 - Software Peer Reviews and Inspections for Requirements, Test Plans, Design, and Code) to accomplish this task.
  8. Track status considering the following example questions:
    • Is the contractor meeting their staffing plan?
    • Have the project and the contractor met the user’s needs?
    • Does the contractor have stable, educated staff?
    • Does the contractor’s project have adequate resources, e.g., adequate staffing and computer resources?
    • Is there realistic planning/budgeting in place?
    • Is the build plan being met?
    • Does the contractor have a good understanding of what is required?
    • Are the requirements stable?
    • Is the completion of designed functionality visible?
    • Is the evolving capability and performance of the contractor’s product likely to impact development on the acquirer side of the interface?
    • Are integration and testing proceeding as planned?
    • Is contractor cost/schedule performance on target?
    • Is contractor developing a quality product?

9. Provide regular status reviews to higher-level management on contractor progress.
10. Regularly assess status of identified risks and provide reports during management reviews. 
11. Software engineering should provide technical review to the level required to enhance the probability of mission success. (See the $paramlinktext of this topic for a list of areas to consider for software engineering technical review.)

5. Contract Administration

In addition to monitoring the selection provider’s progress and quality, contract administration activities are also carried out for the project.  The following guidance should be included when establishing the process for contract administration:

  1. Regularly assess contractor financial data and invoices against budget.
  2. Work with Contracting Officer to ensure timely resolution of any contract-related issues.
  3. Work with Contracting Officer to ensure timely address of needed modifications to contract terms and conditions, as needed.  These are primarily those affecting schedule, costs, services/products, resources (people, facilities), deliverables.
  4. Periodically evaluate contractor performance in manner consistent with contract and provide documented evaluation to Contracting Officer.

6. Product Acceptance and Control

Once the provider is ready to deliver the software product, the acquirer should have a process in place for review and acceptance of the product.  The following guidance should be included when establishing the process for product acceptance:

  1. Review deliverables based on agreed-upon acceptance criteria (or generally accepted standards, if specific criteria have not been established), document results, and work with contractor to resolve acceptance issues.
    • Typically, an acceptance test plan is created addressing the following:
      • Acquirer and contractor roles and responsibilities.
      • Defined test strategy.
      • Defined test objectives.
      • Defined acceptance criteria.
      • Developed test Scenarios.
      • Developed test scripts.
      • Developed test matrix.
      • Time and resources estimate.
      • Approval cycle.
      • Strategy for post-delivery problem resolutions.
    • Once approved, the test plan is executed and results are documented:
      • Select test tools.
      • Select and train team members.
      • Execute the test plan (manual and automated methods).
      • Track test progress.
      • Regression test.
      • Document test results.
      • Resolve problems.

2. Complete a Physical Configuration Audit (PCA) and a Functional Configuration Audit (FCA) to ensure that traceability is complete, that necessary waivers are in place, and that all required documentation has been developed.
3. Place formal deliverables under configuration control.
4. After acceptance of delivered products, support transition to an operational and/or maintenance environment.

7. Contract Closeout

The final acquisition step is to close out the contract. The following guidance should be included when establishing the process for contract close-out:

  1. Verify satisfaction of all contract terms and conditions, considering the following sample questions:
    • Has the contract period of performance expired (level of effort type contract)?
    • Have all deliverables been delivered (completion type contract)?
    • Have all Contract Data Requirements List (CDRL) items been delivered and accepted?
    • Was the contractor’s performance of the SOW acceptable?
    • If the contract involved patent rights, has the final patent report been filed?
    • Has the final invoice been received?

2. Verify return of all

<ac:macro ac:name="unmigrated-wiki-markup">



, as appropriate.
3. Complete final reports as requested by Contracting Officer.
4. Provide final contractor performance evaluation to Contracting Officer.
5. Capture Lessons Learned, if not captured earlier in the project life cycle.



9. Resources

SWEs and Topics related to this Handbook topic:


Cost Estimation


Software Life Cycle


Use of Commercial, Government, and Legacy Software


CMMI Levels for Class A, B, and C Software


Acquisition vs. Development Assessment


Acceptance Criteria


Software Milestones


Acquisition Planning


Access to Software Products


Open Source Software Notification


Source Code Electronic Access


Track Change Request


Project Participation in Audits


Supplier Software Schedule


Traceability Data


Software Peer Reviews and Inspections for Requirements, Test Plans, Design, and Code

Topic 7.4

Flowdown of NPR Requirements and Contracts

Topic 7.18Documentation Guidance

9.1 Tools

Tools to aid in compliance with this Topic, 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.

  • No labels