I think your approach is right on target. I only wish I could get the kind of direct interaction information as outlined in your article. Most often, the developers only get the "Knowledge Expert" point of view via Use Case. In many instances we find the Knowledge Expert lacks a true scenario understanding of processes in the field (The end user point of view). I do think USE Case and UML in general was a great leap forward, but much is dependent on the talent of the Business Analyst to drive out the real scenarios.

I think these defintions are spot on.

I've found that along with the use case, it's helpful to include a super lightweight version of one user scenario before diving into the pre-conditions, action, post conditions and exeptions. While most companies cross reference to the scenarios, if you've got a number of complex interactions, this helps considerably.

Where I am left struggling is, what is that relationship between the scenarios and use cases? One-to-one? Many-to-many? I think the latter.

At first blush, it would seem that a common pattern is for a single use case to give rise to many scenarios. I see the many to many angle as well, and I think this can be illustrative in evaluating a design: if use cases define the behavior of units of functionality and common scenarios bridge several use cases, it may be useful to reconsider the organization of functionality in the UI.

Thanks for the post Thomas. At first blush, I believe it is one scenario (informal) to many use cases (formal). But I can definitely see the need for a many-to-many relationship.

I'd tend to agree with Thomas--I view a scenario as a narrative description of a particular path through a use case.

If you've got a single scenario encompassing several use cases, it suggests that the scenario is written at the system goal level while the use cases are written at the user goal level.

Interesting. Kevin, you think it is more often 1-1? I could agree with your suggestion. Fantastic analysis. Thanks!

For me, a single use case encompasses many scenarios. A scenario is a specific "path" through a use case. I wrote about scenarios in my blog late last year.

One of the important things about scenarios is that they are more concrete than use cases. Since use cases are supposed to be general enough to encompass many types of users, they tend to be abstract, and it can be difficult to relate them to realistic uses of the product. Scenarios, on the other hand, have by definition a very specific purpose and involve very specific choices on the part of the user.

Roger, thanks to reviving this. When I read your post, and everyone elses I think they, and you, may be be on the same page. Makes sense to me. Thanks!

Hi great discussion.

Agree with everyone. Just bear in mind that use cases should be light on from the start and needn't be too design focused.

By the way, use cases have to be very tied to the functions of the product otherwise (before or after product selection).

That's why we use them in software land. Cheers

You are right John. There are lots information around to help write use cases and all are in line with what you say about keeping them light and to avoid design. Keeping them light helps you implement them in stages rather than ONE big use case. -Stewart

what is difference betwee flow and scenario's. isteh scenrio is equal to flow(normal,alternate ,exception flow)

The structure is different. Where the use case will follow step by step in the respective sections, the scenario is more narrative. Generally simpler to read (and write).

Stewart

I'm inclined towards Roger's point of view.

Furthering the thought on the scenario being a 'path' through the use case, the use case can have as many paths as there are outcomes, i.e. one scenario for each flow, main, sub, exception etc.

While it may not be (and usually isn't) necessary to detail as many user scenarios as there are possible flows, it is important to keep the alternative possibilities in mind when describing your scenario.

End users are often a surprising bunch and it I find it really helps to take into account the inquisitive nature of the human mind when writing up user scenarios for bulletproof systems.

Cheers