case is commonly described as:
A methodology used in system analysis to identify, clarify,
and organize system requirements. The use case is made up of a set of possible
sequences of interactions between systems and users in a particular environment
and related to a particular goal. It consists of a group of elements (for
example, classes and interfaces) that can be used together in a way that will
have an effect larger than the sum of the separate elements combined. The use
case should contain all system activities that have significance to the users.
A use case can be thought of as a collection of possible scenarios related to a
particular goal, indeed, the use case and goal are sometimes considered to be
A use case (or set of use cases) has these characteristics:
- Organizes functional
- Models the goals of
system/actor (user) interactions
- Records paths (called
scenarios) from trigger events to goals
- Describes one main flow of
events (also called a basic course of action), and possibly other ones,
called exceptional flows of events (also called alternate courses of
- Is multi-level, so that one use
case can use the functionality of another on 
Jacobson has a more concise definition. However, that definition conjures up
proprietary issues, which the TC is working hard to avoid. The important
concepts are the same in the various definitions. A use case provides a
description of what is occurring from the user's perspective. Complex use cases
are made up of a series of other use cases. Use cases capture information about
the context, activity and requirements involved in specification development.
to look at real world situations that require data to be sequenced,
orchestrated and/or choreographed.
spec ultimately has to demonstrate it will provide economic value by being a
standard that will enable business activity that is "stateful" (not
stateless). Business activity that requires long series of time, has data
dependent interactions, and is not fully predictable; business activity that
requires more than the invocation of a procedure call.
paraphrase, bpel is data in motion. If the goal of bpel is to advance web
services, this by definition will necessitate using use cases with complex
another look at the WS-I doc of 4/15/03 in the use case list repository; the
document is SCM Use Cases 1.0. It is, as the doc states, a series of use cases.
Presumably the complex use case would require the described use cases plus
additional ones. A complex use case for the listed use cases could be something
along the lines of (or we can ask the WS-I folks for the expanded description
of the higher-level use case):
Sell electronics to consumers using a low margin/high volume
business model that relies on no customization, delivery direct from the
warehouse, and inventory on hand (in warehouse) equal to one production run.
The amount in the production run varies by product category.
the level we need to get to in order to test the bpel specification and flesh
out any additional requirements.
utilize the work of the WS-I (& others) that has already been done we can
build the complex use cases that will be necessary to test/exercise specific
issues/requirements of the specification. That is, if we cannot obtain a fully
developed use case that addresses the specific issue from the Issues List that
is under consideration we can construct a complex use case using the catalogue
we are compiling in the supply chain domain.
soliciting use cases, we will need to specify what issue/requirement we are
addressing. For example, Issue 5, we will need to ask for a business
perspective example of a suspend/resume that occurs over a long period of time.
The solution is going to be in the design and writing of the specification. And
I suspect there will be multiple times when there will be several different
approaches to that solution. We can't lose sight that the ‘real’
solution is will the spec enable/allow the user to do what they intended.
Wording from TechTarget.com