Diagramming the Scenario
Some requirements analystsand some stakeholdersbelieve that it is more appropriate to use a diagram to explain the functionality of a business use case. This preference is a matter of personal choice, and it depends largely on whether your audience responds more favorably to either text or diagrammatic scenarios. We leave it to you to experiment and decide which method is right for you.
Several diagrams can be used for scenarios. The UML activity diagram seems to be a particularly popular choice. Figure 6.2 shows the airline check-in example in this form.
An activity diagram showing the passenger checking in for a flight.
In Figure 6.2, note the "swim
The activity diagram shows a certain amount of parallel processing. For example, there is no reason why the "Attach frequent-flyer number" and "Allocate seat" activities cannot be performed in parallel. The text scenario does not show this possibility. However, if you want to point out the parallel nature of these two activities, you could amend the scenario as
The following two things can be done in any order:
The activity diagram also shows other control aspects. For example, the diamond at the bottom of the model in Figure 6.2 is called a merge . This symbol means that all processing must reach this point before proceeding. In the case of Figure 6.2, the whole process cannot end until both the bag tags and the boarding pass have been printed. Diamonds are also used to denote decisions as they were in flowcharts. We tend to leave them out where the conditions are obvious or can be shown by attaching guard conditions (the words in brackets at the exit of an activity). When using activity diagrams during requirements, simplicity is more useful than maximum precision.
The book you are reading makes no claims to be a treatise on UML modeling. If you look at the model and the text scenario side by side, however, you should get the idea of how you can use either models or text to represent scenarios. For more on UML, we refer you to the books mentioned in the margin, as well as the
Alternative cases arise when you wish the
Alternative cases arise when there is an intentional choice of user actions.
The work reacts differently depending on the selected alternatives. Consider step 4 of our example:
You find alternatives by examining each step of the normal case. Look for instances where the step may be carried out differently or the actor can be given a choice. These choices are sometimes interesting from the point of view of improving the work or providing a better service.