RE: stds-80220-requirements: numbering requirements

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

-----Original Message-----
From: Anu Appaji [mailto:aappaji@sta.samsung.com]
Sent: Monday, August 25, 2003 9:49 AM
To: 'Joanne Wilson'; Chickinsky, Alan; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements

Based on my experience with requirements, I agree with Joanne. Its much easier to deal with numbering once we have a first clean consensus document.

-----Original Message-----
From: Joanne Wilson [mailto:joanne@arraycomm.com]
Sent: Friday, August 22, 2003 3:09 PM
To: Chickinsky, Alan; stds-80220-requirements@ieee.org
Subject: RE: stds-80220-requirements: numbering requirements

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.

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

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.

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

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.

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

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.

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

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.

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

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

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

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

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.

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

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.

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