SRS（ソフトウェア要件仕様書）テンプレート
準拠規格：IEEE 29148:2018 / ISO 25010:2023
バージョン：v3.0
使い方：[角括弧]の部分を自分のプロジェクトに書き換える
ドキュメント管理
| 項目 |
内容 |
| ドキュメントID |
SRS-[プロジェクト略称]-v1.0 |
| プロジェクト名 |
[プロジェクト名] |
| 作成日 |
[YYYY-MM-DD] |
| 最終更新日 |
[YYYY-MM-DD] |
| 作成者 |
[名前] |
| ステータス |
草稿 / レビュー中 / 承認済み |
1. はじめに（IEEE 29148 §5.2）
1.1 目的
本ドキュメントは、[プロジェクト名]の機能要件・非機能要件・制約条件を定義する。
開発者（Claude Code）はこのドキュメントに基づいて実装を行い、このドキュメントに記載のない機能は実装しない。
1.2 スコープ
システム名： [システム名]
何をするシステムか（一文で）：
[例：Substack記事を自動スケジュール投稿し、購読者への配信を管理するWebアプリケーション]
スコープ内（作るもの）：
- [機能1]
- [機能2]
- [機能3]
スコープ外（作らないもの）：
- [作らない機能1]
- [作らない機能2]
1.3 定義・略語
| 用語 |
定義 |
| [用語1] |
[定義] |
| [用語2] |
[定義] |
1.4 参照文書
- CLAUDE.md（プロジェクト設定）
- SDD_v1.md（設計書）
- TEST_PLAN_v1.md（テスト計画書）
2. 全体的な説明（IEEE 29148 §5.3）
2.1 システム概要
[システムの全体像を2〜3文で説明する]
2.2 ユーザー像（ペルソナ）
主要ユーザー：
- 名前：[ペルソナ名]
- 属性：[年齢・職業・ITリテラシー]
- 目的：[このシステムを使って何を達成したいか]
- 課題：[現在困っていること]
2.3 動作環境
| 項目 |
要件 |
| OS |
[例：Windows 10以上 / macOS 12以上] |
| ブラウザ |
[例：Chrome最新版 / Safari最新版] |
| インターネット |
[例：必須（常時接続）] |
| 画面解像度 |
[例：1280x720以上] |
2.4 制約条件
- 技術制約： [例：既存のSubstack APIを使用すること]
- ビジネス制約： [例：月額コストを5,000円以内に抑えること]
- 法的制約： [例：個人情報保護法に準拠すること]
3. 外部インターフェース要件（IEEE 29148 §5.4.1）
3.1 ユーザーインターフェース
- [UI要件1：例：スマートフォンでも操作できること（レスポンシブ対応）]
- [UI要件2：例：主要操作は3クリック以内で完了できること]
- [UI要件3：例：エラーメッセージは日本語で表示すること]
3.2 外部システム連携
| 外部システム |
連携方法 |
用途 |
| [例：Substack API] |
[例：REST API] |
[例：記事の投稿・管理] |
| [例：SendGrid] |
[例：REST API] |
[例：メール送信] |
4. 機能要件（IEEE 29148 §5.4.2）
要件IDの命名規則
FR-[機能カテゴリ]-[番号]
例：FR-AUTH-001（認証機能の要件001）
FR-ART-001（記事管理機能の要件001）
優先度の定義
- Must（必須）：Phase 1で実装する。これがないとシステムが成立しない
- Should（推奨）：Phase 2で実装する。あると便利だが、なくても動く
- Could（任意）：Phase 3以降。余裕があれば実装する
- Won't（今回は対象外）：今回のバージョンでは実装しない
4.1 [機能カテゴリ名：例：ユーザー認証]
FR-AUTH-001：[機能名：例：ユーザー登録]
| 項目 |
内容 |
| 優先度 |
Must |
| 説明 |
[機能の説明] |
受け入れ基準（Given-When-Then）：
Given（前提）：
- [前提条件1]
- [前提条件2]
When（操作）：
- [ユーザーが行う操作]
Then（結果）：
- [期待される結果1]
- [期待される結果2]
異常系：
Given：[異常な前提条件]
When：[操作]
Then：[エラーメッセージや処理]
FR-AUTH-002：[機能名：例：ログイン]
| 項目 |
内容 |
| 優先度 |
Must |
| 説明 |
[機能の説明] |
受け入れ基準：
Given：[前提条件]
When：[操作]
Then：[期待結果]
4.2 [機能カテゴリ名：例：記事管理]
FR-ART-001：[機能名]
| 項目 |
内容 |
| 優先度 |
Must |
| 説明 |
[機能の説明] |
受け入れ基準：
Given：[前提条件]
When：[操作]
Then：[期待結果]
5. 非機能要件（ISO 25010:2023準拠）
| 要件ID |
要件 |
測定方法 |
| NFR-PERF-001 |
ページ読み込み時間が3秒以内 |
ブラウザの開発ツールで計測 |
| NFR-PERF-002 |
API応答時間が1秒以内 |
ネットワークタブで計測 |
5.2 信頼性（Reliability）
| 要件ID |
要件 |
測定方法 |
| NFR-REL-001 |
稼働率99%以上（月間ダウンタイム7時間以内） |
監視ツールで計測 |
| NFR-REL-002 |
データ損失ゼロ（バックアップ毎日1回） |
バックアップログ確認 |
5.3 セキュリティ（Security）
| 要件ID |
要件 |
確認方法 |
| NFR-SEC-001 |
全通信をHTTPS化 |
ブラウザの鍵マーク確認 |
| NFR-SEC-002 |
パスワードをbcryptでハッシュ化 |
DBの値を確認 |
| NFR-SEC-003 |
セッションタイムアウト（24時間） |
動作確認 |
5.4 使用性（Usability）
| 要件ID |
要件 |
確認方法 |
| NFR-USE-001 |
ITに不慣れなユーザーが説明書なしで主要機能を使えること |
ユーザーテスト |
| NFR-USE-002 |
エラーメッセージが日本語で分かりやすく表示されること |
目視確認 |
5.5 保守性（Maintainability）
| 要件ID |
要件 |
確認方法 |
| NFR-MAINT-001 |
テストカバレッジ80%以上 |
カバレッジレポート |
| NFR-MAINT-002 |
全公開関数にJSDocコメントがあること |
コードレビュー |
6. 制約条件（IEEE 29148 §5.5）
6.1 技術制約
- [例：Node.js v20以上を使用すること]
- [例：PostgreSQL 15以上を使用すること]
6.2 ビジネス制約
- [例：月額インフラコストを5,000円以内に抑えること]
- [例：2026年8月31日までにPhase 1を完成させること]
6.3 法的制約
- [例：個人情報保護法（日本）に準拠すること]
- [例：利用規約に同意したユーザーのみが利用できること]
7. 用語集
| 用語 |
定義 |
| [用語1] |
[定義] |
| [用語2] |
[定義] |
8. 付録
付録A：ユースケース図（テキスト形式）
[ユーザー] → [機能1] → [システム]
[ユーザー] → [機能2] → [システム]
[システム] → [外部API] → [外部サービス]
付録B：データモデル（主要テーブル）
users テーブル：
id, email, password_hash, created_at, updated_at
articles テーブル：
id, user_id, title, content, status, scheduled_at, created_at
付録C：Claude Codeへの引き渡し手順
このSRS（docs/SRS_v1.md）を読んで、以下を実施してください：
1. 不明な点・矛盾する点があれば先に質問してください
2. Phase 1（Must要件）の実装計画を提示してください
3. 実装計画に同意したら、AGENT-ARCHとしてSDDを作成してください
4. SDD完成後、AGENT-DEVとして実装を開始してください