Requirement management presentation to a software team

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 leandevelopment@yahoogroups.com

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