1. © Colin Potts B2-1 Small-group approaches to requirements determination Colin Potts Georgia Tech

2. © Colin Potts B2-2 The role of group work in requirements l Multiple stakeholders & perspectives »Need for consensus-building procedures l Unstructured & ill-understood problems »Need for methods for recording & keeping track of unstructured information l Planned change »Need for facilitation & participation l All of these are small-group issues

3. © Colin Potts B2-3 Overview: small group techniques l Brainstorming »Proposal & evaluation of new ideas through facilitated meeting practices l Issue tracking »Keeping track of loose ends through systematic note-taking l Joint Application Design (JAD) »Reaching consensus on new system requirements through workshop discussion

4. © Colin Potts B2-4 Brainstorming for desired features l Goal: produce many ideas quickly »Application to reqts: identifying features or alternative automation strategies l Golden rules »Produce lots of ideas, minimize discussion l Benefits »Rapid creation of team approach & shared appreciation of ramifications »Most applicable to product design or situations where the customer has very vague requirements

5. © Colin Potts B2-5 Brainstorming procedure l Select group carefully l Phase I: Divergence (brainstorming proper) »Generate as many ideas as possible in fixed period »Record all ideas on shared writing space »Build on or combine previously posted ideas, but don’t discuss or criticize l Phase II: Synthesis »Cluster similar ideas and combine »Rank and select ideas (e.g. using weighted voting)

6. © Colin Potts B2-6 Class exercise: Brainstorming l Take the requirements document & imagine you are starting the project that wrote it l Using brainstorming, identify 50 desirable product features in 10 minutes l Discuss how to collate/combine the features l Vote on priorities of the remainder »You can vote for 20 features »Features with 10% vote are retained l Discuss the quality of the resulting product

7. © Colin Potts B2-7 Brainstorming: Where to find out more l Brainstorming, and team-based idea generation methods like it are summarized in a number of books: »Jones: Design Methods »Scholtes: The Team Handbook »Gause & Weinberg: Exploring Requirements

8. © Colin Potts B2-8 Issue tracking l Design and planning answer questions »“Is” questions –“What do you do in the library?” –“What exactly is a patron ‘in good standing’”? »“Ought” questions –“How do you want this information to be communicated?” –“Is this feature more important to you than that?” l Questions can be addressed to all stakeholders »Customer, actors, owner (in SSM terms) »May be answered by them or on their behalf

9. © Colin Potts B2-9 Issues and actions in meeting minutes l Keeping track of actions is standard l Can also keep track of open issues »Some of these are actions, if one person has responsibility to resolve –But others are more open-ended & just need to be remembered It was decided to base the meeting scheduler on a shared calendar. Action: Frank to sketch 1st-cut schema Issue: How much of one’s schedule can a co-worker know? For example...

10. © Colin Potts B2-10 IBIS: Issue-based information systems l Structured method for keeping track of issues, positions and arguments »Originated in architecture & urban planning l Issue »An open question about which there are likely to be opposing points of view l Position »A response to an issue by a stakeholder l Argument »A reason put forward by a stakeholder for choosing or rejecting a position

11. © Colin Potts B2-11 Example IBIS graph Issue: How much of one’s schedule can a co-worker know? Position: Only whether one is free Position: All details of appointments Argument: Important to retain privacy Argument: We have no secrets here Argument: Information may be useful in scheduling + + -

12. © Colin Potts B2-12 QOC: Design space analysis l Similar to IBIS, but uses explicit criteria l Compare: Question: How much of one’s schedule can a co-worker know? Option: Only whether one is free Option: All details of appointments Criterion: Privacy Criterion: Compatibility with corporate culture Criteria: Spin-off benefits + + - + - 0

13. © Colin Potts B2-13 Experiences with issue tracking l NCR has used IBIS for restaurant IS design l Design Space Analysis has been used to record design rationale for interactive systems at Xerox »See Moran & Carroll book for more information l In practice, the ideas are watered down

14. © Colin Potts B2-14 1.1 The system shall blah, blah... 1.2 If the co-worker is blah, blah, the system shall inform the user... 1.2.1 Blah, blah, blah...... The Inquiry Cycle (1) l Insight: Questions are always prompted by something »Attach questions to the document fragments that gave rise to them Question: How much of one’s schedule can a co-worker know? This question annotates a specific reqt.

15. © Colin Potts B2-15 The Inquiry Cycle (2) l Answering the question should lead to a revision of the artifact 1.1 The system shall blah, blah... 1.2 If the co-worker is blah, blah, the system shall inform the user only that the co-worker is busy... 1.2.1 Blah, blah, blah...... Question: How much of one’s schedule can a co-worker know? Decision: Only whether one is free This decision record represents the rationale for the new reqt.

16. © Colin Potts B2-16 Team exercise: Issue tracking l Take a requirements document and review it in an issue-based way. »Attach several issues to the document at specific places »Propose more than one position in response to each issue »Either list arguments for or against the positions, or list criteria that the positions contribute to or detract from l As a class, discuss what insights arise

