[wscm] Merged milestones from breakout groups for requirements work

[Charles F Wiecha <wiecha@us.ibm.com>]

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.