As to the correlation between the number of Use Cases and the number of
requirements, I can personally attest to that! Part of what I have been
doing is extrapolating actual requirements from a set of Use Cases (in
this case narrative use cases, to clarify). I can assure you it's *not*
a 1 to 1 relationship. Where
I'm finding myself struggling is that these particular use cases don't
even seem to be designed with re-use in mind - there are no 'extends'
use cases, etc. as one would normally see. The
caveat to all of this is that the specific cases I'm dealing with were
delivered by a 3rd party vendor as the 'requirements' for the
application. Going forward, however, I
ask because there is an great interest in exploring and implementing
RUP or a similar process for the Object Oriented Projects here going
forward, and I wondered at how more 'testable' requirements are covered
within such processes. For example, the
use cases do not include UI Functionality, describe the fields that
will exist on a given screen and the order they should follow, and
things of this nature. In one instance, a step includes a note stating
that "the screen returned will be slightly different based on which of
the 5 options the user selects", but never goes into what the
differences will be (nor is there even a 'base' identified).
|