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

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

    Re: Functional Decomposition and Use Cases

    ‏2007-09-05T23:35:22Z  
    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

    Re: Functional Decomposition and Use Cases

    ‏2007-09-06T08:19:20Z  
    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

    Re: Functional Decomposition and Use Cases

    ‏2007-09-06T09:41:32Z  
    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
    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

    Re:Re: Functional Decomposition and Use Cases

    ‏2007-09-06T11:32:11Z  
    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
    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
  • LynnGroup
    LynnGroup
    4 Posts

    Re: Functional Decomposition and Use Cases

    ‏2007-09-06T14:47:09Z  
    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

    Re:Functional Decomposition and Use Cases

    ‏2007-09-11T23:28:33Z  
    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

    Re:Functional Decomposition and Use Cases

    ‏2007-09-17T16:08:07Z  
    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
    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

    Re: Re:Re: Functional Decomposition and Use Cases

    ‏2007-10-08T18:25:26Z  
    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
    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
  • SystemAdmin
    SystemAdmin
    3545 Posts

    Re: Functional Decomposition and Use Cases

    ‏2008-10-07T11:18:55Z  
    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

    Re: Functional Decomposition and Use Cases

    ‏2008-10-22T20:40:53Z  
    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.
    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

    Re: Functional Decomposition and Use Cases

    ‏2011-09-14T14:35:43Z  
    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.