Intro to Use Case Types

Analyzing or designing the various features and functions of a software system can be daunting, especially when there are multiple actors and other interfacing systems involved. Thankfully, analysts can turn to use cases to make this process much easier.

At the very minimum, an effective use case should:

• define how stakeholders interact with a system
• define how a system interacts with other systems
• provide a common understanding of both stakeholder and system requirements

This article introduces the different types of use cases you may encounter and identifies some of the ways use cases are represented.

Identifying a Use Case

Since Ivar Jacobson first formulated textual and visual modeling techniques for use cases in 1986, quite a bit has changed. However, certain key factors have remained effectively the same; particularly the methods employed to identify use cases.

1. The first and probably most critical step to identify a use case is to first identify the actors because the use case will be written from their points of view.
2. Next, the actor’s functions must be identified as well as the actors’ actions within the system.
3. Last but not least, it is important to identify all external events that can influence the actors and system as the actors perform their functions within the system.

Below is an illustration of the identification process.

Use Case Example

So how do you identify a use case? Well, suppose that ABC Corp has customers that must register on ABC’s online portal in order to receive services. Using the Use Case Identification method, we can determine that the actor is the customer. The actor’s function is to provide personal information to complete his/her profile. The actor’s actions in the system include accessing it to provide personal information. Next, we identify external events. These may come from multiple sources and can also include other use cases. In this example, it will be login credentials provided to the customer by a system administrator (a poor user provisioning method, but that’s a conversation for another day/blog article). In order to provide the credentials to the customer, the system administrator will need to first log into the system themselves with their own credentials. This process has nothing to do with the customer and as a result, “Provide Credentials” is considered an external influence and can be considered its own use case even though it’s performed in the same system (this concept is known as use case partitioning).

Formulating a Use Case

Formulating a use case after having identified the use case is quite simple. Typically, use cases are part of a larger documentation effort and should be named and numbered for easier identification and to facilitate referencing by another use case. Another thing to note is that the primary courses defined for a use case may vary from analyst to analyst. It all depends on how critical each stated step is, as perceived by the analyst. In addition, there are alternative courses to the primary courses and these are typically used to achieve the use case goal using other means that are not used by the primary course. Alternative courses typically handle situations when a primary course fails or deviates due to some specific factor. Using the ABC Corp example, a formulated use case would look like this:

Use Case Name	Complete Customer Profile
Goal	Input personal information into ABC Corp online portal
Use Case ID	UC001
Actors	Customer, System Admin
PreCondition	Customer has login credentials provided by ABC Corp System Admin
Primary Course	Customer accesses ABC Corp’s portal Customer logs in using credentials provided by System Admin System verifies customer and displays personal details entry form Customer enters personal details into form and clicks save System presents a confirmation screen informing the Customer that the  information has been saved
Alternative Course	1a.     System is down   1a1.  Customer emails personal information to System Admin 1a2.   Proceed with Alternative Course 1b.   1b.     System Admin enters customer information 1b1.   System Admin accesses “customer information” functionality 1b2.   System Admin enters personal information emailed by Customer 1b3.   End Use Case   3a. System Cannot verify Customer 3a1.   Customer emails System Admin for credentials reset 3a2.  Resume at step 3

 

Types of Use Cases and their Presentation Methods

There are basically two types of use cases analysts can draw from: Business Use Cases and System Use Cases.  Business Use Cases are more about what a user expects from a system while System Use Cases are more about what the system does. Both use case types can be represented by diagrams or text.

Diagrammatically, both types of use cases are denoted differently. In our example, we have used the System Use Case.

Textual Use Cases

When representing the use cases in textual form, both use case types can be presented as either “informal” use cases or “formal” use cases.  “Informal” use cases are quite brief with just enough information to get the point across. “Formal” use cases are meant to be more detailed.

ABC Corp’s use case UC001 is a good example of a “formal” use case. Below is an “informal” example of use case UC001.

Use Case Name	Complete Customer Profile
Use Case ID	UC001
Primary Course	1.       Customer enters provided credentials   2.       System verifies customer and provides personal details entry form 3.       Customer enters personal details 4.       System presents a confirmation screen informing the customer that the information has been saved 6.       End Use Case

Even though the examples listed above are in tabular form, they are still considered examples of the text-based method of presenting use Cases.

Use Case Diagrams

As mentioned above, use cases can also be represented using diagrams. The UML notation is the most widely used standard.

Within UML notation, use case diagrams are classified as behavioral diagrams. Using ABC Corp’s example above, a typical system use case diagram looks like this:

Use case diagrams can be particularly helpful when multiple actors overlap and perform the same function in the same system. Being able to represent all actors and their interactions with the system in one diagram gives a better picture of the dynamic system behavior.

Although this is a “by the book” standard description of Use Cases, sometime the objective to achieve in your business analysis efforts is just to simply inventory use cases, rather than launching into a fully dressed illustration of each use case’s steps. If so, then a great way to do this fast is with the System Context diagram instead. It can be created rapidly, and also be the basis for more detailed use cases as described here.

Comments