software-requirements

ソフトウェア要件分析

開発チームが実装でき、QA チームがテストでき、ステークホルダーが確信を持って承認できる、専門的で包括的かつ明確なソフトウェア要件ドキュメントを作成します。

入力の取り扱い

入力の種類を判断し、それに応じて対応します。

1. 非形式的な説明 -- ユーザーが作りたいものを平易な言葉で説明します（例：「パスワードリセット機能付きのログインページが必要です」）。発見フェーズと作成フェーズに従って、これを構造化された要件に展開します。

2. レビュー対象の既存ドキュメント -- ユーザーが批評を求めて既存の要件ドキュメントを提示します。発見フェーズを省略し、要件レビュー モードに進みます。

3. 「Xを書いて」という依頼 -- ユーザーが特定のドキュメントの種類を明示的に依頼します（例：「決済システムの SRS を書いてください」）。スコープが明確であれば発見フェーズを省略し、ドキュメントの種類の選択と作成に進みます。

4. ユーザーストーリー作成の機能リクエスト -- ユーザーが特定の機能やスプリント向けのユーザーストーリーと受け入れ条件を求めています。ドキュメントの種類ガイドにあるユーザーストーリーのテンプレートを使用します。

発見フェーズ（フェーズ 1）

要件を書く前に、必ず以下の 7 つの質問を通じて背景情報を収集してください。ユーザーからすでに情報が提供されている場合は、把握している内容を確認し、不足している項目だけを尋ねてください。このフェーズを省略してはいけません。

以下についてユーザーに確認します。

1. システム／製品：何を構築しますか？対象範囲に明示的に含まれるものと、含まれないものは何ですか？
2. ステークホルダー：エンドユーザー、管理者、運用担当者、外部システム、規制当局は誰ですか？
3. 課題：どのような具体的な課題を解決しますか？なぜこれが必要なのですか？
4. 制約：技術スタック、予算、スケジュール、規制要件（GDPR、HIPAA、PCI-DSS、SOX、ADA）、連携対象の既存システム、レガシーシステムへの依存関係はありますか？
5. ドキュメントの種類：どのような種類のドキュメントが必要ですか？（不明な場合は、背景情報に基づいて推奨します。）
6. 納品形式：.docx、Markdown、Wiki、JIRA ストーリー、Confluence ページのどれですか？
7. 既存資料：参照できるワイヤーフレーム、ユーザー調査、競合分析、既存ドキュメントはありますか？

すべての前提を明示し、最終ドキュメントに列挙してください。

ドキュメントの種類の選択（フェーズ 2）

このフェーズに進む前に、references/document-types.md を読んでください。

発見フェーズの内容に基づき、判断基準に従って適切なドキュメントの種類を推奨してください。参照ファイルには、以下が含まれています。

• 選択表（SRS、PRD、BRD、FRD、ユーザーストーリー、ユースケース）
• 簡易判断ロジック
• 6 種類すべてのドキュメントテンプレート

要件作成（フェーズ 3）

このフェーズの前に、references/requirement-writing-rules.md を読んでください。

要件は次のルールに従って作成してください。

• 言語ルール：すべての要件では、「shall」（必須）、「should」 （推奨）、または「may」（任意）を使用してください。能動態を使ってください。1 つの要件で、「and」または「or」を使って複数の動作を組み合わせないでください。正確な数量を明記してください（例：「すばやく」ではなく「2 秒以内」）。
• 要件 ID の形式：FR-AUTH-001、NFR-PERF-001、 DR-001、IR-API-001 のような階層型 ID を使用してください。
• 要件ごとの必須フィールド：ID、説明、根拠、優先度 （Must/Should/Could/Won't）、出典、受け入れ基準、依存関係、備考
• 使用禁止語を避ける：「should generally」、「as appropriate」、「etc.」、「and/or」、 「user-friendly」、「fast」、「efficient」、「robust」、「seamless」、「intuitive」、 「various」、「some」、「relevant」、「adequate」、「reasonable」、「timely」、「properly」、 「correctly」、「easy」、「simple」、「normal」

