During the early stages, the program works with its operational sponsors to refine and structure the program’s requirements. To set the stage, the team should have a clear understanding of the users’ Concept of Operations (CONOPS), performance objectives, and operational environment. The requirements are prioritized to support an Analysis of Alternatives (AoA), tradeoffs, and the advantages and disadvantages of structuring development via releases. As requirements mature, frequent collaboration with end users is critical to ensure the requirements capture users’ priority needs and that all stakeholders have a common understanding of current and future CONOPS. Collaboration with other stakeholders (e.g., engineers, testers, and enterprise architects) is also critical during the shaping of the requirements. The program identifies a Product Owner, structures the requirements documents, and establishes the requirements management processes. Once a contractor is selected, the development team refines the program and release backlogs with the Product Owner and PMO.

Requirements in an Agile environment are usually managed via program, release, and sprint backlogs rather than through formal requirements documents. Backlogs could take the form of databases, Excel spreadsheets, or Agile-based software tools. The Product Owner actively manages (grooms) program and release backlogs, working with the user community and other stakeholders to identify the greatest level of detail needed for the highest priority requirements.

The figure below shows the relationships among the program, release, and sprint backlogs. The program backlog contains all desired functionality and requirements. A release backlog typically comprises the highest priority requirements from a program backlog that a team can complete within the established timeframe. Each sprint consists of the highest priority requirements from the release backlog. Once the development team commits to the scope of work for a sprint, that scope is locked. Sprint demonstrations conducted by the contractor at the end of a sprint may identify new features or defects that the team would add to the release or program backlogs.

The Product Owner, in collaboration with operational sponsors, requirements organizations, legacy system operators, a broad user base, architects, systems engineers, enterprise architects, and other stakeholders captures, integrates, refines, and prioritizes items on a program backlog. Items can include:

• Epics or themes of major requirements elements that span multiple releases
• Interfaces with other systems
• Infrastructure requirements/interfaces

For additional information visit Agile Requirements page.

The Section 809 Panel recommended DoD to adopt a dynamic portfolio approach to requirements in their Volume III report.

Leading commercial corporations and start-ups apply Agile practices to manage software requirements via dynamic, prioritized backlogs of user stories. User stories capture the functionality the end users expect the software to deliver, often with a clear definition of done that serves as the acceptance criterion. A product owner collaborates with the stakeholders to prioritize the user stories on the product backlogs—the set of features for which software must be developed. The highest priority features determine the scope of the next time-boxed release backlog. The development team commits to design, develop, integrate, test, and demonstrate working software for each sprint backlog to users and testers. Based on software performance and user feedback, product owners may make changes to the release and program backlogs to shape user stories and priorities.

 

Manage IT Requirements Using Dynamic Portfolio Backlogs
A software requirements model should be timely, iterative, dynamic, and user-centric. Execution portfolios should manage their capability requirements via a series of dynamic backlogs rather than large static documents. As mentioned earlier, a dynamic backlog is a prioritized list of required functions written from an operational user’s perspective but can also include technical requirements such as cybersecurity. The highest priority items on the backlog drive the next capability development or research (if greater technology maturity is needed). The requirements to shape a new capability development could be iteratively captured and approved via a tailored document, depending on the size, scope, cost, and risk. Managing requirements via backlogs is easier for software and IT given their dynamic and severable traits, but portfolios could also employ this approach beyond IT programs with smaller, iterative developments.

 

The portfolio’s operational representative should be empowered to dynamically reprioritize, add or delete, and shape capability requirements based on operational needs, threats, technical performance, systems engineering, security, feedback from earlier releases, and other factors. These representatives would actively collaborate with operational commanders, end users, organizations providing threat assessments, and enterprise architects to curate the portfolio backlog. During portfolio reviews with Military Service leadership and operational commands, PAEs and their operational representatives could present the requirements backlog to ensure alignment with Military Service and CCMD operational priorities and outcomes.

 

Each program or increment could also manage its requirements via dynamic backlogs. As interim developments are demonstrated or fielded, user feedback and system performance might generate new capability requirements or shift priorities for the backlog. The goal should be to ensure that each successive iteration addresses the users’ highest priority needs and strengthens force effectiveness.

Actions You Can Take

• Setup a series of discussions with stakeholders from the operational/requirements organizations on managing requirements with greater agility.
• Programs can assess if they are in an environment suitable for Agile. 
• New programs without an approved requirements document are ideal to effectively shape an Agile requirements management structure. 
• Programs with an existing requirements document, could explore tailoring the implementation details or restructuring of the document. 
• Work with an Agile coach to effectively scoping out high level requirements and managing requirements details via backlogs of user stories.
• Socialize and iterate on the planned requirements management approach with key stakeholder and oversight organizations. 
• Outline key roles and responsibilities and identify the right individual(s) to serve as Product Owner and related roles.