DSDM

CONSORTiUM

DSDM

CONSORTiUM

AgileBA

The Handbook

for Business Analysts

Extract
The Requirements Lifecycle
In An Agile Project

www.dsdm.org

This Extract from AgileBA, The Requirements Lifecycle in an Agile Project, is based on a subset of Agile Business Analysis
Handbook is intended for promotional use only and not to be taken out of context. Readers wishing to know more about or
use the AgileBA Handbook are invited to visit the website at www.dsdm.org where the full version of the Handbook will be
published in 2014.
Copyright 2013 Dynamic Systems Development Method Limited
D

DSDM, DS M Atern and AgilePM are registered trade marks of Dynamic Systems Development Method Limited in the United
Kingdom and other countries. AgileBA is a trade mark of Dynamic Systems Development Method Limited in the United
Kingdom and other countries.
All rights reserved. Applications to reuse, reproduce or republish material in this publication should be sent to the address
below or by email to info@dsdm.org
Published by the DSDM Consortium
This Extract first printed September 2013
For further information regarding this and other DSDM products please contact:
DSDM Consortium
Henwood House
Henwood
Ashford, Kent
TN24 8DH, United Kingdom
Website: www.dsdm.org

THE REQUIREMENTS LIFECYCLE IN AN AGILE PROJECT

1. Introduction
The Agile (DSDM) approach to requirements is to clarify the project objective and Business Case and then to define
requirements, at a high level only, early in the project. The definition of detailed requirements is deliberately left until just before
it is needed: just before that particular aspect of the solution is developed and built. This avoids waste and rework. It also
ensures that the product can evolve to reflect the needs of the business at the time of solution-building. It allows for learning
during the project and for change to be embraced, rather than being treated as a problem.
However, the risk inherent in this incremental approach to defining requirements is that an inconsistent or internally-conflicting
set of requirements could evolve. This is where the skills of the Agile BA are essential. The Agile BA must facilitate the evolution
of requirements from high level objectives down to low-level detail at the appropriate time, whilst keeping the consistency and
focus, completeness and prioritisation of the requirements set as a whole.
The traditional Business Analysis discipline of Requirements Engineering is still appropriate and can be applied in an Agile way.
Requirements Engineering acknowledges that each requirement has a lifecycle of its own, from its initial elicitation, through its
analysis and validation to its eventual incorporation into the solution, or its rejection or de-scoping.
In this chapter we look, from an Agile perspective, at the Requirement Engineering lifecycle of:
Elicitation
Analysis
Validation
Management and documentation

Production: Emily Ruffle

Artwork by Debbie Cole
Printed in the United Kingdom by
Buckland Media Group Limited, www.buckland.co.uk

Elicitation

Validation

Management and documentation of requirements

Analysis

Figure 11.1

We see the approach the Agile BA takes, both pre-project and throughout the DSDM lifecycle, including post-project benefits
assessment. We explore how the Agile BA will ensure that the requirements form a consistent and coherent whole. We see
how Agile requirements are captured and recorded appropriately, as they evolve and expand in detail. We also consider the use
of key Agile practices in this process.

2. The role of the Agile BA in handling requirements

The responsibilities of the Agile BA within a DSDM project are to ensure that the business needs are properly analysed and
are correctly reflected in the Evolving Solution. On a day-to-day basis, the Agile BA manages the documentation and products
related to business requirements. They ensure that business implications of day-to-day decisions made by the Project-Level
and Solution Development Team (SDT) roles are thought through. They keep requirements aligned to the purpose and
objectives of the project, as well as the needs of the end-users and customers of the product. They are the facilitator, negotiator
and mediator in conversations between business and technical roles. They have the skills to make visible the implications of
prioritisation and the decisions to include or de-scope requirements. They become the central point of communication about
what is required, and why, for both the Project level and SDT roles.
The role of the Agile BA is to be the guardian and champion of the requirements. They do not own the requirements (it
is important that ownership is accepted by the business representatives). However, the management of a clear, useful and
incrementally-evolving requirements set is the responsibility of the Agile BA.
As we saw in Chapter 1, the role of the Agile BA may be wider than the Agile project; they may also work in a corporate
planning framework or a strategic programme. Requirements Engineering activities are valid for requirements work at any level.

