5 2 I E E E S O F T W A R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 7 4 0 - 7 4 5 9 / 0 3 / $ 1 7 . 0 0 © 2 0 0 3 I E E E

There is plenty of hard and anecdotalevidence that the most critical factorfor your product’s success is yourstakeholders’ involvement in definingrequirements.1,2 Put another way, in-sufficient stakeholder involvement is

often cited as causing erroneousrequirements and project failure.

Why do we often fail to ex-ploit this rich resource? As alongtime requirements facilitatorand consultant, I think I know.Project stakeholders—those whoaffect or are affected by the soft-ware—have diverse and evenconflicting needs and viewpointsthat complicate the already slip-pery slope of discovery and ambi-

guity that often characterizes requirementsdevelopment. In other words, getting stake-holder input is hard, and we often don’tknow how to do it effectively.

A technique I’ve used many times in vari-ous industries and types of organizations isto hold collaborative workshops. You canuse workshops for many purposes—for ex-ample, to outline the project’s vision andscope, to create a release strategy or iteration

plan, or to define requirements in varyinglevels of detail. The beauty of this techniqueis that it creates an efficient, controlled, anddynamic setting where you can quickly elicit,prioritize, and agree on a set of high-qualityproject requirements.3,4 This column ex-plains a key aspect of collaborative require-ments workshops: identifying who shouldparticipate and outlining their roles.

Calling all stakeholdersThe first step is to make sure you’ve iden-

tified everyone who should participate indefining your requirements. It’s helpful tothink in terms of broad categories based onhow people relate to the software. Eachgroup’s members have different but valid per-spectives on both functional and nonfunc-tional requirements. Armed with the follow-ing list, you can plan ways to deal with thestrengths, weaknesses, needs, and questionsyour stakeholders will bring to the process.

Project sponsorThe project sponsor funds the project and

ensures that the resources are allocated. Thesponsor should ensure that the product meetsbusiness objectives and that the project is fin-

requirements

Requirements by Collaboration: Getting It Right the First TimeEllen Gottesdiener

E d i t o r : S u z a n n e R o b e r t s o n ■ T h e A t l a n t i c S y s t e m s G u i l d ■ s u z a n n e @ s y s t e m s g u i l d . c o m

We know that we must involve all the stakeholders if we want to discover a project’s re-quirements. But we need some guidelines on how to involve the right people and, givenhow busy everyone is, how to minimize the time and maximize the result. In this column,Ellen shares her considerable experience running requirements workshops. What are yourexperiences in running collaborative sessions? —Suzanne Robertson

M a r c h / A p r i l 2 0 0 3 I E E E S O F T W A R E 5 3

REQUIREMENTS

ished as quickly and cheaply as possi-ble. Typically, the sponsor understandsthe larger business goals but is notclose to the software’s details, nor doeshe or she fully understand technical is-sues and user concerns.

Product championThe product champion acts as an

ambassador user, ensuring that theneeds of various direct user communi-ties are met (you can have multiplechampions). His or her title might bebusiness manager, project manager, orproduct manager. The champion wantshis or her constituent group’s realneeds to be met and might not fully un-derstand other users’ needs. Also, thechampion might not have authority tosign off on the final requirements.

Direct usersDirect users are the people (or even

other software or hardware) whocome into direct contact with thesoftware. They want the product tomeet their real needs, such as simpli-fying or facilitating their jobs. Theymight not know or care about the“big picture”—how your project fitsinto the organization’s business strat-egy—but they have abundant interestin (and information about) the de-tails. At the same time, they might re-sist the change the project implies, in-cluding loss of their jobs.

Indirect usersIndirect users come in contact with

the system’s products or byproducts.They receive reports or files that thesoftware generates, or the software’sdecisions affect them. Like directusers, indirect users might not under-stand the big picture nor details suchas how data must be loaded andcleaned. They might not know howdirect users employ your system.

AdvisorsAdvisors don’t see or use the sys-

tem but might have relevant informa-tion, such as business rules and poli-cies. They might be involved in train-ing, support, or installation. Advisorsare often overlooked in requirementsefforts.

SuppliersSuppliers design and create the soft-

ware. They include developers, archi-tects, engineers, testers, QA specialists,and vendors. They understand existingsystems and the technical constraintsand possibilities, and they must under-stand the requirements early so theycan move quickly to design, test, code,and install. They might be blind tobusiness needs or enthralled by tech-nology. They might not understandusers’ needs.

