1 要求事項の基本
1.1 定義と目的
1.1.1 何を「満たす」とは何か
要求事項が「満たされる」とは、対象となる活動や成果物が、定められた条件に照らして所定の水準で実現されている状態を指す。ここでの「満たす」は感覚的な一致ではなく、観察可能な性質（振る舞い、性能、品質特性、手順遵守など）として表現され、評価手段が存在することを前提とする。したがって、同じ要求であっても、検証方法や測定指標が不明確なままでは、充足の判定が成立しにくい。
1.1.2 期待される効果（認識合わせ・判断基準）
要求事項には、関係者間の認識を揃える役割と、判断の基準を提供する役割がある。認識合わせの観点では、目的や範囲、望ましい振る舞いが文章上で共有され、議論が感想・主観の応酬になりにくくなる。判断基準の観点では、設計や実装で選択肢が複数ある場合に、採否の根拠として機能する。結果として、手戻りや仕様の手抜きが減り、合意済みの範囲内で意思決定を進めやすくなる。
1.2 要求事項の位置づけ
1.2.1 関連概念（要件・仕様・期待値）
要求事項は、しばしば「要件」や「仕様」「期待値」と近接して用いられるが、観点が異なる。要件は、達成すべき条件の総称として扱われることが多く、要求事項はその中でも、関係者の意図を反映しつつ、実現・検証のために明確化された単位として整理されることが多い。仕様は、要求を受けて具体化された規定であり、設計・実装の直接の指針になりやすい。期待値は、利用者や関係者が抱く望みの表現であり、要求として文書化される段階で、測定可能性や範囲が調整される。
1.2.2 成果物との関係（要件→設計→検証）
要求事項は、成果物の性質を決める上流の入力として位置づく。典型的には、要求（達成すべき条件）が設計に変換され、設計は具体的な構成や振る舞いへ落とし込まれる。さらに実装後、検証によって要求への適合が確認される。ここで重要なのは、要求が設計に「反映されたか」だけでなく、検証により「要求を満たしていると結論できるか」を確かめる点である。要求が設計に姿を変える過程で意味が欠落したり、必要な測定が省略されたりすると、適合性の議論が不安定になる。
1.3 作成プロセスの全体像
1.3.1 調査・収集から合意まで
作成は、利用状況や課題の調査、関係者の発言の収集、成果物の利用シーンの整理などを経て始まる。次に、収集した情報を「何を達成する必要があるか」という形に再構成し、曖昧な表現を避けて記述を整える。最後に、関係者による合意形成を行い、範囲・優先度・受け入れ条件を固める。合意の段階では、実現可能性だけでなく、妥当性（なぜそれが必要か）と検証方法（どう確認するか）も同時に確認される。
1.3.2 優先順位づけと変更管理
優先順位づけは、納期や予算などの制約の下で、どこから着手し何を後回しにするかを決めるために必要である。要求は単純な列挙ではなく、価値とコストのバランスを踏まえて整理され、影響の大きさが高いものから順に扱われる。加えて、変更管理は必須要素である。要求は運用や学習によって変化しうるため、変更の起点、承認者、影響範囲、更新手順をあらかじめ定めておくと、後から発生した変更が混乱や手戻りに直結しにくくなる。
2 要求事項の分類
2.1 機能要求
2.1.1 例示と記述の粒度
機能要求は、対象が提供すべき振る舞いを示す要求である。記述の粒度は、読者が設計判断を行える程度に具体化される一方、実装方法まで固定しない程度に留めるのが基本となる。粒度が粗いと評価が難しくなり、細かすぎると設計の自由度を過度に奪い、別の方式を採れなくなる。例示を用いる場合は、代表的な入力と出力、例外時の振る舞い、利用文脈をセットで示すことで、解釈のブレを減らせる。
2.1.1.1 ユーザー操作と入出力の対応
ユーザー操作と入出力の対応を明確にすることで、機能要求は検証しやすくなる。具体的には、操作（クリック、登録、検索条件の入力など）に対して、表示内容、保存結果、状態遷移、エラーメッセージなどの出力が対応づけられるよう記述する。さらに、操作が失敗した場合（入力の不備、権限不足、通信障害など）にどう振る舞うかも対象に含めると、実装後の品質差が生じにくい。ユーザー視点の「見える結果」と、システム側の「状態変化」を対応させる発想が有効である。
2.2 非機能要求
2.2.1 性能・品質・保守性
非機能要求は、機能そのもの以外の特性に関する条件であり、性能、品質、保守性などの範囲を含む。性能要素は数値で表しやすい一方、品質や保守性は定性的な側面が混ざりやすい。そこで、測定や評価に結びつく指標（ログ出力、復旧手順の整備、修正容易性を示す要素など）へと翻訳して記述することが重要になる。保守性の要求は、将来の変更が見込まれる領域で特に価値を持ち、運用負荷の見積りにも影響する。
2.2.1.1 応答時間、可用性、運用性
応答時間は、入力から結果提示までの遅延を定義し、許容範囲を設定することで示される。可用性は、稼働率や停止許容の考え方として整理され、例外的な停止やメンテナンスの扱いも含めて定義する。運用性は、監視、設定変更、障害時の切り分け、復旧手順の分かりやすさなど、日々の運用に関わる条件として現れる。これらは、実環境での測定可能性を意識し、どの地点・条件で計測するかを同時に決めると、後の評価が安定する。
2.2.2 セキュリティと信頼性
セキュリティと信頼性は、非機能要求の中でも特に重要度が高いことが多い。セキュリティでは、認証や権限制御、情報保護、監査ログなどの観点が要求に転換される。信頼性では、障害が起きた際の挙動、復旧の見込み、エラー耐性などが条件になる。いずれも、単に「安全であるべき」という抽象表現ではなく、具体的な管理策や評価方法へ落とし込み、運用上の検知と対応が成立する形に記述することで、実装後のギャップを抑えることができる。
2.3 制約条件
2.3.1 技術・法令・利用環境
制約条件は、選択肢を狭める前提や禁止事項として機能する。技術面では利用可能なプラットフォーム、対応できる通信方式、既存システムとの連携仕様などが該当する。法令・規約が関わる場合は、対象範囲を特定し、遵守のために必要な設計方針や記録の要否を整理する。利用環境では、端末性能、ネットワーク状況、利用者のスキル、運用体制などが制約として効く。制約は「守るべき壁」であると同時に、「守るために何を確認すべきか」を示す情報でもある。
2.3.2 リソースやスケジュールの制約
リソース制約は、要員数、開発期間、計算資源、テスト環境の有無などの形で現れる。スケジュール制約は、いつまでにどの範囲を完了させるかという時系列の条件である。これらは要求の達成計画に直接影響するため、要求文書に反映する際は、制約を前提として現実的な合否範囲を定めることが望ましい。制約が記述されない場合、実装の遅延や品質低下が後追いになりやすい。
3 要求事項の書き方
3.1 明確性と検証可能性
3.1.1 曖昧語の回避
要求は読み手の解釈を揃えることが目的であり、曖昧語は誤解の温床になる。例として、達成水準が数値化されない「十分」「適切」「可能な限り」などは、評価の基準が見えない。曖昧さを減らすには、定義語を置くか、測定や観察に結びつく指標に置き換える。また、複数の解釈が混ざる箇所は、対象範囲・条件・例外の順に分解して記述することで、判定の足場を作れる。
3.1.1.1 「できる」「適切」などの整理
「できる」は「任意の状況で達成されるのか」「代表ケースのみを想定するのか」「失敗時の扱いを含むのか」などが未確定になりやすい。そこで、条件と範囲を補って明示し、達成水準と評価方法が結びつく形に整理する。たとえば「適切」も、その判断に用いる基準（測定値、規格、ユーザー体験の閾値）を要求に組み込む必要がある。整理の際には、判断主体が誰か（利用者、運用担当、審査者）も特定すると、合否がぶれにくい。
3.1.2 合否基準（受け入れ条件）
合否基準は、要求が満たされたと判断するための条件である。典型的には、計測方法、評価期間、合格閾値、データの扱い、再現性の担保などが含まれる。受け入れ条件がない場合、テストは「それっぽい確認」に留まり、争点が残りやすい。逆に、基準が厳密すぎると現場の運用に不都合が出るため、現実の利用状況に即した範囲で定義することが求められる。
3.2 一貫性とトレーサビリティ
3.2.1 用語集と参照の統一
一貫性は、同じ概念を同じ言葉で扱うことで担保される。用語集を整備し、定義と参照の方針を定めることで、異なる部署や時期で書かれた文章の整合性が保たれる。さらに、関連文書への参照を明確にし、要求同士の依存関係を追えるようにすることで、誤った前提に基づく設計を防げる。用語の揺れは、後から仕様変更の原因にもなるため、早期に統一する価値が大きい。
3.2.2 変更履歴と影響範囲の追跡
変更履歴は、いつ、誰が、何を、なぜ変更したかを記録する仕組みである。要求が変わったときに、設計、テスト、運用手順、教育資料などのどこに影響が及ぶかを追跡できると、手戻りを抑えられる。影響範囲の追跡には、要求ごとのリンク関係や根拠（なぜ必要か）を残しておくことが重要である。結果として、変更の意思決定が説明可能になり、利害調整も進めやすくなる。
3.3 優先順位と要求の粒度
3.3.1 必須・推奨・任意
要求の優先度を必須・推奨・任意などに分類すると、計画や意思決定が容易になる。必須は、欠けると目的達成が難しい要素であり、合否に直結しやすい。推奨は、品質や利用価値を高めるが、状況に応じて後回しにできる場合がある。任意は、補助的で、コストに見合う場合に限って採用されることが多い。分類を行う際は、優先度の根拠（利用価値、リスク、法規対応など）も併記すると、将来の変更議論が安定する。
3.3.2 エピック／ユーザーストーリー等への分解
要求が大きい場合は、分解して扱いやすくする。エピックやユーザーストーリーは、その一例であり、価値の塊として整理して段階的に開発・検証するために使われる。分解の基準としては、ユーザーの目標、業務フローの切れ目、テスト可能な単位などが考えられる。分解後も、上位の意図が下位に引き継がれているか、トレーサビリティが保たれているかを確認することが重要である。粒度が適切であれば、計画の見積りと進捗管理が現実的になる。
4 要求事項の管理と運用
4.1 収集・合意形成
4.1.1 ステークホルダーの整理
ステークホルダー整理は、誰の視点が要求に反映されるべきかを明確にする作業である。利用者は日常的な困りごとや期待する体験を提示し、開発側は実現可能性や実装の見通しを説明する。運用側は、監視、障害対応、保守の観点から現実的な条件を提示する。加えて、意思決定者や監査担当のように、最終的な承認や遵守確認に関わる役割も洗い出すことで、合意のプロセスが円滑になる。
4.1.1.1 利用者、開発側、運用側の役割
利用者は、利用シーンでの目的と期待される結果を中心に語ることが多い。開発側は、その期待を実装・検証可能な要素へ翻訳し、設計選択に関わる制約を提示する。運用側は、日々の管理作業、監視指標、障害時の切り分け手順、復旧に要する時間など、運用で成立する条件を示す。この役割分担が明確だと、要求の抜け漏れが減り、文章の責任所在がはっきりする。
4.1.2 ヒアリングと文書化
ヒアリングでは、単に要望を聞くのではなく、背景にある目的、現在の課題、代替案の有無、成功条件の感覚を掘り下げる。聞き取った情報は、そのまま並べるのではなく、要求として評価可能な形へ整える。文書化では、読みやすさと追跡性を重視し、要求番号や属性（優先度、対象範囲、関連根拠）を付与する。さらに、根拠情報や前提条件を併記しておくと、後日の変更時に判断が速くなる。
4.2 変更管理
4.2.1 要求変更の起点と承認
要求変更の起点は、運用での新たな気づき、技術調査の結果、計画の更新、利用者の反応など複数ありうる。起点を早い段階で記録し、どの要求に対する変更かを明確にする。承認プロセスは、変更の影響が多面的であることを踏まえ、適切な権限を持つ関係者が判断するよう設計する。承認がないまま反映が進むと、検証計画やスケジュールが崩れやすいため、手続きの一貫性が重要である。
4.2.2 優先順位の再評価
変更が入ると、元の優先度の前提が揺らぐことがある。価値の高い領域が別の方向に移ったり、制約が変化してコストが増減したりするため、優先順位は固定ではなく見直しの対象になる。再評価では、変更点の価値、リスク低減効果、影響範囲（設計・テスト・運用）を整理し、必須と推奨の線引きを再確認する。こうした再評価により、チームの焦点がぶれにくくなる。
4.3 検証・妥当性確認
4.3.1 レビューとテストの計画
検証の計画では、要求ごとに確認手段を結びつける。レビューは、記述の妥当性（曖昧さ、矛盾、前提の欠落）を早期に検出するために用いられる。テスト計画は、合否基準に対応するケース設計と、実施環境・データ準備の見通しを含む。計画段階で、どの指標をもって成功とするかを確定させると、実施後の評価が対立しにくい。加えて、負荷試験や例外系の確認など、非機能領域の検証を体系化することが望ましい。
4.3.2 運用後の改善ループ
運用後の実績は、要求の妥当性を再点検する材料になる。ユーザーの行動ログ、問い合わせ内容、障害の傾向、性能指標などのデータを用いて、要求が実際の目的に結びついていたかを評価する。ギャップが見つかった場合は、要求の解釈見直しに留めるか、文言や閾値そのものを修正するかを判断する。改善ループが回ると、要求が単発の文書で終わらず、学習に基づいて精度が上がる。