Role Playing · Business Analysis Notes

What it is#

Leffingwell and Widrig present role playing as an elicitation technique with a simple rationale: everyone sees the world through their own conceptual filter, and watching or interviewing someone does not give you the understanding that doing the work yourself does.

They give four reasons why observation and interviews fall short:

Many users cannot describe their own procedures or needs, because nobody has asked before. (Try explaining in words how you tie your shoelaces.)
Users may hide how they deviate from the official procedure; what they say and what they do differ.
A user’s personal workarounds can hide the real problems from an observer.
Neither side knows all the questions: the developer does not know what to ask, and the user does not know what is expected.

Role playing has two paper-based relatives for situations where you cannot do the job yourself:

Scripted walkthrough. Each participant follows a script that gives them a role. Acting it through exposes misunderstood roles, information an actor or subsystem lacks, and behavior nobody has described. You can change the script and replay it, and use it to train new team members, which makes it a kind of “live” storyboard.
CRC cards (Class–Responsibility–Collaboration), a technique from object-oriented analysis. Each participant gets an index card for one class or object, listing its responsibilities (what it does) and its collaborators (what it works with). An initiating actor starts a behavior and everyone follows their cards. When the flow stalls for lack of information or an undefined interaction, fix the cards and play again. The authors note it works both for elicitation (external behavior) and for design (internal structure), and often reveals wrong or missing requirements.

When to use it#

Users struggle to explain their work, or their explanations do not match what you see.
Analysts or developers believe they understand the user’s problem better than the user does. Leffingwell and Widrig recommend role playing as the remedy for this side of the “user and developer” syndrome.
An existing system is error-prone and you need to feel where the errors come from.

When not to use it. Direct role playing is not possible when the role is algorithmic rather than human, or when it involves risk: you cannot act as a surgical patient or a reactor operator. Use a scripted walkthrough or CRC cards instead. Role playing also does not replace interviews and observation; it complements them.

How to do it#

Pick the role and the tasks. Choose a user class and two or three everyday tasks that matter to the project.
Arrange it with the users and their manager. Agree what you may do, with whom, and how mistakes will be caught.
Do the work. Use the real tools and the real inputs. The authors’ example is entering a few purchase orders in the existing system to feel where errors arise. Half an hour to an hour is often enough.
Note friction as it happens: waits, workarounds, re-typing, information you had to hunt for.
Debrief the same day with the user: confirm what you found and ask about what you could not see.
If you cannot do the job, script it. Write a scenario with roles, hand out roles (or CRC cards), act it through, stop at each gap, fix the script, replay.
Turn findings into requirements and questions, and trace them to the session.

Example#

For The Workshop, a fictional bike-repair chain, the analyst spends a Saturday morning at one workshop’s front desk taking phone bookings with the paper diary, under the front-desk lead’s supervision. Within an hour they notice three things nobody mentioned in interviews: callers often do not know their bike’s model, so slot length is a guess; the desk keeps a private list of “quick jobs” squeezed between bookings; and status calls arrive in bursts after school pick-up time. Each becomes a question or a draft requirement.

Customers cannot be role-played this way, and the parts flow involves an outside supplier, so the team runs a scripted walkthrough of “the part is not in stock”. Participants play Customer, Front desk, Mechanic, Parts supplier and Booking system. The script stalls when Mechanic asks “who tells the customer the repair is delayed?”, and nobody’s role covers it. A follow-up round with CRC cards for Booking, Repair job, Parts order and Notification shows that no card is responsible for recalculating the expected ready date.

Common mistakes#

Watching instead of doing → take the user’s seat, not the chair next to it.
Playing a sanitized version of the job → use real inputs and real volumes where safe.
Skipping the debrief → you will misread some of what you felt; check it with the user.
Role playing risky roles directly → switch to a scripted walkthrough or CRC cards.
Running a walkthrough once → the value comes from fixing the script and replaying.
Not recording findings → write each one down as a requirement, question or rule.

Checklist#

Role, tasks and time box agreed with users and their manager.
Real tools and inputs used, with a safety net for mistakes.
Friction points noted during the session.
Debrief held the same day.
For roles you cannot take: scenario scripted, roles or CRC cards assigned, replayed after each fix.
Findings turned into requirements, questions or business rules, traced to the session.

Sources and further reading#

D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000, ch. 14.