General guidance for Final Recommendations includes:

• This section is characterized by two general themes:

1. Discussing how you intend to organize for the construction of your software

2. Addressing ‘traditional requirements’ from a base ICD

• Up front in this section, you should address:

1. High-level strategy: Discuss how you will identify, catalog, prioritize and refine sponsor, command, and user requirements from across your organization. (Who will you talk with or Survey? When? Where/how will you organize the feedback you receive?) You may be able to lay out an initial Product Roadmap—starting with the ‘vision’ of the software and projecting what features and functionality would be essential to demonstrate in an initial capability.

2. Relationship to Legacy Systems: Discuss how you intend to integrate with any relevant legacy systems, including how, over time, you may displace (retire) some of these systems. Attempt to explain what the Minimum Viable Product (an early version of software with basic capabilities) might look like in order to demonstrate the value and future potential of your software to all stakeholders.

3. Codifying User Commitment: Modern software development relies heavily on the consistent interaction between functional experts and the technical parties writing the code. Whether taking a DevSecOps or an Agile approach, prioritizing work, iterating, testing, providing feedback, and managing backlog requires a significant commitment on both parties. In this section, you should identify what mechanisms you will use to gain—and keep—the commitment of all parties to the task. This mechanism may be a User Agreement, which is separate from this SW-ICD, and is in fact defined in Acquisition Policy (DoDI 5000.87).

*Note: True functional experts—particularly those that are somewhat data or software savvy—are sometimes few in number and will always have commitments well beyond the development of your software. Obtaining the regular commitment of these individuals is CRITICAL to your success. You will need to have a solid agreement in place and means to enforce it when attention wanders.

• To complete this section, you should address:

1. DOTmLPF-P Recommendations: The ‘m’ in this acronym is the software itself. Discuss the other aspects of this framework from two perspectives:

a. Enhancements: What DOTmLPF-P changes do you recommend that would enhance the capabilities of the proposed software? These recommendations might even be independent of the software capability—something that you might recommend even if you weren’t going to also develop the software.

b. I ntegration: What DOTmLPF-P changes do you think you need to make because you intend to introduce a new software capability? These changes are, in effect, precipitated by the addition of the software.

2. Acceptance of Operational Risk: Point out where this SW-ICD may have identified a “relatively low priority capability [gap] to the overall Joint Force.” Acknowledge where you believe risk can be taken, given cost and schedule considerations.

3. Affordability: Describe your organization’s willingness to provide the necessary resources commensurate with the ‘anticipated’ (but not yet known) lifecycle cost of the software. Acknowledging that is it somewhat premature to posit a reliable lifecycle cost at this point, the intent here is to capture the sentiment from the Sponsor that this is an important capability and that they intend to prioritize its development through time.