使用禁止語はすべて、具体的で測定可能な記述に置き換えてください。

入力処理ルール：

• 各 INPUT について、型、形式、有効範囲、必須か任意か、 デフォルト値、最大長を指定してください。
• 各 OUTPUT について、形式、出力先、タイミング、エラー形式を指定してください。
• 各 OPERATION について、失敗時、タイムアウト時、無効なデータを受け取ったとき、同時アクセス時、キャンセル時の動作を指定してください。

簡略な説明を、元の長さの 3 倍以上に拡張してください。たとえば、 1 文の機能説明から、機能、セキュリティ、パフォーマンス、アクセシビリティ、コンプライアンスを網羅する 20 件以上の要件を作成してください。

必須の対象領域（フェーズ 3 続き）

すべてのドキュメントで、次のカテゴリすべてを必ず網羅してください。

A) 機能要件（FR）：中核機能、ビジネスルール、データ 検証、エラー処理、状態遷移、バッチ処理、通知

B) 非機能要件（NFR）：以下を必ずすべて含めてください。

• パフォーマンス：ページ読み込み時間、API 応答時間、スループット、クエリ遅延
• スケーラビリティ：最大同時ユーザー数、最大データ量、成長率
• セキュリティ：認証、認可（RBAC/ABAC）、暗号化、監査 ログ、セッション管理、CSRF/XSS/SQLi 対策
• 信頼性：稼働率目標、MTTR、MTBF、フェイルオーバー戦略、災害復旧
• アクセシビリティ：WCAG レベル（最低 2.1 AA）、キーボード操作、スクリーン リーダー、色のコントラスト
• ユーザビリティ：習得しやすさ、エラーからの復旧、ユーザー満足度のベンチマーク
• 保守性：ログの基準、監視、デプロイ、コード品質
• 移植性：ブラウザーとバージョン、オペレーティングシステム、デバイス、オフライン
• コンプライアンス：GDPR、HIPAA、PCI-DSS、SOX、ADA、COPPA、CCPA、業界規制
• 国際化：言語、ロケール、RTL 対応、Unicode 処理

C) インターフェース要件（IR）：ユーザーインターフェース、スキーマを含む API エンドポイント、ハードウェアインターフェース、サードパーティ統合

D) データ要件（DR）：データモデル、保持ポリシー、移行 戦略、バックアップ手順、プライバシー分類、データ品質ルール

検証フェーズ（フェーズ 4）

このフェーズの前に、references/validation-checklist.md を 読んでください。

すべての要件に対して、検証チェックリストを実行してください。

• 曖昧さのスキャン：禁止語句を検索し、具体的で測定可能な記述に置き換えます
• テスト可能性の確認：各要件について合格／不合格を判定できるテストを作成できますか？
• 完全性の確認：null／空の入力、ネットワーク障害、タイムアウト、ディスク容量不足、不正な形式のデータ、同時アクセス、API の利用不可、権限エラー、セッションの有効期限切れについて検討されていますか？
• 矛盾の確認：同時に満たすことが不可能な要件はありませんか？
• インターフェイスの確認：すべての外部インターフェイスが完全に定義されていますか？
• NFR の確認：すべての非機能カテゴリに対応していますか？
• 優先度の確認：すべての要件に優先度（必須／推奨／可能なら／対象外）が設定されていますか？
• 用語集の確認：すべてのドメイン固有用語が定義されていますか？
• 前提条件の確認：すべての前提条件が明示的に列挙されていますか？
• スコープの確認：対象外の項目が明示的に列挙されていますか？
• トレーサビリティの確認：すべての要件がビジネス目標に紐づいていますか？
• 未解決事項：未解決の項目に、担当者と解決目標日が記録されていますか？

