W3C

Checklist of Checkpoints for "QA Framework: Specification Guidelines"

This version:
http://www.w3.org/TR/2002/WD-qaframe-spec-20020826/qaframe-spec-checklist
This document is an appendix to:
http://www.w3.org/TR/2002/WD-qaframe-spec-20020826/
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, complete with 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 send comments to www-qa@w3.org, the publicly archived list of the QA Interest Group [QAIG]. Please note that any mail sent to this list will be publicly archived and available. Do not send information you wouldn't want to see distributed, such as private data.

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 checkpoint priorities are included, and the order of the specification guidelines document is maintained.

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 of the specification guidelines ([QAF-SPEC], chapter 3) .

Checklist table

Guideline 1. Define Use Cases.

NbrCheckpointPriorityYesNoN/A
1.1

Define the scope of the specification.

[Priority 1]   
1.2

Include User Scenarios.

[Priority 2]   
1.3

Provide examples.

[Priority 1]   
1.4

Ensure that every test assertion is covered by an example.

[Priority 3]   
1.5

Include an interpretation section.

[Priority 2]   

Guideline 2. Identify what needs to conform and how.

NbrCheckpointPriorityYesNoN/A
2.1

Identify all classes of product.

[Priority 1]   
2.2

For each class of product, define the conformance requirements.

[Priority 1]   
2.3

For each class of product, indicate minimal support requirements.

[Priority 3]   
2.4

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

[Priority 3]   

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

NbrCheckpointPriorityYesNoN/A
3.1

Choose whether or not to have profiles.

[Priority 1]   
3.2

Include a table of contents entry.

[Priority 2]   
3.3

If profiles are chosen, indicate whether or not their use is mandatory for conformance.

[Priority 1]   
3.4

If profiles are chosen, define any minimal requirements.

[Priority 2]   
3.5

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

[Priority 2]   
3.6

If profiles are chosen, address rules for profiles.

[Priority 2]   

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

NbrCheckpointPriorityYesNoN/A
4.1

Choose whether or not to have modules.

[Priority 1]   
4.2

Include a table of contents entry.

[Priority 2]   
4.3

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

[Priority 1]   
4.4

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

[Priority 2]   

Guideline 5. Specify conformance policy.

NbrCheckpointPriorityYesNoN/A
5.1

Make it clear where there are universal requirements for minimum functionality.

[Priority 1]   
5.2

Make it clear when conformance requirements are strict.

[Priority 1]   
5.3

Make it clear where requirements stop and product-specific extra features begin.

[Priority 1]   
5.4

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

[Priority 1]   

Guideline 6. Clarify the relation between deprecated features and conformance.

NbrCheckpointPriorityYesNoN/A
6.1

Identify and clearly indicate each deprecated feature.

[Priority 1]   
6.2

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

[Priority 1]   
6.3

Include an explanation for the deprecation.

[Priority 3]   
6.4

Include examples to illustrate how to avoid using deprecated features.

[Priority 3]   
6.5

Include a table of contents entry.

[Priority 2]   

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

NbrCheckpointPriorityYesNoN/A
7.1

Address whether the specification uses or will use functional levels.

[Priority 1]   
7.2

Include a table of contents entry.

[Priority 2]   
7.3

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

[Priority 2]   

Guideline 8. Define discretionary items.

NbrCheckpointPriorityYesNoN/A
8.1

Explicitly state the cases and conditions where discretionary items are allowed.

[Priority 1]   
8.2

Indicate implementation dependencies and address allowable differences between implementations, where applicable.

[Priority 1]   
8.3

Describe alternative approaches and the conditions under which an implementation is considered to be conforming.

[Priority 1]   
8.4

Include a statement regarding consistent handling of a discretionary item within an implementation.

[Priority 2]   
8.5

Include a table of contents entry.

[Priority 2]   

Guideline 9. Allow extensions or NOT!

NbrCheckpointPriorityYesNoN/A
9.1

If extensions are disallowed, explicitly state it.

[Priority 1]   
9.2

If extensions are allowed, explicitly state it.

[Priority 1]   
9.3

If extensions are allowed, make it clear that the extensions do not negate support for required functionality.

[Priority 1]   
9.4

If extensions are allowed, use a standard mechanism to define the extension.

[Priority 3]   
9.5

If extensions are allowed, register or publish them.

[Priority 3]   
9.6

If extensions are allowed, require that implementations include a way to operate without the extension.

[Priority 3]   
9.7

Include a table of contents entry.

[Priority 2]   

Guideline 10. Provide a conformance clause.

NbrCheckpointPriorityYesNoN/A
10.1

Include a conformance clause.

[Priority 1]   
10.2

Create a separate conformance section.

[Priority 2]   
10.3

Include a conformance clause entry in the table of contents.

[Priority 2]   
10.1

Make normative reference to specifications on which the current specification depends.

[Priority 2]   
10.5

Identify all dimensions of variability that are not used.

[Priority 1]   

Guideline 11. Specify how to make conformance claims.

NbrCheckpointPriorityYesNoN/A
11.1

Identify and define all conformance designations.

[Priority 1]   
11.2

Provide specific wording of the claim.

[Priority 3]   
11.3

Provide a conformance disclaimer.

[Priority 3]   
11.4

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

[Priority 1]   
11.5

Include a table of contents entry.

[Priority 2]   

Guideline 12. Publish an Implementation Conformance Statement proforma.

NbrCheckpointPriorityYesNoN/A
12.1

Include an Implementation Conformance Statement proforma as part of the specification.

[Priority 3]   
12.2

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

[Priority 3]   

Guideline 13. Support general document conformance conventions.

NbrCheckpointPriorityYesNoN/A
13.1

Use conformance key words.

[Priority 1]   
13.2

Distinguish normative and informative text.

[Priority 2]   
13.3

Follow Web Accessibility Initiative and Internationalization Guidelines.

[Priority 1]   
13.4

Use consistent terminology.

[Priority 1]   

Guideline 14. Use granular grammars to author the specification.

NbrCheckpointPriorityYesNoN/A
14.1

Use W3C endorsed grammar.

[Priority 2]   
14.2

Identify intended behavior in the specification using markup.

[Priority 2]   
14.3

Supply prose description of intended behavior together with each test assertion.

[Priority 2]   

Guideline 15. Include test assertions.

NbrCheckpointPriorityYesNoN/A
15.1

Supply test assertions in the specification..

[Priority 1]   
15.2

Tag test assertions according to a granular grammar.

[Priority 2]   

References

QAF-SPEC
QA Framework: Specification Guidelines, L. Henderson, L. Rosenthal, D. Dimitriadis, K. Gavrylyuk, Eds., W3C Working Draft, August 2002, available at http://www.w3.org/TR/2002/WD-qaframe-spec-20020826/.