W3C home > Mailing lists > Public > www-qa@w3.org > June 2003

LC-29.4

From: Lofton Henderson <lofton@rockynet.com>
Date: Thu, 12 Jun 2003 09:05:11 -0600
Message-Id: <5.1.0.14.2.20030611164731.0295d5c0@rockynet.com>
To: www-qa@w3.org

This is one of a few left over issues about test assertions and conformance 
requirements, addressed originally in:

Ref:  http://lists.w3.org/Archives/Public/www-qa/2003Jun/0013.html


LC-29.4 [1]
-----
"It might be valuable to explain some desirable characteristics of a 
specified technical requirement", and then three examples of such are 
suggested.  I'm unclear exactly what IJ means by "specific technical 
requirement", and the scope.  I assume that he means "conformance 
requirement".  Does anyone interpret it otherwise?

And I assume that the scope is:  SpecGL should include such stuff in its 
definition of the concept of conformance requirement, so that the three 
attributes effectively become SpecGL requirements on how target 
specifications formulate their conformance requirements.

Any case, after we sort out the meaning an scope, there are the three 
suggested "desirable characteristics" to consider:

    1. Mutual independence from other requirements

I don't have a problem with this, as a *desirable* characteristic of 
conformance requirements.  I would not interpret "mutual independence" to 
mean "unrelated".  But rather that the normative requirements of different 
conformance requirements in the spec don't overlap (or conflict!).

Other views?

    2. Expresses a minimal requirement

I'm not sure what "minimal" means here.  I'm guessing that it is along the 
lines of "atomic".  Other views?  Can anyone think of cases where this 
would not be desirable?

    3. Distinguish and label: requirements, exceptions to those 
requirements, necessary and/or sufficient techniques for satisfying those 
requirements.

This one might be a little more problematic.  For example, let's look at 
how SpecGL itself (or any of the GL documents) scores on these points.

3.1-- For the first, it passes (styled "Conformance requirements:" sections).
3.2-- For the second, SpecGL states exceptions ("not applicable"), but does 
not "distinguish and label" them (should it?).
3.3-- SpecGL does NOT present necessary and sufficient (N&S) conditions to 
satisfy the requirement.  Nor do I think it should.  The approach we have 
taken is to suggest techniques in SpecET, but these are not normative.  I 
think this is the right approach for SpecGL 1.0 (and the other GL).  It 
would be a huge incremental effort, IMO, to reach consensus and embed 
normative N&S conditions into SpecGL.

Recommendation.  Accept the comment, but apply it to SpecET, as *desirable* 
(recommended) considerations for the presentation of conformance 
requirements in specifications.  (Also ... if any of the IJ recommendations 
raise serious dissent in QA discussion as *general* desirable 
characteristics, then we might need to qualify and narrow their 
applicability.  I.e., maybe we will conclude that there are some scenarios 
where they are desirable, and others where they are not, so that we cannot 
present them as generally applicable to everyone.  This is tbd in QA 
discussion.)

Regards,
-Lofton.


Regards,
-Lofton.

[1] http://www.w3.org/QA/WG/lc-issues#x29
Received on Thursday, 12 June 2003 11:04:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:14:00 GMT