1. 1 ® Mastering Requirements Management with Use Cases Understand Stakeholder Needs

2. 2 Objectives: Understand Stakeholder Needs  Identify sources for stakeholder requests.  Describe the Stakeholder Request Artifact.  List techniques to elicit stakeholder requests.  Practice brainstorming techniques.  Identify requirements from a customer- generated specification.

3. 3 Where Are We in the Requirements Discipline?

4. 4 Understanding Needs: Activities and Artifacts

5. 5 The process

6. 6 What Are Sources for Requirements? Analyst Customer Problem Domain Users Partners Site Visits Domain Experts Industry Analysts Competitive info Initial Requests Bug Reports Change Requests Requirement Specs Business Models Business Plans Personal Goals

7. 7 What Does the Process Look Like? Customer approved Reworked specification Rejected againReworked specificationRejected by customer Requirements specification Customer Ad-hoc requirements given to Project Team Project Team

8. 8 What Problems Might Be Encountered?  Stakeholders  Have a pre-conceived idea of the solution.  Do not know what they really want.  Are unable to articulate what they want.  Think they know what they want, but do not recognize it when it is delivered.  Analysts  Think they understand user problems better than users.  Everybody  Everyone sees things from their own point of view.  Believes everyone is politically motivated. StakeholderAnalyst ??

9. 9 Expressing Stakeholder Requests STRQ “Students need to get grades in a convenient manner” “Report cards can be printed” “End of year results are automatically emailed to the student” “Professors need to know who is enrolled” “Class lists are emailed at end of enrolment”

10. 10 The Stakeholder Requests Artifact  Is owned by the stakeholders.  Contains all requests from the stakeholders.  Is consolidated from many sources.  E-mail, customer requirements specification, napkins, white boards, spreadsheets, and so on.  Used by project team to derive features and software requirements.  May contain references to any type of external source. User Doc Specs Design Specs Stakeholder Requests Vision Document Supl Spec Use-Case Model

11. 11 Techniques for Eliciting Stakeholder Requests  Review customer requirement specifications  Requirements workshop  Use-case workshops  Brainstorming and idea reduction  Interviews  Questionnaires  Role playing  Prototypes  Storyboards

12. 12 Review Customer Requirement Specifications  Identify requirements.  Recognize and label: Application behaviors Behavioral attributes Issues and assumptions  Ask the customer. Requirements review

13. 13 Review Customer Requirements Spec  Part 1  Review the customer requirements specification.  Look for possible requirements in the spec.  Part 2  Review the list of sample stakeholder requests.  Refine the Vision document. Define the system boundary. Revise the list of actors.

14. 14 Feature in relation to need or requirement  Needs  A reflection of the business, personal or operational problem/opportunity that must be addressed  Features  A service which fulfills one or more stakeholder needs  Expressed in short sentences or phrases  Usually try to limit number  Are not yet requirements  Must be tracked  Attributes  Describe feature  Status,priority, level of effort,risk, stability, assigned to, release target, reason

15. 15 User Docs User Docs Design Map of the Territory (Requirements Management) Test Procedures Needs Features Use cases and Software requirements Traceability Proble m The Problem space Solution space The Product To be built The Product To be built Traceability

16. 16 Requirements Workshops  Perhaps the most powerful method of elicitation (and validation)  Many opinions at once  Feed on each other  Improve and clarify each other  Bring total knowledge to bear  Benefits  Team spirit – involvement  All stakeholders get to input Challenge Defend Compromise  Preliminary system features available at the end ??

17. 17 Requirements Workshops  Create consensus on the scope, risks, and key features of the software system.  Are directed by a facilitator.  Duration: three to five days  Produce artifacts, such as:  Problem statement  Stakeholder Requests  Key features  Initial business object model  Use-case diagram  Prioritized risk list

18. 18 Requirements Workshop Benefits  Provides a framework for applying other elicitation techniques.  Use-case workshops, brainstorming, storyboarding  Accelerates the elicitation process.  Gathers all stakeholders together for an intense, focused period.  Promotes participation by everyone.  Results available immediately Requirements

19. 19 Workshops: Plan and Execute Sell the workshop Establish team Handle logistics Send material Prepare agenda Facilitate Keep on track Record findings Summarize conclusions Synthesize findings Condense info Present to customer Plan next steps Pre-Workshop Production Follow-up Session

20. 20 Requirements workshops  Preparing  Selling concept  Right stakeholders  Logistics Room Lighting Equipment and facilities Travel Refreshments  Pre meeting materials Project specific Out of the box 1 to 2 weeks early

