Subject: RE: [v6tc] v6tc - is there life

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Thu, 18 Nov 2004 10:05:53 +0100

Hi Pekka,

I can live with what you suggest, provided that the
should and mays are made deployment scenario specific, i.e. (which I think was
what you said in an earlier mail, anyway, though this mail made me doubt it a little bit).

Which of the various requirements that a potential solution supports will
be described in a trade-off document, not in the requirements document as such, I suppose ?

BR, Karen

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Thursday, November 18, 2004 9:53 AM
> To: Karen E. Nielsen (AH/LMD)
> Cc: 'Kurt Erik Lindqvist'; 'Tim Chown'; [email-masked]
> Subject: RE: [v6tc] v6tc - is there life
> 
> 
> On Thu, 18 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
> > Another issue. I have some problems with SHOULD and MAY 
> > requirements. I would much rather stick with must-only 
> requirements, 
> > perhaps with the addition that a certain feature (requirement) 
> > possibly could be profited from in this and that deployment 
> > scenario. I do not see the point in having SHOULD requirements and 
> > in general I do not see the point in using the words MUST, SHOULD 
> > and MAY in a requirement document.
> 
> I think it's useful to be able document those features which we think 
> really must be in the solution, as must, but also be able to express 
> those features we'd really, really like to see in the solution if 
> that's feasible from the solution's point of view, as "should". 
> Otherwise the result is either: 1) too few requirements to make a 
> realistically usable solution in all the scenarios, or 2) 
> elevating of 
> too many 'should' statements to musts.
> 
> The usefulness of "may" requirements comes not that they're mays, but 
> from the fact that the reader sees that those requirements have been 
> considered and they are NOT shoulds or musts.  That could be 
> accomplished as a non-requirements section as well, of 
> course. I don't 
> have personally a strong opinion on what to do with these, removing 
> them would be OK by me.
> 
> I agree that uppercase keywords shouldn't be used, unless we define 
> when those mean ourselves.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 19 Nov 2004 08:12:28 +0100

Agree with both of you.

I especially agree with 
providing _qualified_ guidance rather than solid requirements -
we are not in a product development process here.

There has never been doubt about that we should 
use the term goals in the document, only when we(I) speak about it we(I) sometimes
forget the subtle difference and use the term we(I) are more familiar with.

Karen

> From: Soininen Jonne (Nokia-NET/Helsinki)
> [mailto:[email-masked]]
> Sent: Thursday, November 18, 2004 7:38 PM
> To: ext Alain Durand
> Cc: Karen E. Nielsen (AH/LMD); [email-masked]
> Subject: Re: [v6tc] v6tc - is there life
> 
> 
> Hi,
> 
> I agree with Alain. Let's not use normative text and have "goals"
> instead of requirements. The documents should be guiding of 
> nature - not
> stating hard requirements.
> 
> Cheers,
> 
> Jonne.
> 
> On Thu, 2004-11-18 at 20:08, ext Alain Durand wrote:
> > On Nov 18, 2004, at 12:44 AM, Karen E. Nielsen (AH/LMD) wrote:
> requirements.
> > > I would much rather stick with must-only requirements, 
> perhaps with 
> > > the addition
> > > that a certain feature (requirement) possibly could be 
> profited from 
> > > in this and that
> > > deployment scenario. I do not see the point in having SHOULD 
> > > requirements and in general
> > > I do not see the point in using the words MUST, SHOULD 
> and MAY in a 
> > > requirement document.
> > 
> > Karen,
> > 
> > I remember Brian Carpenter strongly advising us to use the 
> term goal 
> > instead
> > of requirements and remove the uppercase normative language.
> > 
> > I makes sense to focus on what is really needed. However, 
> if there are 
> > "really nice to have" things,
> > it might make sense to mention them as such.
> > 
> > 	- Alain.
> > 
> > 
> Jonne Soininen
> Nokia
> Tel: +358 40 527 46 34
> E-mail: [email-masked]
>