この付録は情報を提供するものである。 This appendix is informative.
この表は QA フレームワーク:仕様指針 [QAF-SPEC] 【QA = 品質保証】に定められたすべての要件と良い実践の照合リストから得られたものである。各要件と良い実践に対し、表では要件または最良の実践を満たす SVG Tiny 1.2 仕様の一部分へのリンクを与えている。 This table is derived from the checklist of all defined requirements and good practices from the QA Framework: Specification Guidelines [QAF-SPEC]. For each requirement and good practice, the table links to the part of the SVG Tiny 1.2 specification that satisfied the requirement or best practice.
指針 | YES | NO | N/A | 備考 |
---|---|---|---|---|
2.1 適合性の指定 2.1 Specifying Conformance | ||||
要件 01: 適合性の条項を含めている。 Requirement 01: Include a conformance clause. | YES | |||
良い実践 01: 仕様の適合性モデルを適合性の条項で定めている。 Good Practice 01: Define the specification's conformance model in the conformance clause. | YES | |||
良い実践 02: 適合性の条項の中で正式な内容と情報を与える内容の区別の仕方を定めている。 Good Practice 02: Specify in the conformance clause how to distinguish normative from informative content. | YES | |||
良い実践 03: 適合性の条項の中で言葉遣いを定めている。 Good Practice 03: Provide the wording for conformance claims. | no | |||
良い実践 04: 実装の適合性の表明についての見積もりを提供している。 Good Practice 04: Provide an Implementation Conformance Statement Pro Forma. | no | |||
良い実践 05: 有効な適合性要求の一部として実装の適合性の表明を要求している。 Good Practice 05: Require an Implementation Conformance Statement as part of valid conformance claims. | no | |||
2.2 基本原則の設定 2.2 Setting up ground rules | ||||
要件 02: 【機能/応用の】範囲を定めている。 Requirement 02: Define the scope. | YES | |||
良い実践 06: 用例, ユースケース, グラフィックを提供している。 Good Practice 06: Provide examples, use cases, and graphics. | YES | |||
良い実践 07: サンプルコードやテストを書いている。 Good Practice 07: Write sample code or tests. | YES | |||
要件 03: 誰がまたは何が仕様を実装するかを特定している。 Requirement 03: Identify who or what will implement the specification. | YES | |||
要件 04: 正式な参照文献の一覧を作成している。 Requirement 04: Make a list of normative references. | YES | |||
良い実践 08: 正式な参照文献からの要求を課す際に適合性の依存関係を述べている。 Good Practice 08: When imposing requirements by normative references, address conformance dependencies. | YES | |||
2.3 用語の定義と運用 2.3 Defining and using terminology | ||||
要件 05: 仕様の正式な部分において用いられる用語を定義している。 Requirement 05: Define the terms used in the normative parts of the specification. | YES | |||
要件 06: 適合性モデルの各部分に適合性ラベルを作成している。 Requirement 06: Create conformance labels for each part of the conformance model. | YES | |||
良い実践 09: 馴染みの薄い用語を文中に定義して用語一覧の節の定義を補完している。 Good Practice 09: Define unfamiliar terms in-line and consolidate the definitions in a glossary section. | YES | |||
良い実践 10: 定義済みの用語の定義を変えずに用いている。 Good Practice 10: Use terms already defined without changing their definition. | YES | |||
要件 07: 適合性要件を一貫したスタイルで用いていて、それらの区別の仕方を説明している。 Requirement 07: Use a consistent style for conformance requirements and explain how to distinguish them. | YES | |||
要件 08: どの適合性の要件が義務的で, どれが推奨されるもので, どれがオプションなのかの指示がなされている。 Requirement 08: Indicate which conformance requirements are mandatory, which are recommended, and which are optional. | YES | |||
良い実践 11: 可能な限り公式の言語を用いている。 Good Practice 11: Use formal languages when possible. | yes | |||
良い実践 12: テスト assertion を書いている。 Good Practice 12: Write Test Assertions. | no | |||
2.4 多様性の管理 2.4 Managing Variability | ||||
良い実践 13: 正当な理由が生じた際に技術を分割している。 Good Practice 13: Create subdivisions of the technology when warranted. | YES | |||
要件 09: 技術が分割された際に、どの分割が適合性において義務的になるかを示している。 Requirement 09: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. | YES | |||
要件 10: 技術が分割された際に、分割の制約に言及している。 Requirement 10: If the technology is subdivided, then address subdivision constraints. | YES | |||
良い実践 14: 技術のプロファイルが行われた際に、新たなプロファイルを作成する規則を定めている。 Good Practice 14: If the technology is profiled, define rules for creating new profiles. | YES | |||
良い実践 15: 正当な根拠の下にオプション機能を用いている。 Good Practice 15:Use optional features as warranted. | YES | |||
良い実践 16: オプションの機能を明白に特定している。 Good Practice 16: Clearly identify optional features. | YES | |||
良い実践 17: オプション機能に関する限界または制約を示している。 Good Practice 17: Indicate any limitations or constraints on optional features. | YES | |||
要件 11: 拡張性について言及されている。 Requirement 11: Address Extensibility. | YES | |||
良い実践 18: 拡張が許容されている場合に拡張の仕組みが定められている。 Good Practice 18: If extensibility is allowed, define an extension mechanism. | YES | |||
良い実践 19: 拡張を作成する者に対し、拡張の作成にあたって適合性を損なわないように警告している。 Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance. | YES | |||
良い実践 20: 未知の拡張に対するエラー処理を定めている。 Good Practice 20: Define error handling for unknown extensions. | YES | |||
要件 12: 廃止予定の機能を特定している。 Requirement 12: Identify deprecated features. | YES |
廃止予定の機能には明確にそのようにマークされている。
Deprecated features are clearly marked as such.
|
||
要件 13: 各廃止予定の機能に対し各分類のプロダクトがどのように処理するかを定めている。 Requirement 13: Define how each class of product handles each deprecated feature. | n/a | |||
良い実践 21: 廃止予定の機能の利用を避ける方法を説明している。 Good Practice 21: Explain how to avoid using a deprecated feature. | n/a | |||
良い実践 22: 旧式になった機能を特定している。 Good Practice 22: Identify obsolete features. | n/a | None | ||
良い実践 23: エラー処理の仕組みを定めている。 Good Practice 23: Define an error handling mechanism. | YES |