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