Overview:

This artifact is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the project team.

Explanation:

A use-case model is a model of how different types of users interact with the system to solve a problem. As such, it describes the goals of the users, the interactions between the users and the system, and the required behavior of the system in satisfying these goals.

A use-case model consists of a number of model elements. The most important model elements are: use cases, actors and the relationships between them.

A use-case diagram is used to graphically depict a subset of the model to simplify communications. There will typically be several use-case diagrams associated with a given model, each showing a subset of the model elements relevant for a particular purpose. The same model element may be shown on several use-case diagrams, but each instance must be consistent. If tools are used to maintain the use-case model, this consistency constraint is automated so that any changes to the model element (changing the name for example) will be automatically reflected on every use-case diagram that shows that element. The use-case model may contain packages that are used to structure the model to simplify analysis, communications, navigation, development, maintenance and planning.

Much of the use-case model is in fact textual, with the text captured in the Use-Case Specifications that are associated with each use-case model element. These specifications describe the flow of events of the use case.

The use-case model serves as a unifying thread throughout system development. It is used as the primary specification of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning, as the basis of defining test cases and as the basis for user documentation

Basic model elements:

The use-case model contains, as a minimum, the following basic model elements.

• Actor: A model element representing each actor. Properties include the actors name and brief description.
• Use Case: A model element representing each use case. Properties include the use case name and use case specification.
• Associations: Associations are used to describe the relationships between actors and the use cases they participate in. This relationship is commonly known as a "communicates-association".

Advanced model elements:

The use-case model may also contain the following advanced model elements.

• Subject: A model element that represents the boundary of the system of interest.
• Use Case Package: A model element used to structure the use case model to simplify analysis, communications, navigation, and planning. If there are many use cases or actors, you can use use-case packages to further structure the use-case model in much the same manner you use folders or directories to structure the information on your hard-disk.
• You can partition a use-case model into use-case packages for several reasons, including:
  • To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning.
  • To support parallel development by dividing the problem into bite-sized pieces.
  • To simplify communication with different stakeholders by creating packages for containing use cases and actors relevant to a particular stakeholder.
• Generalization: A relationship between actors to support re-use of common properties.
• Dependencies: A number of dependency types between use cases are defined in UML. In particular, <<extend>> and <<include>>. <<extend>> is used to include optional behavior from an extending use case in an extended use case. <<include>> is used to include common behavior from an included use case into a base use case in order to support re-use of common behavior.
  The latter is the most widely used dependency and is useful for:
  • Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case to simplify communications.
  • Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and ensure consistency.

Example Use-Case Diagram:

Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.

Figure 1: ATM Use-Case Diagram

This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and Maintenance Person), five use cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three <<includes>> dependencies, and the associations between the performing actors and the use cases.

The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use cases <<include>>. The base use cases are independent of the method used for identification, and it is therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on the result of Validate Customer.

Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions of each actor, descriptions of each use case, and use-case specifications for each use case.

Check Items:

• Is it easy to understand what the system does by reviewing the model? 
  • Does the Use-Case Survey provide a clear, concise overview of the purpose and functionality of the system?
  • Are there no long chains of include relationships, such as when an included use case includes other use cases? These can obscure comprehension.
  • Are included use cases independent of the use cases that include them?
  • If several use cases contain similar subflows, have you investigated whether factoring this common behavior into an included use case will simplify the model? 
• Have all use cases been identified? 
  • Do the use cases identified collectively account for all required behavior of the system?
  • Have all features identified in the Vision document for this iteration been addressed by at least one use case?
  • Have all nonfunctional requirements that must be satisfied by a specific use case been captured in that use case?
  • Have you verified that the use-case model contains no superfluous behavior (known as "gold-plating")?
  • Is each concrete use case associated with at least one Actor, as it should be?
  • Is every Actor associated with at least one use case? 
• Is the model consistent? 
  • Is the system behavior consistent under the same conditions and with the same input? 
• Are all relationships between use cases required? 
  • Does each included use case make the model easier to understand, implement, and maintain?
  • Is each concrete use case (not an included use case) independent of other use cases?
• Are use-case packages used appropriately? 
  • Have cross-package dependencies been reduced or eliminated to prevent model ownership conflicts
  • Is packaging intuitive? Does the packaging make the model easier to understand and implement? 
• Do all model elements have appropriate names? 
  • Have you verified that no two use cases have the same name?
  • Does each Actor have a name that effectively describes that person's Role?
• Are individual use cases properly specified? 
  • Have you reviewed the quality of each use case specification using the Checklist: Use Case.

Guideline:

The key to successful iterative development is ensuring that the development team maximizes stakeholder value and minimizes risk early in the lifecycle, while minimizing re-work later. This imposes some constraints on how we develop the use-case model.

At one extreme is the classical waterfall approach, which attempts to detail all of the requirements prior to design and implementation. This approach delays delivery of stakeholder value and risk reduction unnecessarily.

