Re: LC-67 leftover -- MUST use MUST?

>
>I disagree. I believe that it is usually clear when requirements are

I'm sorry but it's not good enough to be "usually clear".  One "non-clear" 
spec could do an awful lot of damage.  If we can't guarantee clearness 
(which we can't) why not use RFC 2119 keywords which we know are clear?  To 
me this is an obvious decision.  In one case - no problems; in the other 
case - potential problems.

>programmatically identifiable. For example, using all-caps for RFC
>2119 keywords makes those keywords (and associated requirement
>phrases) identifiable with a simple Perl script.
>
> > We have some pretty good history that RFC 2119 makes requirements
> > identifiable.
>
>Yes, but only if capitalized or otherwise marked. It is not the RFC
>that makes the requirements identifiable (because the RFC uses common
>English words), it is the capitalization.


I think it's both.  The keywords themselves have become known through 
common usage and are thus understandable.  The caps highlight them.

>RFC 2119 does not require
>capitalization or special marking. Many RFCs use RFC 2119 keywords
>without capitalization, leading to some non-requirements looking like
>requirements (and, hence, violating the programmatically identifiable
>principle).
>
> > We need to use objective measures to ensure that requirements are
> > identifiable, not subjective ones.
>
>Yes, of course, to the extent possible. Apparently the definition of
>an "objective measure" is subjective.
>
> > > > I don't buy "** Alt.2 or Alt.3 strongly encourage uniformity
> > > > rather than forcing it, and that should suffice.".  Why should
> > > > that suffice?  Encouraging, but not mandating, this MAY result
> > > > in non-compliance with specific requirements due to poor
> > > > communication (didn't know it was a requirement).  What can be
> > > > gained by this?
> > >
> > >This is a strange argument. If we accept "didn't know it was a
> > >requirement" as an excuse, there is no reason to write SpecGL at
> > >all. SHOULD and MUST have about the same visibility and about the
> > >same probability of being unknown due to poor communication.
> >
> >
> > Huh?  We're talking about whether or not to mandate the keywords in
> > RFC 2119, not whether to use MUSTs vs. SHOULDs.
>
>Yes. I do not think my response implies anything else. Perhaps I
>misinterpreted your "due to poor communication" phrase.
>
> > Not mandating the keywords may (will) result in specs using
> > alternative language.  Any alternative language is permissible.
>
>Anything is permissible as long as the requirements are
>programmatically identifiable. For example, it is OK to use no keywords
>if the spec contains special visible marks that identify all

Again, what are obvious special marks to you might not be to me.  I agree 
that there are some cases when we would all agree that the requirements are 
clear, but we certainly cannot count on getting these.  What we will 
probably get are at least some cases where some people think the 
requirements are clear and others misinterpret them.


****************************************************************
Mark Skall
Chief, Software Diagnostics and Conformance Testing Division
Information Technology Laboratory
National Institute of Standards and Technology (NIST)
100 Bureau Drive, Stop 8970
Gaithersburg, MD 20899-8970

Voice: 301-975-3262
Fax:   301-590-9174
Email: skall@nist.gov
****************************************************************

Received on Thursday, 26 June 2003 09:55:01 UTC