See comments below
-----Original Message-----
From: John Cortes
Sent: Thu 3/29/2001 8:17 PM
To: Michael Hill; Yves Gagnon; Rose Forum
Cc:
Subject: Re: (ROSE) Use Case versus generic system
The 'Use Cases' below appear at first glance as a Functional
Decomposition rather than a set of Use Cases.
Use Case are functional pieces of the system and a decompostion
of the system, even though RUP says flow of events in a system, there is
no real difference. Use Case are just a better way to organize the
requirements( more below on another comment).
If you are using RUP check out the Check Points for Use Cases
and identify where common behaviour exists and possibly 'merge' into a
fewer number. Use the Use-Case Outlines for this initial activity and
then after performing the Check Points, detail the Use Case(s) and
review them again. Also review the Use Case Model using their Check
Points. (these are easiest to find using the browser
Artifacts>Requirements>Use Case>Checkpoints. Also don't feel that you
need to complete each use case before reviewing them. Getting them to
outlines, comparing, prioritising them and then detailing them is a very
efficient way of avoiding rework and getting a feedback from other team
members early.
Again below I was talking intial activity of creating your use
cases not the whole flow of the process for creating use cases, don't
read more into than what I wrote. Check points in RUP are excellent and
should be used. You are review more than the Use Case Model, what about
the use case specification????????????
At first glance, not understanding the scope of the system, the
value to the Customer is to Park the car and then Exit. As these
behaviours are quite different, probably two Use Cases. Another may be
required for Configuration and that would probably contain initialising
the system. Other Use Case may be required for a vending type machine
for payment.
Agreement with you on this paragragh above.
The problem with functional decomposition is that you may do a
LOT more writing than necessary and create a more complex model than
necessary. I have seen a real-life example where going from a Functional
Decomposition based model to a Use Case model cut 50% of the project
schedule.
I have seen the real world, and yes they cut project schedule by
50% but the use case that I have seen and reviewed, cut the requirements
buy 50%, NOT GOOD.
Use Case are two things, specification and a model. The model
contains the picture of how use cases interact with actors other use
cases. The specification contains the details of each use case. Don't
get hung up on just doing a Use Case Model, if you do, then you have
only 50% of it. Use Case should never be meant to cut the project
schedule, just a way to organize the requirements into User Cases so the
everyone understands the system from users to testers.
Hope this is of some use.
regards
Glen
-----Original Message-----
From: Michael Hill [mailto:[EMAIL PROTECTED]]
Sent: Friday, 30 March 2001 12:32 AM
To: Yves Gagnon; Rose Forum
Subject: RE: (ROSE) Use Case versus generic system
First of all, define all your actors to your system
(Client, Administrator, Arming Loop, etc.).
Then define all the responsibilities for each actor,
those responsiblities are your Use Cases.
* Enter Parking with Credit Card (Client Actor)
* Enter Parking with Ticket (Client Actor)
* Configures System for One Barrier
(Administrator Actor)
* Configures System for Two Barriers
(Administrator Actor)
* Recognizes Car Passage through the Barrier
(Arming Loop)
* etc.
Now you have your system boundries defined. Then finish
each Use Case with the details (Description, Pre & Post Conditions,
Flows, Special Requirements).
What I gave above is an example, I don't know much about
the system being written but I think this might give you a good start.
-----Original Message-----
From: Yves Gagnon
Sent: Thu 3/29/2001 8:47 AM
To: Rose Forum
Cc:
Subject: (ROSE) Use Case versus generic system
Hi all,
We start a system for the parking area. The
purpose of it his to manage the
entry/exit of the client. The system could be
connect to an barrier, an
arming loop (a device that capture the passage
of the car), en entry device
(that have button for the ticket, credit card
reader etc). My question is
about the approach to define a use case like
'Client enter in the parking'
for a system that could have different
configuration. We want to let our
customer be able to configure the entry like
they want. That means they
could decide to include a credit card reader or
not, to have two barrier or
one etc. I ask myself what approach to take to
define my use case ? What
could be me primary scenario ? Even with a
configuration, the client that
enter in the parking could take many path, like
to use the credit card
reader instead of the button to take a ticket.
An help will be very appreciate
Thank you
Yves Gagnon
[EMAIL PROTECTED]
************************************************************************
* 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
*
************************************************************************
*
winmail.dat