As posted in another message on this thread the boundary for business use cases is wider than that of system use cases, becasue it will include actors of the system.
In a business use case the actors are the stakeholders (the people benefiting from the activity). In the system use case the actors are the users of the system (not the same thing, these will often be the workers in the business use case model). Another way we looked at the difference between business and system use cases (just today this came up) is to think of the business use cases as having no system. Imagine how the business would operate if the workers used just pencil and paper to do their jobs. Hope this helps. Les. > > First let's look at the definition of a Business Use Case and a Use > Case. > > Business Use Case: The processes of a business are defined as a number > of > different business use cases, each of which > represents > a specific workflow in the business. A business use > case defines what should happen in the business when > > it is performed; it describes the performance of a > sequence of actions that produces a valuable result > to > a particular business actor. > > Use Case : In its simplest form, a use case can be described as > a > specific way of using the system from a user��s > (actor��s) > perspective. A more detailed description might > characterize a use case as: > - a pattern of behavior the system exhibits > - a sequence of related transactions performed by > an actor and the system > - delivering something of value to the actor > Use cases provide a means to: capture system > requirements, > communicate with the end users and domain experts, > and > test the system. Use cases are best discovered by > examining > the actors and defining what the actor will be able > to do > with the system. > > From these definitions it is clear that Business Use Cases are used to > capture > the high level busisness model -- they have nothing to do with the > system to be > designed except that they give the designer an understanding of how the > business > works. Once the designer has this understanding, they can move on to > Use Cases. > Use Cases deal with the system being designed -- they capture how the > system which > will be used by the business is required to work. > > Once the Use Cases are set you should have a basic idea of what the > system is > required to do. Then it is time to move on to Use Case Realizations. > ________________________________________________ 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 * * Post or Reply to: [EMAIL PROTECTED] * 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 *************************************************************************