納品に進む前に、すべての問題を修正してください。

納品フェーズ（フェーズ 5）

成果物は次の構成にしてください。

1. 主要な要件ドキュメント -- フェーズ 2 のテンプレートを使用し、すべての要件をカテゴリ別に構成し、ID、優先度、受け入れ基準、相互参照を記載します。

2. 番号付きの前提条件リスト -- 発見と計画の過程で明らかになった暗黙の前提条件をすべて列挙し、それぞれのリスク評価を記載します。

3. 未解決事項ログ -- 未解決の項目を、ID、質問、担当者、目標日、ステータスの各列とともに記載します。

4. 付録：

   • 要件トレーサビリティマトリクス（要件 ID → ビジネス目標 → テストケース ID）
   • ドメイン固有用語をすべて記載した用語集
   • 変更履歴（バージョン、日付、作成者、変更内容）

5. バージョンブロック：ドキュメントの成熟に合わせて、v0.1 Draft → v1.0 Approved とします。

要件レビュー モード

ユーザーが既存の要件ドキュメントをレビュー用に提示した場合：

1. コメントする前に、ドキュメント全体を読む
2. 各要件を 7 つの品質原則（references を参照）に照らして確認する
3. 正確な参照箇所を示して問題を指摘する：
   • 曖昧さ：曖昧な表現を引用し、具体的な置き換え文を提示する
   • 不足：欠落箇所を特定し、それを補う要件文を提案する
   • 矛盾：競合する両方の要件 ID を示し、解決策を提案する
   • テスト不可能：その理由を説明し、テスト可能な書き換え案を提示する
   • 不完全：不足しているエラーケース、エッジケース、NFR カテゴリを特定する
4. 各問題を評価する：
   • 重大：開発を阻害する
   • 大：手戻りの原因となる
   • 小：仕上げ上の問題
5. 要約する：重要度別の問題件数、優先度の高い修正事項トップ 5、全体の品質スコア（1〜10）

最も問題のある要件を、回答内で全面的に書き換えます。

出力ルール

• 要件は「何を」であり、「どのように」ではありません。「システムはユーザーを認証すること」とし、「OAuth 2.0 と JWT を使用すること」とはしません（技術が真に制約となる場合を除く）。
• 非形式的な説明を展開する場合、ユーザーが説明した要件数の最低 3 倍の要件を作成します。
• 必ず末尾に「不足している事項／ステークホルダーからの入力が必要な事項」セクションを含めます。
• 必ず番号付きの前提条件リストを含めます。
• 必ず担当者と目標日を記載した未解決事項ログを含めます。
• ドキュメントをバージョン管理し（v0.1 Draft → v1.0 Approved）、変更履歴を維持します。
• 関連する要件を、全体を通じて ID で相互参照します。
• 正式なドキュメントの場合：目次、ヘッダー、ページ番号、要件表を含めて作成します。
• アジャイル成果物の場合：JIRA／Linear／Shortcut に直接インポートできる形式にします。

ガイドライン

• 発見のプロセスを省略しないでください。憶測で補わないでください。すべての前提を明示してください。
• 使用禁止の語句は決して使わないでください。具体的で測定可能な記述に置き換えてください。
• 関連する要件を ID で相互参照してください。例：「セッション管理の要件については、FR-AUTH-001 を参照してください。」
• くだけた説明を書き換える際は、隠れた前提を明らかにしてください。前提を列挙し、それぞれについて確認してください。
• 複合的な要件は、単一の動作を示す個別の要件に分割してください。
• ユーザーが明示的に求めていない場合でも、分野に応じたセキュリティ、アクセシビリティ、コンプライアンス要件を必ず追加してください。
• 文書が非常に大きい場合（要件が 100 件を超える場合）は、論理的なセクションに分割し、全体をまとめた概要を提示してください。
• ユーザーの意図が不明な場合は、判断を黙って下すのではなく、前提を明示してください。