Requirement management
Nov 07, 2014
Requirement management
"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/
Overview
Importance of requirement management
If we got 'perfect' requirements, do you think we would have
● completed our projects faster, ● better quality and● lesser cost ?
Benefits of Good Requirements
Excerpted from 'Managing Software Requirements: A Use Case Approach' by Dean Leffingwell, Don Widrig
Evolution of requirements documentation
● Verbal requirements● BRS ● SRS ● FRS ● Use cases ● User stories ● Acceptance tests
Overlap between requirement analysis and management
In an iterative model they both follow each other in an endless cycle.
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
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 ?
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.
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 ?
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.
http://www.gilb.com/Blog
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
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
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 [email protected]
Exit criteria
Does the requirements specify what constitutes closure of project ?
How do we know we are 'done' ?
Validation
Excerpted from http://softwareandme.wordpress.com/2009/10/20/software-development-life-cycle/sdlc_v_model/
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.
Transferred applications
How do we maintain applications which do not have updated requirement documentation
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 ?
Pictures
How can we use pictures to represent requirements.
Screen shotsUML
If a picture is worth a thousand words, a video is worth a thousand pictures. How can we use multimedia technology to represent requirements ?
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 ?
SRS Management
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 ?
Value stream mapping
Excerpted from 'Lean Software Development - An Agile Toolkit' by Mary and Tom Poppendieck
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
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 ?
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.
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
Embedded - even the hardware evolves
Excerpted from http://www.agilerules.com/articles/Taming_Embedded_Tiger.pdf
Agile Test Techniques for EmbeddedSoftware● Strong unit testing is the foundation of agile software
development but embedded systems present special problems.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_Tiger.pd
Test Strategy for embedded (TDD)
Excerpted from http://www.agilerules.com/articles/Taming_Embedded_Tiger.pdf
Exercise 1 -Use Case and User Stories
Convert an SRS in your domain into Use cases and User Stories
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 ?
User stories for an embedded system
How do these fare in comparison to the Use cases ?
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 ?
'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
Exercise-2 on Issue Tracker Analysis
Fill the worksheet
Using 'JIRA'
Track root cause and avoidable / non-avoidable defects/issues.
What can we do to reduce these times and occurrences ?
Project retrospectives
To improve processes to reduce these churn rates
Share lessons learned with our peers
Statistics important to a Project manager
Excerpted from 'Lean Software Development - An Agile Toolkit' by Mary and Tom Poppendieck
Monthly burndown chart
Excerpted from http://en.wikipedia.org/wiki/Burn_down_chart
Traceability
Tools to achieve it
Requirement Tools
Excerpted from 'Software Requirements' by Karl E Weigers
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
Manual tools - Test case User story matrix
Number all User stories
Number all Acceptance tests
Use these numbers for cross referencing across the system
Visual Displays of project status
Excerpted from 'Lean Software Development - An Agile Toolkit' by Mary and Tom Poppendieck
Elicitation
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.
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