[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wscm] Merged milestones from breakout groups for requirements work
The Business Collaboration Patterns and Monitored (BCP+MC) Commitments working group over in the eBTWG (http://www.ebtwg.org/projects/collaboration.html) as part of the ongoing collaborative work between OASIS and the UN/CEFACT on ebXML is gathering real world business scenarios as input for the determination of useful, reusable business collaboration patterns. While this group applies UMM modeling methodologies they have leveraged the REA framework for designing and reasoning their business scenarios. REA by my limited understanding provides a very clean definition of things such as Resource, Events and Agents (as the name implies) which should also go some way to address one of the points raised by Jacques Durand regarding defining an agreed upon glossary of terms. The folks active in the eBTWG working group are experts in this field and can provide you with more comprehensive details. As their is already a free flow of information between the eBTWG working groups and their counterparts in OASIS working on the ebXML framework components perhaps some of the results of their excellent work may provide an effective on-ramp for these WSCM breakout groups assuming they meet the requirement of being "relevant" business scenarios by your definition. I have cc'd Dave Welsh and Bob Haugen who are driving the BCP work over in the eBTWG. I image if you are interested they may well be happy to share the fruits of their ongoing work to help you effectively meet your deliverables. David David Russell Bind Systems Ltd. www.bindsys.com ----- Original Message ----- From: "Charles F Wiecha" <wiecha@us.ibm.com> To: <wscm@lists.oasis-open.org> Sent: Friday, January 18, 2002 12:37 AM Subject: [wscm] Merged milestones from breakout groups for requirements work Merged milestones from Producer and Consumer groups leading to WSIA requirements Summary To define the requirements of the OASIS WSIA TC, both breakouts recommended a three-step process: define a set of relevant Business Scenarios, define a set of Use-cases that represent key activities in the Business Scenarios, and describe the Requirements that are implied by the Use-cases. Each step results in a deliverable that serves as the basis for the next step and that can be retained as permanent documentation. Both also recommended the creation and maintenance of a Glossary. The proposed process is defined here only at a high level, with emphasis on the earlier steps; the details of each step will have to be defined in a timely manner, and we have included a proposed schedule for doing so. This note may not have captured all the relevant elements necessary for the requirement process. Please view it as a starting point. Overview The art of requirements gathering is not a science: there is no one way to attack the problem. Some folks articulate Business Scenarios to help generate abstract definition of Use-cases. Others take the opposite approach, which is to define some abstract Use-cases and then provide Business Scenarios as test cases for each. Considering that there is no single best way to proceed, both breakout groups recommended a process consisting basically of the following steps. 1. Define a set of relevant Business Scenarios 2. Define a set of Use-cases that represent key activities in the Business Scenarios 3. Describe the Requirements that are implied by the Use-cases In parallel, they recommended the creation and maintenance of a Glossary that may serve as an individual output of the committee to aid both internal and external communications. Deliverables Each deliverable serves as the basis for the next step in the requirements process and can be retained as permanent documentation. 1. A set of Business Scenarios. A Business Scenario is a description of one or more business entities, the relationships between them, the objectives of each business entity, the sequence of activities that each business entity performs in order to achieve its objective, and the interrelationship between the activities performed by each business entity, i.e. the overall flow of events. The objective of the business entity and the activities that it performs may be defined in terms of one or more actors that are part of the business entity. Examples of actors include people, application programs, computer systems, etc. The activities may involve direct interaction between the actors that are part of the business entities (which may be person to person, person to computer, or computer to computer), or they may involve interaction with "the system" that connects the business entities. A Business Scenario may identify alternative flows. 2. A set of Use-cases. A Use-case is an abstract description of a sequence of activities that appears in one or more Business Scenarios. A Use-case is initiated by an actor to make progress towards the achievement of a business objective of the business entity to which the actor belongs. Like a Business Scenario, a Use-case may identify alternative flows. 3. A set of Requirements Requirements are characteristics and capabilities that "the system" must have in order to enable the business entities to achieve the objectives described in the Business Scenarios. The Requirements will be derived from the Use-cases. In order to do this, sub-teams will be established to write sections of the Requirements document based on selected Use-cases. The content and organization of the Requirements document remains to be defined. Proposed time line The proposed process is defined here only at a high level, with emphasis on the earlier steps. The details of each step will have to be defined in a timely manner. The following is a proposed schedule for doing so based on our goal of having a draft requirements document by the next face to face meeting in April. Friday 1/18 Review example glossary entries Review strawman overall process for arriving at the Requirements document Review strawman Business Scenario template Establish three sub-teams to work on refining the glossary, overall process, and Business Scenario template. Develop business scenarios Friday 2/1 Review initial glossary to facilitate Business Scenario descriptions Review final process for arriving at the Requirements document Review Business Scenarios submitted by TC members Friday 2/15 Review additional Business Scenarios submitted by TC members Decide which Business Scenarios to include, based on uniqueness, business value, and relevance to WSIA TC scope Review strawman Use-case template with an example Establish sub-teams to study the Business Scenarios and propose Use-cases that represent selected activities within the Business Scenarios Develop use cases Friday 3/1 Review Use-cases submitted by the sub-teams Review strawman Requirements document template Friday 3/15 Review revised and additional use cases submitted by the sub-teams Establish sub-teams to write sections of the Requirements document based on selected Use-cases Develop business and technical requirements Friday 3/29 Review Business Requirements section of the document Friday 4/12 Review Technical Requirements section of the document TC F2F meeting 4/17-19 Review the draft Requirements document Conclusion This note may not have captured all the relevant elements necessary for the requirements process?let's discuss and refine during the 1/18 telecon. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC