Requirements Engineering in Agile

Slides based on:

Tricode Professional Services

www.tricode.nl

Madalina Cerchia
The bottleneck has moved

• Developers are NOT the bottleneck:

– Faster machines with Gigaspaces
– Better languages: Java, Ruby, Scala
– Better tools: IntelliJ, Eclipse
– Better practices: Test-Driven Development, Pair Programming, SCRUM…

• Less rework-> more productivity

• Lean thinking-> less code (1)

(1) Allan Kelly, “Changing Software”

 Bottleneck is Requirements
• Requirements errors are the greatest source of defects and quality
problems

• Most of errors originate in requirements and design activity

• Only 5% originate in programming

• Fixing requirements errors eats up roughly one-third(2) of your

project budget

• Requirements are NOT a document:

– Dialogue

(2) Hooks and Farry 2001

Agile Development
• “Agile software development is a group of software
development methodologies iterative and incremental
development, where requirements and solutions evolve
through collaboration between self-organizing, cross
functional teams.”
Agile Development …

• Agile development is less document-centric

and more code-oriented.
• Doesn’t mean NO-DOCUMENTATION
• Agile methods were developed to adapt and
thrive on frequent changes.
• Agile methods are people-oriented rather
than process oriented.
 Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

•Individuals and interactions: over processes and tools

•Working software: over comprehensive documentation
•Customer collaboration: over contract negotiation
•Responding to change: over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.
Agile development process VS.
Waterfall process

First iteration in an agile development process

XP

• Extreme Programming (XP) is based on

values of simplicity, communication,
feedback, and courage.
• XP uses story cards for elicitation.
• XP is based on frequent small releases.
Scrum process

• Each iteration begins with good requirements

Problems with Tradition RE
Approaches
• Traditional RE inapplicable to the quick and
changeable work under an agile
environment.
• AMs seem to manage effectively
requirements in small projects but not in
large ones.
• The teams lack a good, lean and agile way to
collect requirements.
Requirements challenges in Agile
Challenge 1: Does the business know what it wants?
“I’ll know it when I see it”

• New domain
• Highly innovative product
Challenge 2: “Working software over comprehensive documentation”

• Agile doesn’t mean that you don’t need

requirements

• Agile means you successively elaborate

requirements

• “Just-Good-Enough” requirements
Challenge 3: Dependencies between
geographically distributed teams

• More difficult to coordinate work activities between

teams

• Does a User Story provide enough context?

Possible solutions:
• Business, Analysts and
Designers work a “Sprint”
ahead of the development

• Write Use Cases when it’s

needed (alternative scenarios)

• Development teams should

coordinate their activities
Essential Aspects to An Agile Approach to
Requirements
Customer involvement
• Customer involvement is essential for project success whether you
follow traditional or agile approach
• Customer involvement timing is different
• Waterfall – Early involvement
• Agile – Through out the SDLC
• On agile projects, customers (or a product owner who represents
them) are engaged continuously throughout the project.
• Customer helps to identify and prioritize user stories

• Customer also needs to be involved as user stories are less

detailed

• Customer involvement is necessary to test and provide feedback

on developed features.
Documentation Detail
• The close collaboration of customers with developers on agile
projects generally means that requirements can be documented in
less detail than on traditional projects.

• Instead, BAs or other people responsible for requirements will

develop the necessary precision through conversations and
documentation when it is needed.

• Agile methods encourage creating the minimum amount of

documentation needed to accurately guide the developers and
testers.

• Only the riskiest or highest-impact functionality being specified in

