examples of scenarios

[Kaija]

Hi All,

I'm hoping to get some real world scenario examples that people have used for their modeling. Are your scenarios a list like 1. first the user does this and 2. then the system responds like this and 3. then the user does...

Or, do you give a paragragh explaining what is meant by the scenario and the differences between that scenario and other scenarios under the same use case?

If you would be willing to tell me how you're doing these and your experiences (good/bad) with your method, I would be greatly appreciative. We've adopted an approach on this and I'm just not sure it's really going to suffice for our needs.

Thanks so much,
Kimberly

[thomaskilian]

Kimberly,
unfortunately I'm short of time now. But this question has been asked more than once here. The problem with these Real World examples is, that
a) most of them contain non public information
b) they are rather complex and thus not very useful to a beginner
c) each EA user has his own way and perspective how to use this tool.
For these and many other reasons not mentioned here, you will not find any of the requested models. You can get some inspiration by inspection Sparx example model which comes along with EA. Also you can search thoughout this forum in order to get more insight how people are using this great tool.

Not much help - I know

[Kevin Brennan]

Hi Kimberly,

Could you perhaps tell us a little more about what you're trying to do? There are a couple of techniques that are referred to as "scenarios", although they have some underlying similarities.

Basically, a scenario is an instance of a use case. A use case describes all of the possible ways a person might try to complete a particular goal using your system, a scenario, including all of the possible errors, failure conditions, and so forth. A scenario is one particular way of completing a use case.

As I said, though ,there's a lot of different ways to document them depending on what you want to use them for.

[TrtnJohn]

There are many different ways to describe your use cases.  I use multiple scenarios as a way to describe all possible combinations of success and failure scenarios for the Use.  Typically this can be described using a single basic path (success) scenario and alternates scenarios that handle all possible exceptions.  Each alternate path will be related to a step in the basic path.  For example:  

For the Use Case:  "Check Account Balance" you could have a basic path scenario that describes logging into a web site and selecting account, ...  But, you could also have an alternate path scenarios such as "Network Unavailable", "Invalid Password", ....  Each of these alternate paths would be associated with one or more steps in the basic path.  (This is mainly the approach laid out by Alistair CockBurn).

http://alistair.cockburn.us/usecases/usecases.html

Often a confusion I see around where I work is that the Use Case being specified isn't really a Use but more of a feature request.  In this case your scenarios become way too broad and complicated.  Features are implementations not requirements!

[Kaija]

Sorry for being MIA and not responding sooner.

We are certainly using multiple scenarios to describe the possible combinations (I wouldn't say we've got all of them yet, but we're working towards that.) of performing a use case.

So, our basic path is normally the successful path, and we'll have scenarios for different users (if how they interact is different) and then there will be scenarios for what happens when things don't work as expected or whatever.

I know that there is basically an art to doing this and I'm hoping for some pointers in the right direction (though we're already pretty far towards having a fully documented system).

TrtnJohn, your comment about the use case being specified is really more of a feature request rather than a use might be part of our problem. Could you give me an example (not your scenarios, but rather an example of a feature that someone is trying to do a use case for)?

Currently, our scenarios are numbered lists, (basic idea in my original post), but we were discussing that maybe they should have been just a paragraph explaining for the user and the developer what is expected to happen. Our thinking being that the numbered list seems to imply a user interface design (not really where we want to do this) and that the paragraph would likely be easier to read and follow, both for the programmer and the user.

Does that clarify my original post at all?
Thanks!
Kimberly

[Pascal]

I came across this post, since I ran into the exact same problem as Kimberly. I'm used to writing my use cases in Alistair Cockburn's style, where alternate scenario's are described as exceptions to the basic path. Therefore you'll have to reference steps in the basic path from alternate scenario's. Like Kimberly I was wondering how you guys do this elegantly in EA in such way that the scenario's stay manageable and readable for all stakeholders.

Here's a simple example of a "login" use case as I would normally model it. Who'd like to show us what you find the best way to capture this particular example in EA's "basic path" and "alternate path" paradigms?


Basic Path
1. System requests login information (username, password)
2. Actor enters the requested login information
3. The system verifies the login information and grants him access to all functionality available to the roles he is authorized to fulfill.

Alternate scenario's
2a. The actor forgot his password:
 - The system request's the actor's e-mail address
 - The actor enters his e-mail address
 2a1. The system does not know the e-mail address:
    - The system reports that the e-mail address is unknown
    - Continue with step 2.
 2a2. The system knows the e-mail address:
   - The systems send the password, that is associated  to the entered e-mail address, to the e-mail address
   - The actor retrieves his password from the e-mail message that has been sent to him.
   - Continue with step 2.

3a. The e-mail/password combination is unknown by the system:
 - The system reports that login has failed.
 - Continue with step 1.


