[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"
Hello Chunbo, Good to hear feedback. Please see my comments inline below. Yin Leng -----Original Message----- From: Chunbo Huang [mailto:email@example.com] Sent: Thursday, 24 July 2003 4:33 AM To: Husband, Yin-Leng; firstname.lastname@example.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:email@example.com] > Sent: Tuesday, July 22, 2003 6:48 PM > To: Husband, Yin-Leng; firstname.lastname@example.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 > >