3. The Lifecycle of a Requirement

A requirement may begin life as an idea, a need, or a statement of a problem to be addressed. The first requirement of the
project is its objective, expressed in outline in the Terms of Reference (TOR) and clarified during Feasibility. From this point, a
hierarchy of requirements begins to emerge, expanding from the project objective to Major Themes, to Epic Stories (High-level
Requirements) of the Prioritised Requirements List (PRL) and down to the detailed User Stories elaborated during Exploration
and Engineering.

Business Strategy / Need

3.1 Elicitation
Elicitation is the identification, extraction and capture of the requirement. In an Agile project this is typically achieved by:
face-to-face conversations;
observation;
Facilitated Workshops;
demonstrations of working elements of the solution;
scenarios
Modelling and Prototyping.
These approaches can work together. For example, scenarios can bring to life business situations and can provide the basis for
prototyping and testing.
Storyboarding scenarios can be seen as a form of low fidelity prototype.
Elicitation is not a trivial task; many users do not know clearly what they do want from the solution, until they see something.
Also, knowledge that the users have may be:
Explicit: easy to explain and capture;
Tacit: hard to capture because people do not even know that they are holding it
 Semi-Tacit: where things are taken for granted, or only held in short term memory and therefore not really remembered or
known.
Many requirements are omitted because they are taken-for-granted or merely forgotten. The Business Analyst is a detective,
uncovering the true requirements as the project progresses and using Agile practices and business analysis skills to identify gaps
and disconnects.

3.2 Analysis
Each requirement needs to be analysed to clarify its meaning and to determine whether it is:

Business Objectives /
Goals

P
R
O
J
E
C
T

Strategic Business Case

Project Business Case

Objectives and Themes

Project Objectives /
Goals
Project Business
Requirements

Epic Stories
High Level User Stories

Project User
Requirements
Project Solution
Requirements

User Stories

Detailed
User Stories

Solution
Figure 11.2

Every requirement passes through the following stages:

- Elicitation
- Analysis
- Validation
- Management and Documentation
These requirements lifecycle stages are not serial, with Management and Documentation happening
throughout. Elicitation and Analysis run together iteratively, overlapping with Validation as the
requirements become more mature.

realistic;
unambiguous - clear enough to be understood by different stakeholders;
feasible technically, financially, socially;
congruent with the business goals;
relevant to the objectives of this project.
Its dependence on other requirements must be analysed and made visible and any potential conflicts and duplication with other
requirements must be resolved.
The Agile BA will analyse each requirement and also facilitate the prioritisation of each requirement by the business. The Agile
BA must be a negotiator, as there is a good chance that some requirements will be in conflict with each other, which may result
in conflict between the stakeholders who own them. The Agile BA will mediate to reconcile these conflicts and differences,
often by using facilitation skills in a Facilitated Workshop to bring together the parties in conflict.
Agile techniques such as hands-on prototyping, role-plays, demonstrations and modelling can be helpful in uncovering tacit and
semi-tacit information.
Requirements can emerge as business requirements, technical constraints, technical opportunities, business rules. The Agile
BA may also find that they are stated as solutions in the first instance. These need further analysis to discover what benefit they
must give. If requirements are too solution-oriented, they may place unnecessary constraints on the Evolving Solution, removing
some of the flexibility needed by the SDT when they come to evolve that piece of the solution.
Requirements can be functional, describing the features needed or what the solution must achieve. Others can be nonfunctional and address the end-products required behaviours such as performance, usability, access security, archiving, backup,
security, availability, maintainability, robustness. The completeness of the requirements from a functional and non-functional
perspective, and the evolution from business requirement to technical implementations of those requirements is part of the
analysis the Agile BA must perform.

3.3 Validation

3.4.2 Requirements Management