21. 21 Requirements workshops  Facilitator  Should be outsider (trained in the role)  Team only if: Trained in the process Has team/consensus building skills STRONG to control a meeting that can get heated Is well respected  Has no input into the workshop  A facilitator of a requirements workshop needs to be prepared for the following difficulties: Stakeholders know what they want but may not be able to articulate it. Stakeholders may not know what they want. Stakeholders think they know what they want until you give them what they said they wanted. Analysts think they understand user problems better than users. Everybody believes everybody else is politically motivated.  Responsibilities  Set the tone  Start and stop on time  Establish and enforce the rules  Introduce goals and agenda  Manage the meeting  Facilitate decision/consensus process  Manage logistics  Be sure all input  Handle disruptive behavior

22. 22 Preparation for the Workshop  Before the Workshop  The facilitator needs to "sell" the workshop to stakeholders that should attend, and to establish the group that will participate in the workshop. The attendees should be given "warm-up" material to review before they arrive. The facilitator is responsible for the logistics surrounding the workshop, such as sending out invitations, finding an appropriate room with the equipment needed for the session, as well as distributing an agenda for the workshop  Conduct the Session  The facilitator leads the session, which includes: Giving everyone an opportunity to speak. Keeping the session on track. Gathering input for applicable Requirement Attributes Recording the findings. Summarizing the session and working out conclusions.  Consolidate Results  After the requirements workshop, the facilitator (together with fellow system analysts) need to spend some time to synthesize the findings and condense the information into a presentable format.

23. 23 Tricks of the Trade  The table below lists a collection of problems and suggested solutions that could come in handy for the facilitator. The solutions are referring to a set of "tickets" that may sound unnecessary to have, but in most cases turn out to be very effective: ProblemSolution Hard to get restarted after breaks. Anyone who is late gets a "Late From Break" ticket, use a kitchen timer to catch peoples attention, use a charitable contribution box (say $1 for each ticket used). Pointed criticism - petty biases, turf wars, politics and cheap shots. "1 Free Cheap Shot" ticket, "That’s a Great Idea!!" ticket. Grandstanding, domineering positions, uneven input from participants. Use a trained facilitator, limit speaking time to a "Five Minute Position Statement". Energy low after lunch.Light lunches, breaks, coffee, soda, candies, cookies, rearrange room, change temperature.

24. 24 Requirements workshops  Conducting the workshop  Follow the agenda  Problems Gimmicks  Follow up  Documented Approval Further clarification

25. 25 Brainstorming  Helps find hidden “undiscovered” features/ needs  Usually part of a workshop – may start with a brainstorming session  Benefits  Encourages participation by all  Expand on ideas of others  No constraints  Broad set of possible solutions

26. 26 Brainstorming rules Rules No debate or criticism No bad ideas Use imagination Generate as many ideas as possible Build on others

27. 27 Brainstorming  Getting started  Facilitator states the objective of the session  As soon as the objective is met and there are no new ideas your done  Speak your idea, write it down  No criticism/ or comments on the ideas other than expansions  End  When your done  1 to 3 hours  Never force close

28. 28 Brainstorming  Generates as many ideas as possible. Rules for Brainstorming  Clearly state the objective of the session.  Generate as many ideas as possible.  Let your imagination soar.  Do not allow criticism or debate.  Combine ideas.

29. 29 Brainstorming Advantages and Disadvantages  Advantages  Used anytime, anywhere.  Good for groups.  Good for high-level entities and assumptions.  Amenable to some automation.  Disadvantages  Susceptible to group processes.  Unsystematic in “classic” form. Takeda et al. 1993

30. 30 Brainstorming  Prune Ideas down  Concurrence on validity  Further consideration yes/no  Group ideas  Related ideas are grouped into categories Pick your classes Reopen if grouping causes participants to want to add more  Feature definition  A definition agreed to by all is created to be sure everyone understands  Prioritize  Money or marbles  Critical/important/useful

31. 31 Idea Reduction: Prune and Organize Affinity Diagrams

32. 32 Idea Reduction: Prioritize Ideas  Prioritize remaining ideas.  Vote Cumulative votes  Buy ideas Single vote  Apply evaluation criteria Non-weighted Weighted

33. 33 Exercise Brainstorming  Gather ideas for stakeholder requests/needs.  Clarify and organize the ideas.  Condense ideas.  Prioritize remaining ideas.

34. 34 Considerations for Selecting Elicitation Techniques  Requirements Purpose  Specification for design and implementation.  Selecting off-the-shelf packages.  Legal contract for system procurement.  Knowledge Types  Different methods acquire different types of knowledge.  Internal Knowledge Filtering  Some knowledge can be retrieved from memory; whereas, other knowledge cannot.  Acquisition Context  Environment can influence elicitation techniques. WP6: ACRE: Selecting Methods for Requirements Acquisition Maiden N.A.M. & Rugg G., 1996

