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
Not too surprising given that one of the largest proponents of use cases (Alastair Cockburn) is also one of the signatories of the Agile Manifesto.
So we agree: use cases can walk alone.
(cont’d)
When designing a process map, you need enough detail so that stakeholders in brainstorming sessions can see where improvements can/should be made. Once the map is published it is only rarely consulted except in construction where it is convenient to mark up the diagram with a felt pen marker.
When rolling out a process to a run-time environment for b2b where you can easily have 100 live instances of a template, the basic rule for level of detail is to split a task if there is a change in skill because there will be a handoff and we know that delays between handoffs can significantly impact reaching goals/objectives.
In my consulting business we won’t send out a consultant unless/until they are able to map in real time as fast as the customer says “… and then we do this”. They usually don’t need a lot of training.
Building rule sets typically does require IT involvement. Most of the rule sets needed by our customers are of the if-then variety – we don’t get to where reverse reasoning is required.
Example: In healthcare you get a lot of “A or B plus two from C thru F plus E plus G” and this type of math can be handled with a few counting variables and one consolidating variable.
I think many BPM practitioners over-complicated their mapping and run-time software systems .
I very much like “the aim of use cases is to describe what happens between users and systems.”. Very clear . . .
I can’t imagine how we got to “Use cases are often associated with the whole of UML diagrams, and consequently with cumbersome procedures, and excessive overheads.”
If BPM is an derivation of Critical Path Method, the act of mapping out a once-through process (from 1957) was fairly straightforward (nodes/arcs),
Of course there were a few attributes such as duration, resource consumption, costs and you had to designate certain nodes as “milestones” in order to have the software perform ES-EF-LS-LF and “float’ calculations.
Today, of course, we have branching decision boxes, gatekeeper nodes, loopbacks and yes, we have to have rule sets at many of these slightly special nodes but other than these few constructs, it seems a bad turn to have invented “languages”
I can’t see where in this there is a need for a UML?