Topic
11 replies Latest Post - ‏2011-09-14T14:35:43Z by vlc
SystemAdmin
SystemAdmin
3545 Posts
ACCEPTED ANSWER

Pinned topic Functional Decomposition and Use Cases

‏2007-09-05T21:22:31Z |
In my organization, they have elected to use a functional decomposition
approach to creating requirements with use cases. In all my UML training,
the instructors indicate this is less desirable than the use case modeling
actors/goals approach that UML recommends. I would appreciate if anyone can
provide some perspective on the pros and cons of both approaches and why you
recommend one and are against the other.
In my organization, they have elected to use a functional decomposition approach to creating requirements with use cases. In all my UML training, the instructors indicate this is less desirable than the use case modeling actors/goals approach that UML recommends. I would appreciate if anyone can provide some perspective on the pros and cons of both approaches and why you recommend one and are against the other.  
_______________________________________________
rup mailing list
rup@lists.ca.ibm.com
Unsubscribe:rup-leave@lists.ca.ibm.com
Updated on 2011-09-14T14:35:43Z at 2011-09-14T14:35:43Z by vlc
  • SystemAdmin
    SystemAdmin
    3545 Posts
    ACCEPTED ANSWER

    Re: Functional Decomposition and Use Cases

    ‏2007-09-05T23:35:22Z  in response to SystemAdmin
    With both methods you may end up with very similar results, and there are similar uses of abstraction, generalization, and so forth used in each.

    One benefit of taking an actor/goals approach to functional modeling is that you are more focused on the features that your users actually do that drive business value. It's a more agile way of looking at development vs. earned value. Coming up with a perfect decomposed functional model may result in an over emphasis on modeling without building working code.

    But there's no reason why you can't spend a little time using both practices to derive a working use case model. It doesn't have to be perfect before design and coding kicks in.

    Carson
  • SystemAdmin
    SystemAdmin
    3545 Posts
    ACCEPTED ANSWER

    Re: Functional Decomposition and Use Cases

    ‏2007-09-06T08:19:20Z  in response to SystemAdmin
    Hi,

    according to my personal experience (it's good to fail and feel the results = we call it lessons learned, don't we:-) if you use functionally decompose the use cases (e.g. Create account use case, Find account use case, Update account, Delete account, etc. linked together with some kind of dependency, extending, including others, etc.) you will easily end up with heavy non-readable model => people will not read it and you will get lost or spend amazing amount of energy to make it consistent, up-to-date, organized, or you simply discard it - what is the value then?

    I use the use cases to communicate user's intent or need among all team members (down to code) - that is usually very missing and hard to do; I like this joke about the hole digger:

    [i]Two guys were working for the city works department. One dug a hole and the other followed behind him filled the hole up. They worked one side of the street up, then the other down, then they moved to the next street, working furiously all day. An onlooker was amazed by their hard work, but couldn't understand what they were doing. So he asked the hole digger, Why do you dig a hole, only to have your partner follow behind and fill it up again?" The hole digger wiped his brow and sighed, "Well, I suppose it probably looks odd because we're normally a three-man team. But today the guy who plants the trees called in sick."[/i]

    These guys didn't understand the sense of their work; the objective is to make the city beautiful with the trees. Regardless their hard work they don't contribute to this objective.

    Many people act as the hole diggers; they work hard uselessly (just implement tasks, right?); they don't understand the sense. The use cases come in play here: I use them to link the developers with an user and his intent; to put their work in context; to make their work meaningful.

    Let's take Google (and compare with other tools) - what is the use case here? You need to search information as quickly as possible; your goal is not to put keywords in the box - do you get something value-able from this? Is this a use case then? Are you satisfied to get a reference to any page? Is this a use case then? - - - You need relevant page or document you are looking for and you don't one to spend 1 hour.

    I always ask: why would a user start to ask the system for something in this case/context? How does an outcome of the use-case contributes to (helps with) his/her work (a step from his/her business process)?

    That is the way I successfully use the use cases.

    Regards,

    Roman
    • SystemAdmin
      SystemAdmin
      3545 Posts
      ACCEPTED ANSWER

      Re: Functional Decomposition and Use Cases

      ‏2007-09-06T09:41:32Z  in response to SystemAdmin
      I've forgotten very useful practice: it improves requirements a lot if you start to define them as test cases; then look on all your test cases (= particular scenario, or user story) and group them by common objectives from user perspective => you will get the use cases.
      Roman
      • SystemAdmin
        SystemAdmin
        3545 Posts
        ACCEPTED ANSWER

        Re:Re: Functional Decomposition and Use Cases

        ‏2007-09-06T11:32:11Z  in response to SystemAdmin
        Doesn't deriving use cases from test cases rather beg the question where
        the test cases come from in the first place?

        Bill Taylor
        Unless stated otherwise above:
        IBM United Kingdom Limited - Registered in England and Wales with number
        741598.
        Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

        _______________________________________________
        rup mailing list
        rup@lists.ca.ibm.com
        Unsubscribe:rup-leave@lists.ca.ibm.com
        • SystemAdmin
          SystemAdmin
          3545 Posts
          ACCEPTED ANSWER

          Re: Re:Re: Functional Decomposition and Use Cases

          ‏2007-10-08T18:25:26Z  in response to SystemAdmin
          In practice we see many people completely lost in use cases, asking themselves questions like
          • How to create it?
          • Should this be a separate use case or is it just a scenario?
          • What is the relationship between these two use cases?
          etc.

          For beginners it's rather difficult to answer these questions in their specific case and they spend much time trying to keep a use case model up-to-date and containing reasonable amount of details.

          So why not to start from something more concrete (test cases) and proceed to more abstract (use cases)? Test cases are easier to create and as you start to discuss the system behaviour, you will definitely dig out enough details to understand the required functionality (plus you also find out how to verify the correct implementation) and you clearly identify a value provided to a customer in each test case. Then you just look at what goal/value have different groups of these test cases in common and this way you can group them into use cases as their different scenarios.

          This goes a bit against the principle of re-using use cases in test case creation but we don't think you have to do it this way all the time and underall circumstances - do it just enough to obtain answers to your use case related questions.

          We also feel the need for use cases when working with user stories (like in SCRUM). In our opinion these stories miss some common goal that you can use to group them and understand the relations among them. And we think that having use cases connecting these stories may help you not to get lost in many different and at the first look quite unrelated stories. Because, in fact, user stories are just use case scenarios.

          Marty
  • LynnGroup
    LynnGroup
    4 Posts
    ACCEPTED ANSWER

    Re: Functional Decomposition and Use Cases

    ‏2007-09-06T14:47:09Z  in response to SystemAdmin
    Functional decomposition will probably lead to many use cases that individually will have little value but create a lot of overhead and lifetime work in keeping them up to date. With this approach you will probably focus on the 'how' and not the 'what' and 'why' aspects of the system. You will also end up in a waterfall type of effort rather than an iterative effort.

    Use Cases focus on the 'what' and 'why' and deal with functionality from the perspective of the actor in atomic units of value to the actor. These units will be much larger than what you will get in functional decomposition and will be easier to manage and keep up to date over time.
    Fred Parker
    Lynn Consulting Group, LLC
  • SystemAdmin
    SystemAdmin
    3545 Posts
    ACCEPTED ANSWER

    Re:Functional Decomposition and Use Cases

    ‏2007-09-11T23:28:33Z  in response to SystemAdmin
    My take, like others is that if your organization is functional
    decomposing use cases they are not writing use cases, they are
    probably doing design with data flow diagrams. There are tools
    which do this very well. Do not confuse them with tools for
    building use cases.

    Possibly a good way to educate your colleagues to make sure that
    when you are asked to look at this 'use case diagram', say hey
    nice data flow diagram.

    Les.
    ________________________________________________
    Get your own "800" number
    Voicemail, fax, email, and a lot more
    http://www.ureach.com/reg/tag
    • On Wed, 5 Sep 2007, Bob Parro III (bob.parro@gmail.com)
    wrote:
    ATTACHMENT 0: multipart/alternative

    In my organization, they have elected to use a functional
    decomposition
    approach to creating requirements with use cases. In all my UML
    training,
    the instructors indicate this is less desirable than the use
    case modeling
    actors/goals approach that UML recommends. I would appreciate if
    anyone can
    provide some perspective on the pros and cons of both approaches
    and why you
    recommend one and are against the other.

    _______________________________________________
    rup mailing list
    rup@lists.ca.ibm.com
    Unsubscribe:rup-leave@lists.ca.ibm.com
    • SystemAdmin
      SystemAdmin
      3545 Posts
      ACCEPTED ANSWER

      Re:Functional Decomposition and Use Cases

      ‏2007-09-17T16:08:07Z  in response to SystemAdmin
      There is nothing wrong with functional decomposition except what people
      do with it. If you are asking domain experts "what do we do/what should
      the system do?" and using some kind of functional decomposition scheme
      (which the UML doesn't support, by the way) to make sure you cover
      everything, that's one thing. If you are just an obsessive-compulsive
      who likes decomposing in isolation, that's another. Unfortunately, the
      person who programs or analyzes or designs is very often
      obsessive-compulsive (like me), and most have no idea that they need to
      get a grip on themselves.

      Using "pure" use case analysis won't save you, because you can develop
      use cases out of contact with reality, too. Management often seems
      to think that only a wimp is guided by the user (or a strong surrogate).
      They'll be content for a long time if you go off and produce a
      decomposition or a use case analysis all by yourself. Both of these two
      different things can be made with good effect, but you have to persuade
      your management to let you base your modelling on the knowledge of
      someone who actually knows the work, and spend the expert's hours. If
      you succeed in that, your tools have a reasonable chance of working, and
      you'll tend to choose the right ones.

      Now I've done it. I've said a kind word about functional decomposition.

      -Eric

      Les Munday wrote:
      > My take, like others is that if your organization is functional
      > decomposing use cases they are not writing use cases, they are
      > probably doing design with data flow diagrams. There are tools
      > which do this very well. Do not confuse them with tools for
      > building use cases.
      >
      > Possibly a good way to educate your colleagues to make sure that
      > when you are asked to look at this 'use case diagram', say hey
      > nice data flow diagram.
      >
      > Les.
      >
      >
      > ________________________________________________
      > Get your own "800" number
      > Voicemail, fax, email, and a lot more
      > http://www.ureach.com/reg/tag
      >
      >
      > ---- On Wed, 5 Sep 2007, Bob Parro III (bob.parro@gmail.com)
      > wrote:
      >
      >
      > ATTACHMENT 0: multipart/alternative
      >
      > In my organization, they have elected to use a functional
      > decomposition
      > approach to creating requirements with use cases. In all my UML
      > training,
      > the instructors indicate this is less desirable than the use
      > case modeling
      > actors/goals approach that UML recommends. I would appreciate if
      > anyone can
      > provide some perspective on the pros and cons of both approaches
      > and why you
      > recommend one and are against the other.
      >
      > _______________________________________________
      > rup mailing list
      > rup@lists.ca.ibm.com
      > Unsubscribe:rup-leave@lists.ca.ibm.com
      >
      >
      _______________________________________________
      rup mailing list
      rup@lists.ca.ibm.com
      Unsubscribe:rup-leave@lists.ca.ibm.com
  • SystemAdmin
    SystemAdmin
    3545 Posts
    ACCEPTED ANSWER

    Re: Functional Decomposition and Use Cases

    ‏2008-10-07T11:18:55Z  in response to SystemAdmin
    Functional decomposition is good. You need fine-grained use case for good estimation, good project scheduling and progress tracking. See my blog http://advanceduml.wordpress.com/2008/10/07/granularity-of-use-cases/ for more details.
    • LynnGroup
      LynnGroup
      4 Posts
      ACCEPTED ANSWER

      Re: Functional Decomposition and Use Cases

      ‏2008-10-22T20:40:53Z  in response to SystemAdmin
      Your blog entry needs more work. It is a little short to judge and you didn't really get into functional decomposition, how far, how many use cases are too many, or give any examples.

      The trap many projects fall into is the use cases are grouped into functional areas and separate teams work on them. As an example, a loan origination system has several functions, qualify the lead, take the application, verify the information, and fund the loan. How the company I worked for got to over 500 use cases was beyond me, I could only come up with 6 and 3 of those were administrative. The problem was the title team only did title use cases, 30 of them, the closing and funding team did those use cases, 50 of them, and so on. There was no overall vision in the use cases, they were functionaly decomposed. Each one did a little bit of work but there was no way to see how it all fit together.

      So, I guess my question is, where do you stop? How many is too many?
  • vlc
    vlc
    1 Post
    ACCEPTED ANSWER

    Re: Functional Decomposition and Use Cases

    ‏2011-09-14T14:35:43Z  in response to SystemAdmin
    Do what you need. Functional decomposition is especially needed when the process you're trying to understand and model is either complex and poorly understood and/or covers both manual and automated tasks and you want to model them clearly to verify correctness with all project stakeholders. Decompose until you reach a point that is clearly understood or can be clearly described in a few sentences.