How collaboration worksOne key to an effective collabora-

tive workshop is to systematically,resolutely—dare I say stubbornly—elicit and then resolve everyone’sconcerns.

Your requirements workshop willneed a facilitator to plan and lead the

work and a recorder to record theworkshop contents. Table 1 shows alist of specific workshop roles thatstakeholders might represent.

The workshop’s sponsor might bethe project sponsor or a productchampion. He or she might kick offthe workshop and return afterwardfor a “show-and-tell” (when theteam presents the deliverables). If thesponsor has rich domain knowledge,he or she might even participate,adding a lot of expertise if you’re,say, developing the requirements’scope and creating an iteration planfor a new product line.

Some subset of direct users willalso be workshop participants.Those new to their roles might beworkshop observers. In one work-shop I facilitated, the newly assignedbusiness analyst sat in to learn aboutthe new functionality the group wasdefining for an application she wouldsoon use daily. Advisors with experi-ence in the business domain mightalso participate. In other cases, anadvisor benefits from observing. Forexample, a product trainer observedone requirements workshop, whichgave him an early heads-up about thenew and revised requirements for thecompany’s flagship product.

Indirect users might also partici-pate. Business analysts often attendmy workshops because they need datafeeds from the application under de-velopment. Suppliers might observeand even help plan the workshop. Inmost workshops, we include develop-ers and IT analysts with deep applica-

Table 1

Requirements workshop rolesRole Responsibilities

Workshop sponsor Authorizes and legitimizes workshopFacilitator Plans and designs workshop

Recommends requirements deliverablesLeads process

Content participant Creates workshop productsRecorder Records the group’s workObserver Listens and learns On-call subject matter expert Is available to answer questions

One key to an effectivecollaborative workshop

is to systematically,resolutely—dare I saystubbornly—elicit and

then resolve everyone’s concerns.

5 4 I E E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e

REQUIREMENTS

tion knowledge as full participants.Some organizations train and mentoranalysts or project managers to beworkshop facilitators if they can beneutral to the workshop outcome.

Working the workshopStructure the workshop around a

set of agreed-upon deliverables. Forexample, if your workshop’s goal isto create a document describing theproject vision or charter, you mightplan to deliver a list of features, aproposed sponsorship organizationchart, or a product vision statement.If you’re looking for scope or high-level requirements, you’ll deliver acontext diagram, a conceptual do-main model, or a set of high-level use

cases. If you’re defining detailed re-quirements, you’ll deliver statecharts,business rules, detailed use casesteps, prototype screens, and so on.A workshop planning team partici-pant or the facilitator briefly explainseach deliverable; the facilitator leadsthe group through the process andsees that everyone agrees on the finalproduct.

It’s crucial to work iteratively. Youexplain everyone’s role ahead of timeand assign “prework” based on indi-vidual roles; you also plan to completecertain tasks (“post-work”) after theworkshop. That way, everyone is fo-cused on collaboration, which acceler-ates the time the group is together.During the workshop, you create your

deliverables step by step. You can usevarious techniques based on well-known rules of group dynamics, suchas the iterative process referred to as“forming, storming, norming, per-forming, and adjourning.”5 Table 2describes how the workshop facilita-tor makes the process work smoothlyfor each stage.

FormingForming involves orienting the

group and explaining various options.The group is just coming together andfeeling each other out, so the membersproduce few measurable results.However, they do identify tasks, es-tablish ground rules, socially relate,give advice, and evaluate each other.

StormingDuring storming, group members

challenge each other’s roles and dis-pute and debate the process. Conflictand diverse opinions emerge alongwith role confusion, rebelling, andconcerns about team and individualresponsibilities. Overt and coverthostility, power struggles, rebellious-ness, and attacks on participants orthe facilitator can occur.

NormingNorming involves group members

understanding and supporting eachother’s viewpoints and dialogingabout the project. Conflict subsides,and the group becomes cohesive;members begin to interact and createproducts. Tolerance increases as har-mony develops. Conflict is avoidedand mutual support, trust, and com-munication increase.

PerformingDuring performing, acting as a

team becomes the norm, and mem-bers quickly define and solve prob-lems. Solutions emerge; requirementsbecome more detailed and easier toprioritize. Creative problem solvingand collaboration occur as membersgain insight into their perspectivesand effective group interactions.

AdjourningThe group ends its work during

Table 2

Forming, storming, norming, performing, and adjourningStage Workshop facilitator actions

