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

[usage-centered] Documenting Business Requirements thru UCD

Expand Messages
  • tnunes@snet.net
    Hello everyone. I am a new member to this group. I look forward to sharing some great ideas with you all. My question is: Through Use Cases or any other UCD
    Message 1 of 5 , Nov 23, 1999
    • 0 Attachment
      Hello everyone. I am a new member to this group. I look forward to
      sharing some great ideas with you all.

      My question is: Through Use Cases or any other UCD models, how do you
      capture the detailed business requirements? I have just completed the
      first draft of essential use cases (as defined by Constantine &
      Lockwood, whose site directed me to this group) and am preparing to
      review them with the business users. I am anticipating comments like,
      "Yes, that is how the system would be used, but I can't tell from these
      use cases if you've understood all the requirements." I am speaking of
      requirements such as: If option A is chosen, then information XYZ is
      required. How are the business rules and edits captured? Do they
      belong in the use case, or should they be written in a supporting
      document? Any suggestions would be appreciated.
    • Larry Constantine
      ... In our view, it is a mistake to overload use cases by trying to capture all requirements in a single model. Non-functional requirements--such as
      Message 2 of 5 , Dec 1, 1999
      • 0 Attachment
        > My question is: Through Use Cases or any other UCD models, how do you
        > capture the detailed business requirements?

        In our view, it is a mistake to overload use cases by trying to capture all
        requirements in a single model. Non-functional requirements--such as
        performance criteria, minimum availability, deployment platforms, and the
        like--are necessarily a completely different species and should be
        documented apart from the use case model.

        That said, you raise a key issue regarding business rules.

        > How are the business rules and edits captured? Do they
        > belong in the use case, or should they be written in a supporting
        > document? Any suggestions would be appreciated.

        There are three possibilities here.

        (1) Many business rules regarding the contents, relationships among,
        permissible operations upon data naturally belong with or attach to the data
        model (or domain class model). For example, "total of order and outstanding
        balance cannot exceed credit limit." Within use cases, the connection to the
        business rules is often implied by the explicit references to data within
        the interaction narrative (flow of events). A good CASE tool would allow you
        to click through to or surface such attached rules as needed to explore or
        validate the model. In the absence of full CASE support, a flag could draw
        attention to a reference to data constrained by a rule, along with a
        reference to the rule by name, number, etc.

        (2) The business rule applies to the use case (as a whole) or to its
        relationship with other use cases. For example, "Manual positioning (an
        extension use case) is not permitted unless the machine tool has been
        stopped (another extension use case)."

        (3) The business rule applies to a step or steps within the interaction
        narrative (body) of the use case. For example, in the use case for entering
        shipping address, the enter ZIP code step may be constrained by a rule that
        if ZIP code is entered before city and state, these are filled in
        automatically; otherwise ZIP code must match city and state.

        In either (2) or (3), we would prefer to see a reference to the rule by
        name, number, or other identifier. A good CASE tool would allow
        click-through or surfacing the rule.

        The rationale for not copying or repeating the business rules in the use
        cases where they apply is a matter of change management. If a business rule
        changes and it is copied in various places, all such places must be found,
        creating maintenance problems and increasing the risk of error.

        Note also that some business rules can be embedded within or referred to
        within pre- and post-conditions. For instance, we might cover the example in
        (2) as a precondition on the use case. If such pre and post-conditions are
        truly business rules, then they should be referenced as such and point to
        the relevant document.

        So, the answer to your anxious user/customer might be along these lines:
        "First we are going to look at the overall process of entering a new claim,
        leaving out some of the specific rules about what can be entered where and
        when. Then we will go back and check out the detailed rules as they apply to
        this particular task (use case)."

        You may also find it worthwhile to read Ellen Gottesdiener's management
        column in the December Software Development magazine; it deals with use
        cases and business rules as requirements.

        And you may find our upcoming February seminar of value.

        --Larry Constantine <www.foruse.com>
      • Nuno Nunes
        on 01/12/99 19:52, Larry Constantine at lconstantine@compuserve.com wrote: Hello, some comments on our experience with small software developing companies and
        Message 3 of 5 , Dec 2, 1999
        • 0 Attachment
          on 01/12/99 19:52, Larry Constantine at lconstantine@... wrote:

          Hello, some comments on our experience with small software developing
          companies and evolutionary model-based approaches.

          >> My question is: Through Use Cases or any other UCD models, how do you
          >> capture the detailed business requirements?
          >
          > In our view, it is a mistake to overload use cases by trying to capture all
          > requirements in a single model. Non-functional requirements--such as
          > performance criteria, minimum availability, deployment platforms, and the
          > like--are necessarily a completely different species and should be
          > documented apart from the use case model.

          We successfully attach non-functional requirements (business rules and
          others) at different levels in the use case model (at the model level, at
          the use case or relationship level, etc.).
          We also use activity charts to detail use-cases and attach non-functional
          requirements to activities. I think you will find activity graphs very
          useful to capture information like task flows and business rules.

          In a typical OO method you usually have two distinct types of models in
          early inception. One is use case driven (use cases, task flows) and the
          other architecture centric (domain and business model). In our evolutionary
          prototyping approach we found out that mixing both models early in
          development usually produces week architectures (both internal and interface
          architectures). This means that you should avoid populating the domain and
          business models with non-functional requirements.

          So regarding Larry's possibilities I would say (in my context): (1) can be
          dangerous, (2) and (3) together work very well. You can also try replacing
          narrative descriptions in (3) with activity charts. In our experience this
          approach (combined with participatory techniques) fosters communication with
          end users and facilitates requirements discovery and evaluation.

          Hope it helps
          Nuno

          --
          Nuno Jardim Nunes
          University of Madeira - Teaching Assistant
          Mathematics Dep. - Computer Science Unit
          phone: +351 91 705160 (direct) 705150 (secretary)
          fax: +351 91 705199
          URL: http://math.uma.pt/njn/
          Address: Campus Universitário da Penteada
          9000 - Funchal - Portugal
        • Larry Constantine
          ... Good point to note that business rules and non-functional requirements can also apply to relationships among use cases. I am curious about the scope of
          Message 4 of 5 , Dec 2, 1999
          • 0 Attachment
            Nuno Jardim Nunes remarks:

            > We successfully attach non-functional requirements (business rules and
            > others) at different levels in the use case model (at the model level, at
            > the use case or relationship level, etc.).

            Good point to note that business rules and non-functional requirements can
            also apply to relationships among use cases.

            I am curious about the scope of your projects using evolutionary
            prototyping, both in size and in time. How long do you take to develop
            initial models? How long is each iteration through the development cycle.
            How many use cases result and how complex is each (e.g., in pages of
            description)?

            > We also use activity charts to detail use-cases and attach non-functional
            > requirements to activities. I think you will find activity graphs very
            > useful to capture information like task flows and business rules.

            > You can also try replacing
            > narrative descriptions in (3) with activity charts. In our experience this
            > approach (combined with participatory techniques) fosters
            > communication with
            > end users and facilitates requirements discovery and evaluation.

            Our experience is that activity graphs (or diagrams) and other
            logical/programmatic models (such as sequence diagrams, collaboration
            diagrams, data flow diagrams, state-transition diagrams, etc.) can sometimes
            be useful adjuncts to use cases for programmers and software designers, but
            they should not be used as the primary definition of the interaction process
            (flow of events) of external-user-based use cases. Such diagrams, owing to
            their rigor or appearance of rigor, may appeal to academics, hard-core
            programmers, and computer scientists, but not to users. By and large they
            are inappropriate for communication with most ordinary users. An interaction
            narrative, even a structured one, is just a dialogue (or conversation, as
            Rebecca Wirfs-Brock terms it). When expressed in the language of users and
            the application domain (as they are in usage-centered design), they are
            completely natural and intuitable to users--there is nothing to learn.
            Activity graphs (and their kin) comprise notations that must be learned to
            be understood correctly, and there is nothing natural or intuitable about
            most of them.

            In short, one should use narrative forms for requirements gathering and
            communication with users and save the diagrammatic arcana for the software
            engineers.

            The advantage of the more flexible and natural narrative form is even more
            dramatic when it comes to driving user interface design, where the details
            and apparent precision and rigor of the programmatic models are distractions
            that get in the way of understanding the users' intentions and what is the
            essential nature of the tasks. Such detail can and should be added later,
            after a sound usage-centered essential use-case model has been devised, and
            activity diagrams may be useful for such detail.

            > In our
            > evolutionary
            > prototyping approach we found out that mixing both models early in
            > development usually produces week architectures (both internal
            > and interface
            > architectures). This means that you should avoid populating the domain and
            > business models with non-functional requirements.

            > So regarding Larry's possibilities I would say (in my context): (1) can be
            > dangerous, (2) and (3) together work very well.

            I would agree that helter-skelter intermingling of business rules,
            non-functional requirements, and the domain model is not recommended. When I
            said that some business rules "naturally belong with or attach to the data
            model (or domain class model)," I was not suggesting that they should be
            jumbled together. I was referring only to those rules which have a clear and
            simple relationship to elements of the domain model, and meant only that
            they are associated or connected. Business rules, non-functional
            requirements, domain models, and task models are distinct models or views of
            the problem and solution; they are separate but interconnected and should be
            kept that way: separate, interconnected.
          • Nuno Nunes
            ... It depends a lot on the development team and project. Our approach is also a process improvement approach so we work with different companies and teams
            Message 5 of 5 , Dec 3, 1999
            • 0 Attachment
              on 02/12/99 15:44, Larry Constantine at lconstantine@... wrote:

              > I am curious about the scope of your projects using evolutionary
              > prototyping, both in size and in time. How long do you take to develop
              > initial models? How long is each iteration through the development cycle.
              > How many use cases result and how complex is each (e.g., in pages of
              > description)?

              It depends a lot on the development team and project. Our approach is also a
              process improvement approach so we work with different companies and teams
              within user organizations.
              On average (if that makes sense in process improvement) for a 12 man.month
              project with a team already working out the basics of the method and
              notation I would say that initial models in the early iteration would take
              from 1 to 2 weeks. From them on evolutionary releases (actual functional
              releases) would take also 1 to 2 weeks. Typically there would be a customer
              deployment every month or every other month. The actual product evolves
              incrementally through a succession of evolutionary prototypes so the
              mentioned releases are in fact snapshots of the product as times goes by.

              > In short, one should use narrative forms for requirements gathering and
              > communication with users and save the diagrammatic arcana for the software
              > engineers.

              We also use the formal representation only internally. User sessions are
              carried out using a modified version of a popular participatory technique
              called the Bridge [Tom Dayton et al]. What happens in that users work and
              discuss over sticky notes that get translated to activity diagrams in
              internal brainstorming sessions. We found out this works very well for all
              kinds of initial models (including domain and use cases). There is little
              concerns about formality in user sessions, i.e., it unimaginable to use
              fork/join constructs with users, although they can appear in the internal
              translation. Interestingly users make extensive use of spatial placement of
              sticky notes, very similar to your approach in essential use cases. It's a
              pity we have some many problems formalizing that kind of information within
              UML and modeling tools...

              >(...)
              > the problem and solution; they are separate but interconnected and should be
              > kept that way: separate, interconnected.

              Couldn't agree more.

              Cheers
              Nuno

              --
              Nuno Jardim Nunes
              University of Madeira - Teaching Assistant
              Mathematics Dep. - Computer Science Unit
              phone: +351 91 705160 (direct) 705150 (secretary)
              fax: +351 91 705199
              URL: http://math.uma.pt/njn/
              Address: Campus Universitário da Penteada
              9000 - Funchal - Portugal
            Your message has been successfully submitted and would be delivered to recipients shortly.