From mbsh@poudre.fc.hp.com Thu Dec 24 06:20:13 1992 Received: from hpfcla.fc.hp.com by dkuug.dk with SMTP id AA27288 (5.65c8/IDA-1.4.4j for ); Thu, 24 Dec 1992 21:20:13 +0100 Received: from dancer.fc.hp.com by hpfcla.fc.hp.com with SMTP (1.36.108.3/15.5+IOS 3.20) id AA09443; Thu, 24 Dec 92 13:20:01 -0700 Received: by poudre.fc.hp.com (1.37.109.4/15.5+IOS 3.22) id AA10520; Thu, 24 Dec 92 13:20:13 -0700 Date: Thu, 24 Dec 92 13:20:13 -0700 From: Maureen Hoffert Message-Id: <9212242020.AA10520@poudre.fc.hp.com> To: SC22WG5@dkuug.dk Subject: Requirements Process X-Charset: ASCII X-Char-Esc: 29 From: Maureen Hoffert Last Modification Date: December 24, 1992 Date: October 5, 1992 Subject: Fortran Requirements Collection Process Background: ----------- WG5 has established the structure of two revisions to Fortran in the years 1995 and 2000, approximately, in WG5 / N820, "Strategic Plan for Fortran Standardization". In order to determine what should be in those revisions it has been determined that a database of requirements should be kept. In the "Strategic Plan for Fortran Standardization" in section 3.2 it states that: WG5, on a continuing basis, determines, records, distributes, and maintains the needs and suggested requirements for Fortran. To begin a new revision WG5 using the recorded needs and suggested requirements, establishes objectives and corresponding functional requirements, specifications, and schedule for that revision. In the past X3J3 maintained a Journal of Development (JOD) which held proposals that were fairly complete but were not included in the final Fortran 90 standard. A new subgroup of X3J3, the Journal of Requirements, has been established to begin to deal with these issues. I suggest that some of the issues that should be considered in this process are: - Is there a distinction between a "requirement" and a "specification" or "proposal" for a feature? - What defines a "requirement": . is it a simple statement of a desired feature; . is it a statement of a rationale for a feature, the definition of the feature; . is it a proposed schedule for the design and integration of the feature into the standard; . or is it somewhere in a mixture of the above? - How does a "need" or "suggested requirement" become recorded, what criteria should be used for its selection for consideration - What kind of process should be used to collect requirements? . How active a role is taken to collect opinions outside the standards community? . Do we survey the public, and if so what forums are appropriate: + the electronic network + Fortran Journal + Fortran Forum + Symposiums + Others? . Do we survey the public review responses for suggestions from X3J3 that we would consider a suggestion in the next revision? - Can we or should we keep the requirement collection process a dynamic one, so that the Fortran standards community is continuously collecting possible requirements to be considered in the "next" revision; or do we collect requirements for a limited time after each minor or major revision and then close the requirements phase until the next revision? - At what stage are complete proposals for a given feature set of a requirement drafted, after a requirement is accepted as one of interest by WG5, or as part of a feasibility study for a given feature? Preliminary Proposal for Requirements Process: ---------------------------------------------- - a "requirement" conforms to the following guidelines: . a short document, about 1 - 2 pages . a brief descriptive title . a rationale statement justifying the proposed extension or set of extensions to Fortran . a statement of the basic functionality that such a feature would provide . a statement for the projected Fortran user of such a feature . a description of the impact of the feature on the Fortran language . an outline of syntax and semantics for implementation; provided for illustration and feasibility . a status field defined to be: + draft requirement + X3J3 approved requirement + WG5 approved requirement + draft specification for requirement X with a possible list of modifications or a modification history + accepted specification for requirement X + rejected specification for requirement X for a list of reasons provided - a "specification" is a requirement that has been expanded into a full proposal with actual syntax and semantics for a language feature. It is not drafted until after the requirement has been approved. It contains an implementation section that discusses efficiency and integration issues. - Process for submittal of requirements and specifications: . proposed requirements should continually be presented to X3J3 and WG5 or any other WG5 national member body to be considered in the format specified . at X3J3 each proposed requirement that meets the guidelines will be placed in the Journal of Requirements (JOR) . proposals can be developed and submitted for a given requirement at any time. . the JOR would be a respository for requirements as well as specifications, the status field would keep track of where the proposals were in the process. Vote of the committee would determine the status of a given requirement or specification. It would be expected that the JOR would become the source for which requirements for future revisions would be drawn. . requirements will be considered for future revisions, not specifications . when WG5 calls for requirements, the approved requirements in the JOR will be provided to WG5 who will then determine the priority of a given requirement for the next revision . if the committee considered that a given requirement or specification did not warrant future work, then it could vote to reject further consideration of a requirement; such a vote and the reasons given for the rejection would be recorded in the JOR . if a requirement has been rejected by the committee then it could only be reconsidered based on new information that was not considered as part of the earlier decision for rejection . if the committee approved of work on a given requirement, then that work would only be rejected based on the specifications of that requirement (it did not meet proposed schedule, it was unimplementable, etc.), it could not be rejected based on simply rejecting the "idea" of a requirement unless new information about the requirement that was unknown at the time the requirement was accepted . once a requirement was accepted by the committee, then a specification for the requirement would be developed Summary: -------- I have attempted to outline a process for requirements and specificaions that could help us create a standard language definition with a timely and dynamic process. This is just a prelimary proposal that hopefully will illicit further discussion on these issues.