RE: (ROSE) Use Case versus generic system

[Glen Tattersall]

Title: (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. 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.   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.   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.   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 * *************************************************************************