more detail in user stories, typically in the form of acceptance
tests.
The backlog and prioritization
• The product backlog on an agile project contains a list
of requests for work that the team might perform
• Product backlogs typically are composed of user
stories, but some teams also populate the backlog with
other requirements, business processes, and defects to
be corrected.
• Each project should maintain only one backlog,
Therefore, defects might need to be represented in the
backlog for prioritization against new user stories.
• Backlogs can be maintained on story cards or in tools.
• Prioritization of the backlog is an ongoing activity to
select which work items go into upcoming iterations and
which items are discarded from the backlog.
• Tracing items in the backlog back to the business
requirements facilitates prioritization.
Timing
• Agile projects require fundamentally the same types of requirements
activities as traditional development projects
• However, detailed requirements are not documented all at once at the
beginning of an agile project
• Instead, high-level requirements, typically in the form of user stories, are
elicited to populate a product backlog early in a project for planning and
prioritization.
User stories, Epics and features
• A user story is a concise statement that articulates
something a user needs and serves as a starting point
for conversations to flesh out the details.
• User stories were created specifically to address the
needs of agile developers.
• Which normally have been referred as use cases,
features, or process flows when exploring user
requirements.
• User stories are sized so as to be fully implementable
in a single iteration.
• An epic is a user story that is too large to fully
implement in a single iteration.
• A feature is a grouping of system capabilities that
provides value to a user.
Feature
• A feature is a grouping of system capabilities that provides
value to a user.
• In the context of an agile project, features could encompass an
individual user story, multiple user stories, an individual epic,
or multiple epics.
• For example, a zoom feature on a phone’s camera might be
developed to enable execution of the following two unrelated
user stories:
– As a mother, I want to take recognizable pictures of my daughter
during school performances so that I can share them with her
grandparents.
– As a birdwatcher, I want to be able to take clear photographs of birds
from a distance so that I
can identify them.
Minimum Marketable Feature (MMF)
• Minimum (or minimal, or minimally) Marketable
Feature(MMF) is the concept of identifying the lowest level
of stories aligned with the business requirements, allowing
you to determine the smallest set of functionality that the
team can deliver that provides value to the customer.
Expect change
• The biggest adaptation that BAs need to make when a
requirement change arises on an agile project is to say not,
• “Wait, that’s out of scope” or “We need to go through a formal
process to incorporate that change,”
• Rather,
• “Okay, let’s talk about the change.”
• This encourages customer collaboration to create or change user
stories and prioritize each change request against everything else
that’s already in the backlog.
• Change also includes removing items from scope. Items can be
removed from an iteration’s scope for various reasons, including
the following:
• Implementation issues prevent an item from being completed
within the current time frame.
• Issues discovered by product owners or during testing make
the implementation of a particular story unacceptable.
• Higher-priority items need to replace less important ones that
were planned for an iteration
How to gather requirements

-best practices-
Agile practices to gather requirements
(1/4)

Capture the “the Big-picture”

Artifacts: Data Flow Diagrams

Data Flow Diagram (DFD)- used to visualize the flow of data
in a given context.

Common applications:
Design of an existing business process
Define the upfront roadmap

Common misapplications:
Over specification by "drilling down" into sub processes
with more DFD’s.

Tool: white board, CASE tools, Visio, etc.

Example:
“Order Processing” Data Flow
dfd Order Processing

Webshop
Warehouse

Orders

Orders & Payments

Books
Shipping details

Order details

Billing
Information
Ship Books
Process Orders Customer address
Customer address

Invoices

Customers
Books

Customer
Invoice details name

Invoice
Collect
Payments

Customers

Payment
Agile practices to gather requirements
(2/4)

Identify Use Cases- define how the new product

will work

UML Artifacts: Use Cases Diagram

Use Case Diagram (UCD)- graphical overview of the
functionality provided by a system in terms of actors
and their goals (use case)

Common applications:
Analysis of system functions that are performed by
which actor

Common misapplications:
Identification of usage requirements

Example:
“Manage Users” Use Case diagram

uc ManageUsers

Users Management

Login

Create member
account
User

«extend» View history

View account

«extend»
View activ ated
modules

Disable account

Administrator
Agile practices to gather requirements
(3/4)

Model a bit ahead- focus on individual Use Cases

for the first release