At the other extreme is beginning development prior to understanding what the system must do. This approach results in significant, and costly, re-work later in the lifecycle.

A better approach is to detail only those requirements which will be the focus of development in the next iteration (or two). Selection of these requirements is driven by value and risk, and thus requires as a minimum an abstract understanding of the "big-picture".

The following discussion will outline the approach used to evolve the use-case model to achieve these goals.

How the Use-Case Model Evolves:

The recommended approach to evolving the use-case model takes a "breadth before depth" approach. In this approach, one identifies the actors and use cases and outlines them quickly. Based on this knowledge, one can then perform an initial assessment of risk and priorities and thus focus the effort of detailing the use cases on the right areas.

Inception:

The purpose of inception is to understand the scope of the system. We need to understand the main purpose of the system, what is within the scope of the system, and what is external to the system. We should strive to list all the primary actors and use cases, however we don't have the luxury of being able to detail all of these requirements at this time. Strive to identify by name ~80% of the primary actors and use cases and provide a brief description (one - three sentences) for each.

Identify Stakeholders
Begin by listing all the external stakeholders for the system. These individuals will be the source of the requirements.

 

Identify Actors
Name and describe the primary actors. See Guideline: Find and Outline Actors and Use Cases.

 

Identify Use Cases
For each actor, ask "what does this actor want to accomplish with the system"? This will reveal the primary use cases for the system. Name and describe each of these as you discover them.

 

Update the Use-Case Model
Update the use case model to capture the actor and use case names and brief description. Capture the relationship between the actors and use cases.

 

Outline the Basic Flows
For those use cases that are considered high priority by the stakeholders, or high risk by the development team, capture a step-by-step description of the Basic Flow. Don't worry about structuring the flow at this point. Focus on capturing the dialogue between the actor and the system and the key requirements for the system.

 

Identify Alternate Flows As you work through the Basic Flows, ask: "What can go wrong?"; "What options are available at this point?"; etc. These types of questions will reveal alternate flows. Capture these, giving each a name and brief description. Fight the urge to detail these alternate flows at this time.

 

Refactor the Use Case Model
Based on the Basic Flows you have identified, determine if there is common behavior that could be factored out into <<include>> use cases. Refactor the Use Case model accordingly.

 

Prioritize Use Cases
Given the abstract description you now have of the requirements, work with stakeholders to prioritize the use cases. This will be the primary input to iteration planning.

Elaboration:
The purpose of elaboration is to demonstrate the feasibilty of the solution prior to committing additional resources. To be successful, one should demonstrate that stakeholder value can be delivered and that the risk of continuing is acceptable. We should strive to detail and implement ~20% of the scenarios. These scenarios should be selected to achieve good coverage of the architecture (for example, a vertical slice through the architecture, touching as many components and interfaces as possible, is preferred to elaborating the GUI only).

Detail Basic Flow For those UC selected for the next iteration, spend the time to detail the basic flow now. See Guideline: Detail Use Cases and Scenarios.

 

Detail Alternate Flow
For those alternate flows selected for the next iteration, spend the time to detail the flows now.

 

Update the Use-Case Model Update the Use-Case Model to capture any refinements made as a result of your work. Depending upon the complexity of the system, you may want to introduce packages to group the use cases in a logical manner to simplify communications, iteration planning, and parallel development.

Construction:

The purpose of construction is to incrementally deliver functionality (and value). Working from the iteration plan, continue detailing the remaining requirements. Shoot for completion of ~90 - ~95% of use cases by the end of construction.

Detail Basic Flows
For those UC selected for the next iteration, spend the time to detail the basic flow now. See Guideline: Detail Use Cases and Scenarios.

 

Detail Alternate Flows For those alternate flows selected for the next iteration, spend the time to detail the flows now.

 

Update the Use-Case Model
Update the Use-Case Model to capture any refinements made as a result of your work.

Transition:

The purpose of transition is to make the system operational in its intended environment. Some requirements will still be uncovered at this point, but if we have done things right they should not stress the design. The remaining ~5% to ~10% of use cases should be detailed and implemented in this phase.

Avoiding Functional Decomposition:
A common pitfall for those new to use-case models is to perform a functional decomposition of the system. This results in many small "use cases", that on their own do not deliver the "observable result of value" to the actor. 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?

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.

There are several advanced modeling concepts available in the literature for structuring the use-case model, however, following the principle of "keep-it-simple" only the most useful of these, namely the <<include>> relationship is discussed in this process. This relationship permits one to factor out common behavior into a separate use case that is "include" in other use cases. See Concept: Use-Case Model for more details.

Another aspect of structuring 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.

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:

• An "included" use case might not interact with an actor if the base use case does.
• 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. CAUTION: if you have a lot of "time" actors in your model, challenge them. Perhaps you missed a real actor, such as an administrator responsible for scheduling reports, etc.