An essential use case (Constantine and Lockwood 1999), sometimes called 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 essential 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. An essential 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.

It isn’t quite accurate to say that an essential use case is a business use case in the RUP sense of the term, although they are very close.  A business use case is often more focused on the business process and existing technology concerns are often brought into them.  Think of them as somewhere in between essential and system use cases, although leaning towards the essential end of the spectrum.

Figure 1 presents an example of a detailed essential 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. An essential 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. Essential use case.

Enroll In Seminar

ID: UC 17

Preconditions:

• The student is enrolled in the university.

Postconditions:

• None

Essential 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).  You basically want to avoid Use Cases of Mass Destruction.

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 essential 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 essential 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 essential 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.

Suggested Reading

• Agile Usability: User Experience Efforts on Agile Software Projects
• Artifacts for Agile Modeling: The UML and Beyond 
• Initial High-Level Architectural Envisioning
• Initial High-Level Requirements Envisioning
• Modeling Style Guidelines
• Use Cases of Mass Destruction
• Why Extend the UML Beyond Object and Component Technology?

		This is the best book to read if you want to learn how how write use cases effectively.
		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		This is a very good book describing techniques for working with your stakeholders, including use case modeling.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.
Other artifact overviews		Use Case Diagrams and System Use Cases.
Other Use Case Writings		UML Use Case Diagram Style Guidelines Reuse in Use Case Models

Translations

• Japanese

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.