Use Case Realization

Use case scenarios should be detailed enough to describe how the user interacts with the system, but they should not include design decisions or implementation details. The scenario should not particularly include statements such as "User clicks on a button" or "System calls a web service". However, as the analysis proceeds, these details must but captured somewhere so that it is clear how the use case steps are going to be realized in the actual system.

DEFINITION

A use case realization describes how a particular use case is realized within the design model, in terms of collaborating objects

Even though all use case steps are the same textual statements describing what the user does with the system, and how the system responds, the character of each of them might be different. Some steps are mini use cases, which could be broken down into lower-level scenarios, some of them represent algorithms, and some refer to a part of the user interface or to a service/function call.

1. Use case step is a mini use case

1. User enters basic invoice data, and selects customer
2. User enters multiple invoice lines
3. System updates the invoice grand total
4. User ...

The step 'Select customer' on line 1 is a use case step, but since it also describes an interaction between the user and the system, it could be considered itself a mini use case too. However, this mini use case does not conform to the use case definition as it has a lower level of detail, so it should not be called a use case. It does not matter if we choose to call it a sub-use case, an activity, or something else, it is important that the mini use cases will be separated from the user-goal use cases. This will guarantee that the set of use cases will remain concise, and it will still be easy to find out the basic user goals of the system.
We personally prefer to model such steps as activities, which could then be described either with a text or using an activity diagram, for example:

2. Use case step performs some algorithm

1. User enters the size and weight of the package
2. System calculates the price of transportation
3. User ...

The final price of transportation is calculated according to the algorithm. The algorithm is, in fact, a business rule, represented by a diagram in this case.

3. Use case refers to a screen

Use cases should not include the user interface details (it is not their purpose). Yet, it is very convenient to provide links from the use case steps to the relevant user interface specification (coherence principle):

4. Use case step is a function call

1. ...
2. User enters address
3. System verifies address. If it's ok, it is associated with the user as the main address.
4. ...

Although this point may seem identical to point 2, there is a difference. While the selected step in the number two refers to the business description of how to calculate the price, in this case, the step "verifies address" refers to the description of the actual system function doing the verification. It could be an internal system function but also a service provided by another system.

Note: It is all right to link the function/service directly from the use case when it is an automatic call. Nevertheless, when the function or service is triggered by some user action, it is a better approach to describe the call in the corresponding user interface artifact instead. This way, the use case then will remain cleaner:

From Use Cases to Artifacts

Use cases are a powerful, user-centric tool for capturing software requirements during the initial analytical phases. However, developers do not implement use cases. They implement screens, functions, interfaces, services, and other design artifacts, so the use cases need to be sooner or later transformed into these artifacts. Also, it is not possible to identify all requirements just with use cases, as use cases are suitable for capturing requirements only at the user-goal level. For these reasons, always take use cases only as a first step to understand the scope and context, but iterate to other techniques as soon as possible. Create wireframes, models, or prototypes. Use cases are not the crucial thing for the implementation, so it is not necessary to spend much time tuning them.

Starting with use cases and breaking them down to more concrete artifacts has a significant side effect. If you take a look at example 4 from the previous section, you may spot that the 'Onclick' behavior description is exactly the same as the corresponding use case step: "System verifies address. If it's ok, ...". Unfortunately, this duplication cannot be easily avoided. The only advice here is to keep the use cases on the user-goal level without including specific details because the fewer details the use case provides, the less likely it will have to be modified when the scenario changes.