Download as PDF, PPTX
Uploaded byRoopa Nadkarni
Req Pro - Andreas gschwind
This document summarizes a presentation on adopting an agile approach to requirements for complex systems and distributed teams. It discusses using a product backlog, user stories, use cases and scenarios to understand desired outcomes. It also covers exploring solutions through visualization, prototyping, and reviews. The presentation emphasizes using the right level of detail for requirements and a blend of techniques including backlogs, models, prototypes and specifications.
More Related Content
![[QUATIC 2012] A Multi-Model Case Study: High Maturity in Development + Servic...](https://cdn.slidesharecdn.com/ss_thumbnails/strongsteppaperpresentationmultimodelquatic2012v21-120911082655-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Req Pro - Andreas gschwind
- 1. IBM Rational SoftwareConference 2009 A Scalable “Just Enough” Approach to Requirements Andreas Gschwind Rational Services Executive GMU RDM02 Based on Ideas from Kurt Bittner/Robin Bater © 2009 IBM Corporation RDM02 1
- 2. IBM Rational SoftwareConference 2009 Topic: Adopting an Agile approach to Requirements • From engagements with our clients • We don’t do requirements any more • Backlog based • Test case driven • Feedback loop • Scalability ? • Complex systems • Distributed teams • Team size > 5 RDM02 2
- 3. IBM Rational SoftwareConference 2009 The Problem with Software • Organization’s goals are poorly understood by IT, & often by the business itself • “Requirements” processes often dive too deep, too early into specifying poorly conceived solutions • Cultural divide between organizations clouds communication • Exploring innovative alternatives is slow & expensive • How to overcome? Facilitate discussion RDM02 3
- 4. IBM Rational SoftwareConference 2009 Some Interesting things about Requirements Users expect functionality they did not initially ask for 93% Requirements are incomplete 89% Requirements are unclear or ambiguous 85% Developers make assumption when they encounter 85% ambiguities or gaps Users demand functionality that they never use 78% Models are not consistently used or not used well 74% The project’s vision and scope are not clearly defined 74% Internal customers are unhappy due to project delays and 67% missing the mark Models are not consistent with written requirements 59% Requirements are contradictory or conflicting 52% Source: Dr. Dobb’s Requirements Development Journal, 2006 RDM02 4
- 5. IBM Rational SoftwareConference 2009 Have a discussion to find out what the business needs Next generation airplane Boing: smaller, more hops, less travellers per hop, more routes Airbus: bigger, longer distance, direct connection Business doesn’t always understand what they want RDM02 5
- 6. IBM Rational SoftwareConference 2009 Explore Solutions Envision Understand Augment Evaluate Desired Spec Alternatives Outcomes Business Enact Opportunity Deploy Evaluate Solution Develop Results Solution A roadmap for building the right solution RDM02 6
- 7. IBM Rational SoftwareConference 2009 Explore Solutions Envision Understand Augment Evaluate Desired Spec Alternatives Outcomes Business Enact Opportunity Deploy Evaluate Solution Develop Results Solution A roadmap for building the right solution RDM02 7
- 8. IBM Rational SoftwareConference 2009 Understanding Desired Outcomes • The business opportunity is rarely well understood, even by the business • The business benefits are usually overstated and expected costs are understated • Real needs are obscured behind “wish lists” • What you really need to understand are desired outcomes • Ask what they want to achieve, how they will know if they have achieved it • The solution they have asked for may or may not deliver the desired outcomes • Business result You need to get to the root of the problem, not just treat the symptoms RDM02 8
- 9. IBM Rational SoftwareConference 2009 Some Techniques for Understanding Needs • 5 Whys • Fishbone diagrams • Pareto Charts • Mind Maps • Desired Outcomes Analysis What are you trying to achieve vs what do you need RDM02 9
- 10. IBM Rational SoftwareConference 2009 Explore Solutions Envision Understand Augment Evaluate Desired Spec Alternatives Outcomes Business Enact Opportunity Deploy Evaluate Solution Develop Results Solution A roadmap for building the right solution RDM02 10
- 11. IBM Rational SoftwareConference 2009 Requirements as a Means of Communication Order Customer Location : String Order Date : Date Shipped Date : Date Order Number : Integer Item but also: Special Instructions : String Quantity Ordered : Integer and: 9 Product Reference Number : Integer Name : String Unit Price : Float Domain Model Use-Case Specification User Interface Prototypes and/or • Glossary of Terms as well as: Storyboards • Supplementary (declarative) Requirements • Business Rules • Test Cases • ... RDM02 11
- 12. IBM Rational SoftwareConference 2009 A Map of Requirements Techniques RDM02 12
- 13. IBM Rational SoftwareConference 2009 Comparing Requirements Techniques Facilitates Handles inter- Low over- Handles Technique discussion dependencies head “flows” Moderate Poor Moderate Poor Declarative (Traditional) Good Moderate Poor Good Scenario-based Moderate Good Poor Moderate Model-based Good Poor Moderate Good Prototype-based Moderate Poor Good Moderate Testing-based Poor Poor Good Poor Backlog-based •No technique works best in all cases •Too much detail is as bad as too little! •The best approach is a blend of techniques RDM02 13
- 14. IBM Rational SoftwareConference 2009 An Agile approach to requirements 1. Start with a Product Backlog 2. For major new functionality, identify use cases/stories and scenarios 3. Outline the flows (if there are flows) 4. Define unfamiliar terms in a glossary • Augment the Glossary with a Domain Model to describe concepts with relationships or structure 5. Prototype the visualizable 6. Add declarative requirements for things that can’t be expressed in scenarios, prototypes or as backlog items 7. Write detailed descriptions of scenarios only where the need for precision justifies the investment in effort Incremental & iterative, stop when you think you have enough info RDM02 14
- 15. IBM Rational SoftwareConference 2009 1) The Product Backlog Stakeholder Requests Product Backlog Vision Document Supplementary Defects, User Use-Case Model Specification Change Stories, Requests Scenarios Design Specifications User Documentation Specifications RDM02 15
- 16. IBM Rational SoftwareConference 2009 RDM02 16
- 17. IBM Rational SoftwareConference 2009 New Functionality Description RDM02 17
- 18. IBM Rational SoftwareConference 2009 2) Use Cases and User Stories • User Stories are statements made by the customers as things that the system needs to do for them – They are in the format of about three sentences of text written by the customer in the customer’s terminology without techno-syntax. – User stories provide a good way to start talking about what the system needs to do • User stories often correspond to identified “scenarios” of a use case – Given a number of user stories, it is often possible to start synthesizing the use cases – Find the common parts of a number of user stories - this becomes the start of the “basic flow” of the use case – The leftover parts start to form the alternative flows – Refine both over time as new stories are found • Large numbers of user stories become unmanageable; use cases provide a way to consolidate the user stories – With large numbers of stories it is hard to see what’s in common RDM02 18
- 19. IBM Rational SoftwareConference 2009 Example User Stories • Web Customers purchase products online. • When attempting a purchase, the credit card may be rejected. • Inventory is received. • Inventory is reconciled. • An online order is abandoned. • An online order is interrupted. • The shopping cart for an online order is saved for later. • ... RDM02 19
- 20. IBM Rational SoftwareConference 2009 3) Identifying Use Cases to Map to Desired Outcomes Example This use case describes how a Web Customer uses the system to view and purchase the products on sale. Products can be found by various methods including browsing by product type, browsing by manufacturer or key word searches. RDM02 20
- 21. IBM Rational SoftwareConference 2009 5) Exploring Solutions through Visualization • Most people think visually rather than verbally; visualization enables people to be more creative • Visualization forces people to be concrete about the solution that they often have in their heads • Visualization creates more interesting discussions about possibilities than “documents” Visualization converges the vision • Visualization provides a way of the solution faster to articulate the solution in in a language everyone can understand RDM02 21
- 22. IBM Rational SoftwareConference 2009 Examples of Visualization Informal Sketch High-fidelity Prototype RDM02 22
- 23. IBM Rational SoftwareConference 2009 Example UI Design in RRC RDM02 23
- 24. IBM Rational SoftwareConference 2009 Explore Solutions Envision Understand Augment Evaluate Desired Spec Alternatives Outcomes Business Enact Opportunity Deploy Evaluate Solution Develop Results Solution A roadmap for building the right solution RDM02 24
- 25. IBM Rational SoftwareConference 2009 Strategies for Reviews • Using the visualizations, walk through scenarios, describing how the solution will deliver the desired outcomes • Bring in other reference material where needed to supply detail • Make the sessions interactive • Look for undiscovered desired outcomes or ways to improve processes • Seek to simplify Don’t circulate documents as discussion basis! Use Documents as final record on agreement You won’t get good feedback and you’ll miss the opportunity for an interactive discussion about whether you’ve met the real needs. RDM02 25
- 26. IBM Rational SoftwareConference 2009 Choosing the Right Participants • Select people with a deep understanding of the process being improved - People who will be directly affected by the outcomes produced by the solution - A small but diverse group of individuals – not just “lead users” but also, and especially, “average” users • Avoid people only indirectly involved in the solution • Avoid using review sessions for “information sharing” (Korean way) RDM02 26
- 27. IBM Rational SoftwareConference 2009 Explore Solutions Envision Understand Augment Evaluate Desired Spec Alternatives Outcomes Business Enact Opportunity Deploy Evaluate Solution Develop Results Solution A roadmap for building the right solution RDM02 27
- 28. IBM Rational SoftwareConference 2009 Augmenting Specifications • Envisioning work will have created a rough picture of the solution; the work here is to add details, where needed, to create a specification of what needs to be built • Some or all requirements techniques may be used to augment the items in the Product Backlog RDM02 28
- 29. IBM Rational SoftwareConference 2009 Levels of Detail in Use Case Specifications: An Example • Each use case flow may be at a different Briefly Described level of detail • Many or most use cases may only be Bulleted Outline outlined if the behavior is simple Fully Described • Only the most complex flows need to be fully described RDM02 29
- 30. IBM Rational SoftwareConference 2009 Exploiting the levels of detail Authoring State Primary Purpose Supports Briefly Described Identify the use case and • Basic Scope Management summarize its purpose • Discussions about requirements Bulleted Outline Summarize the shape and • Scope Management extent of the use case • Low fidelity estimation • Collaborative test definition • Prototyping Fully Described Provide a full requirements • High fidelity estimation specification for the behaviour •Analysis and Design encapsulated by the use • Implementation and testing case. • Creation of user documentation RDM02 30
- 31. IBM Rational SoftwareConference 2009 Strategies for Deciding How Far to Take Artifacts ↑ Complex behavior ➔ more precision ↑ Importance of implementing in a specific way ➔ more precision ↑ Regulatory scrutiny ➔ more precision ↓ Faster time to market ➔ less precision ↓ Simpler behavior ➔ less precision ↓ Lower risk of misunderstanding what is needed ➔ less precision Don’t detail CRUD!, use prototypes & a domain model Create, Retrieve, Update, Delete) RDM02 31
- 32. IBM Rational SoftwareConference 2009 Bulleted Outline Basic Flow Alternative Flows 1. Browse Products A1 Key Word Search 2. Select Products A2 No Product Selected 3. Identify Payment A3 Product Out of Stock A4 Payment Method Rejected Method A5 Shipping Method Rejected 4. Identify Shipping Method A6 Product Explicitly Identified 5. Confirm Purchase A7 Order Deferred A8 Ship to Alternative Address A9 Purchase Not Confirmed A10 Confirmation Fails Etc… RDM02 32
- 33. IBM Rational SoftwareConference 2009 Using a Domain Model to capture Data Requirements The Domain Model is a convenient mechanism for capturing requirements about data - think of it as an extension of the Glossary Many tools enable prototypes to be generated from data models (like the domain model) The domain model is easily integrated with other requirements approaches RDM02 33
- 34. IBM Rational SoftwareConference 2009 Example: Handling CRUD behavior RDM02 34
- 35. IBM Rational SoftwareConference 2009 Fully Described: A Very Simple Partial Example Basic Flow The use case begins when the Web Customer begins browsing the catalog of product offerings. {Browse Catalog} The system displays the product offerings that are currently available, highlighting the product categories that the customer has saved in their profile. The Web Customer browses through the catalog. {Select Product} The Web Customer selects a product to be purchased by entering the quantity of the product and adding it to their shopping cart. {Validate Stock On Hand} The system determines that the quantity requested is in stock, then records the product identifier and the quantity requested on the order, reducing the available quantity in inventory by the amount requested. The Web Customer continues to browse the product catalog and select products to order until they indicate that they are done shopping and wish to process the order. ... RDM02 35
- 36. IBM Rational SoftwareConference 2009 Use Cases and User Interface Prototyping • Visualization helps people to comprehend how the solution will work -- but it can also obscure the “big picture” • Use cases are useful to capture the usage scenarios, while prototypes are useful for exploring usability issues • Done in parallel, they can complement each other Movie-making analogy Script Storyboard RDM02 36
- 37. IBM Rational SoftwareConference 2009 Referencing the Glossary Use Case – Browse Products & Place Orders - Extract • The use case begins when the Web Customer begins browsing the catalog of Use boldface to product offerings. highlight Glossary terms. Hyperlinking • The system displays the product offerings that are currently available, works well if your tools highlighting the product categories that the customer has saved in their support this. profile. … Glossary Extract … catalog of product offerings: an online listing of all products offered for sale. currently available (products): A product is available if there is a non- zero quantity of that product available for sale. product category: A product category is a grouping of related products. Products can belong to more than one ctagory … RDM02 37
- 38. IBM Rational SoftwareConference 2009 Types of Declarative Requirements • Cross-cutting requirements, functional or non-functional, which are requirements that affect many use cases • Non-functional requirements quantify some property of the system or its required behavior but cannot be represented as a behavioral description • Constraints prescribe specific technical solutions, such as use of specific technologies or algorithms • Business Rules describe the operations, definitions and constraints that apply to an organization in achieving its goals RDM02 38
- 39. IBM Rational SoftwareConference 2009 Examples of Business Rules • Cash and credit card are accepted for payments at shows. Only Credit Card is accepted for online payments. • Purchased items may be returned within 30 days of purchase if accompanied by receipt. • Applicable local taxes are computed and added to the invoice at shows. • Merchandise marked as “on-sale” is not eligible for a discount. RDM02 39
- 40. IBM Rational SoftwareConference 2009 Referencing Business Rules from Use Cases ... • Flow steps refer to business rules • Flow steps give context to the business rules • Don’t repeat Rules in the actual Use Case flow text RDM02 40
- 41. IBM Rational SoftwareConference 2009 Explore Solutions Envision Understand Augment Evaluate Desired Spec Alternatives Outcomes Business Enact Opportunity Deploy Evaluate Solution Develop Results Solution A roadmap for building the right solution RDM02 41
- 42. IBM Rational SoftwareConference 2009 Developing Solutions • Having visualizations & supporting documentation provides a firm foundation on which to build • Keeping open communication with the business is important - frequent demonstration and review of working software builds confidence & allows fine- tuning of direction Frequent review of working software is the surest means of keeping a project on track RDM02 42
- 43. IBM Rational SoftwareConference 2009 Explore Solutions Envision Understand Augment Evaluate Desired Spec Alternatives Outcomes Business Enact Opportunity Deploy Evaluate Solution Develop Results Solution A roadmap for building the right solution RDM02 43
- 44. IBM Rational SoftwareConference 2009 Evaluating Results • Testing is essential for closing the loop - it is a means for evaluating whether the overall project objectives were achieved • Testing means more than just making sure there are no defects - it also means making sure the solution meets expectations. • Comparing results delivered against the desired outcomes will tell you whether you have delivered the right thing • Involving the business in the effort, continuously throughout the project, ensures that expectations are being met RDM02 RDM02 44
- 45. IBM Rational SoftwareConference 2009 Summary • Use the simplest possible way to express yourself – Start with the Product Backlog – Use a Glossary and a Domain Model for information requirements – Visualize and prototype the UI – Employ use-case specifications for scenarios that have “flow” • Choose an appropriate level of detail – More detail for complex scenarios, higher scrutiny or greater risk – Not all requirements need to be documented to the same detail • Choose an approach that will improve your interactions with stakeholders – What do they expect to see? – What do they need to see? – What is the best way to get feedback? – How will you document agreements? RDM02 45
- 46. IBM Rational SoftwareConference 2009 Summary • Improving results from software projects is mostly about improving communication • Clarity about desired outcomes is essential, but is often overlooked in the rush to develop solutions • Visualization of potential solutions is an ideal way to achieve consensus on how the solution will deliver the desired outcomes • Continuous feedback through the development effort provides a means of assessing progress • Testing means more than just verifying that there are no defects - it more importantly means closing the loop back to business value RDM02 46
- 47. IBM Rational SoftwareConference 2009 Automation RRC RTC Stakeholder Requests Product Backlog Vision Document ReqPro Doors Supplementary Defects, User Use-Case Model Specification Change Stories, Requests Scenarios Design User Documentation Specifications Specifications RDM02 RDM02 47
- 48. IBM Rational SoftwareConference 2009 © Copyright IBM Corporation 2009. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. RDM02 48