[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC