How to use the use case diagrams

Use case diagrams have their power in discussions at the beginning of a project. Mostly you hear the complaint that it's unnecessary to make it, because things are already ”clear to everyone”. ”It's only one or two usecases”, no need to make such an effort of drawing a diagram for this simple example.

It is wrong! There are three possibilities:

1. The problem is so simple that the use case diagram would only get one ore two use cases at all. Then just do it!, because it will not cost you much time if it's really that simple (actually most projects admit to be not such simple when you have started the diagram, but that's an other story)
2. The problem is so complex that it would take you hours to define all use cases. Then do it!, because it is the best method to determine how “big” it really is, and where you could better split the whole project into parts.
3. The problem has the ideal size to draw a use case diagram. Then do it! anyway.

Don't prepare it at all, but develop it together with your stake holders. Grab the people which represtent your ”user group”, get a meeting room and a prjector and develop the use case diagram as team work. Even if you had the time to prepare the meeting, don't start with a prepared diagram. The drawing of the diagram is a creative process where you have the chance to get a common point of view in your team. Don't spoil this by starting with your own point of view.

Now motivate your team If they don't see the need of doing the diagram, beg for the time. Use the above arguments: If the problem seems too simple for the effort - well then it will not take much time

Start AstadeDraw on the projector and insert your most obvious actor. Ask your team how to call him/her/it. Add the most obvious use case and attach your actor to it. Stop here! Let your team continue to think up use cases and additional actors. Just complete the drawing and immediately add everything which get mentioned.

Now you must moderate the meeting. Your goal should be to agree on a diagram with you team in less than 1-2 hours. If things go wrong, lead them back. If there are areas which you cannot answer, blame yourself for not inviting the right people. Leave these points open and try to solve the missing part with the missing people in a separate meeting, when it's only a minor part. If it's a major part - make another meeting. Don't forget important people next time.

The following problems may occur:

After people discover that making use case diagrams is not a big deal at all, they tend to get too much into detail. They might even start to make a game out of it. Whenever one finds a more detailed use case, another one tries to find an even more detailed use case. Your task is to recognize this and to stop them!

• Make yourself clear how many details your diagram can bear.
• Select approximally the same detail level on all aspects of your problem
• Tell your team how much detail you plan
• As a rule: your diagram should fit into one computer screen

If your problem really needs more details, make them later in separate diagrams.

This is mainly the same as the chapter before. If you run out of space, you have too many details! Please don't complain that the tool does not support large enough diagrams, but consider the following:

1. Not too long ago, you did not make use case diagrams at all!
2. The tool may be improved, but the brains of your team may not! If the diagram does not fit on one screen any more, it'll not fit in an average brain.

From time to time you might run into discussions whether a certain use case should be connected “here” or “there” or “both”. Try to stop these discussions.
The connections of the use cases help your association during the drawing process. It helps not to forget something. But they are not so important at all. The things which are important are:

• don't forget a use case
• don't forget an actor

If you have them all, the diagram has fulfilled its purpose. The connections are not needed, except during the drawing process. So don't spend energy on these discussions. Make a “best fit” decision and leave it that way.

When your diagram is almost finished, search for forgotten actors. It is essential to have them all, because if you forget actors you'll certainly forget use cases, too. You will think on the customer, of course. But maybe you have other actors which are less obvious but important, too. Look at this short checklist; maybe you'll find some additional actors and their use cases:

• Quality department (need some test routines?)
• Developers (need some debugging features?)
• Shipment (serial numbers? labels?)
• Production (loaders? self-tests? calibration?)
• Hotline (remote functions? error dumps?)
• Administrators (remote access? installation console?)
• Sales (some user statistics?)
• Customer service (backward compatibility? upgrade possibility?)
• Support (manual?)
• GPL (some source packages?)

They all might be actors and bring their own use cases. Don't forget them!
It's better to go into less detail at other points than to forget e.g. the manual. That's because it normally consumes a lot of project time and it has to be clear in advance whether it is part of the project or not