Thanks in advance!

Pascal.

[TrtnJohn]

If you make your uses too broad then the scenarios become overly complex.  Here a simple example of what I mean by defining a feature versus a Use:

You could define a Use called Edit Configuration.  This Use would describe changing settings for the system.  This could become very broad as you could list X settings and have to describe each.

It may be better to define the use Change default printer instead.  Setting the default printer is a configuration option of your system.  But, the act of setting it is a Use that is independent of all other configuration settings and should be listed separately.

Another thing I do when my scenarios become too complex is to break them out into smaller pieces and use the <<includes>> association in your diagrams.  Then you can add steps in any scenario such as Execute all steps in the Use Case X.   I also do this when I want to make re-useable use cases.  These sub-uses aren't exactly real uses from a system-actor point of view but do make it easier to document.  No idea if this is the "correct" way or not though

[Pascal]

Not a reply to your message TrtnJohn (sorry), bat rather to my own post. I've puzzled around a little with my example and I've decided the nicest way to capture a use case like the "Login""  one in EA is this way:

Basic Path
1. System requests login information (username, password)
2. Actor enters the requested login information
3. The system verifies the login information and grants him access to all functionality available to the roles he is authorized to fulfill.

Alternate scenario "Forgot password"
2. The actor forgot his password:
 - The system request's the actor's e-mail address
 - The actor enters his e-mail address
 a1. The system does not know the e-mail address:
    - The system reports that the e-mail address is unknown
    - Continue with step 2.
 a2. The system knows the e-mail address:
   - The systems send the password, that is associated  to the entered e-mail address, to the e-mail address
   - The actor retrieves his password from the e-mail message that has been sent to him.
   - Continue with step 2.

Alternate scenario "Login failed"
3. The e-mail/password combination is unknown by the system:
 - The system reports that login has failed.
 - Continue with step 1.

I hope this helps you a little, Kimberly. If anyone uses some other variant, I'll be interested in reading about it.

Pascal.

[thomaskilian]

I'm using quite the same notation with one exception. I state clearly where and how alternatives are used by inserting [Labels] in the basic path. In the alternatives I refer to these labels and the circumstances where they are used.
E.g.:
Basic Path  
1. System requests login information (username, password)  
[Passphrase]
2. Actor enters the requested login information  
[Verify]
3. The system verifies the login information and grants him access to all functionality available to the roles he is authorized to fulfill.  

Alternate scenario "Forgot password"
At [Passphrase] if the actor forgot his password:  
1  - The system request's the actor's e-mail address  
...
Resume at [Verify]
or
The use case ends.
--------------
This requires some manual handling but improves readability of the Use Case description quite a lot.

[Pascal]

Thanks for your input Thomas. I started with labels like this as well, but while I was creating these I found that apart from labels denoting exceptions, I also had to add labels denoting entry points to which alternate scenario's could return. My feeling was this made the use case somewhat less readable. But it's good to hear this works fine for you.

Pascal.

[thomaskilian]

I adopted this from Bittners book.

[Kevin Brennan]

Bittner's notation works more easily with EA. I also find it is more easily read by non-technical users but YMMV. On the other hand, developers seem to prefer Cockburn's.

I think the reason for that is that the Cockburn approach makes it easier for developers to spot where they have to put in exception handling, while the Bittner approach makes it more obvious to business users what functionality is present.

[nifsmith]

Having attended an OOAD course recently they also suggest that a Scenario is an instance of a Use Case. However their take on it is slightly different from what has been suggested in previous posts.

Your Use Case description is made up from basic, alternative and exceptional flows. A Scenario is a flow through the system that combines the basic and where necessary alternative and exceptional flows to create one path through the System using real data. This forces the developer to think in terms of the real world and not in the abstract.

Where a Use Case description states "Actor A" or "User" a Scenario states "Bob" or "Mike". Where a Use Case Description states "enters User Name" a Scenario will use "enters Mike001". This method exercises the System using good and bad data. Each Scenario creates a Sequence Diagram and is also used as a basis on which to build any test cases.

I have recently used this approach on a Project and it seems to work for me.

Nifsmith

[colinc]

I have been struggling with the same issues as well.

I tried numbering references but found it fairly quickly becomes unreadable. Particularly with extension points and links to other Use Cases.

An extension to enable underlines, as Cockburn describes, would help indicate where the exit / entrance points are and what they link to in the model. The current linkage to use case only makes it difficult if you need to represent a particular scenario (although this probably be worked around by finer grained use cases).

So far I have capitalised usecase references, and this helps a bit, but it's not as easy to follow the end to end process (and thus validate) as I'd like for the business users.

Does anyone have any suggestions of better ways to reference other items ?

Thanks, Colin