W3C

Checklist of Checkpoints for "QA Framework: Specification Guidelines"

This version:
http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/qaframe-spec-ics
This document is an appendix to:
http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/
Latest version of "QA Framework: Specification Guidelines":
http://www.w3.org/TR/qaframe-spec/
Editors:
Dominique HazaŽl-Massieux (dom@w3.org)
Lofton Henderson (lofton@rockynet.com)
Contributors:
See Acknowledgments in QA Framework: Specification Guidelines.

Abstract

This document is an appendix QA Framework: Specification Guidelines [QAF-SPEC] . It provides a tabular checklist of all checkpoints from the specification guidelines, sorted by their priorities. Please refer to QA Framework: Specification Guidelines [QAF-SPEC] for the full statement and description of the specification guidelines and checkpoints, as well as references to related documents and full credits and acknowledgements of contributors to the specification guidelines work.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This document is derived from and is an appendix to QA Framework: Specification Guidelines [QAF-SPEC] , which document is a W3C Working Draft (WD), made available by the W3C Quality Assurance (QA) Activity for discussion by W3C members and other interested parties. For more information about the QA Activity, please see the QA Activity statement. Please see the "Status of this document" section of the corresponding specification guidelines [QAF-SPEC] , for complete details about the status of the specification guidelines version from which this is extracted and which it accompanies.

Please use this form to make your comments. If for some reason you are unable to use the form, you may email comments to www-qa@w3.org, the publicly archived list of the QA Interest Group. Note that comments that you make will be publicly archived and available, do not send information you would not want to see distributed, such as private data. Please submit your comments by 14 March 2003, when Last Call review ends.

Publication of this document does not imply endorsement by the W3C, its membership or its staff. This is a draft document and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.


Introduction

This checklist includes all checkpoints from the QA Framework: Specification Guidelines [QAF-SPEC] presented in a tabular format. The checkpoints are presented by order of their priorities, which makes it an appropriate Implementation Conformance Statement for the guidelines.

The presentation is intended to be convenient for organizers and evaluators of QA projects in W3C Working Groups, to facilitate assessing specifications against the checkpoints. The table includes spaces for scoring each checkpoint, "yes" (satisfied), "no" (not satisfied), "n/a" (not applicable).

Priorities

For a description of the meaning of the priorities in the following table, please consult the conformance clause and the priorities definition section of the specification guidelines ([QAF-SPEC], chapter 3 and section 1.7) .

Checklist table

Degree A Conformance

To be A-conformant with the guidelines, the following Priority 1 checkpoints must be fulfilled:

NbrCheckpointYesNoN/A

Guideline 1. Define Scope.

1.1

Include the scope of the specification.

   

Guideline 2. Identify what needs to conform and how.

2.1

Identify all classes of product.

   
2.2

For each class of product, define the conformance requirements.

   

Guideline 3. Specify conformance policy.

3.2

If special conformance terms are used, include a definition in the specification.

   
3.3

Justify any usage of a dimension of variability

   

Guideline 4. Address the use of profiles to divide the technology.

4.1

Indicate whether or not the use of profiles is mandatory for conformance.

   

Guideline 5. Address the use of modules to divide the technology.

5.1

If modules are chosen, indicate any mandatory conditions or constraints on their usage.

   

Guideline 7. Identify the relation between deprecated features and conformance.

7.1

Identify each deprecated feature.

   
7.2

For each class of product, specify the degree of support required for each deprecated feature and the conformance consequences of the deprecation.

   

Guideline 8. Define discretionary items.

8.1

State the circumstances for when discretionary items are allowed

   
8.2

For implementation dependencies, address the allowable differences between implementations

   

Guideline 9. Allow extensions or NOT!

9.1

Indicate if the specification is extensible.

   
9.2

If extensions are allowed, define their scope and constraints.

   
9.3

Prevent extensions from contradicting the specification.

   

