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
>
>
>
>
>