The use case diagrams are, of course, commonly used in the requirement management process. The use case diagram describes the relations among actors and use cases - and these will be the two main elements of this diagram.
You should not confuse the actors with personas - a term first introduced by Alan Cooper in "The Inmates are Running the Asylum". A persona is an embodiment of an imaginary user, described quite in detail (his tasks, goals, knowledge level, skills, you can even name him, if you want).
It is safe to say that a persona is to an actor what is a usage scenario is to a usage case - an instance, or a "snapshot". If your marketing department has some statistics or demographic data, this is the place to use them. This may look like an office game, but correct use of personas can alter your perception of the application considerably. For instance, think that you have two users who have to perform the same action (two instances of the same actor), but one of them is computer illiterate, while other uses the computer regularly. And perhaps a third persona, who is a familiar with the previous version of your program, as well as with the software from your competition, because he has worked in this field all his life. They are the same "actor", but their interactions with the application will be completely different. This will give you a pretty good idea how the users react. If you use them, make sure you create the person before, and the use case later, based on the persona. You don't need to write all the possible scenarios - in fact that would be impossible - but make sure you include some of the most likely failure options.
The use case diagrams are quite simple and intuitive - they include the actors, the use cases and the boundaries of the application. Actors are always placed outside the boundaries, since they will always be external to the application. You can use lines or arrows to indicate the relations among them - in UML, indicating the flow is not mandatory. You can also compile an additional glossary of the terms used in the diagram, which may prove useful later on.
The key word in this phase is always "interaction". How the actor interacts with the application, what the application detects and what is its response.
When you are satisfied with the use case diagram, or everybody has had enough of the brainstorming for creating imaginary friends, you need to check the result using the robustness analysis. If everything works well, you can move on to the sequence diagram, if not, you can return and work on the use case diagram some more.
For the robustness analysis you need to identify the objects (which are still depicted in the form of literary text in the use cases) and to divide them into three main categories: boundary objects (that the actors use to interact with the system - interface, menus), entity objects (which belong to the domain model) and control objects or controllers (these aren't necessary objects, they connect the objects from the previous two categories; also, they are used to localize and store changes, sometimes, they disappear when the process comes to an end).
There are two main reasons for performing the robustness analysis: to check that you didn't let yourself carried away with the use cases and include actions that could not be performed by the respective objects, and to refine the model obtained, if it proves correct, to bring it closer to the design stage.
Now, in order for the robust analysis to validate your use case diagram, the relations must be in the correct sequence: the actors can interact directly only with boundary objects; boundary objects interact directly with actors and controllers, controllers can interact with boundary objects, entity objects and with other controllers, while entity objects can only interact with controllers.
Some quick hints before you get lost here: if you wrote the initial use case correctly, in the active voice, you probably find a lot of sentences that include the sequence Subject - Verb - Object, which, in the robustness analysis, corresponds with the sequence Boundary object - Controller - Entity object.
Usually, you need between three to five controllers per use case. If you have fewer, you probably didn't include all the options, if you have more, you need to break down the use case is smaller bits.
When you're done and everything falls into place, you can move to the sequence diagram.
Leave a Reply