RE: stds-80220-requirements: numbering requirements
I think that requirement numbering is a good idea. Numbering has the
advantages of clarifying exactly what portion of the text is an actual
requirement, aiding in review and discussion of the document, and enhancing
cross-referencing of requirements from other contributions and documents.
It is also a good idea to distinguish approved requirements as opposed to
unapproved or draft requirements. Perhaps the requirements could be
designated as "provisional" or "proposed" until approved? Therefore, the
requirements could be numbered something like <R1P>, <R2P>, etc., for now.
When the document (or a portion of the document) is approved, the "P" can be
removed.
Although I agree with Joanne's comment that requirement numbers could be
assigned after the document is approved for the first time, I believe it
would be harder to defer requirement numbering because the text of the
document needs to be clarified to indicate exactly what text is part of what
requirement. Sometimes it is tricky to separate portions of "glue" or
normative text from the requirements and to identify the boundaries between
different numbered requirements. It would also be a bad idea to make major
changes (even editorial in nature) at such a late stage of the process. As
a starting point, the editor could offset every sentence containing a
normative standards word ("may", "should", "shall", etc.) as an individual
requirement in a stand-alone paragraph delimited by "<Rsss.nnnP>", where sss
is the section number and nnn is a sequence number within that section.
That would only take a few minutes on such a small document.
Doug Knisely
-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Joanne Wilson
Sent: Friday, August 22, 2003 3:09 PM
To: Chickinsky, Alan; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements
Alan,
My recommendation remains the same, "I recommend that we deal with a
numbering schema for requirements after we've finalized the current
document."
Clearly you disagree. I'd like to hear what others think.
Best regards,
Joanne
-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Chickinsky, Alan
Sent: Friday, August 22, 2003 11:49 AM
To: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements
Joanne-
Since you do not disagree, can we agree to only to assign the number, once
the group agrees to mark a paragraph as "closed" or "stable". This creation
of the number shows that all members agree that this requirement is well
enough defined that we understand what must be done at the MAC/PHY layer.
alan
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Thursday, August 21, 2003 11:05 AM
To: Chickinsky, Alan; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements
Allen,
I don't disagree with anything you suggest. I just don't see how to
shoehorn this into the process that is currently underway. Hence, I
recommend that we deal with a numbering schema for requirements after
we've finalized the current document.
Best regards,
Joane
-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Chickinsky, Alan
Sent: Thursday, August 21, 2003 8:57 AM
To: stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements
Joanne-
Numbering will help assure we have defined requirements at the proper
"layer". For example, in the security section there was a requirement for a
user challenge to gain access. That is clearly an application layer
requirement. But the derived requirement may be how many messages can be
sent before security must be implemented. Thus my comment to delete the
text, should have been (if we had a numbering system) change the requirement
number from a RMxxxxx to a RAxxxx, and then look at what is the derived
requirement.
But I do agree that we do not assign a number, until we get a "closure"
paragraph. But a proposal should include a statement defining the two
letter requirement prefix, so all readers understand if a derived
requirement is needed. If we create a requirements document with
requirements that are not at the proper layer, we will just have to rehash
previous discussions when we try to create the derived requirement.
As to David Trinkwon's comment "In addition to numbering requirements, it
would be usual to categorize each one as M (Mandatory) or O (Optional)."
Do we have to also mark requirements that are valid for when other
requirements are valid, for example TDD or FDD only requirements?
What I am really saying, how much information do we incorporate into the
numbering schema?
We could have a table that has the requirement as a row, and headings like,
"Mandatory for FDD" or "Optional for all modes". If we do not use a table,
just think of the number of combinations. One could suggest, Q means
"Mandatory for FDD" and W means "Optional for all modes". Without a cheat
sheet we would all be lost.
So I suggest we keep the requirement number simple with only three entries
- requirement or goal
- exists at layer x
- sequential number
But we also create a table with headings,
-Requirement Number
-Requirement Title
-Mandatory
-Optional
I realize as we go further into the requirement process, the column headings
will increase or change.
Alan
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Tuesday, August 19, 2003 2:43 PM
To: Chickinsky, Alan; Robert D. Love; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements
Alan,
While I agree that numbered requirements are useful, I really think that
at this time we should focus our attention on the resolving the open issues
within the Requirements Document. I propose we defer discussions about
numbering
schema until the document is more stable. That will better allow us to take
a more
holistic approach to the subject.
Best regards,
Joanne
-----Original Message-----
From: Chickinsky, Alan [mailto:alan.chickinsky@ngc.com]
Sent: Tuesday, August 19, 2003 8:32 AM
To: 'Joanne Wilson'; Robert D. Love; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements
Joanne-
Once we assign a number, that number is never reused. Thus we have a list
of requirement numbers that are sequential. And the sequential list has
"holes" in it. By adopting this idea:
1- we can resurrect a "dead" requirement at any time.
2- presentations always makes sense.
But your comment raises an issue I did not address. Is the sequential number
unique for all requirements? For example, can we have a RA000001 and a
RP000001?
I propose that we cannot have a RA000001 and a RP000001. Its too confusing.
I also suggest we do NOT reserve numbers. For example, numbers 200-399 are
QOS. There are always problems when we get the 200th QOS requirement.
Robert-
Upper layer requirements should be written as any other requirement. By
definition the standard only addresses MAC/PHY. By using my suggested
numbering, we quickly see which requirements we must meet. So I believe we
do not need to keep saying "The standard shall support the requirements
placed on the MAC/PHY by Requirement X at layer Z". But we need to have a
statement at the front of the requirements document like "The standard shall
address the requirements with the <layer> letters 'M' and 'E'. Requirements
with other <layer> letters will be included in informational sections, to
help the reader understand the intent of the committee."
Alan
-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Tuesday, August 19, 2003 1:32 AM
To: Robert D. Love; Chickinsky, Alan; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements
Bob,
Alan,
I also agree with the proposal to have numbered requirements. So that
we don't complicate this project, I propose that the numbering of the
individual requirements be applied after we have finalized the document.
Otherwise, we could waste time numbering, re-numbering and re-re-numbering
requirements as the document gells.
Best regards,
Joanne
-----Original Message-----
From: owner-stds-80220-requirements@majordomo.ieee.org
[mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
Robert D. Love
Sent: Monday, August 18, 2003 1:32 PM
To: Chickinsky, Alan; stds-80220-requirements@ieee.org
Subject: Re: stds-80220-requirements: numbering requirements
Alan, excellent idea. I certainly hope we can get consensus on this
quickly.
Since we do not standardize what happens above the MAC layer, I assume that
upper layer requirements would be written in the form:
"The standard shall support the requirements placed on the MAC/PHY by
Requirement X at layer Z", where Z is higher than layer 2.
Best regards,
Robert D. Love
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@ieee.org Fax: 208 978-1187
----- Original Message -----
From: "Chickinsky, Alan" <alan.chickinsky@ngc.com>
To: <stds-80220-requirements@ieee.org>
Sent: Monday, August 18, 2003 11:04 AM
Subject: stds-80220-requirements: numbering requirements
>
> folk,
>
> Now that we have a requirement document that has some closure, I would
like
> to suggest that we start to number each requirement. The numbering will
> allow us to determine that a requirement has a evaluation criteria and a
> criteria maps back to a requirement. It will later be a shorthand for a
> discussion on what goes into the standard. Just think if we have to say,
> "The requirement on page 11, line 15-16 in version 9 of the requirement
> document". But we could say "Requirement R0002". Also anyone who has
> worked requirement traceability tools know each requirement needs a unique
> identifier.
>
> I suggest we number each requirement as
>
> <R> <layer> <sequential number>
> or
> <G> <layer> <sequential number>
>
> Where:
>
> <R> is a measurable requirement
> <G> is a goal (not measurable requirement) e.g. "shall have a functional
> user interface"
>
> The following letters should be used for <layer>
>
> <A> Application
> <P> Presentation
> <S> Session
> <T> Transport
> <N> Network
> <L> Link Layer Control
> <M> Media Access Control
> <E> Physical Layer ( we already have a "P", so E for electronics)
>
> <sequential number> is a 6 digit number, with zero padding (leading
> positions), e.g. 000001
>
> We also need to create a table showing a requirement and it's derived
> requirement(s). For example we say we need call blocking and the derived
> requirement is a QOS requirement.
>
> Before I show this proposal to the evaluation criteria folk, I think we
need
> an agreement in the requirements group.
>
> Hopefully we can agree on the idea of numbering, and then the format of
the
> numbering all by e-mail. This is too basic an idea to waste a meeting.
>
> a. chickinsky
>
>
>
>
>