Requirement management presentation to a software team
Upcoming SlideShare
Loading in...5
×
 

Requirement management presentation to a software team

on

  • 26 views

 

Statistics

Views

Total Views
26
Views on SlideShare
26
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Requirement management presentation to a software team Requirement management presentation to a software team Presentation Transcript

    • 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.
    • 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 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 ?
    • 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 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
    • Test Strategy for embedded (TDD) Excerpted from http://www.agilerules.com/articles/Taming_Embedded_Tiger
    • 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