Transcript How to define and validate requirements in an agile environment? © Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 1 (31) Much on requirements here! • at •

How to define and validate requirements
in an agile environment?
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 1 (31)
Much on requirements here!
• at
• … which is right, because testing and
requirements are just two opposite
sides of the same coin,
• so the best engineering practice is to
manage them together…
• … which IT industry has always
stubbornly refused to do 
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 2 (31)
We pleaded around the V-letter
Testers pleaded: “Please,
please, let us check the
testability of requirements!”
… or attempted to bribe: “If you
let us design acceptance tests
early, we’ll help you verify and
validate the requirements –
please?”
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 3 (31)
V
Or simply cried in desperation:
WE WANT BREAD REQUIREMENTS!
• But business just said “Let them eat
cakes!”
• …while developers did
not listen at all, busy
marching on!
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 4 (31)
Like that:
BIG BOSSES (wouldn’t listen)
WISE SOFTWARE
ENGINEERS
TRIGGER-HAPPY DEVELOPERS (wouldn’t listen)
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 5 (31)
We pleaded around Boehm’s curve:
Kill them while they are
still small!
Barry Boehm
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 6 (31)
But nobody would listen…
We do not
have time with
requirements!
Best validation
is in usage!
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 7 (31)
Project
managers
must focus
on
possibilities,
not risks!
Programmers pretended to care…
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 8 (31)
Business pretended to control…
• On one hand, pretending to run
waterfall…
• … on the other hand,
letting requirements and
scope to get out of hand
(there even was a fashionable name
for this: SOFTWARE CRISIS)
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 9 (31)
And this is how it ended 
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 10 (31)
One day, agile movement arrived
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 11 (31)
With religious zeal,
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 12 (31)
they invented new terminology,
calling well-known
things new names,
and pretending it
was all totally new
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 13 (31)
But it worked!
and even big
bosses would
suddenly listen!
When agile
revolutionaries
had arrived
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 14 (31)
many geeks
were
enormously
impressed
So, how is agile RE?
•
•
•
•
•
Pragmatic and user centred
Focus on direct communication
Iterative
Very disciplined
Tightly connected to testing and
project management
• Convincing to main stakeholders
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 15 (31)
Requirements Engineering
Old Dream
• The need for
requirements and
requirements
specifications is
understood and really
accepted
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 16 (31)
How agile provides it
• Agile doesn’t work at all
without requirements

• (even if it forces you to
call them “Product
Backlog Items”)
Elicitation
•
•
•
•
•
Old Dream
Continuous elicitation
xxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
One point of contact
Prototyping
Including developers’
views
Common language
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 17 (31)
•
•
•
•
•
How agile provides it
Sprints, backlog
grooming, sprint demos
(reviews)
Product owner
Sprint demo
Sprint planning
xxxxxxxxxxxxxxxxxxx
User stories using
business language
Consolidation and negotiation
Old Dream
• Let stakeholders take
the heat of decisionmaking, not pass it to
developers
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 18 (31)
How agile provides it
• Sprint planning with
product owner present
(provided it works!)
• However, noting
specific about how the
product owner handles
these issues
Analysis and break-down
Old Dream
• It should be a
continuous process,
breaking high-level
requirements into
chunks small enough to
be estimated correctly
and implemented fast
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 19 (31)
How agile provides it
• Breaking down user
stories: MMF, planning
poker, task
identification, INVEST
• However: it works much
worse between sprints
Modelling
Old Dream
• Often, something in
between purely chaotic
natural language and
over-modelling is
needed
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 20 (31)
How agile provides it
• Agile recommends just
that: user stories
Specification
Old Dream
• An SRS is not waste!
• Too much SRS is waste!
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 21 (31)
How agile provides it
• SRS (Product and Sprint
Backlogs) are obligatory,
but not too detailed,
not fully up-front, and
ready for changes
Traceability
Old Dream
• Full traceability, even
(especially) for big
complexity
•
•
•
•
•
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 22 (31)
How agile provides it
Less complexity => less
need for traceability
Much communication is
obligatory => harder to
loose track
In Product Backlog, one
point of control
Sprint Backlog, small
THIS IS NO
GUARANTEE!
Priorities
Old Dream
• Exist, are clear,
honoured, observed,
realistic, flexible
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 23 (31)
How agile provides it
• This is necessary in
release planning and in
sprint planning
Other attributes
•
•
•
•
Old Dream
Author / owner /
responsible
Status
Quality attributes (upto-date,
understandable, atomic,
correct…)
Testable
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 24 (31)
•
•
•
•
How agile provides it
Product owner… in a
way
DoD (see next slide)
Sprint planning – all
must understand,
INVESTxxxxxxxxxxxxxxxx
xxxxxxxx
Acceptance criteria,
cross-functional team
Requirements status chart 
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 25 (31)
Test connection
•
•
•
•
Old Dream
Test cases designed
together with
requirements
Testers can ask for
clarification
Tests ARE requirements
On all test levels
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 26 (31)
•
•
•
•
How agile provides it
As acceptance criteria,
yes (but not necessarily
otherwise!)
Yes, encouraged (during
sprint planning)
ATDD and TDD
Not really… acceptance
testing kind of makes a
problem here
Connection to project tasks
Old Dream
• Very old dream… even
PRINCE2® recommends
it; project tasks
(planning and
monitoring) managed
together with
requirements
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 27 (31)
How agile provides it
• Sprint planning, sprint
task board: no other
way but requirements
and tasks together
• However, it is no longer
so simple for „tech
stories” and nonfunctional requirements
Validation
Old Dream
• Early validation of
requirements
themselves („static”)
• Early validation through
product demo
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 28 (31)
How agile provides it
• All product backlog
grooming activities,
sprint planning
• Sprint demo (review)
Management
Old Dream
• Effective, and not
excessively timeconsuming
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 29 (31)
How agile provides it
• Essentially, agile
methodology is a
“requirements
management machine”

Summing up:
• Agile “just implements what
requirements engineering has long
known should be done”, but…
• … with agile, it
really WORKS!
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 30 (31)
victo.eu/HUSFTEF2013
Agile replaces
requirements
engineering!
Agile RE is just a
passing fad!
Think for yourself…
© Bogdan Bereza ● victo.eu/HUSFTEF2013 ● 31 (31)