Lesson 3 - UML - Use Case Specification

In the previous lesson, UML - Use Case Diagram, we introduced use case diagrams. We created a simple use case diagram of a content management system similar to ICT.social. Now, in today's UML tutorial, let's take a look at this model and add a use case specification to it.

Use Case Specification

The UC diagram itself shows which features the system provides and how (by whom) they are executed. However, there is no additional information about individual use cases except their names.

This problem solves the Use Case Specification. It's an additional document that is attached to the use case diagram. It has no strict form, it can be a table or plain text.

The use case specification includes the individual use cases, defining several details for each of them. First of all, we're going to describe the details, and then we'll create a part of the specification of our Use Case model. Let's go through the individual parts of the specification of one use case:

1. Brief Description

In the first part, we briefly describe the use case, usually in 1 or 2 sentences. This description should explain the functionality provided by the use case and the added value for the user who activates it. We know that the use case diagram describes the functionality from the user's perspective. This rule will also be applied in the UC specification. A sample description could be: "This use case allows you to print the selected document".

2. Actors

In the next part, we mention the names of the actors who participate in the use case. The actors could be the System and User for example.

3. Pre-Conditions

Each use case can have specific conditions that must be met in order to execute it. We can state these in this part of the specification. We can also omit these conditions. A properly installed printer or Internet connection can be examples of pre-conditions. Without those requirements, the UC wouldn't make any sense and will not be executed.

4. Basic flow

Finally, we get to the basic flow. Here we describe interactions between actors and individual use cases. We write the basic flow as a scenario in which the actor and the system take turns. Again, we keep in mind that we describe everything from the user's perspective and focus on the importance of the use case for the user. A common mistake is to describe what the system displays, what the user fills into the form, and so on. The description should be always completely free from how the system looks, it should focus on how it works. The basic flow does not expect possible errors and it assumes smooth run, where the use case will achieve its goal in the last step. We'll show an example below.

5. Alternative flows

The specification may include several alternative flows (scenarios) that allow to respond to deviations from the basic flow. These are faults or errors, either made by the user (incorrectly typed password) or the system (failed to print the document). An alternative flow always refers to a particular step of the basic flow and solves its non-standard behavior. Mostly, at the end, it refers to a step of the basic flow, where the basic flow continues.

6. Post-Conditions

As there can be pre-conditions for a use case before being executed, a use case may also have conditions before it's considered done. For example, post-conditions can be e.g. that no errors occurred or that all the errors has been logged in the error log.

Let's now focus on our first use case, which is Post a comment. We can write the specification for it:

UC1 - Write a comment

Now, we have an idea ​​how the UC specification looks like. You can add the specification for another UCs from our use case diagram.

More complex UC diagrams

Below is an example of a more complex UC diagram. You can see what a real reclamation system diagram looks like:

Relationship between requirements and UC Diagram

We will not get a finished use case diagram from the customer but only the list of requirements. Once we classify the requirements using the FURPS method and get the functional requirements, we'll create a use case diagram. To make sure that each requirement is realized by a UC and that we have not forgotten any, we often use a table to map the requirements to corresponding use cases. It may look like this:

In the table, there's a column for each use case (in this example, we have only 4 use cases). The rows represent functional requirements from the customer (3 in our example). We can see that the F1 functional requirement is realized by multiple UCs. This can happen if the customer makes a "Manage articles" request, for example, and we'll break it into the UC Publish an article, UC Find an article, and UC Reject an article. On the contrary, the F2 requirement is realized only by a single UC. For F3, we can see that it's not realized by any UC, it's a mistake. When there are many UCs, finding these types of errors is the reason for making this table. So we can be sure that the system will contain everything according to its requirements.

In the next lesson, UML - Domain Model, we'll draw a domain model.