Preamble
Use cases are often associated with the whole of UML diagrams, and consequently with cumbersome procedures, and excessive overheads. But like cats, use cases can be focused, agile, and versatile.
Simple minded, Robust, Easy going
As initially defined by Ivar Jacobson, the aim of use cases is to describe what happens between users and systems. Strictly speaking, it means a primary actor (possibly seconded) and a triggering event (possibly qualified); that may (e.g transaction) or may not (e.g batch) be followed by some exchange of messages . That header may (will) not be the full story, but it provides a clear, simple and robust basis:
- Clear and simple: while conditions can be added and interactions detailed, they are not necessary parts of the core definition and can be left aside without impairing it.
- Robust: the validity of the core definition is not contingent on further conditions and refinements. It ensues that simple and solid use cases can be defined and endorsed very soon, independently of their further extension.
As a side benefit, use cases come with a smooth learning curve that enable analysts to become rapidly skilled without being necessarily expert.
Open minded and Versatile
Contrary to a somewhat short-sighted perspective, use cases are not limited to users because actors (aka roles) are meant to hide the actual agents involved: people, devices, or other systems. As a consequence, the scope of UCs is not limited to dialog with users but may also includes batch (as one-step interactions) and real-time transactions.
Modular and Inter-operable
Given their simplicity and clarity of purpose, use cases can be easily processed by a wide array of modeling tools on both sides of the business/engineering divide, e.g BPM and UML. That brings significant benefits for modularity.
At functional level use cases can be used to factor out homogeneous modules to be developed by different tools according to their nature. As an example, shared business functions may have to be set apart from business specific scenarii.
At technical level, interoperability problems brought about by updates synchronization are to be significantly reduced simply because modules’ core specifications (set by use cases) can be managed independently.
Iterative
Given their modularity, use cases can be easily tailored to the iterative paradigm. Once a context is set by business process or user’s story, development iterations can be defined with regard to:
- Invariants (use case): primary actor and triggering event.
- Iterations (scenarii): alternative execution paths identified by sequences of extension points representing the choices of actors or variants within the limits set by initial conditions.
- Backlog units: activities associated to segments of execution paths delimited by extension points.
- Exit condition: validation of execution path.
Scalable
Last but not least, use cases provide a sound and pragmatic transition between domain specific stories and architectural features. Taking a leaf from the Scaled Agile Framework, business functions can be factored out as functional features represented by shared use cases whose actors stand for systems and not final users.
Depending on targeted architectures, those features may or may not be implemented by services.
Further Reading
- Thread: use cases
- Thread: Agile
- Use Cases
- Use Cases Patterns
- Use Cases shouldn’t know about Classes
- Business Processes & Use Cases
- Use Cases & Action Semantics
- The Scope of Agile Principles
- Agile vs Waterfall: Right vs Left Brain ?
- How to Mind a Tree Story
- From Stories to Models
- From Processes to Services
- Agile & Models
- Thinking about Practices
- Spaces, Paths, Paces (Part 1)
- Projects as non-zero sum games
- Iterative Processes
- Modeling Paradigm