top of page

Run a Requirements Workshop — Requirements Engineering, Part 6

  • Shawn West
  • Jul 28
  • 8 min read

Updated: Aug 17

Requirements Engineering · Part 6

Some requirements can't be elicited one person at a time, because no single person holds them. They live in the seam between departments, and the only way to reach them is to put the departments in one room and let them collide.

This tutorial runs that session. For why fragmentation needs a different instrument than an interview, see requirements elicitation techniques that work; for resolving the collisions it produces, handling conflicting requirements. This is the two hours.

Illustrative composite continuing the support-tooling example from Parts 1–5. Figures are illustrative, not measured.

Before You Start

  • The use case, already written. Process a Refund Request from Parts 1–5, with alternate flows A1/A2/A3 and exception flows E1/E2. A workshop labels and resolves requirements; it does not discover the process. If the flows aren't written, run the elicitation first.

  • Part 4's traceability matrix, open and editable. REQ-001, 004, 005, 006, 007 and 008 are your starting inventory. Anything the room decides lands here in Step 9, not in a notebook.

  • Five to eight named seats, each with a named constraint. Including the two that collide in this session: finance, who owns the processing fee, and Dana, the support lead, who owns what the customer actually says. Confirm both by name before you book the room.

  • A facilitator with no stake in the outcome. If the only candidate is you and you want a particular ordering rule, hand the decision to someone else or hand away the facilitation. Not both seats.

  • Two uninterrupted hours in a single block, plus 30 minutes to plan the agenda and 10 to send the pre-read two days out. Split the two hours across two sessions and the collisions never surface — the room re-establishes context instead of arguing.

  • A wall everyone can see, and one sticky note per requirement. Remote works if the board is shared and everyone can write at once; a document one person types into does not.

What You'll Build

A two-hour facilitated session ending in labelled requirements, resolved conflicts, and named owners — captured live, not written up afterwards.

Step 1: Write the Goal as a Decision (10 min)

A workshop goal is not a topic. It is a decision you intend to leave holding.

  • Weak: "align on refunds"

  • Strong: "decide the refund ordering rule for split-tender orders, and confirm what R1 covers"

Ours came straight from Part 2: alternate flow A3, split-tender refunds, had no owner. Support couldn't decide it, engineering couldn't decide it, and it had been open for three weeks because deciding it required two departments who had never been asked the same question.

Check: your goal contains a verb like decide, choose, or agree, and names the thing being decided. "Discuss X" will produce a discussion and another meeting.

Step 2: Invite by Constraint, Not by Interest (15 min)

Five to eight people. Invite the ones who hold a constraint:

  • Product owner — decides priority, owns the outcome

  • Engineering lead — feasibility and cost

  • The constraint-holders — here, finance (who owns processing fees) and support (who owns the customer conversation)

  • Facilitator — ideally not a stakeholder in the outcome

Seat

The constraint they hold

What you lose without them

Product owner

Priority and the release commitment

Labels get assigned with nobody accountable for them

Engineering lead

Feasibility and cost

The room agrees to something that can't be built in the timebox

Constraint-holder A (here: finance)

The money rule — processing fees

You decide the routing and finance overturns it in week three

Constraint-holder B (here: support)

What the customer actually says

You optimise a cost and create a support queue

Facilitator

The clock and the turn-taking

The loudest seat wins and calls it consensus

Leave out anyone attending for visibility, and brief senior leadership separately — their presence changes who is willing to disagree, which is the one thing you cannot afford to lose.

The decision you'll face: the person most likely to block is also the most difficult in a room. Invite them. A decision made without the constraint-holder isn't a decision; it's a proposal they'll overturn in week three.

Check: for every attendee you can name the constraint they hold. Anyone you can't place is an observer — send them the output.

Step 3: Send a One-Page Pre-Read (T-2 days)

Goal, what's already known, agenda, and the specific thing you want each person to think about. For finance: what does each refund route cost us? For support: what do customers ask for when a refund is split?

Check: the pre-read asks each attendee a question only they can answer. A generic pre-read gets skimmed in the first five minutes of the session.

Step 4: Time-Box the Agenda (5 min to plan)

00:00–00:10  Goal and context
00:10–00:30  Silent generation
00:30–00:50  Share and cluster
00:50–01:20  Label with MoSCoW
01:20–01:50  Resolve the collisions
01:50–02:00  Recap, owners, dates

Each block ends on time, even mid-sentence. Overrunning the early blocks is how the conflict resolution — the reason you convened — gets eight rushed minutes at the end.

Step 5: Generate Silently First (20 min)

Fifteen minutes of silence. Everyone writes requirements on individual stickies: one requirement per note, short and specific.

This exists to defeat anchoring. In an open round the first confident speaker sets the frame and everyone calibrates to it, producing agreement that reflects seniority rather than knowledge.

Check: nobody has spoken about content before the timer ends. If someone "just quickly" framed the problem first, you now have their framing, not the room's.

Step 6: Share and Cluster (20 min)

Each person posts and reads their notes — two to three minutes each, no debate. Then cluster.

