Hi,
Thanks Jerry - and the next two sentences after your highlighting are also
important. A Design Requirements document (or section) can say "The
Foobar design SHOULD support...", but the v1.0 Protocol or Interface
standard doesn't have to satisfy every requirement - it just needs to
document what and why for requirements that are NOT satisfied.
And I agree that will Bill that the Use Models need to be moved to
section 1. I was following the style of the existing section 3 Use Models
in the Port Mon MIB (which will now also have to be moved, Jerry).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of
thrasher@lexmark.com
Sent: Monday, June 13, 2005 3:31 PM
To: wims@pwg.org
Subject: WIMS> Re: WIMS Counter Spec Requirements...requirements..
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 associate! d 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@comcast.net
Sent by: owner-wims@pwg.org
06/13/2005 01:09 PM
To: wims@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.pdf
ftp://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
This archive was generated by hypermail 2b29 : Tue Jun 14 2005 - 14:58:20 EDT