W3C

Checklist of Checkpoints for "QA Framework: Specification Guidelines"

This version:
http://www.w3.org/TR/2002/WD-qaframe-spec-20020515/qaframe-spec-checklist
This document is an appendix to:
http://www.w3.org/TR/2002/WD-qaframe-spec-20020515/
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 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 specifications 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 specification writers and evaluators, 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], section 3).

Checklist table

Guideline 1. Support general document conformance conventions.

Nbr Checkpoint Priority Yes No N/A
1.1

Use conformance key words.

[Priority 1]      
1.2

Distinguish normative and informative text.

[Priority 2]      
1.3

Follow Web Accessibility Initiative and Internationalization Guidelines.

[Priority 1]      
1.4

Use the same words to express the same ideas.

[Priority 1]      

Guideline 2. Provide a conformance clause.

Nbr Checkpoint Priority Yes No N/A
2.1

Include a conformance clause.

[Priority 1]      
2.2

Create a separate conformance section.

[Priority 2]      
2.3

Generate a conformance clause entry in the table of contents.

[Priority 2]      

Guideline 3. Specify flavors of conformance.

Nbr Checkpoint Priority Yes No N/A
3.1

Choose one or more of the following flavors: (a) strict conformance, (b) conditional and unconditional conformance, (c) other, (d) no flavor.

[Priority 2]      
3.2

If (a) or (b) or (c) is selected, generate a table of contents entry.

[Priority 2]      
3.3

For choice (a), include a definition of strict conformance in the specification.

[Priority 2]      
3.4

For choice (b), include a definition of conditional and unconditional conformance in the specification.

[Priority 2]      
3.5

For choice (c), provide the name of the flavor and its definition within the specification.

[Priority 2]      

Guideline 4. Identify what needs to conform and how.

Nbr Checkpoint Priority Yes No N/A
4.1

Identify all classes of product.

[Priority 1]      
4.2

For each class of product, define the conformance requirements.

[Priority 1]      
4.3

Indicate minimal support requirements.

[Priority 3]      

Guideline 5. Divide specification in order to group requirements.

Nbr Checkpoint Priority Yes No N/A
5.1

Choose one or more of the following methods for grouping or dividing up the specification: a) modularization, b) profiling, c) levels, d) none of the above.

[Priority 1]      
5.2

If (a), (b), and/or (c) was selected, ensure that a table of contents entry is generated.

[Priority 1]      
5.3

For (a), (b) and/or (c), indicate whether its use is mandatory.

[Priority 1]      
5.4

For (a), (b) and/or (c), define any minimal requirements.

[Priority 2]      
5.5

For (a), (b), and/or (c), indicate relationships between modules, profiles, and/or levels.

[Priority 2]      

Guideline 6. Specify how to make a conformance claims.

Nbr Checkpoint Priority Yes No N/A
6.1

Identify and define all conformance levels or designations.

[Priority 1]      
6.2

Provide specific wording of the claim.

[Priority 3]      
6.3

Provide a conformance disclaimer.

[Priority 3]      
6.4

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

[Priority 1]      
6.5

Generate a table of content entry.

[Priority 2]      

Guideline 7. Define user scenarios.

Nbr Checkpoint Priority Yes No N/A
7.1

Define the scope of the specification.

[Priority 1]      
7.2

Include Use Cases.

[Priority 2]      
7.3

Include examples.

[Priority 1]      
7.4

Include an interpretation section.

[Priority 2]      

Guideline 8. Define discretionary behaviors.

Nbr Checkpoint Priority Yes No N/A
8.1

Explicitly state the cases and conditions where discretion is allowed and/or expected.

[Priority 2]      
8.2

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

[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

Generate a table of contents entry.

[Priority 2]      

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

Nbr Checkpoint Priority Yes No N/A
9.1

Identify and clearly indicate each deprecated feature.

[Priority 1]      
9.2

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

[Priority 1]      
9.3

Include an explanation for the deprecation.

[Priority 3]      
9.4

Include examples to illustrate how to avoid using deprecated features.

[Priority 3]      
9.5

Generate a table of contents entry.

[Priority 2]      

Guideline 10. Allow extensions or NOT!

Nbr Checkpoint Priority Yes No N/A
10.1

If extensions are disallowed, explicitly state it.

[Priority 3]      
10.2

If extensions are allowed, explicitly state it.

[Priority 1]      
10.3

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

[Priority 1]      
10.4

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

[Priority 3]      
10.5

If extensions are allowed, register or publish them.

[Priority 3]      
10.6

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

[Priority 3]      
10.7

Generate a table of contents entry.

[Priority 2]      

Guideline 11. Publish an Implementation Conformance Statement proforma.

Nbr Checkpoint Priority Yes No N/A
11.1

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

[Priority 3]      
11.2

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

[Priority 3]      

Guideline 12. Use granular grammars to author the specification.

Nbr Checkpoint Priority Yes No N/A
12.1

Use W3C endorsed grammar where applicable.

[Priority 1]      
12.2

Specify intended behavior in the specification using markup.

[Priority 1]      
12.3

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

[Priority 1]      
12.4

Supply test assertions in the markup of the specification, if applicable using a set of predefined tags used in the specification markup language.

[Priority 1]      
12.5

Tag test assertions according to the above.

[Priority 1]      

References

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