3-4 要件仕様書（SRS）
Software Requirements Specification
1. SRSの目的と重要性
1.1 SRSとは
SRS（Software Requirements Specification）は、ソフトウェアシステムに 求められる機能・性能・制約を体系的に記述した文書である。 IEEE 830やISO/IEC/IEEE 29148で標準化されている。
1.2 SRSの役割
SRSは開発プロジェクトにおいて重要な役割を果たす。
| 利用者 | SRSの役割 |
|---|---|
| 発注者・ユーザー | 期待するシステムの確認、受入基準の根拠 |
| 設計者 | 設計の入力、設計判断の根拠 |
| 開発者 | 実装すべき機能の理解 |
| テスター | テストケース作成の根拠 |
| プロジェクトマネージャー | スコープ管理、変更管理の基準 |
| 保守担当者 | システム仕様の理解、変更影響分析 |
SRSは発注者と受注者の合意文書であり、契約の基盤となる。 「言った・言わない」の紛争を防ぎ、スコープの明確化、 変更管理の基準として機能する。
2. SRSの構成
2.1 IEEE 830に基づく構成
IEEE 830（現在はISO/IEC/IEEE 29148に統合）では、 SRSの標準的な構成を定義している。
| セクション | 内容 |
|---|---|
| 1. はじめに | 目的、スコープ、用語定義、参考文献、概要 |
| 2. 全体説明 | 製品の視点、機能、ユーザー特性、制約、前提条件 |
| 3. 具体的な要件 | 機能要件、非機能要件（性能、インターフェース等） |
| 付録 | モデル、プロトタイプ、未解決事項 |
2.2 機能要件の記述
機能要件は、システムが提供する機能を具体的に記述する。 一般的に以下の形式で記述される。
| 項目 | 内容 | 例 |
|---|---|---|
| 要件ID | 一意の識別子 | FR-ORD-001 |
| 要件名 | 簡潔な名称 | 注文登録 |
| 説明 | 要件の詳細説明 | ユーザーは商品を選択し注文を登録できる |
| 入力 | 必要な入力データ | 商品ID、数量、配送先 |
| 処理 | システムの処理内容 | 在庫確認、金額計算、注文データ保存 |
| 出力 | 処理結果 | 注文番号、確認メール送信 |
| 優先度 | 重要度 | Must |
| 関連要件 | 依存する要件 | FR-INV-001（在庫管理） |
2.3 ユーザーストーリー形式
アジャイル開発では、ユーザーストーリー形式で要件を記述することが多い。
「[ユーザータイプ]として、[機能]をしたい。なぜなら[価値]だからだ。」
例：「購入者として、過去の注文履歴を確認したい。なぜなら再注文を簡単にしたいからだ。」
| 要素 | 説明 |
|---|---|
| ユーザーストーリー | ユーザー視点での機能記述 |
| 受入基準 | ストーリーが完了とみなされる条件 |
| ストーリーポイント | 相対的な規模・複雑さの見積り |
3. 要件の品質基準
3.1 良い要件の特性
IEEE 830では、SRSが満たすべき品質特性を定義している。
| 特性 | 説明 | チェックポイント |
|---|---|---|
| 正確性 | 記述が事実と一致 | ステークホルダーの確認を得ているか |
| 曖昧でない | 唯一の解釈のみ可能 | 「など」「適切な」などの曖昧な語がないか |
| 完全性 | すべての要件が含まれる | TBD（未定）が残っていないか |
| 一貫性 | 要件間に矛盾がない | 同じ用語が同じ意味で使われているか |
| 検証可能性 | 達成をテストで確認可能 | 具体的な数値や条件があるか |
| 追跡可能性 | 出所と影響が追跡可能 | 要件IDと関連が記録されているか |
| 変更可能性 | 変更が容易 | 重複がなく、構造化されているか |
3.2 避けるべき表現
要件記述では曖昧な表現を避ける必要がある。
| 避けるべき表現 | 問題点 | 改善例 |
|---|---|---|
| 「速く」「高速に」 | 基準が不明 | 「3秒以内に」 |
| 「使いやすい」 | 主観的 | 「3ステップ以内で完了」 |
| 「など」「その他」 | 範囲が不明確 | 具体的に列挙 |
| 「適切な」「必要に応じて」 | 判断基準が不明 | 具体的な条件を記述 |
| 「できれば」「可能な限り」 | 必須かどうか不明 | Must/Shouldを明示 |
「現行システムと同様」という記述は要件として不十分である。 現行システムの仕様が文書化されていない場合、解釈の相違が発生する。 具体的な機能・仕様を明記すべきである。
4. 要件トレーサビリティ
4.1 トレーサビリティとは
要件トレーサビリティとは、要件の出所（ビジネス要件）から 成果物（設計、コード、テスト）までの追跡可能性を確保することである。
4.2 トレーサビリティマトリックス
要件トレーサビリティマトリックス（RTM）は、 要件と関連成果物の対応を表形式で管理するツールである。
| 要件ID | 要件名 | 設計書 | ソースコード | テストケース |
|---|---|---|---|---|
| FR-001 | ユーザー登録 | DD-2.1 | UserRegister.java | TC-001〜005 |
| FR-002 | ログイン認証 | DD-2.2 | AuthService.java | TC-010〜020 |
| NFR-001 | 応答時間3秒以内 | DD-5.1 | - | PT-001 |
変更の影響分析：要件変更時に影響範囲を特定できる。
テストカバレッジ：すべての要件がテストされているか確認できる。
監査対応：規制産業での証跡として活用できる。
5. レビューと承認
5.1 SRSレビュー
SRSはステークホルダーによるレビューを経て承認される。 レビューでは前述の品質特性を確認する。
| レビュー形式 | 特徴 | 適用場面 |
|---|---|---|
| インスペクション | 形式的、チェックリスト使用 | 重要なSRS、規制対応 |
| ウォークスルー | 著者主導で説明 | 一般的なレビュー |
| ピアレビュー | 同僚による非形式レビュー | 日常的な確認 |
5.2 ベースライン化
レビュー・承認されたSRSはベースラインとして管理される。 以降の変更は変更管理プロセスを通じて行われる。
変更管理のポイント
すべての変更要求を記録する。
変更の影響（コスト、スケジュール、品質）を評価する。
変更管理委員会（CCB）で承認/却下を判断する。
承認された変更をSRSに反映し、バージョンを更新する。
関係者に変更を周知する。
要件定義の全体像を学習しました。 次は「第4章 設計」で、要件をシステム設計に落とし込む方法を学習しよう。
[1] IEEE (1998). IEEE Std 830-1998.
[2] ISO/IEC/IEEE (2018). ISO/IEC/IEEE 29148:2018.
[3] Wiegers, K. (2013). Software Requirements 3rd Edition.