Checklist of Checkpoints for "QA Framework: Specification Guidelines"

This version:: http://www.w3.org/QA/WG/2002/12/qaframe-spec-checklist-20021220
This document is an appendix to:: http://www.w3.org/QA/WG/2002/12/qaframe-spec-20021220
Latest version of "QA Framework: Specification Guidelines":: http://www.w3.org/QA/WG/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-20021220] . 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-20021220] 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-20021220] , 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-20021220] , 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-20021220] 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 @@@ against the checkpoints. The table includes spaces for scoring each checkpoint, "yes" (satisfied), "no" (not satisfied), "n/a" (not applicable).

Checklist table

Guideline 1. Define Scope.
Nbr	Checkpoint	Priority	Yes	No	N/A
1.1	Define the scope of the specification.	[Priority 1]
1.2	Provide Usage Scenarios.	[Priority 2]
1.3	Provide examples.	[Priority 1]
1.4	Provide an example for each section that is difficult to understand .	[Priority 2]
Guideline 2. Identify what needs to conform and how.
Nbr	Checkpoint	Priority	Yes	No	N/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	Identify which of the categories of object are specified in the document as a whole.	[Priority 3]
Guideline 3. Specify conformance policy.
Nbr	Checkpoint	Priority	Yes	No	N/A
3.1	Specify any universal requirements for minimum functionality.	[Priority 1]
3.2	Identify strict conformance requirements.	[Priority 1]
3.3	Distinguish requirements from product-specific extra features	[Priority 1]
3.4	If special conformance terms are used, include a definition in the specification.	[Priority 1]
3.1	Justify any usage of a dimension of variability by reference to usage scenarios and requirements	[Priority 1]
Guideline 4. Address the use of profiles to divide the technology.
Nbr	Checkpoint	Priority	Yes	No	N/A
4.1	Indicate whether or not the use of profiles is mandatory for conformance.	[Priority 1]
4.2	If profiles are chosen, define any minimal requirements.	[Priority 2]
4.3	If profiles are chosen, define their relationships and interaction with other dimensions of variability.	[Priority 2]
4.4	If profiles are chosen, address rules for profiles.	[Priority 2]
Guideline 5. Address the use of modules to divide the technology.
Nbr	Checkpoint	Priority	Yes	No	N/A
5.1	If modules are chosen, indicate any mandatory conditions or constraints on their usage.	[Priority 1]
5.2	If modules are chosen, define their relationships and interaction with other dimensions of variability.	[Priority 2]
Guideline 6. Address the use of functional levels to divide the technology.
Nbr	Checkpoint	Priority	Yes	No	N/A
6.1	If levels are used, define their relationships and interaction with other dimensions of variability.	[Priority 2]
Guideline 7. Identify the relation between deprecated features and conformance.
Nbr	Checkpoint	Priority	Yes	No	N/A
7.1	Identify each deprecated feature.	[Priority 1]
7.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]
7.3	Include an explanation for the deprecation.	[Priority 3]
7.4	Include examples to illustrate how to avoid using deprecated features.	[Priority 3]
Guideline 8. Define discretionary items.
Nbr	Checkpoint	Priority	Yes	No	N/A
8.1	State the circumstances for when discretionary items are allowed	[Priority 1]
8.2	For implementation dependencies, address the allowable differences between implementations	[Priority 1]
8.3	Indicate any constraints on the number of choices/options that can be implemented	[Priority 2]
8.4	Promote consistent handling of discretionary choices.	[Priority 2]
Guideline 9. Allow extensions or NOT!
Nbr	Checkpoint	Priority	Yes	No	N/A
9.1	Indicate if the specification is extensible.	[Priority 1]
9.2	If extensions are allowed, define their scope and constraints.	[Priority 1]
9.3	Prevent extensions from contradicting the specification.	[Priority 1]
9.4	Use a standard mechanism to define the extension.	[Priority 3]
9.5	Require that extensions be published.	[Priority 3]
9.6	Require implementations to include a way to "turn off" extensions.	[Priority 3]
Guideline 10. Provide a conformance clause.
Nbr	Checkpoint	Priority	Yes	No	N/A
10.1	Include a conformance section.	[Priority 1]
10.2	Make normative reference to specifications on which the current specification depends	[Priority 2]
Guideline 11. Specify how to make conformance claims.
Nbr	Checkpoint	Priority	Yes	No	N/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]
Guideline 12. Publish an Implementation Conformance Statement proforma.
Nbr	Checkpoint	Priority	Yes	No	N/A
12.1	Provide an Implementation Conformance Statement proforma.	[Priority 3]
12.2	Require the ICS be completed as part of the conformance claim.	[Priority 3]
Guideline 13. Support general document conformance conventions.
Nbr	Checkpoint	Priority	Yes	No	N/A
13.1	Use conformance key words.	[Priority 1]
13.2	Distinguish normative and informative text.	[Priority 1]
13.3	Use consistent terminology.	[Priority 1]
13.4	Provide a fast way to find conformance information	[Priority 2]
Guideline 14. Provide test assertions.
Nbr	Checkpoint	Priority	Yes	No	N/A
14.1	Provide test assertions	[Priority 1]
14.2	Provide a mapping between the specification and the test assertions list	[Priority 2]

