Guideline: Use-Case Model

How the Use-Case Model Evolves

Use the requirements of stakeholders and potential users as vital information to help you find both the actors and use cases. As you discover them, briefly describe the use cases and the actors. Before you describe the use cases in detail, the use-case model should be reviewed by the stakeholders to verify that you have found all of the use cases and actors and that, together, they can provide what the stakeholder wants. For more information on finding actors and use cases see Guideline: Find and Outline Actors and Use Cases.

When you have found the actors and use cases, describe the flow of events for each use case in detail. These descriptions show how the system interacts with the actors and what the system does in each case. In an iterative development environment, you will select particular scenarios of the use cases, or parts of a scenario, to be detailed in each iteration. For more information on detailing use cases and scenarios, see Guideline: Detail Use Cases and Scenarios.

Finally, the completed use-case model (including the descriptions of use cases) is reviewed, and the developers and stakeholders use it to agree on what the system should do.

Avoiding Functional Decomposition

It is not uncommon that the use-case model degenerates into a functional decomposition of the system. To avoid this, watch for the following symptoms:

Small use cases, meaning that the description of the flow of events is only one or a few sentences.
Many use cases, meaning that the number of use cases is some multiple of a hundred, rather than a multiple of ten.
Use-case names that are constructions such as "do this operation on this particular data" or "do this function with this particular data". For example, "Enter Personal Identification Number in an ATM machine" should not be modeled as a separate use case for the ATM machine, because no one would use the system to do just this. A use case is a complete flow of events that results in something of value to an actor.

To avoid functional decomposition, make sure that the use-case model helps answer these kinds of questions:

What is the context of the system?
Why are you building this system?
What does the user want the system to do?
How do the users benefit from the system?

Nonfunctional Requirements

It is quite easy to see that use cases are a very good way of capturing functional requirements on a system. But what about the nonfunctional requirements? What are they, and where are they captured?

Usability, reliability, performance, and supportability requirements are often categorized as nonfunctional requirements (also see Guideline: Supporting Requirements). They often specify statutory or regulatory requirements that you must comply with, by law. They can specify design constraints, such as the operating system used, the platform environment, interface requirements, business rules, or any application standards that apply. In general, you can say that any requirement that does not allow for more than one design option should be regarded as a design constraint.

Many nonfunctional requirements apply to an individual use case and are captured within the flow of events of that use case or as a special requirement of that use case (see Concept: Use Case).

Example

In a recycling machine system, a nonfunctional requirement specific to the Return Deposit Items use case could be:

The machine must be able to recognize deposit items with a reliability of more than 95%.

Often, the nonfunctional requirements apply to the whole system. Such requirements are captured in the Artifact: Supporting Requirements.

Example

In the recycling machine system, a nonfunctional requirement that applies to the whole system could be:

The machine will allow only one user at a time.

Structuring the Use-Case Model

There are three main reasons for structuring the use-case model:

To make the use cases easier to understand.
To partition common behavior described within many use cases
To make the use-case model easier to maintain.

Structuring is not the first thing you do, however. There is no point in structuring the use cases until you know a bit more about their behavior than a one-sentence description. You should at least have established a step-by-step outline for the flow of events of the use case to make sure that your decisions are based on an accurate understanding of the behavior.

To structure the use cases, you use three kinds of relationships. You will use these relationships to factor out pieces of use cases that can be reused in other use cases, or that are specializations or options for the use case. The use case that represents the modification is called the addition use case. The use case that is modified is called the base use case.

If there is a part of a base use case that represents only the result of a function that the use case depends on, not the method used to produce the result, you can factor that part out to an addition use case. The addition is explicitly inserted in the base use case, using the include relationship. For more information on the include relationship, see Concept: Use-Case Model.
If there is a part of a base use case that is optional, or it is not necessary to understand the primary purpose of the use case, you can factor that part out to an addition use case to simplify the structure of the base use case. The addition is implicitly inserted in the base use case, using the extend relationship. For more information on the extend relationship, see Concept: Use-Case Model.
If there are use cases that have commonalities in behavior and structure, as well as similarities in purpose, their common parts can be factored out to a base use case (parent) that is inherited by addition use cases (children). The child use cases can insert new behavior and modify existing behavior in the structure they inherit from the parent use case. For more information on use case generalization, see Concept: Use-Case Model.

You can use actor generalization to show how actors are specializations of one another. For more information on actor generalization, see Concept: Use-Case Model.

Example

Consider part of the use-case model for an order management system.

It is useful to separate an ordinary Customer from an Internet Customer, because they have slightly different properties. However, given that Internet Customer does exhibit all properties of a Customer, you can say that Internet Customer is a specialization of Customer, which you indicate with an actor generalization.

