Template Instructions

This template is for programs using the Software Acquisition Pathway, which is designed to be flexible and can be tailored to specific needs and requirements of different services and agencies. This document will be reviewed annually and updated as needed to reflect the current practices and responsibilities of those involved. Review the Purpose of this Document section below to understand the goals of producing this document. Review the purpose of this document, complete the remaining sections to provide a complete and representative view of impacted stakeholders, their roles and responsibilities specific to the project/program, and the approach to ensure engagement. The Template Instructions can be deleted once this document is complete.

Purpose of this User Agreement

Agile software methodologies require users to make a greater commitment to software programs than to traditional programs, including more frequent engagement that occurs in ways that differ from traditional programs. Effective software acquisition requires engagement with users to understand their concepts of operations, environment, existing capabilities, external systems with which the required capability must interface, interoperability requirements, threats, and other specific needs.

Level of engagement may require additional and/or separate funding resources to secure the necessary user commitment. Agile software acquisition and development requires consistent, continuous, and active user engagement, as well as decentralized decision-making authority to improve software development and delivery activities. This requires alignment of roles and responsibilities by the sponsor, project/product team, and user communities. The specifics of these commitments are captured in a User Agreement (UA).

To facilitate the above, a written UA must be signed by all relevant stakeholders before a software program enters the execution phase. The UA is a signed agreement developed by the Operational Sponsor and the program manager with input from other key stakeholders. In general, the UA provides program ways of working that:

- Ensure developments address user priority needs

- Supports active collaboration between the operational users, acquisition community and software development teams.

- Supports the role of an empowered Product Owner to shape and prioritize requirements.

- Establishes roles and responsibilities for all stakeholders (including the program office and user communities).

More specifically, the UA ensures each user community is properly represented and engaged throughout software development and delivery. It defines responsibilities and expectations for:

- Anticipated developer and user ceremonies, events, and interactions.

- Prioritizing feature set against the overarching CNS.

- Determining Minimum Viable Product (MVP), Minimum Viable Capability Release (MVCR), and other releases.

- Developing and participating in user training and knowledge sharing.

- Performing user testing and software demonstrations.

- Decision-making regarding software release and deployment.

Finally, the UA includes specific user engagement events and activities to ensure:

- All user communities are identified, represented, and engaged.

- Users have a shared understanding of the product, service, or problem.

- Approaches to engaging each user community are clearly elaborated.

- Users have clear expectations about when and how to engage with the program.

- Users make clear commitments when working with the program.

- Users understand what is expected of them over the life of the program.

General guidance on using the RDW includes:

• The sections and sub-sections in the RDW are laid out sequentially according to the elements that the governing manual or instruction requires within your document.

• Most are MANDATORY and will show an error in RED FONT if you do not address them.

• If you don’t believe a mandatory element is applicable to your document, simply enter, “XXX is not applicable because….,” or similar verbiage.

• If you choose to address a mandatory required element within another sub-section (perhaps in conjunction with another element), you may skip over (leave blank) these mandatory sections, just bypass the error messaging. Just make sure you address each requirement somewhere in the relevant section.

• Some sub-sections are marked “Optional.” These can be skipped (left blank) without showing an error. HOWEVER, if the element is applicable to your document, ensure to address it SOMEWHERE in your document.

• You are able to use rich text (e.g. bold, italicize, underline, red or black font, etc.) within many of the writing sections (not all). Some simple entries are constrained to plain text. If you want to use bold, underline, etc., you can make the changes once you pass the template contents to MS Word.

• If you choose to cut and paste text from another source, make sure you convert it to the font you are using throughout the document. The RDW defaults to the fonts of:

1. Times New Roman, Regular, and size 12 for most text and text boxes; and,

2. Arial, Regular, and size 10, for all tables.

• Please refer to the "RDW post-export to MS Word Actions" section of the Desk Reference, available through the website (https://content1.dau.edu/rdw) for additional formatting required to be performed once you've exported your RDW Document to MS Word