Small-group approaches to requirements determination

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

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

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

4. Brainstorming for desired features • Goal: produce many ideas quickly • Application to reqts: identifying features or alternative automation strategies • Golden rules • Produce lots of ideas, minimize discussion • 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. Brainstorming procedure • Select group carefully • 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 • Phase II: Synthesis • Cluster similar ideas and combine • Rank and select ideas (e.g. using weighted voting)

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

7. Brainstorming: Where to find out more • 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. Issue tracking • 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?” • Questions can be addressed to all stakeholders • Customer, actors, owner (in SSM terms) • May be answered by them or on their behalf

9. Keeping track of actions is standard 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 Issues and actions in meeting minutes For example... 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?

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

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

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

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

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) • 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. The Inquiry Cycle (2) • Answering the question should lead to a revision of the artifact Question: How much of one’s schedule can a co-worker know? 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... ... Decision: Only whether one is free This decision record represents the rationale for the new reqt.

16. Team exercise: Issue tracking • 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 • As a class, discuss what insights arise

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

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

19. Roles Executive sponsor JAD leader Scribe Support person Full-time user participants Full-time MIS participants Users on call Observers 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 Assembling a JAD team

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

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

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

23. Team exercise: JAD planning • 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 • Discuss the activity as a class

24. JAD: how to find out more • 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. Cooperative requirements capture (CRC) • 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 • More information: • Macaulay’s book

26. Participatory design (PD) • In PD, user representatives are members of design team • Unlike JAD, participation continues throughout project • Origins in Scandinavia • 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. Future Workshops in PD • Preparation • Designers become users’ apprentices • 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 • Build prototype

28. Envisionment through scenarios • Scenarios are descriptions of actual or imagined sequences of events

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

30. Tabular representation of scenarios time

31. Scenarios as stories • 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 • Like folktales/myths, named scenarios persist • E.g. later on the team might ask “how would this work with Joe’s meeting?”

32. Team exercise: Scenario invention & analysis • 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. Scenarios: how to find out more • Book • Carroll: Scenario-Based Design • Articles • Special section in ACM SIGCHI • Potts et al Inquiry Cycle article

34. The importance of facilitation • 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 • Facilitation requires practice & experience

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