Requirement management presentation to a software team


Published on

Published in: Software, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Requirement management presentation to a software team

  1. 1. Requirement management
  2. 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
  3. 3. Overview
  4. 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. 5. Benefits of Good Requirements Excerpted from 'Managing Software Requirements: A Use Case Approach' by Dean Leffingwell, Don Widrig
  6. 6. Evolution of requirements documentation ●Verbal requirements ●BRS ●SRS ●FRS ●Use cases ●User stories ●Acceptance tests
  7. 7. Overlap between requirement analysis and management In an iterative model they both follow each other in an endless cycle.
  8. 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. 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. 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. 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. 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. 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. 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 problems.html
  15. 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
  16. 16. Exit criteria Does the requirements specify what constitutes closure of project ? How do we know we are 'done' ?
  17. 17. Validation Excerpted from development-life-cycle/sdlc_v_model/
  18. 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.
  19. 19. Transferred applications How do we maintain applications which do not have updated requirement documentation
  20. 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. 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. 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 ?
  23. 23. SRS Management
  24. 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 ?
  25. 25. Value stream mapping Excerpted from 'Lean Software Development - An Agile Toolkit' by Mary and Tom Poppendieck
  26. 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. 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. 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. 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. 30. Embedded - even the hardware evolves Excerpted from .pdf
  31. 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 iger.pd
  32. 32. Test Strategy for embedded (TDD) Excerpted from
  33. 33. Exercise 1 -Use Case and User Stories Convert an SRS in your domain into Use cases and User Stories
  34. 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. 35. User stories for an embedded system How do these fare in comparison to the Use cases ?
  36. 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. 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
  38. 38. Exercise-2 on Issue Tracker Analysis Fill the worksheet
  39. 39. Using 'JIRA' Track root cause and avoidable / non-avoidable defects/issues. What can we do to reduce these times and occurrences ?
  40. 40. Project retrospectives To improve processes to reduce these churn rates Share lessons learned with our peers
  41. 41. Statistics important to a Project manager Excerpted from 'Lean Software Development - An Agile Toolkit' by Mary and Tom Poppendieck
  42. 42. Monthly burndown chart Excerpted from
  43. 43. Traceability Tools to achieve it
  44. 44. Requirement Tools Excerpted from 'Software Requirements' by Karl E Weigers
  45. 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. 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. 47. Visual Displays of project status Excerpted from 'Lean Software Development - An Agile Toolkit' by Mary and Tom Poppendieck
  48. 48. Elicitation
  49. 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. 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