Validation applies to both the individual requirement and to the whole set of requirements for the increment and for the
project. Since requirements do not emerge in detail until just before they are built, a high-level view of the requirements and
their dependencies needs to be expressed and communicated. Modelling can assist the process of defining the increments into
which the project is divided, and can show dependencies, in order to minimise unexpected overlaps and reduce risk.
Requirements must also be testable. Even at the very early stage of identifying requirements, the Agile BA will ensure
measurable acceptance criteria for each requirement are agreed with stakeholders. This way, they will confirm what is needed
for the requirement to be successfully implemented.

Once a requirement has been identified, its inclusion within the final product or its de-scoping should be traceable, along with
the rationale for this, both horizontally (from beginning to end of the project); and vertically (from the overall business goal it
is addressing to the realisation of this). This enables the stakeholders of the project to understand what is, and is not, contained
within the final solution. It helps to prevent requirements being missed by accident or new requirements being brought into the
project without consideration of their impact on others or on Timebox and project timescales. This is not to prevent change
Agile projects embrace change, even late in the process. However this change needs to be introduced in a considered way, with
an appropriate level of change control not too heavy, but not non-existent. The Agile BA will be the guardian of the project
requirements and the related PRL from this perspective, although decisions on whether or not to accept change will ultimately
lie with the Business Visionary.

3.4 Management and documentation

3.4.1 Requirements Documentation
Agile has a reputation for being light on documentation, but why do requirements need to be documented? Documentation is
typically for at least one of four purposes:
- To pass a message from one person / set of people to another;
- To record information now, whilst we know it, for later when we may have forgotten it;
- To help us to manage complexity;
- To prove we have done something.
In an Agile situation, the first three are still valuable. The fourth should not be quite as necessary in an Agile culture of trust, as
it would be in a culture where the fear of failure predominates. However, this may still have relevance for audit and compliance
purposes, in highly-regulated industries, for example. The actual needs of such an audit purpose should be investigated as many
situations do not need the volume of documentation which was customarily provided in traditional waterfall projects.

IT tools to support the management of requirements, from first capture through to integration and delivery of the evolving
solution, may be necessary and useful. However, tools alone are hardly ever the solution to requirements problems or
poor requirements engineering. Visibility of the requirements as they progress through the lifecycle is the Agile approach to
communication and dissemination of information, through Information Radiators such as wallboards and permanently-visible
large screens, and through collaborative practices such as daily stand-up meetings and Facilitated Workshops.

4. Requirements within the Agile (DSDM) project Lifecycle

The pattern of eliciting, analysing, validating and managing/documenting requirements is embedded at every phase of the DSDM
lifecycle. However, the level of detail is different, progressing from the project objective and the very high level requirements
defined at Feasibility, through to the most detailed level, which emerges timebox by timebox during Exploration and Engineering.

For the first point above, the documentation needed will be reduced if the team (including business roles) can be co-located.
For the second point, documentation is reduced in an Agile situation as the detail is only elaborated just before it is needed, so
the timeframe to remember detail is short. For the third point, complexity is reduced by the incremental approach to solution
evolution and the feature-focused timeboxes. These aim to deliver a complete, cohesive, small and potentially-implementable
segment of the solution in a short timeframe.

Pre-Project

Feasibility

Thus documentation in an Agile project should be sufficient for purpose, and only that. The two golden rules of Agile
documentation are:
- Do not document unless it is useful to someone specific (a 50 page document that no-one actually reads is not proving useful
to anyone);
- document in a way that is useful to the recipient (ask how this will be used, and by whom).

Foundations

The level of documentation required depends on the ease of communication of team members. Co-located Agile teams need
less detail when writing down User Stories than distributed teams, for example. However, the documentation of requirements
may also be needed to act as a basis for support documentation, for the end-users of the product and also for those supporting
the end-users (a Service Desk, for example) and where there are regulatory/compliance/audit obligations to meet. In this case,
the documentation needs to be sufficient to satisfy that need.

Exploration

Post-Project

The documentation of requirements in an Agile project is an incremental, evolving activity.

A unique Requirement / Story Identifier;

a short recognisable name;
Description;
Acceptance criteria;
Source; Owner; Author;
Priority;
Rationale/Benefits; Business Value;
Related or dependent requirements/ User Stories;
Version control/status.
This information helps to classify, identify and manage the requirement and its emerging detail. It also supports configuration
management and change control.

