use case scenarios

[birdy]

Suppose i have a use case.

1. User enters his Name and Pswd.
2. System validates the input/
3. User enters ...
4. Sytem..
..

And on each step user can quit the System.

How do you suggest to reflect it in scenario?

Should I write an alternate path for each step?
Or what?

[Kevin Brennan]

If you're using Cockburn's notation, you write:

*a. User can cancel use case at any point.

as an alternate flow.

For most other styles it's much the same.

[jeshaw2]

See the EA Help topic interruptible activity region to specify this capability in the Use Case's Activity Diagram.

In the textual document, you might include a sub-topic for Exceptions at an equal level in indentation as Alternate Flows.

[birdy]

hi, there is one more question about scenarios.

as far as i understood, use case has just one basic path.

Cockburn wrote:
"We often explain things to other people by starting with an easy to understan description and then adding,
"Well, actually, there is a little complication. When such-and-such occurs, what really
happens is ..."."

And what about the sitiuation when in use case i got not the basic and alternative flow, but two equally - weighted flows (suppose i can do THIS or THAT in some part of my scenario)? Well, i dont like to include THIS to the basic path, and THAT to the alternate.

May be in fact there are two use cases? But im afraid that if i follow this i would produce TOO much use cases.

[jeshaw2]

And what about the sitiuation when in use case i got not the basic and alternative flow, but two equally - weighted flows (suppose i can do THIS or THAT in some part of my scenario)? Well, i dont like to include THIS to the basic path, and THAT to the alternate.
 

It depends.....

If the two alternate paths lead to two different outcomes, I'd suggest two Use Cases.  I like one clearly defined goal per use case.

If the alternative flows lead to one outcome, I'd suggest that your use case description is too fine grained or at too low a level of detail.  Pull up to a higher level of abstraction about the flow and let the activity diagram show the details of the alternative flows.

[Tuser]

I'd suggest that your use case description is too fine grained or at too low a level of detail

Exactly.

Use cases are a powerful analysis tools, supporting the high-level analyis of your system requirements. Don't try to make them into the specification. They should describe your major success path, not every little detail of possible flows. Major forks can also be documented.

And then you use the activity flows to specify all the details.

[thomaskilian]

Exactly.

Use cases are a powerful analysis tools, supporting the high-level analyis of your system requirements. Don't try to make them into the specification. They should describe your major success path, not every little detail of possible flows. Major forks can also be documented.
 
And then you use the activity flows to specify all the details.

Just 0.02€ from an old German: Use Cases are not meant for analysis but for synthesis. It took quite a while until I got this but it really makes sense!

[Tuser]

You mean from the use cases, ideally defined by the users, you extract ('synthesis') the specification through analysis?

[thomaskilian]

I meant that Use Case Analysis is not the right term. It should be named Use Case Synthesis. Instead of breaking things into bits and pieces what you do during an analysis, you group information towards single goals. Don't split: gather! Most people (almost everyone) tends to use the <<include>> and <<extented>> relations extensively. This is a bad approach. Do not use them until you are able to work without  them Once you get this, your use cases automatically get the right form.

[Kevin Brennan]

Thomas speaks wisdom.

<<include>> and <<extend>> should almost never appear in the first version of a use case model. Bring them in only when you know for sure that they're useful to you.

[birdy]

Thomas!

You wrote, that one should not use <<include>> and <<extend>> until you he/she will be able to work without  them. So it would be interesting for me, how would you draw the following situation.
Suppose i have UC1 and UC2 and they have common functionality inside. It seems logical to me to make the third usecase UC3 and write:

UC1 <<include>> UC3
and
UC2 <<include>> UC3

I have one strong reason to do it - when i want to change the fuctionallity, that is common  for both UC1 and UC2 a just change UC3.

Where am i wrong?

[Kevin Brennan]

You're not. Thomas's advice is practical--people who haven't worked with use cases before tend to get hung up on whether and when to use <<include>> and <<extend>>, leading to analysis paralysis.

In practice, what's really important is to get the use case written and understood by all concerned. The point is, don't let figuring out whether you've used <<include>> and <<extend>> correctly get in the way of finishing the requirements documentation.

[mikewhit]

or: don't think of refactoring or commonality at first - concentrate on correctly representing each use case.

If you seek to factor things out at the start, you may make unjustified assumptions.

[jeshaw2]

Thomas, Kevin and Mike provide sage advice; get the use cases correct first, then in the editing process you can factor out common sub-activities.  

When you write the included use case, be sure to write it a a goal level below that of the use cases in which it is included.