Requirements Development

Developing Requirements for Agile

Key Question: FAR 15.203 requires agencies to identify requirements in their requests for proposals (RFPs). How does this requirement fit with Agile processes, which rely on refinement of system requirements based on testing and customer feedback after the contract is awarded?

Agile software development, as with any software development, requires thorough acquisition planning. Lack of proper acquisition planning and failure to follow FAR subpart 7.1 can be fatal to any procurement, but especially software development procurements. With Agile software development, requirements and priorities are captured in a high level Product Vision, which establishes a high level scope of the project, describes expected outcomes, and produces high level budgetary estimates. The government component of the agile team defines the core capabilities of the project which are required to meet the mission objective and provide business value.

Agile software development can satisfy core principles related to requirements development by writing a Product Vision and coupling it with an explanation of how the Agile process will be used to achieve the Product Vision. Rather than providing a set of “how to specifications” (or Requirements Traceability Matrix), the Product Vision focuses on desired outcomes, similar to performance-based contracting, which has been permitted by the FAR for many years.

Many agencies get caught up on requirements definition for agile development because what they traditionally think of as requirements are really system design specifications, like the blueprints of a house. In agile development, we think more about the end state of the house rather than the architectural diagrams. An agile requirements document would still comply with FAR provisions like FAR 15.203 without trapping the contractors into a waterfall methodology using a very familiar concept: performance-based contracting. For many years the FAR has provided for performance-based service contracts, where the Government issues a statement of objectives (SOO) defining its outcomes that allows for industry to provide innovative solutions that are measured under a quality assurance surveillance plan. This same approach is applied to contracts using an Agile software development methodology.

An agile requirements package that includes elements like a Product Vision, definition of done, and Product Roadmap would still comply with FAR provisions like 15.203(a)(1) without trapping the contractors into a waterfall methodology. Refer to this Sample Language for Government Contracts for Agile Software Development Services as a baseline for developing your requirements document.

Using the Product Vision to Develop Functional Contract Requirements

Key Question: How can a product vision be used to develop contract requirements?

In our Agile Overview, we discussed the difference between technical requirements and functional requirements, where technical requirements are developed during the period of performance to achieve the desired functional requirements. The example below demonstrates how a Product Vision can be broken down into functional requirements through the agile planning process. Once the functional requirements are defined, the agile team works to identify the necessary technical requirements during release and sprint planning.

Techniques for Developing a Product Vision

A good technique to help you get started on a Product Vision is to use the following structure:

• For (target customer)
• Who (statement of the need or opportunity)
• The (product name) is a (product category)
• That (key benefit, compelling reason to buy)
• Unlike (primary competitive alternative)
• Our product (statement of primary differentiation)

Here is how this structure looks when applied to two example requirements.

Sample Product Visions for Agile Development

Collaboration Platform — For stakeholders who need to maintain a centralized view of all customer interactions, the collaboration platform will track behaviors and facilitate outreach to citizens engaging with the Agency through all communication channels. Unlike the costly and outdated legacy systems, this new collaboration platform will replace all critical and major business processes with a user-friendly, responsive design at a reasonable cost.

Electronic Benefits System — For benefits recipients who need an easier way to apply for and check the status of their benefits, the electronic benefits system will allow customers to easily create and submit a new benefits application, get the status of a new application, and review the status of their benefits. Unlike the old paper-based system, the electronic benefits system will provide a faster processing time and will increase the transparency into the status of the benefits application, two key needs identified by user research. We expect the new system to also address several agency needs such as increasing the ability of the agency to identify fraudulent claims, and reducing the level of effort required for an agency claims specialist to process a benefits application.

Specifying Agile Needs in a Manner that Promotes Competition

Key Question: FAR 11.002 states that agencies should specify needs in a manner that promotes competition. Given that requirements may not be fully defined when the agency solicits offers and that not every offeror knows how to perform Agile software development, what is the best way to ensure effective use of competition?

While requirements for the end state of an agile contract are not always concretely defined at the time of solicitation, this does not preclude competition in contracting. In designing agile solicitations, the government achieves effective competition using outcomes-based objectives that link to the Product Vision (if the Government has already created one), rather than explicit tasks that may be required to deliver the outcomes.

