Use Cases are Agile Tools

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.

Use cases are agile tools with side view

Use Case: agile, simple-minded, with a side view (P. Picasso)

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.

Use cases at the hub of UML diagrams

Use cases can be easily combined with a wide range of modeling tools

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

Execution paths & Development cycles

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.

BP2SOA_4

Mapping Processes to Services (through Users’ Stories)

Depending on targeted architectures, those features may or may not be implemented by services.

Further Reading

External Links

Advertisements

4 Responses to “Use Cases are Agile Tools”

  1. Karl Walter Keirstead Says:

    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?

    Like

  2. Karl Walter Keirstead Says:

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

    Like

  3. caminao Says:

    So we agree: use cases can walk alone.

    Like

  4. abiggecko Says:

    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.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: