Essential use cases express the essence of what a software application or system must do to fulfill the goals of its
users. They are at the appropriate level of granularity to optimize communication between stakeholders and developers
for areas of the system that are already understood by the team and stakeholders.
Essential use cases are brief and exclude detailed specifications. Any detail is usually provided in the scenarios
descriptions or test cases.
Essential use cases are:
-
User driven, with one use case covering a high level process (series of steps or interactions) that provides an
outcome of value to the users of the system.
-
Strongly focus on getting the flow of user interaction right without being tied to the detail, particular
technology, or describing the user interface design.
-
Focused on describing use and user interaction.
Stakeholders must be able to clearly see how an essential use case achieves their goals for the system, and
developers need to better understand the business context for the functions they need to build. This is true
of any use case. Essential use cases can make these benefits even clearer because the team requires less information
than a fully detailed use case. This emphasis on processes of value means that essential use cases can also be useful
in prioritization and planning.
Essential use cases are good for deriving test cases for both user acceptance test (UAT) and system/integration
testing. Unit test cases can potentially be spun off from these higher level test cases without significant extra
effort.
Characteristics of Essential Use Cases
Characteristic
|
Description
|
Inclusion of Create-Read-Update-Delete (CRUD) functions
|
CRUD functionality is a portion of a use case. All of these operations are covered within the Main Flow or
Alternate Flows, usually of the same use case.
|
Actor generalization
|
Actors in the use case model have been well generalized. Generalized Actors are typically users who inherit
the same functionality, even though they can hold different job roles or titles, or access a system
through different channels.
|
Value based flows
|
All use cases' basic flows complete a major interaction with the system – a set of steps or process that
provides a result of value to the users.
|
Technology agnostic
|
Use cases are not associated with system or architectural components, and will often include functionality
that spans sub-systems or components.
|
Not a user interface design
|
Use cases are completely independent of user interface implementations. No reference is made to screens or
screen elements such as controls or menus.
|
Many alternate flows
|
Use cases contain many alternate flows. Any exception processing that may occur as a deviation from the
basic flow is included as an alternate flow.
|
One Use Case can include many scenarios
|
Use cases represent many concrete examples of scenarios. The main flow will cover the most common
occurrence, but other scenarios can be derived by following the main flow and branching off into the
different alternate flows.
|
Higher level test cases can be derived
|
Use cases are useful for usability and system/integration testing. These types of tests typically exercise
the system from “end to end”, rather than just a subset of functionality.
|
References
[CON99], [BIT02], [AMB04]
|