OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-uc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel-uc] Thoughts on the use of the term "Use Case" vs. "Scenario"


very good thoughts/clarification on the terms.  I think it is a good idea to
adopt "usage scenario" in this sub group.  Just two comments:

1. "usage scenario" may only best serve to derives functional requirements,
not quality requirements.  For example, the customer's PO service process
needs to handle concurrent requests/messages from clients.  This kind of
requirement can be easily derived from an usage scenario, but it is
difficult to derive the requirements of message throughput, reliability,
etc, qualify (non-functional) requirements.

2. Not all the functional requirements are derived from usage scenarios.  So
I agree with you that the 6 entries are not usage scenario, but they are
still qualifying for functional requirements.



> -----Original Message-----
> From: Husband, Yin-Leng [mailto:yin-leng.husband@hp.com]
> Sent: Tuesday, July 22, 2003 6:48 PM
> To: Husband, Yin-Leng; wsbpel-uc@lists.oasis-open.org
> Subject: [wsbpel-uc] Thoughts on the use of the term "Use Case" vs.
> "Scenario"
> Since Ivar Jacobson first introduced the term "use case" (at the OOPSLA
> conference in 1987), and James Rumbaugh used the term "scenario" in OMT
> (1991), I thought we should see how these two authors defined these two
> terms.
> Definition of the two terms from The Unified Software Development
> Process (1999, Ivar Jacobson, Grady Booch, James Rumbaugh), for what
> it's worth, are:
> 1. "Use case - a description of a set of sequence of actions, including
> variants, that a system performs that yields an observable result of
> value to a particular actor." "... A use case is a piece of
> functionality in the system that gives a user a result of value.  Use
> cases capture functional requirements."
> 2. "Scenario - a specific sequence of actions that illustrates
> behavior."
> 3. James Rumbaugh's Object Modeling Technique (OMT) defines a scenario
> as: "a scenario is a sequence of events that occurs during one
> particular execution of a system ... a scenario can be the historical
> record of executing a system or ... experiment of executing a proposed
> system."
> These authors have specific meanings for the two related, but not
> interchangeable terms.
> There was a similar discussion in the Web Services Architecture WG on
> the difference between "use case" and "usage scenario" (instead of
> "scenario").
> (See http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0464.html
> which had
> "Basically, use cases (e.g., UML) are something more structured and
> oriented to software design.  Usage scenarios are less structured, and
> perhaps more abstract to illustrate broad architectural concepts.")
> I suggest we do something similar to the WSA WG and adopt the term
> "usage scenario" so as not to re-define terms (i.e. "use case" and
> "scenario") that already have well-defined meanings in their original
> context.
> Suggest for wsbpel-uc purposes, we could define
> Usage scenario - a description of sequence of business-level activities,
> that illustrate the concepts and usages that should be standardized, and
> from which functional and qualitative requirements may be derived.
> Usage scenarios are descriptions in terms from end-users' domains (e.g.
> sending a purchase order, purchasing a ticket, filing an insurance
> claim), whereas requirements are in terms relevant to a specification's
> support of functionality (e.g. shall support semantic shortcuts, support
> parallel split pattern, support process compensation, support
> compensation handler) and quality (e.g. shall support caching to
> increase performance).
> From the above, the 6 entries in the 21 July WSPBEL Use Cases doc
> (http://www.oasis-open.org/apps/org/workgroup/wsbpel-uc/download.php/296
> 0 /usecases.html) would be requirements IMO.
> -
> Yin Leng

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]