自社案件で「要件 (WHAT)」を確定させる文書の H2 10 節骨格 SSoT。承認済 BRD を起点に · 機能要件 / 非機能要件 / データ要件 / 外部インタフェース要件 / 制約 を確定させ · 実装 (設計 → 開発) の入力にする。RQ-120 3 モデル Deep Research (docs/research/rq-120-brd-rdd-standards/) の 5 標準比較から抽出した中小企業向け mini template 10 章 · 10-15 ページ規模想定。
BRD / RDD / 設計書 の使い分け
- BRD (
brd-template.md): 要求 (WHY) の合意記録
- RDD (本テンプレ): 要件 (WHAT) の合意記録 · 「システムは 〜 する」の文型 · HOW (実装技術) は書かない
- 設計書 (Design Document): 実装 (HOW) の技術記録 · アーキ · スキーマ · API 詳細
RDD で技術選定を書き始めたら設計書側に送る (例: 「Cloud Run で実装する」は RDD ではなく設計書)。
想定読者
- エンジニア · Jr: RDD を起点に設計 → 実装 → テストを進める
- QA · テスト担当: Fit Criteria (§9) をテスト仕様の入力に使う
- 顧客側 IT 部門: 検収時のチェックリストとして使う
- 将来の保守担当: 数年後に本 RDD を Read してシステムの WHAT を復元する
全体設計原則 (3 モデル consensus)
- WHAT のみ · HOW は書かない — 「〜する」まで書いて止める。「〜を X で実装する」は設計書側
- 各要件に Fit Criteria を書く — Volere の技術。「検収時に何を測るか」を各要件に添える (曖昧要件検出装置)
- 非機能要件は ISO/IEC 25010 の 8 特性を全部確認 — 使わない特性は「該当なし」と明記 (欠落 = 抜け漏れ扱い)
- 文型は「システムは 〜 する / であること」 — 主語を書く · 曖昧語 (「適切に」「必要に応じて」「原則として」) 禁止 · 定量表現必須 (「〜秒以内」「稼働率 99.5%」)
- Traceability Matrix を最終節に必ず書く — BRD ↔ RDD ↔ (後段) テスト仕様の 3 段リンクの起点
H2 10 節 (順序固定)
以下の順序で H2 を配置する。番号 prefix (## 1. Introduction & Scope) は推奨 (lint で strip して比較)。案件固有の説明は H3 サブ見出しで該当節の下に入れる。独自 H2 は禁止。
1. Introduction & Scope (序文とスコープ)
1.1 対応する BRD
- BRD ID:
- BRD 承認日:
- BRD 承認者:
1.2 RDD の適用範囲
1.3 用語 · 略語
2. Overall Description (全体説明)
2.1 ユーザークラス
2.2 想定利用環境
- ブラウザ:
- OS:
- モバイル対応:
- ネットワーク:
2.3 前提とする外部システム
2.4 全体像 (概念レベル)
3. Functional Requirements (機能要件)
3.1 FR-01: (機能名)
- 概要: システムは 〜 する
- 入力:
- 処理:
- 出力:
- 例外処理:
- 優先度: Must / Should / Could
- 対応 BR: BR-XX
3.2 FR-02: (機能名)
4. Non-functional Requirements (非機能要件)
4.1 機能適合性 (Functional Suitability)
- 時間効率: 応答時間 < XX 秒 (p95)
- 資源効率:
- キャパシティ: 同時アクセス XX ユーザー
4.3 互換性 (Compatibility)
4.4 使用性 (Usability)
- 学習容易性: 新規ユーザー XX 分で初回タスク完了
- 操作性:
- UI 美的性:
- アクセシビリティ:
4.5 信頼性 (Reliability)
- 成熟性:
- 可用性: 稼働率 XX.X% (月間ダウンタイム < XX 分)
- 障害許容性:
- 回復性: RPO XX 分 / RTO XX 時間
4.6 セキュリティ (Security)
- 機密性:
- 完全性:
- 否認防止:
- 説明責任:
- 真正性:
4.7 保守性 (Maintainability)
- モジュール性:
- 再利用性:
- 解析性:
- 修正性:
- 試験性:
4.8 移植性 (Portability)
5. Data Requirements (データ要件)
5.1 主要 Entity 一覧
5.2 データ保存要件
5.3 データ主権 · 個人情報
6. External Interface Requirements (外部インタフェース要件)
6.1 API インタフェース
6.2 UI · 主要画面
6.3 Hardware インタフェース (該当あれば)
7. Business Rules & Constraints (ビジネスルールと制約)
7.1 ビジネスルール
7.2 実装制約
8. Assumptions & Dependencies (前提と依存)
8.1 技術前提
8.2 外部依存
9. Fit Criteria (Volere 適合基準)
| 要件 ID | Fit Criterion (測定方法) | 検証タイミング |
|---|
| FR-01 | | |
| NFR-4.2 | | |
10. Traceability Matrix (トレーサビリティ表)
| BR ID | 関連 FR / NFR | 備考 |
|---|
| BR-01 | | |
| BR-02 | | |
逆引き (FR / NFR → BR)
Fit Criteria (RDD 完成条件 · IEEE 830 §4.3 "Good SRS" 8 特性)
RDD 承認前に以下を満たすことを確認する:
関連
- RQ-120 (
docs/research/rq-120-brd-rdd-standards/): 本テンプレの一次調査 (3 モデル Deep Research · $6.58)
brd-template.md: 本テンプレの前段 (BRD)adr-draft.template.md: RDD 内の技術選定論点は ADR draft 経由で個別起案adr-draft-style-guide.md: 用語 Tier · アンチパターンは ADR draft と共有
参考文献 (一次資料)
- IEEE 830-1998 (Recommended Practice for Software Requirements Specifications)
- ISO/IEC/IEEE 29148:2018 §9 (Software Requirements Specification structure)
- ISO/IEC 25010 (System and software quality models · 8 品質特性)
- IPA 情報処理推進機構「要件定義編」: https://dx.ipa.go.jp/youken-teigi
- IPA「非機能要求グレード」: https://www.ipa.go.jp/sec/publish/tn12-002.html
- Volere Requirements Template v18 (volere.org · Fit Criterion の一次資料)
- BABOK v3 §10 Techniques (IIBA)