I thought I'd take advantage of this thread to advertise my skills to the list.
Finding myself unemployed recently I thought I'd use the time to put down in writing my experiences with use cases and object- oriented modeling. This work includes several chapters on use case modeling which might help with some of the questions raised in this thread. If you're interested pay a visit to -> http://home1.gte.net/res0hbt4/html/process.htm and if you like what you see, feedback in the form of advice, comments, criticism is welcome. Cheers, Les. --- On Fri, 2 Nov 2001, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > > (responding to Anil Emmadi) > > > In our project Our process owner has defined some guide lines for > > modeling System use cases. > > > > He says "we have to show only those sysetm use cases which can bu > > automated by the system". > > But Iam not convinced with that even the team. > > My queries are > > 1 .Is this correct guide line? > > 2.Are there any thumb rules or guide lines to identify the System use > > cases.? > > 3.For the enterprise applications do system use cases give any value > > addition? > > 4.Is it a must that we have to go for Business use cases and system > use > > cases even though we know 90% of them will be the same. > > 5.An example or case study for identifying system use cases from the > > Business use cases. > > I'd say this is partially right, IMHO. Each primary Use Case represents > something the User wants to do when he turns to his computer. > > It may be the case that of all the primary Use Cases, there will be > much commonality, and for this reason, it saves work for the > Analyst to factor these common areas out as System Use Cases. > > Further down the line, the development should consider the primary > Use Case as an indivisible whole, and break it down in a way that > suits the Object Model. > > It may well be the case that this breakdown corresponds to that > of the Use Case break down. However, subsequent development > should take the Use Case break down as 'hints' not as 'requirements'. > > I do not think there is any reason to describe Use Cases for any > part of the process that is not to be considered for automation. > > If this is the case, then a primary Use Case would be a Business > Use Case. > > Hope this helps toward answering your questions. > > Paul Oldfield > > any opinions expressed herein are not necessarily those of > Mentors of Cally > **************************************************************** ******** > * 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/support/usergroups/rose/rose_forum.jsp > * Other Requests: [EMAIL PROTECTED] > * > * To unsubscribe from the list, please send email > * > * To: [EMAIL PROTECTED] > * Subject:<BLANK> > * Body: unsubscribe rose_forum > * > **************************************************************** ********* > > > ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ************************************************************************ * 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/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rose_forum * *************************************************************************
