The purpose of a use case is to meet the goal of its associated actor(s), such as a guest making a reservation with a hotel. This implies that a use case should include everything that must be done to meet that goal. For example, if it is necessary to check the availability of rooms in the hotel for the desired length of stay before accepting a reservation, then we expect the use case to contain that check. In general, a use case contains a narrative about the flow of events that specifies a particular use of the software system.
A scenario is a description of a sequence of actions that illustrate a piece of interesting behaviour. In the UML, a scenario is said to be an instance of a use case (implying that there could be several such instances, each one describing a different situation). So, a scenario describes the interaction and dialogue between the users of a system (its actors) and the system itself. For a given use case, we expect to see one main scenario that describes the flow of events leading to a successful conclusion. There may be other scenarios that describe alternative or additions to the main scenario. Here, for example, are two possible scenarios for making a reservation at a hotel.
Jill wants to reserve a room at the Ritz Hotel for 14 July. A room is available for that date and so the receptionist makes a reservation for the guest, Jill.
Jack wants to reserve a room at the Savoy Hotel for the first week of August. There is no single room that is free for seven days in August, but there is one room available for four days followed by another of the same type for three days. The receptionist presents that option to Jack, who rejects it.
Both scenarios are possible instances of the make reservation use case. Their interactions and outcomes are different. In the first, there is a description of the use case leading to a successful outcome. In the second, there is an exception to the main success scenario. Exceptions to the normal behaviour for a use case are common, especially where actors decide to abort a use case without completing it. However, the common theme among all the scenarios is the intent of an actor to reach the goal defined by a use case. In the unsuccessful scenario above, Jack was trying to make a reservation at the Savoy Hotel. Perhaps he didn't like the idea of changing rooms during his stay. Hence, a use case should include any unusual or alternative courses of action.
You could start an investigation by simply identifying a use case and its main success scenario, and later refine or adapt it. You will need to decide the way in which you record the information for each use case not just for the main success scenario, but for all the relevant scenarios. At its simplest, you can record a textual description (narrative) for each use case that details each scenario together with its outcome.
Remember that your description of a use case expresses what the system should do without constraining how it should do it. Since the description takes an external viewpoint, all the behaviour is in the form of observable results. Later on, a developer will choose an architecture for the solution and produce a workable design and implementation. While the structure and format of a use case description may vary among the different development processes, we suggest that you include the following items as minimum details.
A unique identifier for the use case that allows traceability throughout development.
The name of the actor that initiates the use case as well as the identity of any other actors that may be associated with the main success scenario.
A short description of the goal of the use case.
A single sequence of steps that describe the main success scenario. You may also find it helpful to number these steps for traceability, in cases where you need to identify any extensions or variations that occur as a result of the other scenarios of a use case (we discuss this in more detail later).
A textual description of the pre- and post-conditions.
In some circumstances, you may have to add other information. For example, the identity of the authors may be required where there is a large team of developers. In a risk-driven process, you might be required to record an assessment of the risks, assumptions and outstanding issues to support the decision-making process. For example, it helps to record the things that the authors of a use case had assumed to be true during their analysis.
Opinions vary about the correct format of the description of a use case. One development process might require a detailed structure with tightly controlled phrasing and numbering of each item in the description. Another might place few or no limitations such that each use case reads like a story – with a beginning, a middle and an end.
However, you should use the language of the domain to formulate the use cases and identify requirements. Each requirement is part of the contract between the developer (as supplier) and the customer. Both parties need to have a clear understanding of what is captured in each use case and of what it means. Table 2 illustrates one way to structure and record a use case.
The main success scenario in Table 2 contains a stepwise description of what happens when nothing goes wrong; usually the most common case. It is assumed that the steps are performed in the order described with no concurrent (simultaneous) behaviour. In the next section, you will see how each step can be used as a decision point to deal with exceptional circumstances. For example, what should be done if there is no available room for the desired stay? Later, you will see how the UML can be used to model the conditional and concurrent activities of a business process. For example, what should be done at step 5 if the ‘guest’ had stayed in the hotel chain before and had already provided these details?
Table 2 Textual description of a use case in the hotel domain
|Identifier and name||UC_1 Make reservation.|
|Initiator||Receptionist or Guest.|
|Goal||Reserve a room at a hotel for a guest.|
|Pre-condition||None (that is, there are no conditions to be satisfied prior to carrying out this use case).|
|Post-condition||A room of the desired type will have been reserved for the guest for the requested period and the room will be occupied for that period.|
|Assumptions||A guest can make a reservation via the Internet. The guest is not already known to the hotel's software system (see main success scenario, step 5).|
|Main success scenario|
|1||The guest requests a reservation.|
|2||The guest selects the desired hotel, dates and type of room.|
|3||The hotel receptionist provides the availability and price for the request (an offer is made).|
|4||The guest agrees to proceed with the offer.|
|5||The guest provides identification and contact details for the hotel's records.|
|6||The guest provides payment details.|
|7||The hotel receptionist creates a reservation and gives it an identifier.|
|8||The hotel receptionist reveals the identifier to the guest.|
|9||The hotel receptionist creates a confirmation of the reservation and sends it to the guest.|