High Level Prioritised

Requirements
(Epics and User Stories)

Deployment

The documentation related to requirements is used by both users and technical team members. The language, therefore, must
be clear, with agreed terminology and accessible to all disciplines involved.

The information needed about a Requirement / User Story at any point is typically:

Very High Level

Requirements
(Objectives and Themes)

Detailed Requirements
(Detailed User Stories)

Figure 11.3

Engineering

Below, the involvement of the requirements lifecycle within each project lifecycle phase is considered, together with the use of
DSDM practices.

4.2.3 Validation

Pre-project activity supplies the Terms of Reference (TOR) for the project. The TOR will identify the problem to be solved or
opportunity to be addressed. This is effectively the first, very high level requirement.

The project team during Feasibility is: the Business Sponsor, Business Visionary, Technical Co-ordinator; Project Manager and
Business Analyst. Validation and acceptance of the very high level Themes and Features may also need approval of a wider set of
stakeholders. These may be a steering committee, or an investment appraisal body within the organisation, for example. Whilst
negotiation and agreement of the major Themes and their prioritises may happen during a Facilitated Workshop, a more formal
Quality Review meeting (described later) may be chosen, to baseline and effectively sign off the Feasibility Assessment.

4.1.1 Elicitation

4.2.4 Management and Documentation

A strategic Business Analyst (a different person from the allocated project BA) may have been involved in the production of this,
and the projects Agile BA will need to understand its context.

The Themes / Features should be recorded appropriately and visibly for all stakeholders. This is the embryonic Prioritised
Requirements List (also often called a Product Backlog in other Agile approaches). During Feasibility, it needs to be at a level
which is just sufficient for purpose. It will form the top level of the hierarchy of requirements which will emerge later. Modelling
and diagramming will aid the visibility and clarity of this hierarchy and set out the context and scope.

4.1 Pre-project

4.1.2 Analysis
The pre-project analysis, or results of a programme of which the project is a part, may produce a high-level scoping diagram to
set the objective in context

4.1.3 Validation
The Business Sponsor, Business Visionary and Business Analyst, and later the Project Manager, need the TOR to be a clear-enough
justification for the project to be considered during Feasibility.

4.3 Foundations
The team during Foundations includes Solution Development Team roles, which are needed to estimate work required and
produce the Delivery Plan. During Foundations, it is important that the whole team is aware that there is more work needed
on requirements than one pass of requirements capture in a Facilitated Workshop! The themes from Feasibility each need be
expanded to a further level of detail, to form high-level requirements (Epic stories).

4.1.4 Management and Documentation

During Foundations, business analysis work will be needed, to provide a clear structure (firm foundation) on which to work
during Exploration and Engineering, when Epics are split into lower level User Stories. Foundations also provides the testing
strategy (as a part of the Solution Foundations documentation) against which validation will be performed.

The TOR should be documented (one or two pages at a maximum) with high level objective, benefits, costs, risks and any initial
assumptions. DSDM has a product definition for the TOR, along with other documents mentioned later.

4.3.1 Elicitation

4.2 Feasibility

The Agile BA will organise Facilitated Workshops to expand the Themes and Features into high-level requirements. These
workshops are often supported by modelling and prototyping, which the Agile BA will do. The participants will be selected
as appropriate for each workshop, but will draw from the Business Sponsor, Business Visionary, Technical Co-ordinator, Project
Manager, the Solution Development Team, Business Advisors and a wider group of stakeholders.

The purpose of Feasibility is to provide a high-level overview of the project, enough to assess whether the project is worth
doing, from both technical and business points of view. During Feasibility, a very high level set of requirements will be elicited
(probably no more than ten or so of these - too many would indicate too low a level of detail for the purpose of Feasibility).
These requirements are at the level of major Themes or very high-level features. They need to be just enough to:
Act as the headline guidance for the project scope. Each theme or feature will typically expand during Foundations into lowerlevel detail;
Give enough detail for a broad estimate of project size, with the acknowledgement that the accuracy of any estimate is within
a broad range.
Allow a first consideration of priorities, although at this level they may all appear to be Must Haves.