35. 35 Purpose Known COTS - Unknown COTS- System Procurement System Development Knowledge Type Behavior Process Data- Effectiveness of brainstorming for acquiring knowledge with different internal representations Future System Non-Tacit Recognized Taken-for-granted- Working memoryX Compiled Implicit- ObservableX Conditions for Method Use Meeting Needed Time to Prepare Time for Session Time to Obtain Number of Stakeholders Friendliness No Technologies LEGEND Good fit Very good fit X Weak fit - Poor fit Brainstorming Classification Example

36. 36 Requirements allocation  Complex systems  Divide and conquer rule Decompose into smaller more manageable sub-systems Done (divided small enough) when  Distribution and functionality are optimized/ min cost- max flexibility  Each sub-system lends itself to small team development  Can test the piece stand alone  Derived requirements  As we sub divide new “requirements” are generated  Usually “smell” different than user requirements  Interface Requirements  As we break apart we generate new “requirements” for communication

37. 37 Requirements Issues and recommendations  Issues  More “derived” requirements than original  Can lead to inflexible systems  Contracting services and sub contractors  Recommendations  Traceability Need Feature Sub system requirement  Partition and isolate Encapsulation Messaging vs data sharing

38. 38 Interviews  Provide a simple and direct technique.  Gain understanding of problems and solutions.  Consider all perspectives.  Users  Customers  Other stakeholders

39. 39 Interview Tips  Avoid asking 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!

40. 40 Gause & Weinberg, 1989 Context-Free Questions  Are high-level, abstract questions.  Explore needs from stakeholder perspective.  User’s problems.  Potential solutions.  Are always appropriate.  Unbiased with application or solutions knowledge.  Are typically posed early in a project.

41. 41 Gause & Weinberg, 1989 Types of Context-Free Questions  User questions  Who are the users?  What the key responsibilities of each user?  What is the user’s 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?

42. 42 Gause & Weinberg, 1989 Types of Context-Free Questions (cont.)  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?

43. 43 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?

44. 44 Typical Interview result

45. 45  1994 by Alan M. Davis Questionnaires  Give access to a wide audience.  Appear scientific because of statistical analysis.  Apply to broad markets where questions are well-defined.  Are powerful, but not a substitute for an interview.  Assumptions:  Relevant questions can be decided in advance.  Questions phrased so reader hears as intended.

46. 46 Observation/Contextual Interviews  Definition  Observe real user in the field.  Master-apprentice model: User explains his activities and answers questions.  Use real data in real situations.  Advantages  Deliver requirements from situated activities.  Probe inherent/tacit knowledge.  Issues  Experienced interviewer needs to keep focused on interview goals.  Expensive and time-consuming to analyse data.  Not always applicable to do in real situations. Beyer & Holtzblatt, 1997

47. 47 Shurtleff ‘94 Storyboard Benefits  Gathers and refines customer requirements in a user-friendly way.  Encourages creative and innovative solutions.  Encourages team review.  Prevents features that no one wants.  Implements features in an accessible and intuitive way.  Eases the interview process.  Avoids blank-page syndrome.

48. 48 Prototypes  Demonstrate some or all of the externally observable behaviors of a system.  Are used to:  Demonstrate understanding of the problem domain.  Gain feedback on proposed solution.  Validate known requirements.  Discover unknown requirements.  Create simulations.

49. 49 Why Use Prototypes?  Elicit and understand requirements.  Prove and understand technology.  Reduce risk.  Enhance shared understanding.  Improve  Cost and schedule estimates  Feature definition

50. 50 Eliciting Stakeholder Requests: Which Techniques to Use? Developer Experience Customer/User Experience Low Hi Low Hi “Fuzzy problem” “Catch Up” “Mature” “Selling/Teaching” Adapted from Alan Davis 1.Requirements Workshops 2.Brainstorming 3.Use Cases 4.Interviews 5.Questionnaires 6.Role Playing 7.Storyboarding 8.Prototyping 9.Requirement Reviews Which of these tools might you use for each quadrant of the graph?

51. 51 Eliciting Stakeholder Requests: Which Techniques to Use? Developer Experience Customer/User Experience Low Hi Low Hi “Fuzzy problem” 1, 2, 7 “Catch Up” 1, 3, 4, 7, 8, 9 “Mature” 1, 3, 4, 5, 6, 7, 8, 9 “Selling/Teaching” 1, 2, 3, 4, 5, 6, 7, 8. Adapted from Alan Davis 1.Requirements Workshops 2.Brainstorming 3.Use Cases 4.Interviews 5.Questionnaires 6.Role Playing 7.Storyboarding 8.Prototyping 9.Requirement Reviews Which of these tools might you use for each quadrant of the graph?

52. 52 Review: Understand Stakeholder Needs 1.What are some elicitation techniques for understanding user needs? 2.What is the relationship between a need and a feature when expressed by a stakeholder during Understand Stakeholder Needs? 3.What should you do with a need that is expressed as a feature? 4.What does the ACRE Framework say about requirements elicitation?

53. 53 System perspective

54. 54