SRS（ソフトウェア要求仕様書）は、自然言語で書かれますが、曖昧さのない正確な記述にしなければなりません。完成した製品が要求通りに動作確認することは必須条件です。曖昧な記述によって、解釈を誤りバグを作り込んでしまったり、手戻りによるスケジュール遅れ、開発費の超過、納期遅れといった事態になる場合があります。米国ＮＡＳＡのSoftware Assurance Technology Centerでは、ＳＲＳの品質特性を下表のように10種類に分類しています。(参考：http://www.gsfc.nasa.gov/)
SRS品質特性
|
ＳＲＳ品質特性 |
意味 |
|
Complete 完全性 |
1つの文書に全てが書かれており、読者が意味を調べるために他の文書を読まなければならなくなるようなことがない。 |
|
Consistent 整合性 |
機能および性能を両立できること。但し、安全性や信頼性などの品質特性によって、これらの機能や性能が打ち消されていないこと。 |
|
Accurate 正確性 |
実際の運用環境におけるシステム性能を正確に定義していること。一般に、多くの仕様書で問題になる部分である。 |
|
Modifiable 変更可能であること |
論理的、階層的な構造になっており、容易に変更可能であること。（関連項目ごとにまとめられていると容易に修正できる。） |
|
Ranked ランク付け |
安定性、重要度、安全性、実装の難易度などの側面から要求項目をランク付けしていること。人命に関わるような装置や設備のソフトウェア開発の場合、十分に考慮すべき点である。 |
|
Testable テスト容易性 |
要求内容通りに正しく実装されたかどうかを検証するための検証方法が記されていること。 |
|
Traceable トレーサビリティ |
要求項目がトレーサビリティであること。具体的には、SRSの基となる参照ドキュメントが明記されていること（Backward tractability）。または、SRSの要求項目に番号付け、ユニークな名前を付けることで、設計仕様書やテスト仕様書の項目からからSRSの要求項目に容易にたどるようになっていること（Forward tractability）。 |
|
Unambiguous 曖昧さがないこと |
要求事項は、誰が読んでも同じ解釈になるように書かれていること。要求仕様書は、自然言語で書かれているため、難しいポイントである。 |
|
Valid 妥当性 |
全てのプロジェクト関係者が要求項目を理解、分析、検証、承認できるような内容になっていること。要求仕様書が自然言語で書かなければならない理由の一つである。 |
|
Verifiable 検証可能であること |
SRSの要求項目が検証可能であること。「works well」、「good human interface」、「shall usually happen」などの表現がある場合、検証が不可能である。「good」、「well」、「usually」などの単語は避けるべきである。入力・設定条件と期待する値などを具体的に書いてあれば検証が可能である。 |
コメントをお書きください