QA Specification Guidelines - Implementation Conformance Statement to Specification Guidelines

Based on April 2005 version of SpecGL ICS applied to April 2005 version of SpecGL; completed on April 20 2005.

Checklist table

Guidelines	YES	NO	N/A	Comments
2.1 Specifying Conformance
Requirement 01: Include a conformance clause.	yes
Good Practice 01: Define the specification's conformance model in the conformance clause.	yes
Good Practice 02: Specify in the conformance clause how to distinguish normative from informative content.	yes
Good Practice 03: Provide the wording for conformance claims.	yes
Good Practice 04: Provide an Implementation Conformance Statement Pro Forma.	yes
Good Practice 05: Require an Implementation Conformance Statement as part of valid conformance claims.	yes
2.2 Setting up ground rules
Requirement 02: Define the scope.	yes
Good Practice 06: Provide examples, use cases, and graphics.	Yes			SpecGL uses many examples, and the 3 embedded stories serve as use cases; it also uses 2 figures for illustration of some of the most complex concepts.
Good Practice 07: Write sample code or tests.	Yes			SpecGL techniques are the equivalent of sample code
Requirement 03: Identify who or what will implement the specification.	yes
Requirement 04: Make a list of normative references.	yes
Good Practice 08: When imposing requirements by normative references, address conformance dependencies.			N/A	SpecGL doesn't impose requirements by normative references, since the only normative reference is RFC 2119 used to define conformance vocabulary.
2.3 Defining and using terminology
Requirement 05: Define the terms used in the normative parts of the specification.	yes
Requirement 06: Create conformance labels for each part of the conformance model.	yes
Good Practice 09: Define unfamiliar terms in-line and consolidate the definitions in a glossary section.	Yes			See for instance how specification is defined in-line and in the glossary
Good Practice 10: Use terms already defined without changing their definition.	yes			SpecGL re-uses the ISO definition of specification, the RFC Keywords
Requirement 07: Use a consistent style for conformance requirements and explain how to distinguish them.	Yes
Requirement 08: Indicate which conformance requirements are mandatory, which are recommended, and which are optional.	yes
Good Practice 11: Use formal languages when possible.			N/A	SpecGL doesn't define machine-processable content, so this doesn't apply
Good Practice 12: Write Test Assertions.		No		SpecGL doesn't define Test Assertions.
2.4 Managing Variability
Good Practice 13: Create subdivisions of the technology when warranted.			N/A	SpecGL goal of use simplicity and focus on a consistent set of checkpoints does not need subdivisions.
Requirement 09: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance.			N/A	see above
Requirement 10: If the technology is subdivided, then address subdivision constraints.			N/A	See above
Good Practice 14: If the technology is profiled, define rules for creating new profiles.			N/A	See above
Good Practice 15:Use optional features as warranted.				@@@
Good Practice 16: Clearly identify optional features.	Yes			In addition to Requirements, the document contains Good Practices. Good Practices are optional and considered recommendations.
Good Practice 17: Indicate any limitations or constraints on optional features.	Yes			It has optional features, but the optional features do not affect conformance.
Requirement 11: Address Extensibility.	Yes
Good Practice 18: If extensibility is allowed, define an extension mechanism.	Yes			This specification is extensible. That is, adding conformance related information and structure to the document in ways beyond what is presented as Requirements in this specification, is allowed and encouraged. Extensions to this specification must not contradict nor negate the requirements in this specification.
Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance.	Yes			Extensions to this specification must not contradict nor negate the requirements in this specification.
Good Practice 20: Define error-handling for unknown extensions.			N/A	SpecGL doesn't have a class of product that can be affected by errors conditions
Requirement 12: Identify deprecated features.			N/A	First version of SpecGL
Requirement 13: Define how each class of product handles each deprecated feature.			N/A	see above
Good Practice 21: Explain how to avoid using a deprecated feature.			N/A	see above
Good Practice 22: Identify obsolete features.			N/A	First version of SpecGL
Good Practice 23: Define an error handling mechanism.			N/A	SpecGL doesn't have a class of product affected by error conditions