1. Requirements Management with Use Cases Module 5: Understand Stakeholder Needs Requirements Management with Use Cases Module 5: Understand Stakeholder Needs

2. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 2 Where Are We in the Requirements Discipline?

3. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 3 Objectives: Understand Stakeholder Needs  Identify sources for needs/requirements  List problems in eliciting needs  Identify techniques to elicit needs/ requirements  Explain context-free questions  Describe a requirements workshop  Practice brainstorming techniques  Identify requirements from a customer- generated specification  Describe business modeling

4. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 4 Understanding Needs: Activities and Artifacts

5. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 5 What Are Sources for Our Requirements? Customer Users Problem Domain Domain Experts Industry Analysts Site Visits Competitive info Bug Reports Change Requests Requirement Specs Business Plans Personal Goals Business Models Analyst Partners

6. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 6 Moore, 1991 Time INNOVATORS Technical Influence No Money Discontinuous innovation Company specific EARLY ADOPTERS Have money Strong Influence Specific features EARLY MAJORITY Pragmatists Mission critical systems Reliability Whole product solutions LATE MAJORITY Conservatives Price sensitive Simplify Commodity Demanding LAGGARDS Skeptics Price 0% 5% 10% 15% 20% 25% 30% 35% CHASM” “Crossing the What Are the Characteristics of Our Customers? % of Target Domain Customers Technology Adoption Profile (the lifecycle of the technology)

7. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 7 What Problems Might Be Encountered?  Stakeholders  Do not know what they really want  Are unable to articulate what they want  Think they know what they want, but don’t recognize it when delivered  Analysts think they understand user problems better than users  Everybody believes everyone else is politically motivated

8. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 8 What Does this Process Look Like? Customer Development Requirements Spec Approved ! Rejected Reworked Spec Rejected Reworked again Ad hoc requirements

9. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 9 Techniques for Eliciting Stakeholder Needs  Interviews  Questionnaires  Role playing  Requirements workshop  Use cases  Brainstorming and idea reduction  Storyboards  Prototypes  Review of customer requirement specifications  Business models

10. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 10 Interviews  Provide a simple and direct technique  Gain understanding of problems and solutions  Consider all perspectives  Users  Customers  Other stakeholders

11. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 11 Gause & Weinberg, 1989 Context-Free Questions  High-level, abstract questions  Explore needs from stakeholder perspective  User’s problems  Potential solutions  Always appropriate  Unbiased with application or solutions knowledge  Typically posed early in a project

12. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 12 Gause & Weinberg, 1989 Types of Context-Free Questions  User questions  Who are the users?  What are their key responsibilities?  What are their background, capabilities, environment?  Process questions  What is the problem?  How do you currently solve the problem?  How would you like to solve the problem?  Where else can the solution to this problem be found?

13. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 13 Gause & Weinberg, 1989 Types of Context-Free Questions  Product questions  What environment will the product encounter?  What business problems could this product create?  What are your expectations for usability? reliability?  Meta-questions  Do my questions seem relevant?  Are you the right person to answer these questions?  Are your answers requirements?  Is there anything else I should be asking you?

14. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 14 Non-Context-Free Examples  Leading questions  You need a larger screen, don’t you?  Self answering questions  Are fifty items about right?  Controlling statements  Can we get back to my questions?  Too long and too complex  I have a three part question,... What are better questions to ask?

15. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 15 Interview Tips  Don't ask people to describe things they don’t usually describe Example: Describe how to tie your shoes.  Avoid “Why…?” questions  Ask open-ended questions  Listen, listen, listen! TP3: Stakeholder Requests: Interview Template

16. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 16  1994 by Alan M. Davis Questionnaires  Give access to a wide audience  Appear scientific because of statistical analysis  Are applicable to broad markets where questions are well-defined  Can be powerful, but not a substitute for an interview  Assumptions:  Relevant questions can be decided in advance  Questions phrased so reader hears as intended

17. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 17  Tools and techniques  Analyst learns and performs user’s job  Analyst performs a scripted walkthrough  Advantages  Gain real insights into the problem domain  Understand problems users may face Role Playing

18. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 18 A Requirements Workshop  Accelerates the elicitation process  Gathers all stakeholders together for an intensive, focused period  Is guided by a facilitator  Provides opportunity for all stakeholder feedback  Presents results immediately  Provides a framework for applying other elicitation techniques

19. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 19 Workshops: Planning and Executing Sell the workshop Establish team Handle logistics Issue warm-up material Prepare agenda Facilitate Keep on track Record findings Summarize conclusions Synthesize findings Condense info Present to customer Determine next steps PRE WORKSHOP SESSIONPRODUCTIONFOLLOW-UP

20. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 20 Use-Case Model How Do Use Cases Help Elicit Needs?  Provide stakeholders’ point of view  Promote discussion: Why is the system needed?  Who will interact with the system (actors)?  What do users want to achieve by using the system (use cases)?  What interfaces should the system have?

21. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 21 Rules for Brainstorming Brainstorming  Clearly state the objective of the session  Generate as many ideas as possible  Let your imagination soar  Do not allow criticism or debate  Mutate and combine ideas

22. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 22 Exercise 5.1: Utilize Brainstorming Techniques  Gather ideas for features  Clarify and organize the ideas  Condense ideas  Prioritize remaining ideas

23. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 23 Shurtleff ‘94 Storyboards  Movies, cartoons, and animated features all begin with storyboards that tell:  Who the players are (actors)  What happens to them  When it happens

24. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 24 Shurtleff ‘94 Storyboard Benefits  Help gather and refine customer requirements in a user friendly way  Encourage creative and innovative solutions  Encourage team review  Prevent features no one wants  Ensure that features are implemented in an accessible and intuitive way  Ease the interviewing process  Avoid the blank-page syndrome

25. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 25 Prototypes  Demonstrate some or all of the externally observable behaviors of a system  Used to:  Gain feedback on proposed solution  Demo the problem domain  Validate known requirements  Discover unknown requirements  Prototyping tools  Demo programs  Simulations

26. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 26 Why are Prototypes Dangerous?

27. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 27 Why Use Prototypes?  Elicit and understand requirements  Prove and understand technology  Reduce risk  Enhance shared understanding  Improve cost and schedule estimates  Improve feature definition

28. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 28 Review Customer Requirement Specs  Identify requirements  Look for and label: Application behaviors Behavioral attributes Issues and assumptions  Ask the customer! requirements review

29. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 29 Exercise 5.2: Review System Specifications  Review the 2001 Elevator System Specifications  Look for possible requirements  Mark and number each requirement

30. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 30 Business Models  Model organization structure and dynamics  Business processes  Organizational structure  Roles and responsibilities  Visualize the organization and its processes  Help understand current problems  Identify potential improvements  Derive system requirements needed to support the organization  Products  Deliveries  Events

31. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 31 Business Models Are Input to System Requirements  Responsibilities of actors supported by the system  Business processes to automate in the system  Types of information to manage  Traceability between business and system model Traceability

32. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 32 Business Use-Case Model Business actor: Someone or something outside the business that interacts with the business. Business use case: A sequence of actions a business performs that yields an observable result of value to a particular business actor. Example: Business Use-Case Model for a Generic Software Solution Vendor

33. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 33 Mapping Guidelines: Business to System Use-Case Model  Business actor  system actor  Business worker  system actor or use case  System actor (if the worker interacts with the system)  System use case (if the worker is automated by system)  Business use case  subsystem or use case Application System or Subsystem Business Workers Business Use Cases Business Actor System Actor

34. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 34 Business Object Model  Shows structural elements  Business entities  Business workers  Responsibilities  Relationships  Is visualized by  Static views–the class diagram  Dynamic views–sequence diagram, collaboration diagram, and state chart diagram  Behavioral views–the activity diagram

35. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 35 Capture Vocabulary: Make a Domain Model  Subset of Business Object Model  Visual model of business objects  Benefits:  Formalizes the vocabulary for the project  Simplifies reasoning about different terms  Describes relationships between terms  Provides visual representation of relationships

36. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 36 Domain Model Example: RU e-st Market transactionTransferTrade CustomerTrading Acct. Transaction 1..2 11..** Limit Transaction

37. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 37 Eliciting Needs: Which Tools to Use? Developer Experience Customer/User Experience Low Hi Low Hi “Fuzzy problem” “Catch Up”“Mature” “Selling/Teaching” Adapted from Alan Davis  Requirements Workshop  Brainstorming  Use Cases  Interviews  Questionnaires  Role Playing  Business Modeling  Storyboarding  Prototyping  Requirement Reviews Which of these tools might you use for each quadrant of the graph?

38. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 38 Review: Understand Stakeholder Needs 1.What are some problems encountered in trying to understand user needs? 2.What are some elicitation techniques for understanding user needs? 3.What is the basis of the “context-free” question? 4.How can a requirements workshop accelerate the elicitation process? 5.How are use cases helpful in eliciting user needs? 6.What would you look for in a customer-generated requirement specification? 7.What is business modeling?