Guideline 1. Define user scenarios.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
1.1 |
Define
the scope of the specification.
|
[Priority 1]
|
|
|
|
1.2 |
Include Use Cases.
|
[Priority 2]
|
|
|
|
1.3 |
Include examples.
|
[Priority 1]
|
|
|
|
1.4 |
Include an interpretation section.
|
[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 |
Indicate minimal support requirements.
|
[Priority 3]
|
|
|
|
Guideline 3. Address the use of profiles to divide
the specification.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
3.1 |
Choose whether or not to have
profiles.
|
[Priority 1]
|
|
|
|
3.2 |
If profiles are chosen, ensure that a table of
contents entry is generated.
|
[Priority 1]
|
|
|
|
3.3 |
If profiles are chosen, indicate any
mandatory conditions or constraints on usage.
|
[Priority 1]
|
|
|
|
3.4 |
If profiles are chosen, define any minimal
requirements.
|
[Priority 2]
|
|
|
|
3.5 |
If profiles are selected, define their
relationships and interaction with other dimensions of variability.
|
[Priority 2]
|
|
|
|
Guideline 4. Address the use of modules to divide the
specification.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
4.1 |
Choose whether or not to have
modules.
|
[Priority 1]
|
|
|
|
4.2 |
If modules are chosen, ensure that a table of
contents entry is generated.
|
[Priority 1]
|
|
|
|
4.3 |
If modules are chosen, indicate any
mandatory conditions or constraints on usage.
|
[Priority 1]
|
|
|
|
4.4 |
If modules are chosen, define any minimal
requirements.
|
[Priority 2]
|
|
|
|
4.5 |
If modules are chosen, define their
relationships and interaction with other dimensions of variability.
|
[Priority 2]
|
|
|
|
Guideline 5. Specify conformance policy.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/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 |
The
conformance clause should contain or refer to the conformance policy.
|
[Priority 1]
|
|
|
|
5.5 |
If
special conformance terms are used, include a definition in the
specification.
|
[Priority 1]
|
|
|
|
5.6 |
Minimize variability.
|
[Priority 1]
|
|
|
|
Guideline 6. Clarify the
relation between deprecated features and conformance.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
6.1 |
Identify and clearly indicate each deprecated
feature.
|
[Priority 1]
|
|
|
|
6.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]
|
|
|
|
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 |
Generate a table of contents entry.
|
[Priority 2]
|
|
|
|
Guideline 7. Address the use of levels to divide the
specification.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
7.1 |
Choose whether or not to have levels.
|
[Priority 1]
|
|
|
|
7.2 |
If levels are chosen, ensure that a table of
contents entry is generated.
|
[Priority 1]
|
|
|
|
7.3 |
If levels are chosen, indicate any
mandatory conditions or constraints on usage.
|
[Priority 1]
|
|
|
|
7.4 |
If levels are chosen, define any minimal
requirements.
|
[Priority 2]
|
|
|
|
7.5 |
If levels are chosen, define their
relationships and interaction with other dimensions of variability.
|
[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. Allow
extensions or NOT!
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
9.1 |
If extensions are disallowed, explicitly
state it.
|
[Priority 3]
|
|
|
|
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 |
Generate a table of contents entry.
|
[Priority 2]
|
|
|
|
Guideline 10. Provide a conformance clause.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
10.1 |
Include a conformance clause.
|
[Priority 1]
|
|
|
|
10.2 |
Create a separate conformance section.
|
[Priority 2]
|
|
|
|
10.3 |
Generate a
conformance clause entry in the table of contents.
|
[Priority 2]
|
|
|
|
Guideline 11. Specify how to make conformance
claims.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
11.1 |
Identify and define all conformance levels or
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 |
Generate a
table of contents entry.
|
[Priority 2]
|
|
|
|
Guideline 12. Publish an Implementation
Conformance Statement proforma.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/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.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/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
the same words to express the same ideas.
|
[Priority 1]
|
|
|
|
Guideline 14. Use granular grammars to author the
specification.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
14.1 |
Use W3C endorsed grammar where applicable.
|
[Priority 1]
|
|
|
|
14.2 |
Specify intended behavior in the specification
using markup.
|
[Priority 1]
|
|
|
|
14.3 |
Supply prose description of intended behavior
together with each test assertion.
|
[Priority 1]
|
|
|
|
Guideline 15. Include test assertions.
|
Nbr |
Checkpoint |
Priority |
Yes |
No |
N/A |
15.1 |
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]
|
|
|
|
15.2 |
Tag
test assertions according to the above.
|
[Priority 1]
|
|
|
|