Text Layout

1. Text Layout • Introduction (1-4) • Team Skill 1 – Analyzing the problem (5-7) • Team Skill 2 – Understanding User and Stakeholder Needs (8-13) • Team Skill 3 – Defining the System (14-17) • Team Skill 4 – Managing Scope (18-19) • Team Skill 5 – Refining the System Definition ( 20-24) • Team Skill 6 – Building the Right System (25-31)

2. The Challenge of Requirements Elicitation Chapter 8

3. Barriers to Elicitation – “Yes, But” Syndrome • When showing a new system to a user, the reaction is often, “This is so cool, But, now that I see it, what about…?” • Users reactions are simply human nature, they haven’t seen your system before and didn’t understand what you described earlier • This is an integral part of application development and we should plan for it • Get the “Buts” out early, elicit the “Yes, But” response early, and then invest majority of development efforts in software that has already passed this test

4. Barriers to Elicitation – “Undiscovered Ruins” Syndrome • The search for requirements is like the search for undiscovered ruins • The more you find, the more you know remain • Unknown unknowns • Nonuser stakeholders are often holders of otherwise undiscovered requirements • For an iterative or spiral lifecycle, take the approach of “We have discovered enough for now; we’ll find the rest later

5. Barriers to Elicitation – “User and the Developer” Syndrome • Communications gap between the user and the developer

6. Key Points • Requirements elicitation is complicated by three endemic syndromes • The “Yes, But” syndrome stems from human nature and the users’ inability to experience the software as they might a physical device • Searching for requirements is like searching for “Undiscovered Ruins”; the more you find, the more you know remain • The “User and the Developer” syndrome reflects the profound differences between these two, making communication difficult

7. The Features of a Product or System Chapter 9

8. Stakeholder and User Needs • Definition: a reflection of the business, personal, or operational problem (or opportunity) that must be addressed in order to justify consideration, purchase, or use of a new system • Examples: • I need easier ways to understand the status of my inventory • I’d like to see a big increase in the productivity of sales order entry

9. Problem Domain & Solution Domain Needs – in user terms Problem Domain Features – a service provided by the system that fulfills a need Software requirements – more specific Solution Domain

10. Features • Definition: a service the system provides to fulfill one or more stakeholder needs • Sometimes in talking to users, they will discuss features not needs and can be hard to distinguish between them • Features are a convenient way to describe the functionality without getting bogged down in detail • Features are at a high level of abstraction

11. Examples of Features

12. Managing Complexity • Limit features to somewhere between 25-99 to avoid getting in the details • Add attributes to the features to track additional information • Example attributes: • Name or Unique identifier • Sponsor • History data • Allocated from • Traced to • Priority

13. Key Points • The development team must play a more active role in eliciting the requirements for the system • Product or system features are high-level expressions of desired system behavior • System features should be limited to 25-99, with fewer than 50 preferred • Attributes provide additional information about a feature

14. Interviewing Chapter 10

15. Interviewing • A simple, direct technique that can be used in virtually every situation • Goal – make sure that the biases and predisposition of the interviewer do not interfere with the free exchange of information • Sociology teaches us that it is extremely difficult to truly understand others because we each of us is biased by our own conceptual filter

16. Questions • Context-Free Questions • Questions asking about the nature of the problem without context • Context-free questions force us to listen before attempting to invent or describe a potential solution • Helps us learn about the user • Examples • Who is the user? • Who is the customer? • Are their needs different? • Where else can a solution to this problem be found? • Solutions-Context Questions • After context-free questions, then move to exploring the solution • Template on page 104 of text

17. The Interview • Tips for a successful interview • Prepare an appropriate context-free interview • If appropriate, prepare solution-context questions • Before the interview, research the background of the stakeholder, try to eliminate questions • Record the answers • Refer to the template to be sure you covered all the material • Allow the stakeholder to go off course, you may gain additional information • End interview with a summary key user needs discovered • Record the top needs after each interview and record how many stakeholders mentioned that need • Never do a questionnaire – too impersonal