Artifacts:
1. Business Process Diagram (BPM)
2. Domain Model Diagram (DMD)
3. State Diagram (SD)
1. Business Process Diagram (BPD)- provides a notation that
is intuitive to business users yet able to represent complex
process semantics

Common applications:
Identifying the business process in an intuitive manner

Common misapplications:
Document technical requirements

Example:
“Register Appointment” Business Process

BPMN RegisterAppointment

Send doctor request Receive

Patient
«Pool»

appointment

Illness occurs

Appointment request

Appointment notification
«Pool»

Doctor

Receive doctor Send appointment

request

Appointment done
2. Domain Modeling Diagram (DMD)- shows
relationships between entities within system, domain
etc.

Common applications:
Explore domain concepts with project stakeholders

Common misapplications:
Complete data models up front!

Simple tool:
White board, Enterprise Architect, Visio, SmartDraw,
etc.
3. State diagram (SD)- describes the behavior of
complex object

Common applications:
Analyze a complex business process

Common misapplications:
Design the behavior of several objects
Design the behavior of a simple object

Example:
Application releases- state diagram
stm release flow state
Initial

[upload]

Beta

[release]

Released
[eol]

[eol]

End-Of-Life

[archive]

Archiv ed

Final State
Agile practices to gather requirements
(4/4)

• Preliminary design mockups prototyping

– document navigation, usability, look & feel without
investing the time and money to develop the entire
products

Tools: Balsamiq Mockups, iRise

User Stories
• A User Story is a requirement expressed from the
perspective of an end-user goal. User Stories may also be
referred to as Epics, Themes or features but all follow the
same format.

• A User Story is really just a well-expressed requirement.

 Use Stories
• The User Story format has become the most popular way of
expressing requirements in Agile for a number of reasons:
– It focuses on the viewpoint of a role who will use or be impacted by
the solution.
– It defines the requirement in language that has meaning for that role

– It helps to clarify the true reason for the requirement

– It helps to define high level requirements without necessarily going

into low level detail too early
• User goals are identified and the business value of each
requirement is immediately considered within the user story.
Use Story Template
• They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some
reason >.
• User stories are often written on index cards or sticky notes,
stored in a shoe box, and arranged on walls or tables to
facilitate planning and discussion.
• As such, they strongly shift the focus from writing about
features to discussing them.
• In fact, these discussions are more important than whatever
text is written.
Epics
• We can write a user story to cover large amounts of functionality.
• These large user stories are generally known as epics.

An epic is a user story that is too large to fully implement in a

single iteration.

• Because epics span iterations, they must be split into sets of

smaller stories.
• Sometimes epics are large enough
that they must be subdivided into multiple epics, each of which is
then split into multiple stories until each resulting story can be
reliably estimated and then implemented and tested within a
single
iteration
Epics ..
• Breaking epics down into smaller epics and then into user stories is
often referred to as story decomposition
Epic Example
• Here is an epic agile user story example from a desktop
backup product:
As a user, I can backup my entire hard drive.
• The epic above could be split into dozens (or possibly
hundreds) user stories, including these two:
– As a power user, I can specify files or folders to backup
based on file size, date created and date modified.
– As a user, I can indicate folders not to backup so that my
backup drive isn't filled up with things I don't need
saved.
User Story Example

Story Identifier: STK001

Story Name: Customer Order
Description: As a Customer, I need to place an order so that I
can have food delivered to my house.
Confirmation: Acceptance Criteria examples:

Functional:
- Can I save my order and come back to it later?
- Can I change my order before I pay for it?
- Can I see a running total of the cost of what I have chosen so
far?
User Story Example …

Confirmation …. continues
Non-functional: availability:
- Can I place an order at any time (24 hours per day or
24/7/365)?
- Can I view the order at any time (24 hours per day or
24/7/365) up to and including delivery?

Non-functional: security:
- Are unauthorised persons and other customers prevented
from viewing my order?
Useful resources

• http://www.agilemodeling.com/

• http://modernanalyst.com/

• http://www.omg.org/spec/UML/2.2/