Business Use Cases: An Agile Introduction

A business use case, is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner. A fully documented business use case is a structured narrative, expressed in the language of the application domain and of users, comprising a simplified, abstract, technology-free and implementation-independent description of one task or interaction. A business use case is complete, meaningful, and well designed from the point-of-view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction. A business use case is often more focused on the business process (requirements) whereas system use cases are focused on implementation (architecture).

Figure 1 presents an example of a detailed business use case. Notice how brief and to the point the language is. There isn’t a lot of detail because you only need to get the basic idea across. The language of the application domain and of users is used, comprising a simplified, generalized, abstract, technology-free and implementation-independent description of one task or interaction. A business use case is complete, meaningful, and well designed from the point-of-view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction.

Figure 1. Business use case.

Enroll In SeminarID: UC 17Preconditions:

The student is enrolled in the university.

Postconditions:

None

User Intention

System Responsibility

Student identifies himself

Choose seminar

Confirm enrollment

Verifies eligibility to enroll via BR129 Determine Eligibility to Enroll.

Indicate available seminars

Validate choice via BR130 Determine Student Eligibility to Enroll in a Seminar.

Validate schedule fit via BR143 Validate Student Seminar Schedule

Calculates fees via BR 180 Calculate Student Fees and BR45 Calculate Taxes for Seminar.

Summarize fees

Request confirmation

Enroll student in seminar

Add fees to student bill

Provide confirmation of enrollment

Business use cases are typically written in two column format, the column on the left indicates the intention of the user/actor and the column on the right the system’s responsibility to hopefully respond. The actor(s) will try to do something and receive one or more responses to that action. As you can see the flow of the use case is apparent from the spacing of the actions and responses, although you may decide to number the steps to make it more apparent.

The use case refers to business rules but does not embed the rule in the use case, reflecting AM’s practice of Apply the Right Artifact(s). This is a style issue, albeit one that over the years has enabled me to travel light by only recording information in one place (other artifacts will need to refer to business rules as well).

Notice how I’ve chosen to indicate a unique identifier for the use case as well as its preconditions and postconditions. These three pieces of information are optional although very useful. I indicate an identifier whenever I need to reference an artifact somewhere else – for example the use case itself references business rules, each of which have a unique identifier. The preconditions, if any, indicate what must be true before this use case is allowed to run. The postconditions, if any, indicate what will be true once the use case finishes successfully.

A significant advantage of business use cases is that they enable you to stand back and ask fundamental questions like “what’s really going on” and “what do we really need to do” without letting implementation decisions get in the way. These questions often lead to critical realizations that allow you to rethink, or reengineer if you prefer that term, aspects of the overall business process.

When you are business use case modeling you can be technology independent but you will never be perfectly “system independent”. You will always be bound by the scope of your effort, but the vision/goals of your project. As a result the perceived system that you’re building, be it manual, automated, or a hybrid of the two, will always affect your how you write your use cases.

Why business use cases? Traditional/system use cases typically contain too many built-in assumptions, often hidden or implicit, about the underlying technology implementation and the user interface yet to be designed. This is a good feature during your analysis and design efforts, but not so good for your requirement efforts. An essential use case, on the other hand, is based on the purpose or intentions of a user, rather than on the concrete steps or mechanisms by which the purpose or intention might be carried out.

Source

This artifact description is excerpted from Chapter 5 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Translations

Japanese