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

Capturing alternative paths, exceptions and business logic.

Expand Messages
  • Okun, Kiril
    The list has been quiet for awhile, so here is a discussion topic to, hopefully, stir up the pot. I have been working on a large project to replace a number of
    Message 1 of 3 , Mar 7, 2002
    • 0 Attachment
      The list has been quiet for awhile, so here is a discussion topic to,
      hopefully, stir up the pot.

      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?

      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?

      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?

      I hope these questions are relevant to all and will spur good discussion.

      Best,

      Kiril Okun
      CapitalOne - CRS
      208-472-6323
      kiril.okun@...








      **************************************************************************
      The information transmitted herewith is sensitive information intended only
      for use by the individual or entity to which it is addressed. If the reader
      of this message is not the intended recipient, you are hereby notified that
      any review, retransmission, dissemination, distribution, copying or other
      use of, or taking of any action in reliance upon this information is
      strictly prohibited. If you have received this communication in error,
      please contact the sender and delete the material from your computer.
    • Larry Constantine
      Kiril, Thanks for opening up some important issues with your questions. ... Keeping the essential narrative to the main flow or success case is so widely
      Message 2 of 3 , Apr 18, 2002
      • 0 Attachment
        Kiril,

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

        --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
      • Okun, Kiril
        Larry, thank you for your thoughtful reply. I will bring up these points with my compatriots. Please, feel free to post this template. It was mostly based on
        Message 3 of 3 , Apr 22, 2002
        • 0 Attachment
          Larry,
          thank you for your thoughtful reply. I will bring up these points with my
          compatriots.
          Please, feel free to post this template. It was mostly based on your
          original template with additions from Cockburn's book and our specific
          project requirements.

          The conference looks very interesting, and I will do my best to make it.

          Truly yours,

          Kiril Okun
          Capital One - CRS
          208-472-6323

          -----Original Message-----
          From: Larry Constantine [mailto:lConstantine@...]
          Sent: Thursday, April 18, 2002 1:27 PM
          To: usage-centered@yahoogroups.com
          Cc: Okun, Kiril
          Subject: RE: [usage-centered] Capturing alternative paths, exceptions
          and business logic.


          Kiril,

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

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







          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


          **************************************************************************
          The information transmitted herewith is sensitive information intended only
          for use by the individual or entity to which it is addressed. If the reader
          of this message is not the intended recipient, you are hereby notified that
          any review, retransmission, dissemination, distribution, copying or other
          use of, or taking of any action in reliance upon this information is
          strictly prohibited. If you have received this communication in error,
          please contact the sender and delete the material from your computer.
        Your message has been successfully submitted and would be delivered to recipients shortly.