User Experience Designers [UxD], Business Analysts [B/A] and Agile developers to often find themselves misunderstanding each other while talking about very similar ideas. These forms of recording baseline user needs have much in common so we will take a stab at sorting them out. This will be necessarily concise as a full study of these issues could fill multiple thesis books. You would be very bored.

Use cases
Use cases gained popularity as a development tool through the Rational Rose project at the corporation of the same name, led by James Rumbaugh, Grady Booch & Ivar Jacobson. Each brought their own methodology to the corporation and then attempted to reconcile them into the so-called Unified Method in 1996/97. The semantic aspect of the notation Unified Modeling Language [UML] are Use Cases, a precise description of a single user action.

In the classic Cox/Aurum/Jeffery words which are cited so often as dominate definition: “A use case is a specific way of using a system using some part of functionality.” This is a bit cold as a description and it exposes some of the issues with writing them; well formed use cases need to be just specific enough; too detailed and you end with an ocean of them, too general and the developers don’t know what to build. The reality is that the generalizations allow the developers to synthesize a contextually appropriate solution.

Alistair Cockburn has a very usable explication of how to write a use case here. But these are the main parts and any User Experience Designer will see many linguistic overlaps with our notion of a scenario - they are named as a sub component of his template. Perhaps the best comment he makes is to construct it in several passes, which invites the Agile notion of iteration:

Description

Use Case: Number and verb phrase

Goal in Context: Short paragraph

Scope: & Level: Which part of which system are we working with?

Primary Actor: This would be primary persona in UxD

Priority:

Frequency:

Trigger:

Narrative

Main Success Scenario - Sunny Day Path

Context

Extensions

Goals

Performance Target:
    Business Goal
    System Goal

Error paths

Due date

There are definite pros & cons to using Use Cases. Personally I find them a very powerful starting point for describing a project if they are written as concisely as possible. Why? Because the primary flaw of Use Cases is one that you discover. They tend to multiply in complexity and create a maintenance nightmare. Which is precisely the Agile XP argument against them. And why Rational Rose uses a database to flag the effects of changing any case.

Looking at the description above, most I/A’s can do a taskflow in about 15 minutes. A taskflow which respects the other contexts in the application or website, reduces the number of steps and elegantly synthesizes actions in ways that create cumulative knowledge may take a bit longer.

This leads us to the primary UxD tool for planning actions, a scenario. If Use Cases are specific to an action, Scenarios are cognizant of the big picture.



Scenarios
Scenarios have multiple roots and the collision of histories can lead to confusion. They have origins in narrative literature and the human tendency to remember things through using stories. They have been used by market strategists as proxy ethnographic mnemonics. Vannevar Bush’s 1945 essay “As We May Think” is written as a scenario of the future, a not unknown storytelling device - Jules Verne comes to mind. Alan Cooper Thomas Erickson & John Carroll, among others have popularized their use in software design in conjunction with personas and this is how we will consider them.

In this light they are broader than Use Cases, and the focus is on the users actions & goals rather than the system or business goals. Typically UxD will only consider the user goals & leave the system functions to a B/A.

Scenarios are aligned with the primary or secondary personas & act as walkthroughs to uncover the requirements of any given set of tasks. One of the advantages of this tool is that it is general in use, allowing the designer to nudge it into a complex context. The rough boundaries also facilitate synthesis through iteration by not eliminating the discover of solutions. These are not trivial advantages.

Here is a typical if clearly fictional one:
1] Stephanie arrives at a west end station at about 8:20, parks in the smallest snowbank & walks through 3 inches of fresh powder to get to the door. Once inside the station, she turns up the heat & pulls out her laptop.
2] She fires up the Zippidy Connecto software and opens the group for the station she will be working on. She then opens the repository pane. Using standard windows navigational metaphors, she locates the current corporate template for the new relay.
3] She drags the template from the repository directly into her workspace. She is prompted to enter device specific information. 
4] Stephanie selects the new device , shift clicks the Nimbus 3000 & clicks the data line connection. The two devices are connected.
5] The points that get passed to the Nimbus 3000 are all standard and set in the corporate IED template. She is done with the relay.
6] Stephanie saves the revised configuration and the configuration parameters have now been added to the Nimbus 3000 client in her station diagram. At this point she’s smiling as to how easy this was. She cleans the snow off of her car and heads back to the office.

From the basic story arc we extrapolate system functionality, rather than trying to determine a list of features based on the teams comfort level & kludging in contextual alignment. The focus is on aligning the experience with the task, which is obviously a user centric method.

In Part 2 we will look at User stories & see if we can find the similarities & differences between these three methodological baselines.