Loading ...
Sorry, an error occurred while loading the content.

144RE: [usage-centered] Capturing alternative paths, exceptions and business logic.

Expand Messages
  • Larry Constantine
    Apr 18, 2002

      Thanks for opening up some important issues with your questions.

      > I have been working on a large project to replace a number of disparate
      > systems supporting a financial services business with an off-the-shelf
      > product, which will act as a system of record, a batch processor
      > and a call
      > center UI.
      > Our first step was to discover and document "the world" as it is today,
      > since there was no coherent business domain documentation. We
      > accomplished
      > it by creating a business use case model to describe existing business
      > processes. (We're using Rational Rose for modeling activities.)
      > After that we went through the business model and identify required
      > actor-system interactions and created system use cases.
      > The next task to elaborate system use cases, and here're the questions.
      > 1. It seems that all essential use case examples that I've seen describe
      > the main path of interaction, leaving out alternative and exception paths.
      > I'm reluctant to use extension use cases to capture other paths
      > for the fear
      > of making the model unreadable. Is there a better way?

      Keeping the essential narrative to the main flow or "success case" is so
      widely practiced because that's what usually works best for so many
      purposes, but especially for guiding interaction design and user interface
      design. This practice keeps the design focused on essentials and leads to
      cleaner interactions. However, the alternatives and exceptions ultimately
      need to be modeled and handled somewhere. We expand these as extension use
      cases whenever the extension cases make sense in and of themselves and are
      of use (or potential use) elsewhere, that is in other use cases. If not, we
      follow Alistair Cockburn's suggestion, and describe them as internal
      extensions or "footnotes" within the base use case.

      The real point is embodied in Constantine's Third Law: "Complexity, though
      easily created, cannot be eliminated but can only be hidden or moved from
      one place to another." Putting exceptions in separate use cases does not
      make the model any more complex or unreadable, it just moves the complexity
      from one place to another. Either you have fewer but messier use cases or
      you have more but cleaner ones. Experienced modelers try to strike a
      balance, such as that suggested by the best practices just described.

      Ideally, we would like to see the software tools recognize this problem and
      incorporate structured use cases so that, at a click of a button or link,
      one could trace all the external extensions, see them on one page as if they
      were internal, or extract internal extensions into external extension cases.
      We keep trying to get the tool vendors to listen.

      > 2. As we're elaborating use cases with our users, much of business logic,
      > procedural and legal constraints will come out. They must be
      > captured. In
      > the past I used activity diagrams to map out logic behind system
      > responsibilities. Is anybody doing something different?

      Following Ellen Gottesdiener's recommendations, we capture and retain
      business rules in a separate model that is cross-linked to the essential use
      cases. The use cases contain references to applicable business rules, and
      each rule refers to the use cases affected. Putting them inside use cases is
      an invitation to mistakes and maintenance headaches.

      > 3. Recently I have re-read the book that started it all "Usage Centered
      > Design..." and it made me wonder if I overloaded the essential use case
      > narrative with my modified template (attached) too much. The information
      > that I added is useful, but it does make each use case a bit heavier. Any
      > suggestions?

      The template looks very thorough and well thought out, but, as you say, it
      has been weighted down some. We have always been hesitant to try and put too
      much into any one model. Independent but cross-linked models are generally
      better. One consequence of cramming so much into the use case narrative is a
      great deal of redundancy and wordiness. We would address stakeholder issues
      at the system/context level, but rarely if ever at the use case level, as
      any significant impact on the task model is typically carried through by way
      of the role/actor model. I would also have reservations about some sections.
      For example, inclusion of "triggers" and "implementation notes" violates
      essential modeling.

      One danger of such heavily loaded models is that they promote a kind of
      obsessive-compulsive approach to box-filling. The modeling drags out into an
      exercise in tedium within which an appreciation for the forest gets lost in
      the recording of every leaf on every tree. This becomes a variant disease of
      the old analysis paralysis.

      The Extreme Programmers have an expression, YAGNI ("You ain't going to need
      it.") that applies. In our experience, much of the time all the stuff that
      gets stuffed into bloated use cases never gets read or used in any any
      meaningful way. We strongly favor the cleanest, simplest use case model that
      supports good visual and interaction design, with elaboration only later and
      as necessary. In the YAGNI spirit, for example, most of the "future
      improvements" and "implementation notes" that one could write when doing the
      task modeling will most likely prove to be wrong headed or outright wrong
      once the system is being built or actually being used.

      Another danger is that modelers get so worn down by the implicit
      requirements of documenting so much, that they start just ignoring or
      skipping over all the extra stuff, which can lead to a false sense of
      security about what is or is not in the model. If it takes a lot to write
      such stuff, it also takes a lot to understand it. In addition, all that
      information has to be maintained, which it will almost certainly not be.
      Often, where highly elaborate use cases have been developed initially, very
      quickly much of the contents becomes obsolete or even wrong, so they are, in
      effect, discarded after one use. Much more streamlined use cases are more
      apt to remain valid or to be maintained as the project continues and the
      application evolves.

      That said, the direction your template takes might be justified in some very
      large projects with many participants and an external or business need (or
      mandate) for highly structured, systematic process. In that context, I could
      myself argue in favor of almost everything you have added, and even add a
      few more things myself. However, in many cases, YAGNI rules. For my part, I
      would still do most or all of my initial modeling on index cards and leave
      the box-filling to someone with the stomach and talent for it.

      I hope to see you at forUSE 2002 in August (www.forUSE.com/2002/).

      BTW, would you have any objection to our posting your comprehensive use case
      template on our Web site? Others in similar circumstances might find it

      --Larry Constantine
      Director of Research & Development | Constantine & Lockwood, Ltd.
      58 Kathleen Circle | Rowley, MA 01969
      t: +1 978 948 5012 | f: +1 978 948 5036 | www.foruse.com
    • Show all 3 messages in this topic