RQ draft

[Jon Bosak <bosak@boethius.eng.sun.com>]

At our last PAC meeting, we discussed the following set of topics:

   A. REQUIREMENTS AND DESIGN PRINCIPLES

      RQ 1. Use cases

      RQ 2. Resource/funding model

      RQ 3. Process modules/phases

      RQ 4. Outcomes (specifications, standards, ...)

I took away an action to draft language for discussion 2000.01.06.
Following is my draft.

Jon

==================================================================

RQ 1. Use cases

   The set of use cases to be employed in the OASIS process
   consists of all the cases that can be generated by each
   possible combination of "operation," "origination,"
   "organizational scope," and "individual participation" below.
   With possibly a few anomalous exceptions, these cases are
   typical of those that will have to be handled by the OASIS
   process.  The set is not intended to exhaust all the
   possibilities but rather to indicate the minimum set of cases
   that the system must be able to handle.

   OPERATION

      Note that "specification" can mean a revision of a
      specification.

      1. Create a specification proposal

      2. Create a new specification

      3. Take over the creation of one or more specifications in
	 progress

      4. Harmonize overlapping specifications, some of which may
	 be complete and some of which may be in progress, by
	 creating a specification or suite of specifications

      5. Review a specification

      6. Maintain a specification

      7. Standardize a specification

      8. Maintain a standard

   ORIGINATION

      a. Requested by a quorum of OASIS members

      b. Requested by OASIS members as individuals

      c. Requested by an OASIS technical committee

      d. Requested by some other kind of OASIS committee (e.g.,
	 ACTC)

      e. Requested by the OASIS board

      g. Requested by some individual or group outside OASIS

	 [Open question: whether a request that in fact comes from
	 outside OASIS is required to be submitted in the form of
	 a request by one or more OASIS members.]

   ORGANIZATIONAL SCOPE (PARTICIPATION, LEGITIMACY...)

      a. OASIS only

      b. OASIS and one or more outside organizations

      c. One or more outside organizations

	 [Open question: whether OASIS standardization of a
	 collaborative effort requires a formal vote of all the
	 collaborating organizations.]

   INDIVIDUAL PARTICIPATION

      a. OASIS members

      b. Members of some outside group that is collaborating with
	 an OASIS group

      c. Invited experts

RQ 2. Resource/funding model

   The creation of OASIS technical committees should not be
   limited by the resources of OASIS as a corporation.

   This appears to imply that the incremental cost of creating a
   TC should, on average, not exceed the incremental revenue
   gained through the addition of members as a direct or indirect
   result of creating the TC.

RQ 3. Process modules/phases

   The number and variety of possible use cases will require
   multiple entry points into the process, so that (for example)
   the same procedure for standardizing a specification can be
   applied regardless of whether the specification has been
   developed by an OASIS TC or by some outside organization
   requesting OASIS standardization status.  The only way we can
   see to accommodate this requirement is to divide the process
   into clearly defined modules with specified inputs and outputs.

   This "pipelining" architecture can yield beneficial side
   effects.

   1. Modular process phases make it possible to assign people
      with different skills and interests to different parts of
      the process.  In particular, the separation of charter and
      work phases allows problems to be stated by business experts
      and solutions to be designed by techology experts.

   2. Transitions between process phases provide checkpoints at
      which projects can be reported upon and reassessed, thus
      discouraging the continuation of failed projects from simple
      inertia.

RQ 4. Outcomes

   The deliverables of a TC include

      1. A report to the agency that created the TC

      2. A technical specification (unless the committee fails, in
	 which case its only deliverable is a report)

	 [Open question: What is the vote required for the
	 committee to approve a spec (as opposed to a working
	 draft)?]

   Elevation of a specification to the status of an OASIS standard
   is an action separate from the approval of a specification by a
   TC.  A vote to approve a specification is a vote of the
   individual members of the TC, whereas a vote to standardize a
   specification is a vote of the members of OASIS.  (The voting
   members of OASIS are typically organizations rather than
   individuals.)

   The nomenclature used for specifications and standards is
   illustrated by the following examples, which assume the
   existence of a fictional OASIS Footware TC.  Note that Draft
   Standards may originate outside OASIS.

      Deliverables of the committee on its own authority:

	 The Shoe Draft Specification of the OASIS Footware TC
	 The Boot Draft Specification of the OASIS Footware TC

	 The Shoe Specification of the OASIS Footware TC
	 The Boot Specification of the OASIS Footware TC

      Results of later actions by OASIS as a whole (assuming for
      purposes of illustration that OASIS rejects Boot and accepts
      Shoe):

         The Rejected Boot Specification of the OASIS Footware TC

         The OASIS Shoe Draft Standard

         The OASIS Shoe Standard