Use Case

[Dmorley]

I'm quite bad at these, but need to start doing them more!! Please have a look at the attached Use Case diagram, it has most of the cases i can envisage for the system.

However, it looks confused & unorganised - any 'Use Case' experts have any suggestions on how to restructure this to be more coherent?

Notes:

The 'Search for Orders' case should be available to all actors. Every actor should be able to search for, view & output order details.

The Product Buyer is the actor that creates orders.

The System Administrator has cases specific to their role, but should have complete system access (they could create an order if they needed to).

Thanks

[a_r_satish]

Hi Friend,

I am also not an expert in this but even then i would like to suggest u a simple way.

I hope u r using Rose for drawing the Use case diagram... just group them individually in seperate diagrams....

If that is not possible.. then in the Menu there is a Format option... In that select the Layout Diagram.. so that it is auto formatted..


Regards,
satish

[klintan]

Use cases are most about text, not diagrams. Do not spend too much time producing neat diagrams, instead spend the time on writing good text.

First, I try to write a few (1-3 maybe) summary use cases, describing how the strategic system goals are fulfilled. Typically, these use cases tie together the use cases on the user level (see below).

Second, I start working with the "real" use cases, e.g. starting from the actors' goal perspective. I usually put them in a simple table, with columns actor, goal, and summary. In your case maybe a column subsystem should be added as well. And, like in your case too, if there are many included use cases I might put them in a column also.

For your system, I would put the use cases "View products on CIS", "Transfer Order Data", "EDI Orders to suppliers", and "Central Orders Module" as real use cases.

Alternatively, if the requirement spec is for three separate systems, a table for each system can be used, and in that case the other systems would show up as actors for that system (e.g. Orders System is an actor that uses the CIS Data use case).

Regarding your use case model I also have the following comments:
- Some use cases have not so good names (e.g. CIS Data, Central Orders Module, EDI Orders to suppliers), I suggest using the form verb - noun when naming a use case.
- It looks like several actors might initiate the same use case (search for orders), only one actor should initiate a use case but other actors can of course participate in it.
- There are a lot of levels of the use cases where one use case uses another that uses another... it looks more like a data flow. Having too many use cases and poorly structured use cases makes the use case model brittle, where a change in one use case affects another use case etc., and that in turn affects both the project and the system. I use the following rules of thumb:

A use case shall have 3-11 steps and not more than 3 flow levels (main flow, alternate flows, alternate sub flows). The includes relationship shall be used in the following situations in accordance with these rules:
• Use include for common functionality for several use cases (don’t use include if common functionality is just one or two steps)
• Use include if a base use case has deep alternative flows (use include if sub-sub flows are needed)
• Use include if the main flow of the base use case becomes too long (more than 11 steps, but be pragmatic here)

My use case guru is Alistair Cockburn, see for instance this article: http://alistair.cockburn.us/crystal/...swithgoals.htm

[Dmorley]

- There are a lot of levels of the use cases where one use case uses another that uses another... it looks more like a data flow. Having too many use cases and poorly structured use cases makes the use case model brittle, where a change in one use case affects another use case etc., and that in turn affects both the project and the system. I use the following rules of thumb:

Thanks for response - you're right, i realised soon after that what I had posted was more of a logical flow rather than a use case diagram! I've since reviewed this & cut down quite a lot out of the diagram - I'll post it back up when I'm finished.

Many thanks for the link, I'll check that out - always after more resource on this subject.

[Cyklyzt]

Hello,

I to prefer the Cockburn style. What is the best tool for filling out these types of use cases. Some of the features I want in a use case editor are

1) Cockburn style numbering. I would like the numbering to be done automatically at I type, however, if steps change, or use cases get moved around, I'd like the numbers to change and keep up.

2) Names linked, so if you change the name of an actor or use case, it is updated everywhere.

3) hyperlinking (or just save as html.) It is nice to hyperlink use cases together, and even hyperlink them to UI mockups, images, testing cases, implementation documents, etc.

Thanks
Gene