The clusters tell you where the room already agrees (move fast) and where it doesn't (the actual agenda). Ours produced a cluster of four notes that only made sense side by side:

  • "Refund gift card first" — finance

  • "Refund card first" — support

  • "Ask the customer which" — design

  • "Whatever the payment provider does by default" — engineering

Four people, four different rules, none of whom knew the others disagreed. Three weeks of drift, visible in ninety seconds because the notes were posted next to each other.

Check: at least one cluster contains genuine contradictions. If everything clusters cleanly, either the room is too homogeneous or the hard questions weren't in the pre-read.

Step 7: Label With MoSCoW (30 min)

Run each cluster through the labels — the mechanics are in Part 5. Every cluster leaves with a label. Where the room can't converge, the product owner decides with input and the disagreement is captured rather than smoothed over.

Check: no cluster is still unlabelled when the block ends. An unlabelled cluster is a decision deferred to whoever touches it first.

Step 8: Resolve the Collisions — the Deliverable (30 min)

This block is why the workshop exists. Walk each collision through three questions: what is the actual tension, what does each side cost, what do we recommend?

Worked, on split-tender:

The tension. Refunding the card first returns real spendable money to the customer, which support wants because it's what customers ask for. Refunding the gift card first avoids the card processor's fee on money that never left the business — roughly 2.9% of the refunded portion, which at the observed split-tender volume was a real annual number finance could state out loud.

What each side costs. Support's version costs money on every split refund. Finance's version produces a support contact when the customer expects cash back and gets store value.

The recommendation, in eleven minutes. Exhaust the gift-card portion first, and say so explicitly on the confirmation screen and email — "£18.00 returned to your gift card, £42.00 to your card ending 4471." The cost was never the ordering; it was the surprise. Making it visible removed support's objection without giving up the fee.

Neither department could have reached that alone, because each held half of it. That's the shape of a workshop's real output.

Check: every collision leaves with a decision and a named owner, or with an explicit "escalate to X by [date]." "We'll follow up" is not a resolution.

Step 9: Capture Live, Not Afterwards (10 min)

The facilitator recaps on screen while everyone is still present: requirements, labels, decisions, owners, dates. Attendees correct it in real time.

Writing it up later means writing up your memory of what people meant, and the corrections arrive a week after the record hardened.

Check: the document is complete before anyone leaves the room.

Step 10: Send Within 24 Hours (varies)

Distribute the output with decisions, open items and owners, and the trigger for any follow-up. Sleep produces "wait, did we agree to X?" — much cheaper to answer on day one than in week six, when it arrives instead as a change request.

Check: at least one attendee replies with a correction or a confirmation. Total silence usually means nobody read it.

You're Done When

  • Every cluster on the wall carries a MoSCoW label, and every collision line in the write-up ends in either a decision with a named owner or an explicit "escalate to [name] by [date]" — no blanks, no "TBD."

  • Part 4's traceability matrix has changed: the split-tender ordering decision is in it as a requirement line with an ID, not sitting in meeting notes.

  • The record was corrected by someone other than you — at least one attendee changed a line during the on-screen recap while still in the room, and at least one replied to the distributed version within 24 hours.

If This Goes Wrong

  • Nobody disagrees during clustering. Don't move on — the fragmentation is still there, you just didn't elicit it. Pull the two most similar notes off the wall, put them side by side, and ask each author what their version costs the other person's team. If that still produces nothing, end the labelling block early and spend the remaining time identifying which constraint-holder isn't in the room.

  • A collision runs past its slot. Do not extend the block. Convert it on the spot into an escalation line — "escalate to [name] by [date]" — read it back to the room, and move to the next cluster. An unfinished argument that leaves with an owner and a date is a result; one that eats the agenda is not.

  • One seat has answered the first three questions. Call a second silent round: two minutes, everyone writes their answer, then read them out in reverse seniority. You're buying back the framing the silent round was supposed to protect.

  • A constraint-holder drops out the morning of. Run the session, but mark every requirement touching their constraint "provisional — [name] to confirm by [date]" and put it in the write-up that way. Deciding the money rule without finance is what produces the reversal in week three.

  • You hit 01:50 with clusters still unlabelled. Stop resolving and spend the last ten minutes labelling what's left, even if the label is Won't. An unlabelled cluster reads as an oversight later; a Won't with a date reads as a decision.

Common Failure Modes

No disagreement surfaced. The most dangerous outcome, because it reads as success. A workshop that produced no conflict didn't resolve the fragmentation — it failed to elicit it, and the conflict is still out there.

Wrong attendees. Plenty of people, none holding the constraint. You'll leave with a well-attended non-decision.

No silent round. The first speaker's framing becomes the room's framing, and you've run an expensive interview with an audience.

No facilitator, or a facilitator with a stake. Whoever runs it steers it; if they want an outcome, they'll get it.

Written up later. The record becomes one person's recollection, and corrections arrive after it's been treated as settled.

Continue the Requirements Engineering path

Part of the Requirements Engineering learning path.

bottom of page