定義の履歴 
●文書のよしあし．文書を「文字で書くことの結果」ととらえて，その結果を評価するために注目すべき性質(11.11.07 塩谷)
＊文書のよしあし．文字や記号や図形で書かれた文書の性質(11.11.30 山本雅)
＊文書の利用目的への適合の程度．文書が利用者に対して情報を提供する上で，その文書の良さを利用者の立場から評価した結果．文書には，文字だけでなく記号や図形で書かれたものも含む
(「情報品質の研究」関口 編,中央経済社の「情報品質」に関する記述を参考)
(11.12.08 塩谷)→NOTEに移動（12.9.13 塩谷)
＃「品質」は，利用者や利用目的を意識した上で評価されるべきものであると考える(11.12.08 塩谷)
＃類語として「開発文書品質」は，「開発文書を利用する関係者にとっての適合性」と定義できる（「情報品質の研究」内の「情報品質」の定義に基づいた「ASDoQロードマップ White Paper」での定義による）(12.2.07 塩谷)
＊文書の利用目的への適合の程度．文書が利用者に対して情報を提供する上で，その文書の良さを利用者の立場から評価した結果．文書には，文字だけでなく記号や図形で書かれたものも含む(「情報品質の研究」関口 編,中央経済社の「情報品質質」に関する記述を参考)(12.7.19 塩谷)
＊文書に備わっている明示された又は暗黙の必要性を満たす能力に関する特性の全体 （12.9.12ミーティング結果によって改訂 塩谷）
＃上記の12.9.12ミーティング版は、定義に使っている用語が難しく、意味を理解しにくいと考えます。１つ前の（12.7.19)版の方が分かりやすいと思います（12.9.17 塩谷）
＊文書における品質
読み手と書き手の間で、正確に、必要十分な情報を伝えるための文書の特性である。
特性の代表的なものは、無矛盾性、非曖昧性、簡潔性、わかりやすい表現や構造などがある。
(12.9.18 永田)
＃上記特性の代表例は、「システム開発文書品質」の定義に移行
＃「正確な」や「必要十分な」は、特性の例に入れた方がよい
(12.9.18 部会ミーティング結果により「システム開発文書品質」に移行 塩谷)
＊(１案）文書の目的を達成するための特性
＊(２案）文書の目的に適合する程度を示すための特性
(12.9.18 部会ミーティング結果による 塩谷)
＃(1案)では，「文書品質」自体に，「目的を達成している」という意味が含まれているようにとられないだろうか？
（例）「品質を保つ」という言い方は正しくない。
∵「品質」という用語自体に「良いor高い」や「悪いor低い」の意味はないはず。
「品質を保つ」ではなく、「高品質を保つ」(程度を示す言葉は「品質」の外に置く）
などとすべきではないか。
＃「品質」は、「良いor高い」や「悪いor低い」の程度や度合い、または「目的がどの程度達成されているか」ということなので、「目的を達成するための」ものではない。(12.9.21 塩谷補記)
＃(2案)では、「目的に適合する程度」（または「目的の達成度合い」でもよい）
として、「程度」や「度合」を問題としているため、「良し悪し」を前提としない。
(2案)の意図で、もっとわかりやすい表現がないだろうか。
(12.9.18 部会ミーティング結果による意見 塩谷)
＃(1案）を外し、(2案）採用＆代替案として以下を検討
＊文書の目的達成の程度を示すための特性(12.9.21 塩谷)
＊文書のその目的に対する達成の程度を示すための特性(12.9.27 石田)
＊文書に課された目的を果たすために求められる，文書が持つべき特性(12.9.27 藤田)
＃「文書品質」は、目的を果たすためのものではなく、目的を果たさないことも含め、その果たし具合の程度を示す。そのため「程度」を入れたい。どのくらい果たしているかという意味を含ませたい(12.9.28 塩谷)
＊文書が目的を達成する程度を示すための特性(12.9.28 塩谷)
＊文書がその文書の目的を達成している程度を示すための特性(12.9.28 永田)
＊文書がその目的を達成している程度を示すための特性(12.10.1 塩谷)
外部での定義
ソフトウェアのJISでは，文書はソフトウェアに含んでいるので，すべてのソフトウェア品質規定は文書を含んでいます。
システム開発文書がソフトウェアを含むという定義にしてあると，矛盾が少なくて済みます。(12.06.15 小川清）
用途
システム開発文書には，「ソースコード」を含む．（→「システム開発文書」の用途に移動してはどうか 12.7.19 塩谷）
#ASDoQで扱う「文書品質」は，システム開発文書を対象とする．（←「用途」を＜使い方の指針＞にしてはどうか 12.7.19 塩谷）
＊文書品質が求められる適合性を満たす度合を示す形容詞には，「良い・悪い」を推奨する．ただし，その適合性の度合が数値化できている場合には，その数値化の指標に応じて「高い・低い」を用いる．(12.7.19 塩谷）
- 「用途」を定義ページから外し、NOTEに移動（2012.9.13 塩谷）
用例
- ASDoQでは，システム開発文書の文書品質に関する取り組みを行っています．
- 開発文書の「文書品質」に対して，未だ，明確な定義や評価基準，その活用および改善方法が確立されていない．
- 文書品質が良い、悪い。文書品質が高い、低い。
- 行間を読まなければ理解できない要求仕様書は、文書品質が悪い。
[ASDoQ_wg:00670]によって「用例」全体を定義ページから外し、NOTEに移動 (2012.9.28 塩谷）
対英語
document quality, quality of document
- 永田さん，塩谷さんの投稿（[ASDoQ_wg:00687] [ASDoQ_wg:00690]）によって，対英語を定義ページから外し，NOTEに移動
（理由）
元の言葉が英語のものに対して，英語表記を確認することで議論の一助とする．という目的で調査した．しかし，実際には，英語の単語を並べただけで、表現としては不適切なものも見受けられるため．(201210.02 石田）
