Are scenarios just requirement specifications?

I have before argued that it should be the scenarios that were specific in functionality and not the pesonas. That statement needs elaboration, as scenarios are much more than a list of requirements. If it was only a list of requirements, then why even consider mixing it with iterative development.

Using scenarios is a tool for reflection, just as the continous feedback of iterative development is. Besides showing functionality of a system, a scenario also shows (1) how the user will access the functionality and (2) how the experience of doing so is. The first of the two things is covered by iterative development, as the programmers decide how a specific feature will be implemented. The latter of the two things, how the user experiences the functionality is something which is neglected by most iterative development methodologies like XP.

Why is experience so important? Isn’t it just another buzzword used to attract customers?

There are other things in the world than plain functionality. Scenarios is a tool for conveying a concrete vision of the system: not an abstract goal nor a list of requirements. As the scenario is grounded in the persona of the user, the user interactions are guarenteed meaningful to the user (persona). The interactions are only meaningful to the user, if the user experiences the interactions like meaningful. The system might be able to do exactly what is needed, but if the functionality isn’t put together in order to make the interactions with the functionality meaningful, then the software is useless. In short – scenarios provide a tool for visioning the system beyond just the technological capabilities. XP does this as well with their real-life users – but using real-life users is much more expensive than creating text-based scenarios.

Scenarios can be used to explore functionality and how it works with the users. Instead of spending money on developing an actual prototype, scenarios can be used as sort of a soft prototype. The soft prototype, which is just text, can help expose the possible design for critique. On top of this, scenarios provide constraints. There are a load of things that could be designed, but only a few is truly needed.[1]

1 Caroll, J. Five Reasons for Scenario-Based Design, Department of Computer Scienace and Center for Human-Computer Interaction, Virginia Tech, 1999.

2 Responses to “Are scenarios just requirement specifications?”

  1. David Heinemeier Hansson Says:

    This relies on the assumption that textual descriptions of functionality is a reasonable approach to discovering valuable software. And I don’t think that’s true. Customers don’t know what they want before they see it. Developers don’t know how to implement it before they do it.

    Attempting to describe a complete system through a textual document is an expensive way to postpone inevitable failure.

  2. Anders Toxboe Says:

    This so-called soft prototype is not meant to be of a complete system from my point of view – but more of something like a spike as in XP.
    If you have a difficult interface problem, scenarios might be a good tool to explore possible solutions. Of course you would have to do a cost-benefit analysis of whether it is faster and less expensive to just make a quick-and-dirty empty shell (be it a HTML page or a app shell) without any functionality working, than it is to use the whole toolbox of personas and scenarios.

    The whole point of using personas (not scenarios) should be that all parties involved know the personas so well, that they all can instantly imagine the same scenarios with the persona in question. If you look at it in this way, the use of written scenarios aren’t really that important.

    I agree with you that customer’s don’t know what they want before they see it and developers don’t know how to implement it before they do it. But I believe that there are some good stuff to use from the UCD world in getting closer to what the customer wants first try than without.

    I guess the ultimate question from my side is whether there is something called “user experience” – and if it is possible to design a uniform and well-thought-out user-experience across the application without the use of UCD?
    Note the title of the post… I am not sure about whether scenarios are actual useful tools or just another requirement document to add that nobody reads.

Leave a Reply