For a long time I have taken the approach that if it isn't in the requirements then it
should not be implemented, and Use Cases are certainly a major part of the
requirements document set. If there is some functionality that a user, or some other
actor, can perform, then document it in a Use Case. Even the most trivial Use Case
adds value, and some turn out to be not as trivial as they first appear.
A system administrator may be able to add new users and modify them, but how, and
under what conditions. What is checked when the user is added; do you require certain
fields (name, password, phone number etc); what if the user already exists; what
privileges are needed; what defaults may be applied? Things get even more complex with
deletes since you have to consider all the object relationships. What if the Bookstore
employee that you are deleting has placed orders for new books - do you delete all the
books as well? Probably not, but what do you do with the reference from the Book back
to the employee?
If you don't write the Use Case that defines the functionality that is to be
performed, then on what basis do you write the Test Case that defines how you test
that the functionality is correct? Or don't you write test cases for the trivial
functionality that doesn't need testing anyway!!! ?
Writing Use Cases of this type is not difficult, and while there may not seem to be
much value in making it complete, there is a great deal of opportunity for disaster if
you don't.
John Hebley
Hebley & Associates
-----Original Message-----
From: "Pankaj Chatterjee" <[EMAIL PROTECTED]>
Sent: Monday, March 19, 2001 11:36 PM
To: "'Rose Forum'" <[EMAIL PROTECTED]>
Subject: (ROSE) CRUD and Use Cases
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
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
