I have no problems with designers using Use Cases at that level and agree
with your objection to creating use cases down to the field updating
level just as, in earlier days, I hated people drawing flowcharts down to
the same level. However, some of the nastiest specifications I've seen
have been the result of a 'designer' thinking he'd finished the job when
he'd produced a use case and a half page of description.
The low-hanging fruit for lazy and/or less than scrupulous BAs and
architects and designers, many of whom are consultants, is use cases,
the highest-level system diagrams, and data models. Doesn't matter if
the rendition is diagrams or text or a mix thereof. This is the easiest
stuff to do, and although this may sound heretical, I think all that
stuff to be the least valuable to an implementer.
The high-level system architecture pictures are pretty and all, and they
are good for impressing the business types, but the technical folks
already know all that stuff. Data models - I am less and less inclined,
as years go by, to see any need to pin down the structure of value
holder classes in stages earlier than detailed, detailed, nitpicking
design. And even then only formally describe what the outside world
needs to know about.
And use cases - this is my opinion - are *only* useful when the
interesting paths are described in detail. Dynamic UML diagrams, text
descriptions, I don't care - just do it. Sounds like your "designer"
forgot his job description...which is to design, not churn out use cases
which is the job of business analysts. Of course, doing the detail work
on use case interesting paths is also hard work...which is why a lot of
people don't do it, and assume that the coders will "get" it.
The problem was that these use cases described a financial message switch
where each message could contain one or more transaction details and
guess what - the use cases made no mention of message validation checks
and no attempt to describe invalid message handling. An then, of course,
said 'designer' couldn't understand why we had problems designing a
regression test suite.
I see important information lost at various stages pretty routinely.
It's often because there's been little or no conversation between BAs
and architects and designers and coders and testers as to what the
signoff expectations are on product. How often do you see a situation
where the coders can tell the designers that their work is crap and to
take it back and fix it? Not often, the people for earlier stages
usually have more seniority and more clout than the people who receive
the various deliverables. That should be turned on its head.
AHS
