Well I have to disagree with the statement say the Use Cases does not
document application requirements. I am assuming that application
requirements pertain to software requirements.
Use Cases should document requirements relevant to a particular flow of
event, business or software requirements. This way the flow of events
in a Use Case can be understood from begining to end. The requirements
should use business terminology so that the users understand what the
system will do.
Now if CRUD deals with maintenace of tables in a database, then they
don't belong in a Use Case, that is more implementation than
requirements.
But if you have a Use Case that describes the steps of events that does
maintenance on a database (inititated by a user), then it should be
written to say as such but in terms of a requirement not implementation.
-----Original Message-----
From: Walter Howard
Sent: Tue 3/20/2001 8:57 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: (ROSE) CRUD and Use Cases
The difference is the vocabulary. CRUD deals with the
maintenance of tables. Users of a system are (usually) oblivious to the
underlying technology of an application. As an analyst, it is your job
to document the requirements using business terminology. Just saying
"Update User" doesn't tell me much about your business. It does tell me
something about your application. The Use Cases document business
requirements, not application requirements.
Walter
>>> "Pankaj Chatterjee" <[EMAIL PROTECTED]> 03/19/01
11:36PM >>>
Hi everyone,
Just wanted a new approach
Sometime back I had put up a question in the Rose forum on
whether or not we should define use cases for CRUD functions. The
general concensus was that we should not as in general CRUD type use
cases do not add value to the system. However, in most of the
applications we develop, there is a lot of create,update,delete and
retreive activity. All persistent object that we develop require CRUD
functionality. So what's wrong in this approach?
Consider this
1) A system has an Administrator, The administrator can grant
access to new users, revoke access permission from existing users,
modify existing user profile.
2) A order fullfilment system allows sales persons to - Accept
new Orders, Cancel existing orders, Change Ordered Items
If these are not example of CRUD functionality then what are
they? I could have written - An Administrator can - Create User, Update
User, Delete User and the end functionality could still be the same. So
whats the difference between 'Create User' and 'Grant Access to new
Users'?
Thanks in advance
Pankaj
winmail.dat