Forming Kick off workshop with sponsorUse ice-breakersFocus on ground rules and deliverablesModel desired behaviorProvide direction for group activitiesGive participants simple tasks to completeBuild in awareness mini-training or awareness presentations

Storming Stay calm and neutralCapture issues and concernsApply and enforce the agreed-upon ground rulesAcknowledge and address conflictInvite input and feedbackMirror or paraphrase disputesProvide observations of “storming” to the group

Norming Back off on structure and explicit directionsAllow adjustments to the processEnsure even distribution of work, contribution, and discussionActively seek feedback on the processGive participants more complex tasksReinforce positive behavior

Performing Provide all information requestedInject celebration frequentlyRotate roles in small group activitiesAllow members to volunteer for workshop tasks and follow-upBack off and challenge the group to figure things out

Adjourning Explicitly conduct a workshop debriefAllow sufficient time to adjournPromote appreciative inquiry, allowing members to review effective behaviors

and actionsUse rituals from project retrospectives6

M a r c h / A p r i l 2 0 0 3 I E E E S O F T W A R E 5 5

REQUIREMENTS

adjourning, wrapping up and reach-ing closure. This transition phaseshould not be ignored or glossed overbecause individuals can harvest theirmost important lessons from thisstage, learning what they can bringto other projects and groups.

Workshop timingHow long should a collaborative

workshop take? It can be as short astwo or three hours if the group hasgathered before and had time to“form” and “storm.” Or you canhold workshops over several days.The key is to allow enough time forthe team to reach closure on a subsetof important deliverables.

The best plan is to schedule con-tiguous hours in a short time (days, orat most several weeks). One group Iworked with arrived at their scope ina one-day workshop, then held fourmore short sessions to complete theirrequirements in almost four weeks.Another team was more efficient.They drafted some requirements asprework and then allotted two fulldays for the workshop. They reachedclosure on all their high-priority usecases, including details around busi-ness rules and interfaces. It took lessthan two weeks to complete their re-quirements.

The case for collaborationRequirements workshops appeal

to business people, developers, andmanagers alike. Business peoplewant to be heard by IT, and theywant enough technical perspectiveto make good techno-business deci-sions. Developers want stable, clear,and correct requirements that re-flect users’ real needs, and they alsoneed to better understand and ap-preciate the business domain andthe big picture. Management wantsto minimize conflict, speed up theproject, and get a quality productdelivered. All these audiences canfind workshops useful in the searchfor excellent requirements.

Having the right participants—theright stakeholders present—is key toyour workshop’s success. Littlethings also go a long way, such as

participants sharing the same physi-cal space, working hands-on with avariety of tools (text and visual), anddisplaying the group’s work on walls(see Figure 1). A skilled facilitatorstacks the deck for success by

■ Helping plan prework that jump-starts group activities

■ Making sure activities follow alogical structure

■ Promoting high group productivityby using “serious play” throughoutthe workshop

W ell-run workshops deliver high-quality requirements, fast. Just asimportant, a collaborative work-

shop builds and nurtures a healthyproject community, not only for re-quirements but also for the whole de-velopment process.

References 1. S. McConnell, Rapid Development: Taming

Wild Software Schedules, Microsoft Press,Redmond, Wash., 1996.

2. Standish Group Int’l, “Chaos: A Recipe forSuccess,” https://secure.standishgroup.com/reports/reports.php?rid=1.

3. E. Gottesdiener, Requirements by Collabora-tion: Workshops for Defining Needs, Addison-Wesley, Boston, 2002.

4. J. Wood and D. Silver, Joint Application De-velopment, John Wiley & Sons, New York,1995.

5. W. Tuckman and M.A. Jensen, “Stages ofSmall Group Development Revisited,” Groupand Organizational Studies, vol. 2, no. 4,1977, pp. 419–427.

6. N. Kerth, Project Retrospectives: A Hand-book for Team Reviews, Dorset House Pub-lishing, New York, 2001.

Ellen Gottesdiener is a Certified Professional Facilita-tor and the principal consultant at EBG Consulting, where sheworks with business and IT project teams to help them explorerequirements, shape their development processes, and collabora-tively plan their work. Contact her at ellen@ebgconsulting.com;www.ebgconsulting.com.

A collaborativeworkshop builds andnurtures a healthyproject community,

not only forrequirements but also for the whole

development process.

Figure 1. Participants in a requirements workshop working on wallsin shared space. They are using various modes (individual, smallgroup, and whole group) and media.