Instead of attempting to see into the future and specifying exactly what the contractor should build 6, 12, 18 and 24 months down the line, the requirements document could simply outline the agile process within the context of the environment that the contractor will be working in, while stating high-level goals and pain points that would help focus the contractor’s initial efforts.

For example, instead of outlining explicit functionalities to be built, the Government could specify expectations for how the contractor will utilize human-centered design processes from the beginning, while utilizing key aspects of the agile process (i.e. utilizing HCD process to co-create a product backlog) to define outcomes.

Here is an example of how this language might look in a solicitation:

Discovery and Design

Working in conjunction with the federal Product Owner and the XYZ agency team, the contractor will utilize modern human-centered design (HCD) principles to conduct user research and discovery around the needs of ABC system users, stakeholders, and other relevant user groups to define how ABC system should meet existing XYZ use cases, as well as emerging user challenges. The contractor will utilize HCD techniques to design approaches to meeting these needs in the most impactful manner possible.

Tasks:

• Review any user research conducted prior to the beginning of this contract
• Conduct research into relevant organizations, processes, systems and policies to understand their needs and goals
• Work hand-in-hand with the federal Product Owner to iteratively develop and update (as relevant) the product vision, product roadmap(s), and product backlog(s) with associated user stories based on what is learned through user research and discovery
• Iteratively design solutions toward the end user experience so that products meet end user needs and goals
• When relevant, analyze opportunities for users to better leverage existing systems
• Analyze opportunities for leveraging open-source tools as part of the technology stack of the overall modernization effort
• Initiate measurable feedback loops and establish metrics to measure effectiveness of products delivered
• Ensure new features are expandable and extensible to meet the ongoing needs of the relevant user groups and stakeholders
• Utilize modern methodologies when doing discovery/user research, including stakeholder interviews and usability tests
• Prototype and test design concepts with end users
• Incorporate UI/UX principles throughout the development process
• Create and track metrics to determine whether delivered solutions meets end user needs
• Formulate testable product hypotheses, measure outcomes, and share learnings
• Account for accessibility considerations and ensure that Section 508 requirements are considered, designed for, and met
• Work with the Product Owner in a continuous, iterative fashion throughout the development process to establish and prioritize features based on discovery/user research findings

Language like this communicates to contractors the expectation that agile processes will be utilized throughout the project, while defining concrete outcomes such as co-creating a product vision, roadmap, backlog, etc. based on those processes. It also retains flexibility by leaning on the agile process to define outcomes without locking the Government in to the contractor building specific functionalities because they’re explicitly defined in the requirements document.

Promoting Competition in Agile Contracts

Key Question: How can acquisition professionals structure agile solicitations to ensure adequate competition?

To promote competition, the Government needs to be able to adequately describe the scope of the project and the expectation that agile development techniques will be used to deliver it. This could include explaining the background and current state of the project, describing the major pain points currently experienced by relevant users and stakeholders, and outlining high-level goals (paired with quantitative metrics where relevant) of the project that the Government expects the contractor to work towards.

This allows offerors to make a reasoned business judgment whether they want to compete, considering their own agile maturity, and is similar to the process used for performance-based contracting. In performance-based contracting, the government can use a high-level Statement of Objectives (SOO) that describes desired outcomes for the effort, rather than instructions on what exactly to build.

To further promote competition in contracts for agile development, the process of requirements development should be coupled with appropriate market research and early vendor engagement to help industry partners understand the project background, pain points, and desired end state. There are many ways to conduct this market research, from the standard issuance of Requests for Information (RFI) or draft solicitations, to more innovative methods like reverse industry days, roundtables, and other mechanisms that allow prospective offerors to ask questions. The Periodic Table of Acquisition Innovation is a good resource for learning how to engage vendors during market research when agile development techniques are expected during contract performance.

Simply because every vendor may not perform Agile software development does not mean that the process should be viewed as unduly restrictive of competition. As explained throughout this document, there are many reasons why Agile software development is beneficial in helping to manage risk and drive results. In addition, the number of contractors that are skilled in this methodology is likely to increase as agencies become more familiar with Agile software development processes and gain experience.

Additional resources

• Customer Experience

  Make your digital tools useful for people with this Customer Experience Toolkit

• Web Design Standards

  Learn how to design compliant, accessible websites with the US Web Design Standards