2. "My biggest learning has been that people do
not look for features, they look for benefits. In
future versions, i may even remove some
features to make the product less
complex, less expensive".
- Pallav Nadhani - Founder , FusionCharts in
'Times Of India' Jan 5th 2011
http://www.fusioncharts.com/
4. Importance of requirement
management
If we got 'perfect' requirements, do you think we
would have
●completed our projects faster,
●better quality and
●lesser cost ?
5. Benefits of Good Requirements
Excerpted from 'Managing Software Requirements: A Use Case Approach'
by Dean Leffingwell, Don Widrig
7. Overlap between requirement analysis
and management
In an iterative model they both follow each other
in an endless cycle.
8. Changing requirements problem
How do we solve it ?
- Is there something intrinsic to software that
makes it so difficult to define upfront ?
- Why do we worry about changes anyway and
how can we get rid of that worry
9. Implicit requirement problem
How do we solve it ?
Can we have a checklist to ensure we fill in all
the gaps ?
How is this related to the earlier problem of
software churn ?
10. Implicit requirements
"Bring me a rock" "Yes, but, actually,
what I really wanted
was a small blue
rock."
'The Rock problem' excerpted from 'Managing Software Requirements: A Use
Case Approach' by Dean Leffingwell, Don Widrig
The delivery of a small blue
rock elicits the further request
for a spherical small blue rock.
11. Business objectives
Should we attach business value to each item
of the requirement ?
Can developers see the larger picture as well
as the trees in the woods ?
12. Project requirements linked to
Organizational goals
"Why did BBC Agile Project Fail? Tom´s Opinion; deliver value
to stakeholders !"
I notice that, as usual, there is no mention of
consciously trying to deliver real value
to Stakeholders early and at every iteration. This
is the fundamental sickness of Agile Today.
Plenty mention of code, none of value to
stakeholder. Plenty mention of learn only at the
end, none of learning what´s real at each
increment.
13. Different project life cycle models
How they influence requirements management
- Traditional top down approach
- Iterative, prototype driven, frequent feedback
approach
The cost implication of each model
- In an agile environment, the risk is transferred
to the vendor
- In a top down approach the risk is transferred to
the customer
14. Requirements Engineering is Iterative
"When projects must deal with conflicts in
stakeholder requirements and changes in
management constraints, an adaptive
process is far more likely to succeed than
traditional methodologies"
- Mary Poppendieck in her blog http://www.leanessays.com/2002/01/wicked-
problems.html
15. Iterative Requirement Management
"The key to successful agile is to have feedback
loops that are as short as possible. In a larger
organisation, the loop gets longer, but the way to
keep those loops as short as possible is by
ensuring that there is bottom-up involvement
also in product design, and perhaps also vision."
Wouter Lagerweij in leandevelopment@yahoogroups.com
16. Exit criteria
Does the requirements specify what
constitutes closure of project ?
How do we know we are 'done' ?
18. Testable Requirements
Excerpted from IEEE Recommended Practice
for Software Requirements Specifications 1998
An SRS is verifiable if, and only if, every
requirement stated therein is verifiable.
A requirement is verifiable if, and only if, there
exists some finite cost-effective process with
which a person or machine can check that the
software product meets the requirement.
In general any ambiguous requirement is not
verifiable.
20. Tools to track, trace, and manage
Can we explain the rational behind the key
architectural decisions of a running application ?
Do we know the key objectives of a system ?
Can we track a Requirement spec to all its
acceptance tests, unit tests , changes ,
enhancements and bugs ? Do we need ?
Does each developer know the exit criteria for
his unit of work ?
21. Pictures
How can we use pictures to represent
requirements.
Screen shots
UML
If a picture is worth a thousand words, a video is
worth a thousand pictures. How can we use
multimedia technology to represent requirements
?
22. Cost, quality and time
How can we build in quality into the process to
ensure that the requirements are met in cost,
quality and time ?
24. Decompose a SRS into units of work
How do we break it into programmable features
?
How do we break it into acceptance tests ?
How do we break it into Unit tests ?
How do we then trace these back and forth from
and to the SRS ?How do we trace changes and
enhancements to the above ?
26. How to map Your Value Stream
●With a pencil and pad in hand, go to the place where a
customer request comes into your organization.
● Working with the people involved in each activity, you sketch
all the process steps necessary to fill the request, as well as
the average amount of time that a request spends in each step.
● At the bottom of the map, draw a timeline that shows how
much time the request spends in value-adding activities, and
how much time it spends in waiting states and non-value
adding activities
Excerpted from 'Lean Software Development - An Agile Toolkit'
by Mary and Tom Poppendieck
27. The Cost-Quality-Time paradox
How can we improve turn around time of each
requirement without compromising on quality ?
Should we limit the commitment to match
resources ?
Can we identify non value added time ?
28. Personas and user stories
●An SRS describes the entire target system, a
Use case describes a part of the target system
and a User Story describes a programmer
feature.
●SRS documents and Use cases are sometimes
abstract and generalized. How does one unravel
an SRS into a story ?
●You can use Personas or User stories or
Scenarios.
29. Requirements in Test Driven
Development environment
Exit criteria in form of Acceptance Tests
Automation of Acceptance tests (FIT for
Business applications and other tools)
Automation of Unit tests
Automation of build including Unit and
Acceptance tests
30. Embedded - even the hardware
evolves
Excerpted
from http://www.agilerules.com/articles/Taming_Embedded_Tiger
.pdf
31. Agile Test Techniques for Embedded
Software
●Strong unit testing is the foundation of agile software de
velopment but embedded systems present special proble
ms.Test of embedded software is bound up with test of
hardware,crossing professional and
organizational boundaries.
●Even with evolving hardware in the picture, agile methods
work well provided you use multiple test strategies.
This has powerful implications for improving the quality of
high reliability systems, which commonly have embedded
software at their heart
Excerpted
from http://www.agilerules.com/articles/Taming_Embedded_T
iger.pd
32. Test Strategy for embedded (TDD)
Excerpted
from http://www.agilerules.com/articles/Taming_Embedded_Tiger
33. Exercise 1 -Use Case and
User Stories
Convert an SRS in your domain
into Use cases and User Stories
34. Use case for an embedded system
Who is the primary actor ?
What is the goal ?
What are the main flows and alternative flows ?
What are the preconditions
What are the post-conditions ?
35. User stories for an embedded system
How do these fare in comparison to the Use
cases ?
36. Benefits of a SRS as compared
What are the benefits of a SRS as
compared to Use cases and User stories ?
Where would you fit in the Non functional
specs in Use cases / Stories ?
37. 'Misuse' cases
Use cases which miss out on the key
computations or algorithms
Use cases which keep repeating the same steps
which are redundant after the first case
Use cases which do not describe the 'soft'
requirements of the user - performance
constraints, integration to other systems, user
friendliness
45. Manual Tools - Tabular worksheets
●Use Excel to capture the Business
requirements
●separate from the Product requirements
●separate from functional requirements.
●Number all items for backward traceability.
●Track revisions using SharePoint or other
collaboration system
46. Manual tools - Test case User story
matrix
Number all User stories
Number all Acceptance tests
Use these numbers for cross referencing
across the system
47. Visual Displays of project status
Excerpted from 'Lean Software Development - An Agile Toolkit'
by Mary and Tom Poppendieck
49. One to one interviews
Vision document.
Study of current system, competitor systems,
benchmarks
Low cost prototypes and pilots to dove tail to 'real'
requirements
User workshops involving all stakeholders in one
session to nail down needs of all stakeholders.
50. References
'Lean Software Development - An Agile Toolkit' by Mary and
Tom Poppendieck
'Software Requirements' by Karl E Weigers
'Taming the Embedded Tiger – Agile Test Techniques for
Embedded Software' by Nancy Van Schooenderwoert, Ron
Morsicato Agile Rules, Lexington, MA
'Managing Software Requirements: A Use Case Approach'
by Dean Leffingwell, Don Widrig
