From: @dishwasher1.mpce.mq.edu.au
Date: Fri Feb 11 2000 - 09:10:29 EST
Data are indeed very important in requirements and systems design, but in=
my
opinion there is more:
functions are requested=20by the user (describing tasks they want to perfor=
m) and
these functions are implemented by the functionality of the system.
Users don't think like we do (and we are both right, but using a different
perspective). The data and the relationships needed=20for the system are no=
t the
same as those of the user. E.g. we colud state a product is associated to=
an
order (by the orderlines), the user however will not percieve this as an
association but the product becomes a part of the order (the difference is
mainly induced by the abstraction we use and which the users do not use).=
For
the user data has always a context to have value, for us data have their me=
rits
on their own.
So at this point use case are of great value because they make clear how the
user will use the system and what actions (transactions) will change or req=
uest
data. The user cases are providing the users context. Users do not work with
'normalized' data but with clusters and the only relationships they know are
inheritance and part of.
In my opinion this difference is a major factor in the mis-communication
between systems people and real users and during requirements we should take
their side and not the systems side (after all we are developping systems=
for
them, aren't we=3F).
>Before making use cases of the new system, however, the
>entity-relationship diagram should be in place, and the check=20for holes=
in
>the functional analysis will then be the activity hierarchy and the
>interaction diagram, not the use case model.
>Tony Markatos responds:
>And, especially for larger scale systems and/or unfamiliar domains, before
>we can create fairly rigorous ERDs, it has been my experience that we need
>to do a functional analysis. Why=3F Essential data relationships are der=
ived
>from the decisions that end-users will make using the system. And only by
>following the flow of data is it possible to "flush-out" the end-user
>decisions.
>In short data flow diagrams are needed before we can create a fairly
>rigorous set of ERD,s. Required end-user decisions determine the data
>relationships - not the other way around.
>Randy Buchholz
>I=20don't agree that user decisions are the determinate of all data
>relationships. Data exists independant of the users and has natural
>relationships.
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:25:09 EST