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

["Husband, Yin-Leng" <yin-leng.husband@hp.com>]

Hello Chunbo,

Good to hear feedback.
Please see my comments inline below.

Yin Leng

-----Original Message-----
From: Chunbo Huang [mailto:chunbo@bea.com] 
Sent: Thursday, 24 July 2003 4:33 AM
To: Husband, Yin-Leng; wsbpel-uc@lists.oasis-open.org
Subject: RE: [wsbpel-uc] Thoughts on the use of the term "Use Case" vs.
"Scenario"

Yin-Leng,

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.

<ylh> Agree that it's not as obvious, nevertheless still possible, to
derive the quality requirements - by designing the usage scenarios
carefully.  E.g. Customer phones CSR; CSR uses browser to do status
check; if status information does not return within 10 seconds, CSR
promises customer a return call or email instead of keeping customer
waiting.  From this type of usage scenario descriptions, IMO, it's
possible to derive quality requirements of performance (<10 sec.
response in example) and other non-functional requirements.
</ylh>

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.

<ylh> Sorry, but I don't follow how your first statement leads to your
agreement with me.  In case of non-clarity in my previous email, my
comments that the 6 entries are not usage scenarios are based on the
fact that either

a) in the case of UC01 - UC05, they do not describe a sequence of
business-level activities, but are straight forward statements of issues
raising functional requirements,
or
b) in the case of UC06, is an "Implementation Guide" of an "e-business
message standard".
</ylh>


> -----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
>
>