Here's the text from the Process Document
Section 4.4
"Prior to completion of the first Working Draft, a clear statement of
requirements for the standard to be produced is required. A requirements
statement documents the best effort collection of known requirements on a
particular protocol, interface, procedure or convention. The requirements statement is important as it leads to a clear, common
understanding of the goals, provides a guide for developing the standard,
and can be used as a final test to measure the completeness of the
resulting specification. It is not necessary that the resulting standard meet every stated
requirement, but the standard should be explicit about which requirements
it does not meet, and why. Requirements may be updated during the
development of the standard, as they become clearer. As with Charter
(above), brainstorming, fact-finding and associated activities frequently
accompany the process of requirements gathering. Often, at the beginning
of a project, the Charter, Requirements and early versions of an initial
Working Draft are all undergoing simultaneous revision until a clear
direction emerges and the Charter and Requirements are formally approved.
"
We clearly have already streached letter of the process document by not
formally approving a statement of requirements prior to the completion of
the first Working Draft. That being said I would think that a statement
of requirements could contain both the use cases and scenarios that
demonstrate the need for standardization of something as well as the
particular design requirements placed on the development of the
specification.
That being said I personally think that the use cases text that Ira has
offered would be better placed as Section 1.1, followed by Section 1.2
Overview of Counters followed by Section 1.3 Design Requirements for
Counters.
I also have a comment about the term "Down Mode"...........I'm not sure
how long this term has been in the document but it's not actually used
anywhere else in the document...and it should be "Down State" or something
other than Mode in my opinion. I would think there are very few printer
vendors that have a "User Mode", a "Maintenance Mode" and a "Down Mode" in
thier respective products. And the first sentence of the definition is
messed up as well......
Jerry Thrasher, Lexmark
wamwagner at comcast.net
Sent by: owner-wims at pwg.org
06/13/2005 01:09 PM
To: wims at pwg.org
cc:
Subject: WIMS> June 15 Conference Call
The next WIMS conference call is at 12 noon EDT on 15 June. Agenda will
concentrate on Counter Spec:
ftp://ftp.pwg.org/pub/pwg/wims/wd/lcrc-wimscount10-20050603.pdfftp://ftp.pwg.org/pub/pwg/wims/wd/lcrc-wimscount10-20050603rev.doc
Dial In: 1-866-365-4406
Passcode: 2635888#
This draft includes changes agreed to at last conference call although the
"requirements" item still needs to be addressed. Ira's message of 7 June
should be discussed as to need, required detail, and who will generate the
new material.
I find the "requirements" requirement of the PWG process unclear with
respect to whether these deal with requirements for the proposed items
(Why have are counters needed ?) or Ira's interpretation that it is a
detailed identification of the requirements of the proposed items. It
would be helpful if Jerry (as protagonist for inclusion) could clarify his
interpretation of the process document. At any rate, it seems odd having
the more general use models (which touch on requirements for) in section 3
, while the design requirements are in section 1. It would seem that the
"Why" should precede the how.
With the resolution of the "requirements" question, I believe that the WG
group has gone well beyond addressing voiced last call issues, and
although we would continue to strive toward perfection, I think we had
better concentrate on wrapping this up and getting it ready for a vote.
Bill Wagner, Chairman, WIMS WG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20050613/0d9bfa16/attachment-0001.html