17. © Colin Potts B2-17 Issue tracking: how to find out more l IBIS and Design Space Analysis: »A good anthology of articles –Moran & Carroll: Design Rationale l Inquiry Cycle »Introductory article –Potts et al: Inquiry-Based Requirements Analysis

18. © Colin Potts B2-18 Joint application design (JAD) l Structured approach to setting scope for system using facilitated workshop »3-10 day JAD session »“Session leader” facilitates »IBM developed JAD in commercial sector l Three phases (1) Preparation (2) The session (3-10 days) (3) Feedback

19. © Colin Potts B2-19 Assembling a JAD team l Roles »Executive sponsor »JAD leader »Scribe »Support person »Full-time user participants »Full-time MIS participants »Users on call »Observers l Guidelines »Full-time attendance is mandatory –minimize distractions »8-15 participants –Everyone is equal »2-3 users for every MIS participant »Participants must have representative knowledge & authority »Mgt. commitment is essential

20. © Colin Potts B2-20 Preparation for JAD l Project definition »Identify open issues & interview mgt. »Select team & schedule session l Research »Familiarize with system & document workflow »Gather preliminary specifications l Session preparation »Preparing working document »Pre-session meeting

21. © Colin Potts B2-21 The JAD session l Typical agenda: (1) Review assumptions (2) Review current workflow & determine new one (3) Define data elements, screens & reports (4) Record & resolve open issues l Making decisions »Failing consensus, use weighted criteria (cf. QOC) l Open issues »Assign responsibility & deadline to resolve

22. © Colin Potts B2-22 After the JAD session l Making the working document authoritative »Incorporate all decisions & issue for approval »Session members review for clarity & accuracy –but not for content l Approval of the document »Important to have authorizing managers (user & MIS) sign off l Post-JAD changes »Working document should be living document

23. © Colin Potts B2-23 Team exercise: JAD planning l Imagine you are planning a JAD for the example system. In teams of 2-3: »Identify who should attend the JAD –name names if possible »Estimate duration of JAD session »Identify sources & types of information during research phase »Record some open issues l Discuss the activity as a class

24. © Colin Potts B2-24 JAD: how to find out more l The best book on JAD is »Wood, J. & Silver, D. Joint Application Design, Wiley, 1989 »It describes the JAD process in detail, giving advice on what to do »It also gives advice on more generic meeting facilitation challenges

25. © Colin Potts B2-25 Cooperative requirements capture (CRC) l A JAD-like process »Smaller group (6-9) »Same research-then-improve structure »Two 2-day meetings –Understand business problem –Propose improvements »Uses many sheets/forms to record current/future issues l More information: »Macaulay’s book

26. © Colin Potts B2-26 Participatory design (PD) l In PD, user representatives are members of design team »Unlike JAD, participation continues throughout project »Origins in Scandinavia l Emphasis on representation of system using mock-ups and low-fidelity prototypes »Less emphasis than JAD on documentation »PD often uses JAD-like “future workshops”

27. © Colin Potts B2-27 Future Workshops in PD l Preparation »Designers become users’ apprentices l Future workshop »Fantasy phase –Brainstorming & weighted voting about future HAS –Metaphors (e.g. library as a warehouse) –Write ‘utopian outline’ »Implementation phase –Prepare common strategy based on utopian outline l Build prototype

28. © Colin Potts B2-28 Envisionment through scenarios l Scenarios are descriptions of actual or imagined sequences of events

29. © Colin Potts B2-29 Dimensions of scenarios l Concreteness »Can the scenario branch or not? l Detail »e.g. “the patron borrows a book” or “the patron presents a book and card, the librarian swipes the card, and...” l Instantiation »e.g. “Diane borrows ‘War and Peace’” l Representation »Narratives, interaction diagrams, rich pictures, etc. l Mood »Does it describe current or desired system?

30. © Colin Potts B2-30 Tabular representation of scenarios time

31. © Colin Potts B2-31 Scenarios as stories l Q: How do we select the “right” scenarios to explore? »A: They tell interesting stories about the system –e.g. normal cases, interesting exceptions & combinations l Like folktales/myths, named scenarios persist »E.g. later on the team might ask “how would this work with Joe’s meeting?”

32. © Colin Potts B2-32 Team exercise: Scenario invention & analysis l For the example system »As a class: –Brainstorm some scenario names –Pick one for further analysis »In teams of 2-3: –Describe scenario at high level in table –Re-do it in more detail »As a class: –Discuss any insights about the reqts.

33. © Colin Potts B2-33 Scenarios: how to find out more l Book »Carroll: Scenario-Based Design l Articles »Special section in ACM SIGCHI »Potts et al Inquiry Cycle article

34. © Colin Potts B2-34 The importance of facilitation l In all these methods, effective facilitation of the group is essential »Precise structure of the activities is less important than ability to work together & converge »Activities best done in meetings, not through email or memos l Facilitation requires practice & experience

35. © Colin Potts B2-35 Small group approaches: conclusions l Goal: »Have key stakeholders converge on vision of future system & agree on essential details l Differences: »Degree & duration of user involvement »Structure of activities vs. structure of process l Key requirements: »Time and commitment of mgt. & participants »Good facilitation & preparation