The concrete use cases in this diagram are Telephone Order (initiated by the Customer actor) and Internet Order (initiated by Internet Customer). These use cases are both variations of the more general Place Order use case, which in this example is abstract. The Request Catalog use case represents an optional segment of behavior that is not part of the primary purpose of Place Order. It has been factored out to an abstract use case to simplify the Place Order use case. The Supply Customer Data use case represents a segment of behavior that was also factored out, because it is a separate function, and only the result affects the Place Order use case. The Supply Customer Data use case can also be reused in other use cases. Both Request Catalog and Supply Customer Data are abstract in this example. Figure 1 is a use-case diagram that shows part of the use-case model for an order management system.

Figure 1 . As a use-case diagram that shows part of the use-case model for an order management system.

Figure 1. Use-case diagram of an order management system

The following table shows a more detailed comparison of the three different use-case relationships:

Table 1: Comparison of different use-case relationships

Question	Extend	Include	Generalization
What is the direction of the relationship?	The addition use case references the base use case.	The base use case references the addition use case.	The addition use case (child) references the base use case (parent).
Does the relationship have multiplicity?	Yes, on the addition side.	No. If you want to include the same segment of behavior more than once, that needs to be stated in the base use case.	No.
Does the relationship have a condition?	Yes.	No. If you want to express a condition on the inclusion. you need to say that explicitly in the base use case.	No.
Is the addition use case abstract?	Often yes, but not necessarily.	Yes.	Often no, but it can be.
Is the base use case modified by the addition?	The extension implicitly modifies the behavior of the base use case.	The inclusion explicitly modifies the effect of the base use case.	If the base use case (parent) is instantiated, it is unaffected by the child. To get the effects of the addition, the addition use case (child) must be instantiated.
Does the base use case have to be complete and meaningful?	Yes.	Together with the additions, yes.	If it is abstract, no.
Does the addition use case have to be complete and meaningful?	No.	No.	Together with the base use case (parent), yes.
Can the addition use case access attributes of the base use case?	Yes.	No. The inclusion is encapsulated, and recognizes only itself.	Yes, by the normal mechanisms of inheritance.
Can the base use case access attributes of the addition use case?	No. The base use case must be well-formed in the absence of the addition.	No. The base use case knows only about the effect of the addition. The addition is encapsulated.	No. The base use case (parent) must, in this sense, be well-formed, in the absence of the addition (child).

Another aspect of organizing the use-case model for easier understanding is grouping the use cases into packages. The use-case model can be organized as a hierarchy of use-case packages. For more information on use-case packages, see Concept: Use-Case Model.

Figure 2 shows the use-case model hierarchy. Arrows indicate possible ownership.

Figure 2. Diagram showing use-case hierarchy, with arrows indicating possible ownership

Figure 2. Use-case hierarchy

Relationship Between Use Cases and Actors

Running each use case includes communication with one or more actors. A use-case instance is always started by an actor asking the system to do something. This implies that every use case should have communicates-associations with actors. The reason for this rule is to enforce that the system provides only the functionality that users need and nothing else. Having use cases that no one requests is an indication that something is wrong in the use-case model or in the requirements.

However, there are some exceptions to this rule:

If a use case is abstract (cannot be instantiated), its behavior may not include interaction with any actor. In that case, there will not be any communication-associations to actors from that abstract use case.
A child use case in a generalization-relationship does not need to have an actor associated with it if the parent use case describes all actor communication.
A base use case in an include-relationship does not need to have an actor associated with it if the inclusion use case describes all actor communication.
A use case may be initiated according to a schedule (for example, once a week or once a day), which means that the system clock is the initiator. The system clock is internal to the system; therefore, the use case is not initiated by an actor but by an internal system event. If no other actor interaction occurs in the use case, it will not have any associations to actors. However, for clarity, you can use time as an actor to show how the use case is initiated in your use-case diagrams.

The Survey Description

The survey description of the use-case model should:

State the primary use cases of the system (the reason the system is being built).
Summarize important technical facts about the system.
Delimit things that the system is not supposed to do.
Summarize the system's environment, such as target platforms and existing software.
Describe any sequences in which use cases are normally performed in the system.
Specify functionality not handled by the use-case model.

Example

Following is a sample survey description of the recycling machine's use-case model:

This model contains three actors and three use cases. The primary use case is Recycle Items, which represents the main purpose of the recycling machine.

These are the supporting use cases:

Print Daily Report, which allows an operator to get a report on how many items have been recycled.

Administer Deposit Item, which allows an operator to change a refund value for a type of deposit item or to add new deposit item types.