SRS(要求仕様書)の品質特性

SRS(ソフトウェア要求仕様書)は、自然言語で書かれますが、曖昧さのない正確な記述にしなければなりません。完成した製品が要求通りに動作確認することは必須条件です。曖昧な記述によって、解釈を誤りバグを作り込んでしまったり、手戻りによるスケジュール遅れ、開発費の超過、納期遅れといった事態になる場合があります。米国NASAのSoftware Assurance Technology Centerでは、SRSの品質特性を下表のように10種類に分類しています。(参考:http://www.gsfc.nasa.gov/)

 

SRS品質特性

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」などの単語は避けるべきである。入力・設定条件と期待する値などを具体的に書いてあれば検証が可能である。