Presentation
Layer Process —> Essential Use Cases
When a Use Case is Essential and Ready for Prime Time
Concepts by Larry Constantine - www.foruse.com
A use case is "ready" when four things are true:
- It is expressed at an approprate level of abstraction. It is abstract
and generalized but still specific to the particular task case and the application
being designed. In other words, it is not "unsuitably vague."
("Expressing needs" as a user intention is unsuitably vague; "specifying
kinds of entertainment of interest" is not.)
- It is technology and implementation independent. It has
been purged of all technological or implementation terms and of all references,
explicit or implicit, to specific solutions. This includes hidden assumptions
in such technology-oriented words as "list" (implies a list of items). Seemingly
innocent common words like "search" often carry implied baggage. (A user
may intend to "find" or "get" or "identify" something, but "search" is a
specific technology solution, not a user intention. The moment you use the
word, it becomes all but impossible not to visualize a search box with a
"go" button.)
- It is expressed in terms of ordinary user language. The
defined vocabulary of the subject matter or application domainis easily understood.
Elements of the subject matter or application domain are correctly and consistently
referenced.
- It is complete, meaning the user can perform the
intended task it
represents. We can verify completeness by walking through the task case,
asking whether the user could complete the task assuming a user interface
that supplied the necessary features and a system that carried out its
responsibilities.
With regards to the last criterion, completeness may refer only to the
"happy path " or also to exceptions and alternatives, depending on resources
and level of formality of the process. If it is a small application being designed
under agile conditions, extensions may be allowed to emerge as needed rather
than being elaborated and validated explicitly at the outset.
Essential Use Case Example
Getting Cash From an ATM
| User Intention |
System Responsability |
| identify self |
verify identity
offer choices |
| choose |
dispense cash |
| take cash |
|
Benefits of Creating Essential Use Cases
In essential use cases, the idea of a responsibility is to identify what the
system must do to support the use case, without making commitments as to how
it will actually be done. This resembles object encapsulation, where the internals
of an object cannot be directly accessed from outside, and it has similar benefits.
This role of responsibility in use cases is entirely consistent with the role
of responsibility in design. Both describe behavior without describing implementation.
This commonality presents valuable opportunities to link the way we work when
determining requirements and the way we work when determining design.