Materiel Solutions Analysis (MSA) Phase

Analyze Requirements

During the Materiel Solution Analysis (MSA) phase 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.

Identify a Product Owner

The product owner fulfills one of the most important roles in the Agile team. In general, the product owner/Product Owner’s responsibilities across the lifecycle include:

Establishes a clear vision for what the program is to accomplish
Conveys the concepts of operations to the Program Management Office (PMO) and development team
Manages the program and release backlogs to ensure the requirements/user stories are current, prioritized, technically feasible, and have a clear “definition of done” acceptance criteria
Works with the development team to convert requirements into user stories
Adds/deletes/refines user stories and acceptance criteria with inputs from multiple stakeholders
Coordinates with senior operational sponsors, expert stakeholders, and a broad pool of end users to capture their requirements, priorities, and feedback while sharing insights, and providing demos on the program’s progress
Answers questions from the development team on user stories, functionality, and user interface
Coordinate capability demonstrations with operational sponsors and end users after each sprint to provide feedback to the development team.
Provides reguarly feedback to development team on interim developments
Identifies active participant in release and sprint planning and retrospectives
Identifies active participant in modeling, mock-ups, and testing
Coordinates with other product owners of related programs the product will interface or integrate with
Coordinates deployment of releases.

The more closely the Product Owner can work with the development team and the PMO during development, the better the chances for success. If co-location with the development team or PMO is not achievable, there should be frequent synchronous collaboration sessions, such as face-to-face meetings, video/audio teleconferences, and online collaboration/demonstrations. A Product Owner should be available to provide timely information and decisions. Asynchronous collaboration involving tools such as JIRA can also enable the Product Owner to work closely with the development team.

The program must select someone who has the operational experience, communication skills, and vision necessary to shape the program. The program should designate and empower product owner(s) who can convey the program vision, serve as the voice of the customer, and manage the program backlog. This could be done by a single leader or a small team of leaders from the operational community who perform day-to-day requirements management.

Product Owner References:

Structure Requirements Documents

Approval of the Information System-Initial Capabilities Document (IS-ICD) at the MDD empowers the program to use the IT Box model of the JCIDS Manual, to tailor subsequent requirements documents per approval of their designated flag-level requirements oversight board. Programs may decompose requirements into Requirements Definition Packages (RDPs), Capability Drops (CDs), and/or alternative document structure. The figure below shows a potential document structure as outlined in the JCIDS Manual. In this example, RDPs and CDs are incrementally developed and approved over time. RDPs are the primary documents that capture a subset of the ICD requirements. CDs can either cover a small subset of an RDP or a standalone item such as a small application.
The IT Box model offers a significant flexibility advantage over the traditional JCIDS documents, but an Agile environment will need even more flexibility in order to dynamically manage requirements. Agile prioritizes working software over documentation; it is critical to not invest too much time and energy creating and approving lengthy requirements documents ahead of time. Agile relies on continual user engagement and requirements refinement throughout the program. The flag-level requirements oversight board identified in the IS-ICD and the Product Owner should share a clear understanding of expectations and authorities.

Establish Requirements Management Process

A clear, rigorous requirements management process is critical to align stakeholders toward common outcomes. One approach is to ask the requirements board to approve a succinct RDP as the initial set of high-level requirements, capabilities, and/or user stories for a release or set of releases to support planning. Managing requirements in a traditional acquisition program includes a requirements owner to develop a large requirements document and collaborate with the user community. In an Agile environment, a similar role helps to capture requirements (via backlogs) and collaborate with end users, but also join the program team as a permanent member to regularly iterate on the requirements. During the planning and execution of the release, the Product Owner should be entrusted to add, delete, change, and refine requirements or user stories per an established Agile requirements process. Because Agile releases and sprints are time boxed, the schedule is locked while the scope is flexible. Similarly, based on development, demonstrations, and feedback on early sprints, the requirements or user stories for the release will likely change. The Product Owner should keep the requirements board informed of major changes during a release for transparency and common expectations. The development team defines and agrees on the scope of each sprint and finalizes it via a sprint planning session that takes a day or less. Given the rapid timelines, it would be too cumbersome to coordinate approval of CDs as a subset of an RDP via a flag officer-level requirements board. The requirements board should empower the Product Owner should to approve the scope of each sprint and inform key stakeholders. This is best accomplished via a set of user stories and acceptance criteria, whether captured in a CD or ideally via collaborative Agile development tools. A small stand-alone capability independent of a release may be captured in a few user stories or CD and, depending on the requirements board’s expectations, approved by the board or the Product Owner.

Requirements Best Practices from Early Agile Adopters

Operational environments support small, frequent capability deliveries.
Requirements are clearly decomposed into small tasks.
End-users can engage throughout requirements and development to share CONOPS insights and provide immediate feedback from demonstrations.
Managed a program backlog via half page work packages with a rough government estimate, design context, and technical interfaces
Empowered Product Owners – Single/multiple based on user community’s size/diversity

The Mature Requirements page describes the next steps in the requirements process and supplies additional references.

Additional references:

IT Box
Eliciting, Collecting, and Developing Requirements, MITRE Systems Engineering Handbook
Analyzing and Defining Requirements, MITRE Systems Engineering Handbook
Agile Software Requirements, Dean Leffingwell
User Stories Applied: For Agile Software Development, Mike Cohn
Requirements Engineering in an Agile Software Development Environment, Alan Huckabee, Sep 2015
Agile Requirements Best Practices by Scott Ambler
Requirements by Collaboration by Ellen Gottesdiener (See also the book by same name)
Agile Requirements Modeling by Scott Ambler
Agile Software Requirements by Dean Leffingwell
Writing Effective Use Cases by Alistair Cockburn
To slice stories, first make sure they are too big, Gojko Adzic

0 Comments