Guideline 1. Define Scope.

Nbr

Checkpoint

Priority

Yes

N/A

1.1

Define the scope of the specification.

[Priority 1]

1.2

Provide Usage Scenarios.

[Priority 2]

1.3

Provide examples.

[Priority 1]

1.4

Provide an example for each section that is difficult to understand .

[Priority 2]

Guideline 2. Identify what needs to conform and how.

Nbr

Checkpoint

Priority

Yes

N/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

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

[Priority 3]

Guideline 3. Specify conformance policy.

Nbr

Checkpoint

Priority

Yes

N/A

3.1

Specify any universal requirements for minimum functionality.

[Priority 1]

3.2

Identify strict conformance requirements.

[Priority 1]

3.3

Distinguish requirements from product-specific extra features

[Priority 1]

3.4

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

[Priority 1]

3.1

Justify any usage of a dimension of variability by reference to usage scenarios and requirements

[Priority 1]

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

Nbr

Checkpoint

Priority

Yes

N/A

4.1

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

[Priority 1]

4.2

If profiles are chosen, define any minimal requirements.

[Priority 2]

4.3

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

[Priority 2]

4.4

If profiles are chosen, address rules for profiles.

[Priority 2]

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

Nbr

Checkpoint

Priority

Yes

N/A

5.1

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

[Priority 1]

5.2

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

[Priority 2]

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

Nbr

Checkpoint

Priority

Yes

N/A

6.1

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

[Priority 2]

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

Nbr

Checkpoint

Priority

Yes

N/A

7.1

Identify each deprecated feature.

[Priority 1]

7.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]

7.3

Include an explanation for the deprecation.

[Priority 3]

7.4

Include examples to illustrate how to avoid using deprecated features.

[Priority 3]

Guideline 8. Define discretionary items.

Nbr

Checkpoint

Priority

Yes

N/A

8.1

State the circumstances for when discretionary items are allowed

[Priority 1]

8.2

For implementation dependencies, address the allowable differences between implementations

[Priority 1]

8.3

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

[Priority 2]

8.4

Promote consistent handling of discretionary choices.

[Priority 2]

Guideline 9. Allow extensions or NOT!

Nbr

Checkpoint

Priority

Yes

N/A

9.1

Indicate if the specification is extensible.

[Priority 1]

9.2

If extensions are allowed, define their scope and constraints.

[Priority 1]

9.3

Prevent extensions from contradicting the specification.

[Priority 1]

9.4

Use a standard mechanism to define the extension.

[Priority 3]

9.5

Require that extensions be published.

[Priority 3]

9.6

Require implementations to include a way to "turn off" extensions.

[Priority 3]

Guideline 10. Provide a conformance clause.

Nbr

Checkpoint

Priority

Yes

N/A

10.1

Include a conformance section.

[Priority 1]

10.2

Make normative reference to specifications on which the current specification depends

[Priority 2]

Guideline 11. Specify how to make conformance claims.

Nbr

Checkpoint

Priority

Yes

N/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]

Guideline 12. Publish an Implementation Conformance Statement proforma.

Nbr

Checkpoint

Priority

Yes

N/A

12.1

Provide an Implementation Conformance Statement proforma.

[Priority 3]

12.2

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

[Priority 3]

Guideline 13. Support general document conformance conventions.

Nbr

Checkpoint

Priority

Yes

N/A

13.1

Use conformance key words.

[Priority 1]

13.2

Distinguish normative and informative text.

[Priority 1]

13.3

Use consistent terminology.

[Priority 1]

13.4

Provide a fast way to find conformance information

[Priority 2]

Guideline 14. Provide test assertions.

Nbr

Checkpoint

Priority

Yes

N/A

14.1

Provide test assertions

[Priority 1]

14.2

Provide a mapping between the specification and the test assertions list

[Priority 2]

References

QAF-SPEC-20021220

QA Framework: Specification Guidelines , D. Hazaël-Massieux, L. Henderson, L. Rosenthal, D. Dimitriadis, K. Gavrylyuk, Eds., W3C Working Draft, W3C Working Draft 20 December 2002 , available at http://www.w3.org/QA/WG/qaframe-spec.

Checklist of Checkpoints for "QA Framework: Specification Guidelines"

Abstract

Status of this document

Introduction

Priorities

Checklist table

References