1. Requirement

2.6.2.6 The project shall document in the solicitation the software processes, activities, and tasks to be performed by the supplier.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

Class D and not Safety Critical and Class G are 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.

2. Rationale

Suppliers (or providers) are accountable for what is stated in their contract and may perform only those tasks stated in that document. The precursor to the contract is the solicitation or request for proposals (RFP) which contains a Statement of Work (SOW). The SOW in the solicitation is the first description of the work for potential providers and needs to contain as much information as possible to ensure potential providers are prepared to perform and deliver what is required for a project.

Acquirers may better assess the capabilities of potential providers by including standards, tasks, activities, processes, requirements, etc. in the solicitation.  This will offer potential providers the opportunity to address these items in their responses.

Including information, such as standards, tasks, activities, processes, requirements, etc., in the solicitation is also useful to the provider community because it allows providers to gauge how well their existing or obtainable skills, resources, and capabilities match up to the required work.

3. Guidance

Typically, solicitations are prepared by the procurement or contracts department with input from project management and engineering.  When determining processes, activities, and tasks to include in the solicitation as items to be performed by the supplier (or provider), include the requirements from NPR 7150.2, but tailored for the project and to exclude Center and NASA Headquarters requirements (see Topic 7.04 - Flowdown of NPR Requirements on Contracts and to Other Centers in Multi-Center Projects). Consider the following, non-exhaustive list of key concepts for the solicitation:

• Development standards to be followed by the provider.
• Adherence to requirements for safety-critical software (see SWE-134, SWE-023, and NPR 7150.2, Appendix D).
• Development life cycle to be followed by the provider, or indication that provider can choose life cycle.
• Surveillance activities (and acquirer involvement) including monitoring activities, reviews, audits, decision points, meetings, etc. (see SWE-039).
• Management and support activities (project management; schedule and schedule updates; configuration management of software products, documentation, and software development environment (hardware and software); non-conformance and change tracking; risk management; metrics collection; Independent Verification and Validation (IV&V) support and access; required records; traceability records; electronic records and code access; Verification and Validation (V&V), etc.).
• Maintenance and support tasks, including updates, new versions, training to be included in life cycle and cost estimates.
• Deliverables with delivery dates, review periods, and acceptance procedures for each.
• Activities and responsibilities related to government and contractor proprietary, usage, ownership, warranty, data, and licensing rights, including transfer.
• Tasks related to OTS (Off the Shelf) software requirements (identify which requirements are met by OTS software, provide OTS software documentation such as usage instructions, etc.) (see SWE-027)
• Use of Open Source (see SWE-041)
• Capability Maturity Model Integration (CMMI) ratings (see SWE-032) and associated rated process areas to be performed on the project for software Classes A, B, and C.

Be as complete as possible to ensure potential providers are aware of all tasks and activities for which they will be held responsible. 

Use checklists (e.g., the NASA PAL contains checklists for NPR 7150.2 requirements by class and safety criticality) and solicitations for similar projects to ensure that all required activities are included in the solicitation. Be sure to use example solicitations, SOWs (Statement of Work), and WBS (Work Breakdown Structure)s considered "best practices"; 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).
• Include a complete set of deliverables with descriptions and delivery format.
• Include templates or Data Item Descriptions (DID) for documentation deliverables (see Book B guidance in this Handbook for NPR 7150.2, Chapter 5, Software Documentation Requirements, as applicable by software class).
• Include time period for responses to review findings, including making changes.
• Include Data Requirements Documents for deliverables, if appropriate.
• Include a list of all mandatory NASA software development standards, documentation, and DIDs, as applicable
• Clearly mark mandatory versus optional/recommended tasks, activities, standards, etc.

For additional considerations for a solicitation to acquire software, see Topic 7.03 - Acquisition Guidance in this Handbook. The SOW checklist and references in this topic may also provide additional guidance on project tasks to consider assigning to providers and including in the solicitation.

Additional guidance related to provider activities may be found in the following related requirements in this handbook:

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.

5. Resources

6. Lessons Learned

A 2001 Software Engineering Institute (SEI) report entitled Real-Time Systems: Engineering Lessons Learned includes the following lesson for SOWs, "Ensure that all critical functional and interoperability requirements are well specified in the contract (statement of work, Statement of Objectives)." The document includes some background and reason for this lesson.