18. HOLIS Case Study • 15 interviews identified about 20 needs • Homeowner’s perspective • Flexible and modifiable lighting control for entire house • “Futureproof” (As technology changes, I’d like compatibility with new technologies that might emerge.”) • Attractive, unobtrusive, ergonomic • Fully independent and programmable or reconfigurable switches for each room in the house • Additional security and peace of mind • Intuitive operations • A reasonable system cost, with low switch costs • Easy and inexpensive to fix • Flexible switch configuration (from 1 to 7 button per switch • Out of sight, out of mind • 100% reliability

19. HOLIS Case Study Homeowner’s perspective (cont.) • Vacation security settings • Ability to create scenes, such as special housewide lighting settings for a party • No increase in electrical or fire hazards in the home • Ability, after a power failure, to restore the lights the way they were • Programmable by the homeowner, using an existing PC • Dimmers whereever the homeowner wants them • Programmable by the homeowner, without using a PC • Programmable by somebody else, so the homeowner doesn’t have to do it • Ability to turn on some lights maually if the systems fails • Interfaces to the home security system • Interfaces to other home automation (HVAC, audio/video, etc.)

20. HOLIS Case Study Distributor’s perspective • A competitive product offering • Some strong product differentiation • An easy way to train salespeople • Ability to demonstrate the system in the shop • High gross margins

21. Key Points • Interviewing is a simple and direct technique that can be used in most circumstances • Context-free questions can help achieve bias-free interviews • It may be appropriate to search for undiscovered requirements by exploring solutions • Convergence on some common needs will initiate a “requirements repository” for use during the project • A questionnaire is no substitute for an interview

22. Requirements Workshop Chapter 11

23. Requirements Workshop • Key stakeholders of the project gather together for a short, intensive period • Benefits • It assists in building an effective team, committed to one common purpose: the success of this project • All stakeholders get their say; no one is left out • It forges an agreement between the stakeholders and the development team as to what the application must do • It can expose and resolve political issues that are interfering with project success • The output, a preliminary system definition at the feature level, is available immediately

24. Preparing for the Workshop • Selling the concept • Ensuring participation of the right stakeholders • Use the initial list from the problem analysis steps • Attending to Logistics • Send a proper invitation and ensure travel is easy • Providing warm-up materials • Project specific information • Out-of-the-box thinking articles • Choosing the facilitator • Prefer and outsider • Facilitator can not contribute to ideas and issues • Set the agenda

25. Problems and Solutions in Requirements Workshop

26. Key Points • Te requirements workshops may be the most powerful technique for eliciting requirements • It gathers all key stakeholders together for a short but intensely focused period • The use of an outside facilitator experienced in requirements management can help ensure the success of the workshop • Brainstorming is the most important part of the workshop

27. Brainstorming and Idea Reduction Chapter 12

28. Live Brainstorming • Stakeholders gather in one room with an objective • Rules • No not allow criticism or debate • Let your imagination soar • Generate as many ideas as possible • Mutate and combine ideas • Write down ideas and say them out loud to encourage piggybacking of ideas • Encourage participation with “Great Idea” rewards

29. Idea Reduction • Pruning ideas • Eliminating those that all agree are not worth further investigation • Grouping ideas • Name groups of similar ideas • Defining features • Write a short description of each feature • Prioritizing ideas • Cumulative Voting: The hundred dollar test • Each person gets $100 dollars to spend on each feature • Only works once; as voters will be biased the second time • Critical, important, useful categorization • Each voter gets same number of votes as features and one third are critical, one third are important and one third are useful • Facilitator multiplies critical votes by 9, important votes by 3

30. Case Study – HOLIS – Attendees at a Requirements Workshop

31. Analysis of Results • “Built-in security” appeared high on the priority list • Competitive differentiator • Became a defining feature • Internationalized user interface • International distributor said with out this feature, it would not be introduced in Europe • Features by priority on page 130

32. Key Points • Brainstorming involves both idea generation and idea reduction • The most creative, innovative ideas often results from combining multiple, seemingly unrelated ideas • Various voting techniques may be used to prioritize the ideas created • Although live brainstorming is preferred, Web-based brainstorming may be a viable alternative in some situations

33. Storyboarding Chapter 13

34. Storyboarding • Purpose: Gain an early reaction from the users on the concepts proposed for the application • Inexpensive • User friendly, informal and interactive • Provides an early review of user interfaces • Easy to create and easy to modify

35. Types of Storyboarding • Passive • Sketches, pictures, screen shots, etc. • Analyst plays role of system and walks the user through the story board • Active • A movie that hasn’t actually been produced yet • Animated and automated • Provides an automated description of the way the system behaves in a typical usage • Interactive • Lets the user experience the system in as realistic a manner as practical • Requires participation by the user • Can be close to a throwaway prototype

36. Storyboards • Tools • Macromedia’s Director or Cinemation from Vividus Corp. • Tips • Don’t invest too much • Make it easy to modify • Don’t make it too functional • Make it interactive if possible

37. Key Points • The purpose of storyboarding is to elicit “Yes, but” reactions • Storyboards can be passive, active, or interactive • Storyboards identify the players, explain what happens to them, and describes how it happens • Make the storyboard sketchy, easy to modify, and not shippable • Storyboard early and often on each project with new or innovative content