We're in violent agreement!
I do several iterations on a Use-Case, adding detail and information as
I drill down. What you are calling a "Business Process", I'd capture on
the second iteration of use-cases as a business level use-case. See
"Writing Effective Use Cases" by Alistar Cockburn. He recommends 5
abstraction levels for use-cases. The steps of a high level use-case
become full-blown use-cases themselves, but at a lower level of
abstraction. The alternative paths through a use-case constitute
use-case scenarios.
In a simple domain like this, I'd keep the business rules in the
use-case just to reduce the number of documents to manage.
Then, you define wire-frames or page mockup to capture the essence of
the user-interaction. Based on the business-level use-cases you create
a "Screen-Flow" showing the navigation path between the diagrams.
Now you "instantiate" the use-case scenarios with specific data values
and you end up with test-cases that you can validate before you even
touch design. Make sure that you have a test-case that validates every
business rule. The combination of these test-cases constitute an
acceptance test.
Before you even consider technology, you have defined the success
criteria and there are no surprises to either the customer or the developer.
Paul Penrod wrote:
Before we get to use-cases, lets start at the bottom:
1. Define the problem: ie: "There is a need to track scouts and their
information"
2. From that, branch out into more detail with regard to business
process. ie: "I need to track
scouts with in my district", "Of the scouts in my district, the
following information about their
activities/awards/rank are important"...
3. These constitute constraints and rules surrounding "how" you are
handling the problem in a
"manual" fashion.
4. Identify the data elements (not int, char, unsigned, but "name",
"rank", "troop", etc.) that are
needed and necessary to address the problem and apply the rules.
Now you can build specific use cases around the business processes
you've identified, and from
there dive into as much detail pain as you are willing to handle.
The key is simplicity...Many simple rules and cases are much easier to
map out and automate, than
small sets of convoluted and incomplete rules and sets.
Once you can walk someone end to end through the "process" of tracking
the scouts, and there are
no holes in either procedures or data elements, then we start with the
technical design and framework,
plus the user interface - no prototype yet... That comes after design
proof..
In the meantime, someone from HQ should take the lead and manage the
output from the group into
a cohesive set of documentation from which the design will be derived.
I never start coding anything until I know exactly what I need to do -
no surprises that way, and
no Microsoft "bend it to fit, paint it match" development.
A. Rick Anderson wrote:
Paul Penrod wrote:
If this is purely a conceptual exercise, then someone from HQ needs to
lead the discussion, starting with a set of business requirements,
and fleshing
things out from there - AND not letting the discussion tail off into
the weeds.
Many of the people on this list are programmers first, designers
second, if at all.
They can give you elegant and clever solutions, but those solutions
have no
meaning without a framework to hang them on.
Otherwise you will get the "wounded duck, spiraling into the pond"
exercise
from what was a good starting point.
As one who has been shooting at the duck <grin>, this is an excellent
point!
Would it make sense for this group to write up some
use-cases/scenarios or simple stories as a means of driving out the
requirements?
That way, people could define the feature or issue that is of a
concern to them in a use-case or story.
ex: write-up a use-case for a parent who choses to opt-out, or a story
of a data-voyeur trying to access someone else's information (whatever
that may be), or of a district leader trying to validate the merit
badges for an Eagle Scout candidate.
All those who want to contribute could write up the stories, the
actual folks who want to code the solution decide which ones they care
about and want to do first and you have the beginnings of a set of
functional requirements. Non-functional requirements can be driven
out the same way, but most programmers don't want to think of those :-)
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
--
A. Rick Anderson
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
