1 / 16

G&W Chapter 7: Getting the Right People Involved Software Specification Lecture 14

G&W Chapter 7: Getting the Right People Involved Software Specification Lecture 14. Prepared by Stephen M. Thebaut, Ph.D. University of Florida. Relevant Context-Free Questions.

hallmichele
Download Presentation

G&W Chapter 7: Getting the Right People Involved Software Specification Lecture 14

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. G&W Chapter 7: Getting the Right People Involved Software SpecificationLecture 14 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

  2. Relevant Context-Free Questions Perhaps the single most common mistake in development efforts is to leave an essential person out of the process. Thus, several of G&W’s context-free questions focus on identifying people whose input will be useful: • Who is the customer / client? • Who should be on the team? • What problems does this product solve (that is, for whom)? • Are you the right person to ask these questions? Software Specification: G&W Chapter 7

  3. Customers / Clients vs. Users • Customers / Clientspay for the requirements work. • A user is any individual who is affected by, or affects the product being designed. Therefore, every customer is a user, but not every user is a customer. Software Specification: G&W Chapter 7

  4. Then why include non-client “users” in requirements work? • When the product is put into use, the users are the people who will make or break the product. • Potential users who feel they have been excluded from the process will feelno commitment to give the product a fair evaluation. Software Specification: G&W Chapter 7

  5. But Identifying Potential Users Can be Difficult… • Consider the Railroad Paradox: • A proposal to establish a new stop on a train schedule is under consideration. • Analysts visit the proposed location at the designated time but find no one waiting to catch the train. • Since there is “obviously” no demand for the new stop, the idea is dropped. Software Specification: G&W Chapter 7

  6. But Identifying Potential Users Can be Difficult… (cont’d) • Similarly, when an (existing) product doesn’t meet the needs of some, they may not be identified as potential users of a better product. As a result, they aren’t consulted, and the product stays bad. Software Specification: G&W Chapter 7

  7. Products Can Unintentionally Create New Users • Railroad Paradox also suggests that products can actually create new user constituencies. • Consider the 55 mph speed limit. • It was created to save fuel – something safety advocates didn’t care about. • But when traffic fatalities began to fall, they became strong supporters. Software Specification: G&W Chapter 7

  8. Products Can Unintentionally Create New Users (cont’d) • Consider the introduction of new tax laws designed to benefit a special interest group. • Unintended Winners: tax attorneys, accountants, and tax return preparation businesses / product developers • Unintended Losers: tax payers NOT in the special interest group Software Specification: G&W Chapter 7

  9. Products Can Unintentionally Create New Users (cont’d) • Pareto(“change should leave some people better off and no people worse off”)was a dreamer. • Veblen(“every change adversely affects some and benefits others”)was a realist. Software Specification: G&W Chapter 7

  10. Losers are Users, Too • “User-Friendliness” is highly touted today, but you may want to intentionally treat some users in an unfriendly way. Examples? • It may even be desirable to hide the existence of a product from some user groups. Examples? Software Specification: G&W Chapter 7

  11. G&W’s User-Inclusion Heuristic • Brainstorm a list of potential users. • Identify different constituencies or categories. • This can lead to highly innovative features and functions. • Classify each as friendly, unfriendly, or ones to ignore, according to how the design is to treat them. Software Specification: G&W Chapter 7

  12. G&W’s User-Inclusion Heuristic (cont’d) • Develop a strategy for dealing with each user group you don’t want to ignore using the three dimensions of participation: • Who: will representation be by surrogate,sample,orexhaustive? • When: will participation be continuousor only atdiscrete intervals? • How: will information be based on experience / perception, and/orexperimentation? Software Specification: G&W Chapter 7

  13. G&W’s User-Inclusion Heuristic (cont’d) • Use your imagination and tact in carrying out the inclusion plan to get full participation. • Consider how each user – including all “friendlies” and “unfriendlies” – is to be handled. • Consider using a broadcasting technique for capturing users – you might tweak the interest of someone in a group you overlooked! Software Specification: G&W Chapter 7

  14. Some Other Nuggets • To avoid dealing with criminals, some organizations sponsor legitimate competitions inviting people to try breaking through their security systems. • A powerful surrogate method is… “participant observation.” (analysts work alongside users for a time) • Whenever you hear, “Nobody could possibly be hurt by this product,” immediately initiate a “loser identification” brainstorm. Software Specification: G&W Chapter 7

  15. Group Exercise Apply steps 1 and 2 of G&W’s User-Inclusion Heuristic to the design of an on-line course evaluation system. Software Specification: G&W Chapter 7

  16. G&W Chapter 7: Getting the Right People Involved Software SpecificationLecture 14 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

More Related