© colin potts b2-1 small-group approaches to requirements determination colin potts georgia tech

© Colin Potts B2-1

Small-group approaches to requirements determination

Colin Potts

Georgia Tech

© Colin Potts B2-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

© Colin Potts B2-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

© Colin Potts B2-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

© Colin Potts B2-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)

© Colin Potts B2-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

© Colin Potts B2-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

© Colin Potts B2-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

© Colin Potts B2-9

Issues and actions in meeting minutes

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

It was decided to base the meeting scheduler on a shared calendar.

Action: Frank to sketch 1st-cut schemaIssue: How much of one’sschedule can a co-workerknow?

For example...

© Colin Potts B2-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


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

+

+

-


QOC: Design space analysis

Similar to IBIS, but uses explicit criteria 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


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


1.1 The system shall blah, blah...1.2 If the co-worker is blah, blah, thesystem 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


This questionannotates aspecific reqt.


The Inquiry Cycle (2)

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, thesystem 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 recordrepresents the rationalefor the new reqt.


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


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


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


Assembling a JAD team

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


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


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


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


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


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


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


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”


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


Envisionment through scenarios

Scenarios are descriptions of actual or imagined sequences of events

Scenarios Specifications

Concrete Abstract

Representative orsalient examples

Exhaustivecoverage ofpossibilities

Specific General

To illustrate withcompelling examples

To definethoroughly andunambiguously


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?


Tabular representation of scenarios

Role Action

Initiator Call mtg

Scheduler Send msgs to all invitees

Typical invitee Read msg

Typical invitee Consult personal schedule

Typical invitee Respond with desired times

Scheduler Collate desired times

Scheduler Select best time

Scheduler Notify invitees and initiator of mtg time

time


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?”


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.


Scenarios: how to find out more

Book» Carroll: Scenario-Based Design

Articles» Special section in ACM SIGCHI» Potts et al Inquiry Cycle article


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


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

© colin potts b2-1 small-group approaches to requirements determination colin potts georgia tech

Documents