Guideline 10. Provide a conformance clause.

10.1

Include a conformance section.

   

Guideline 11. Specify how to make conformance claims.

11.1

Identify and define all conformance designations.

   
11.4

Impose no restrictions about who can make a claim or where claims can be published.

   

Guideline 13. Clearly identify conformance requirements.

13.1

Use conformance key words.

   
13.2

Distinguish normative and informative text.

   
13.3

Use consistent terminology.

   

Degree AA Conformance

To be AA-conformant with the guidelines, the following Priority 2 checkpoints must be fulfilled (in addition to the above Priority 1 checkpoints):

NbrCheckpointYesNoN/A

Guideline 1. Define Scope.

1.2

Illustrate what is in scope

   
1.4

Provide examples.

   

Guideline 2. Identify what needs to conform and how.

2.4

If there are several classes of products, define their relationships and interaction with other dimensions of variability.

   

Guideline 3. Specify conformance policy.

3.1

Specify any universal requirements for minimum functionality.

   

Guideline 4. Address the use of profiles to divide the technology.

4.2

If profiles are chosen, define any minimal requirements.

   
4.3

If profiles are chosen, define their relationships and interaction with other dimensions of variability.

   
4.4

If profiles are chosen, address rules for profiles.

   

Guideline 5. Address the use of modules to divide the technology.

5.2

If modules are chosen, define their relationships and interaction with other dimensions of variability.

   

Guideline 6. Address the use of functional levels to divide the technology.

6.1

If levels are used, define their relationships and interaction with other dimensions of variability.

   

Guideline 7. Identify the relation between deprecated features and conformance.

7.3

If deprecation is used, define its relationships and interaction with other dimensions of variability.

   

Guideline 8. Define discretionary items.

8.3

Indicate any constraints on the number of choices/options that can be implemented for discretionary choices

   
8.4

Promote consistent handling of discretionary choices.

   
8.5

If discretionary items are used, define their relationships and interaction with other dimensions of variability.

   

Guideline 9. Allow extensions or NOT!

9.7

If extensions are allowed, define their relationships and interaction with other dimensions of variability

   

Guideline 10. Provide a conformance clause.

10.2

Make normative reference to specifications on which the current specification depends

   

Guideline 13. Clearly identify conformance requirements.

13.4

Provide a fast way to find conformance information

   

Guideline 14. Provide test assertions.

14.1

Provide test assertions

   
14.2

Provide a mapping between the specification and the test assertions list

   

Degree AAA Conformance

To be AAA-conformant with the guidelines, the following Priority 3 checkpoints must be fulfilled (in addition to the above Priority 1 and Priority 2 checkpoints):

NbrCheckpointYesNoN/A

Guideline 1. Define Scope.

1.3

Provide Usage Scenarios.

   

Guideline 2. Identify what needs to conform and how.

2.3

Identify which of the categories of object are specified in the document as a whole.

   

Guideline 7. Identify the relation between deprecated features and conformance.

7.4

Include an explanation for the deprecation.

   
7.5

Include examples to illustrate how to avoid using deprecated features.

   

Guideline 9. Allow extensions or NOT!

9.4

Define a uniform mechanism to create an extension

   
9.5

Require that extensions be published.

   
9.6

Require that implementations provide interoperable alternatives to extensions

   

Guideline 11. Specify how to make conformance claims.

11.2

Provide specific wording of the claim.

   
11.3

Provide a conformance disclaimer.

   

Guideline 12. Publish an Implementation Conformance Statement proforma.

12.1

Provide an Implementation Conformance Statement proforma.

   
12.2

Require the ICS be completed as part of the conformance claim.

   

References

QAF-SPEC
QA Framework: Specification Guidelines, D. HazaŽl-Massieux, L. Henderson, L. Rosenthal, D. Dimitriadis, K. Gavrylyuk, Eds., W3C Working Draft, February 2003, available at http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/.