Re: Use-case driven development - getting to work-tasks ?

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/26/05

  • Next message: H. S. Lahman: "Re: Objects in a multiprocessor architecture" 
    Date: Wed, 26 Jan 2005 04:47:49 GMT

    REsponding to Mackie...

    > How do you get from a list of use cases, to a list of software components
    > which can be assigned to individual developers to create ? There seems to be
    > a basic mismatch between use cases, and generating development tasks for
    > developers to work on. Consider:
    >
    > A single use case may require numerous software components to implement it.
    > A single software component may be used across multiple use cases.

    Remember that use cases are a form of requirements specification. When
    you estimate projects and allocate developer resources it is generally
    done against the software components that are envisioned for the
    solution. The use cases just determine the complexity of those
    components, which determines the effort and resources needed. IOW,

    Step 1: Identify the components needed to solve the problem. This is
    usually at the level of block diagrams or subsystems.

    Step 2: Identify the use cases that are relevant to each component.

    Step 3: Determine exactly what functionality from the relevant use cases
    apply to the component (i.e., the particular use case steps that are
    relevant to the component).

    Step 4: From (3) determine the complexity of the component (i.e., the
    union of all relevant use cases' functionality).

    Step 5: Estimate the effort needed to construct the component based on
    its complexity from (4).

    Step 6: Allocate schedules and resources to the development in
    proportion to (5).

    > How do you avoid writing requirements twice, once in the form of use-cases,
    > and once in the form of specs for software modules ? Seems like double the
    > work!

    That depends on the form and nature of the specs. If the specs are
    simply design documents, then they reflect developer decisions, not
    requirements. They have simply been organized around the components.

    However, it is often useful for larger applications to provide explicit
    requirements for components so that they can be developed in parallel.
    However, such requirements are generally more detailed than use cases
    because they deal with particular software modules rather than the
    overall system black box. They will also reflect "internal"
    requirements that reflect design decisions made for other components.

    > A simple manual approach - spread*** with a matrix of use cases down one
    > side, software components along the top, mark an X in each cell where a
    > software component supports a particular use case. It should then be clear to
    > a developer what uses cases they need to be looking at, to be aware of what
    > requirements their software component must help satisfy. Not very scalable
    > though!

    That's one way to do Step 2 above. However, it would really have to be
    done at the level of individual use case steps for Step 3 because, as
    you point out, a single use case can be manifested across multiple
    components.

    Unfortunately there is another problem with such a simplistic matrix
    approach. Often uses cases refer to other standards (e.g., "4. Send the
    message using the XYZ protocol"). Those standards may represent a
    substantial suite of rules and policies that may also be spread across
    multiple components.

    *************
    There is nothing wrong with me that could
    not be cured by a capful of Drano.

    H. S. Lahman
    hsl@pathfindermda.com
    Pathfinder Solutions -- Put MDA to Work
    http://www.pathfindermda.com
    blog (under constr): http://pathfinderpeople.blogs.com/hslahman
    (888)-OOA-PATH

  • Next message: H. S. Lahman: "Re: Objects in a multiprocessor architecture"
    • Quantcast