business use case model

[Bruno.Cossi]

The way I see it, ANY use case :-) That's why I do not use the stereotype.

Bruno

[sargasso]

That's what I thought - but they are pretty serious about this so I thought I may have missed something at UMLschool.  :-/

B

[Bruno.Cossi]

Well, Agile Modeling keeps referring to a "business use case" or "essential use case", but the definition is pretty much a definition of a use case... but then again, maybe I am missing something.

Bruno

[KP]

Business modelling has nothing at all to do with creating software. The end product is the model itself, and maybe the recommendations for process improvement or re-organisation that come out of it. Therefore a business use case is a description of how a business process is used, rather than a description of how a software application will be used (I think, although I can't claim to be an expert on business modelling, I don't even own a suit   )

[Kevin Brennan]

KP is pretty much correct. Business Use Cases are intended to describe the enterprise as a whole. (Regular) use cases describe the interaction of an actor with the system.

[Bruno.Cossi]

KP, Kevin,

thanks, that makes sense, actually :-)

Bruno

[sargasso]

still confused  

If a use case describes the interaction of actors with a system - whether that system be a system that involves a chunk of technology or not - I still cant see the need for a delineation.

...or...
Is a business use case a structural (aka model management) item that contains "normal" use cases that specifically involve interactions between actors and the technical system under consideration?
If so, then is it some sort of uber-process notation similar to the way that an Erikkson-Penker process element denotes a whole process embodied in one element.  Then we would have a heirarchy of

Business Use Case ->> E-P process ->> Use case

B

[Kevin Brennan]

Sargasso,

It's an optional deliniation.

A business use case is generally used to describe a business process. A (standard) use case should be written at a lower level and describe the interaction of an actor with the system.

Rational seperates the business modelling workflow from the requirements workflow, with the assumption that you'll design the business process (developing business use cases) and then, once you decide which of those functions will be implemented in the system, document those functions in regular use cases.

Alistair C0ckburn uses different notation for the same concept, with the cloud basically equating to business use cases and the waves representing system use cases.

A distinct notation is mostly only useful if you want to develop different sets of use cases for different audiences. If you're only going to have one set, then the standard notation will be fine.

Personally, I find that it's useful to have high-level scoping use cases for the business stakeholders and detailed use cases with business rules, error handling and suchlike for the development team. YMMV.

(PS. My apologies to Alistair for mangling his surname but the BB software left me no choice).

[sargasso]

So ...

RUP:  Business Use Case -->> Use Case
is the same as
me:  E-P Business Process -->> Use Case
(where -->> = "is related to")
B  

[Kevin Brennan]

Pretty much.

Another way to look at is that a business use case treats the enterprise as the "system" and external partners/customers as the actors.

Using a call center as an example, I might have a business use case that involves a customer disputing a bill and getting a refund.

At the system level, this might track to a few use cases, like "check customer account", "reverse charge" and "issue refund", because internally these are done by different people.

It's a single goal for the customer, who will not use the system, and so should be a single business use case. It's multiple goals for the internal users, and so the system will implement this as multiple system use cases, some of which will be called by other business use cases as well.

Does that make the use of these clearer?

[sargasso]

Yep, fair enough
B

[Gabor]

 Ambler W.Scott writes in his Object Primer book (Cambridge University Press 2001) p. 44:

"business use case model...models a technology independent view of your behavioral requirements. ... concret use case models ... model your analysis of your behavioral requirements, describing in detail how users will work with your system, including references to its user interface aspets."

[Kevin Brennan]

Yeah, there are other definitions for business use case than the one I quoted. However, the symbology we were discussing was developed by Rational because they wanted to use Use Cases and UML for business modelling, so I used their definition.

However, you're right, other books will use a "business use case" to mean something else. I've done what Ambler suggests myself on some projects.