4.2.1 Elicitation
At Feasibility, the Agile BA is trying to establish a shared vision for the project with the Business Visionary and Business Sponsor
and between other stakeholders. Themes and features are typically elicited by face-to-face conversations and Facilitated
Workshops. A Feasibility Prototype may be used to clarify what is envisioned.
The formulation of a simple, one sentence project objective, which sits above the themes and features will form a useful focus
for the whole project.

4.2.2 Analysis
Themes and high-level features are analysed to establish dependencies and conflicts. The Agile BA would use Modelling
to make the structure of the functions visible. Facilitated workshops would be used to enable negotiation of the high level
features and their priorities (MoSCoW prioritisation). Acceptance criteria (very high level, but measurable) would be
established for each Theme or Feature. The Feasibility Assessment will contain these Themes / Features as the embryonic
Prioritised Requirements List.

4.3.2 Analysis
After eliciting requirements, the Agile BA will work face-to-face with appropriate stakeholders to define each requirement
further and analyse whether it is realistic, feasible, ambiguous or conflicting with, or duplicating other requirements. They
would also gather more information about the business goal served and the value of the requirement. The roles of Business
Ambassador(s) and Business Visionary have the empowerment to speak on behalf of the different business areas. During
Foundations, Epic user stories are established. Facilitated Workshops can be used to clarify and share requirements information
and to resolve conflicts and overlaps. Acceptance criteria will be established at a high level against each requirement.
Prioritisation is also done at this point, using Facilitated Workshops and MoSCoW prioritisation.

4.3.3 Validation
Once a Prioritised Requirements List (PRL) has been established, this needs to be validated by the Project Level and SDT roles,
and possibly a wider group of key stakeholders. It is recommended that the PRL is formally agreed and baselined at the end of
Foundations, by Quality Review. This then acts as a clear statement of the scope, upon which estimates during Foundations are
made. Whilst the Agile approach is to embrace change, it is very powerful focus for the project to agree the PRL in this formal
way. When change comes along during the project, which changes the breadth of the project, it is easier to assess its impact.
The Epic Stories on the PRL act as the headlines from which more detailed requirements are elaborated during Development
Timeboxes. Even If the project is exploratory, the PRL will set parameters related to the breadth of scope and the benefits the
project was funded to achieve.
A Solution Prototype may also be produced during Foundations and is a powerful way to elicit and validate requirements.

4.3.4 Management and Documentation

The main requirements product of the Agile BA during Foundations is the PRL. This becomes a central document for the
remainder of the project. The requirements on the PRL should describe what needs to be achieved, rather than exactly how
it will be done, to allow flexibility during Exploration and Engineering to focus on the business need and its achievement.
The PRL should be at a sufficient level of detail to allow the SDT to estimate for the Delivery Plan, showing a schedule of
expected timeboxes for at least the first increment of delivery.

requirements for which the solution has now been built and tested (and is about to be delivered) back to the Business Case.
They will make visible the benefits which should now be able to accrue to the Business Visionary, and to those who will receive
and use the solution.
Post-Project, the documentation of requirements from the project, plus the Business Case will be used to assess the level of
implementation of the requirements. Post-Project benefits assessment is likely to be achieved using a Facilitated Workshop,
which the Agile BA may facilitate.

4.4 Exploration and Engineering

5 Agile Practices

Business analysis is a defined part of the SDT work within each stage of iterative development within the Development Timeboxes.

MoSCoW prioritisation, Facilitated workshops, Modelling and Prototyping, Iterative Development and Timeboxing have been
considered above, alongside the project lifecycle. One additional technique, useful as a collaborative way of agreeing and
validating a set of requirements, is the Quality Review meeting.

The Agile BA facilitates the expansion of the Epic Stories of Foundations into lower-level User Stories, which guide development
and testing. Facilitated by the Agile BA, each User Story will be elaborated via demonstrations, prototypes, models and face-toface communication within the SDT.

4.4.1 Elicitation
During Development Timeboxes, the detailed requirements (User Stories) need to be discovered. This will mostly be through
face-to-face discussions and prototyping. Solution Developers, Solution Testers and Business Ambassadors work together to
concurrently expand the requirements detail and build the product. The Agile BA will capture the emerging detail, expanding the
PRL, timebox by timebox, with appropriate lower level detail and detailed acceptance criteria.

4.4.2 Analysis
As requirements detail emerges, these lower level requirements will need to be prioritised by the Business Ambassador(s)
and Business Visionary and agreed within the SDT. The business value of the detailed requirements also needs to be assessed,
priorities agreed and estimates made of the effort required to complete them.
The Agile BA will facilitate this conversation within the team and keep the link to the higher level requirements, processes and
data within the solution domain. The BA will model the structure of the requirements (story mapping) and keep this visible to
the team, so that the impacts of day-to-day decisions can be seen.

4.4.3 Validation
The Agile BA will work to keep the focus on the business case and higher level themes and features, as lower-level requirements
and acceptance criteria are defined.
During Engineering, the focus is on the validation of the finished, working solution. Frequent demonstrations of elements of the
solution to the project team and a wider stakeholder group will be a key part of this, facilitated by the Agile BA.
The acceptance criteria will drive test scripts. Decisions will be needed on:
The definition of Done the criteria for the product to be considered acceptable and ready for deployment;
test coverage what is being tested at each demonstration or testing session: functional aspects, usability, non-functional, performance.

4.4.4 Management and Documentation

During Exploration and Engineering, detailed requirements (User Stories) are documented in the prioritised requirements list (PRL).
Any modifications or further sub-divisions of the requirement should always be traceable back to the higher-level requirements.
It is also important during Exploration and Engineering to record those Should Have and Could Have requirements or features
that have been traded out or dropped and hence have become Wont Have requirements.
The PRL can be a useful tool for recording errors and bugs discovered when testing the solution so that they can be prioritised
and considered in the context of the overall requirements.

4.5 Deployment and Post-project

By Deployment, the elicitation and analysis of requirements is complete. Any specific requirements related to the deployment
of the solution should have been captured during Exploration and Engineering and fed into the Deployment Planning. The
validation activity here is to ensure that requirements documentation is sufficient for both support of the solution in live
usage, and for the Post-Project benefits assessment to be done. In the first part of Deployment, the Agile BA will link those

5.1 Quality Review meetings

Quality Review meetings are a formal meeting to study a product (here a set of requirements) and identify errors or defects,
which will be corrected outside of the meeting.
In brief, the process is as follows:
Plan the review: the review team is selected, and the time and venue agreed.
Preparation for review: the chairperson for the Review will distribute copies of the document to all parties, who should
return a Queries list before the meeting.
The meeting: the meeting allows the AgileBA to talk through the requirements item by item and for reviewers to respond. It
should be noted that the meeting is not the place to identify the solutions or fixes to problems. At the end, the chairperson
will agree with all reviewers what follow-up action is to be taken for any errors found, by whom and by when.
Follow-up: follow-up action may be needed because the requirements were not acceptable and a further review may
sometimes be needed. At the end of the review process, by agreement, the document can be signed off and baselined, to
provide a firm foundation for further evolution of the requirements during Development Timeboxes.

6 Summary
Agile Requirements Engineering allows requirements to follow a controlled, incremental process of decomposition and
elaboration, from a high level objective, themes and features, through to high-level prioritised requirements, to fully-evolved
requirements present in prototypes and the final solution. Each requirement has a lifecycle of Elicitation, Analysis, Validation,
Management and Documentation. Following this helps the Agile BA to ensure the focus on requirements is appropriate at the
different project lifecycle phases. It also helps to mitigate the risk that an inconsistent or internally-conflicting set of requirements
could evolve.
The Agile BA facilitates the evolution of requirements from high-level objectives down to low-level detail, whilst keeping the
consistency and focus, completeness and prioritisation of the requirements set as a whole. Agile DSDM practices form a key
part of this process, facilitated by the Agile BA.