1 機能要求の基本
1.1 機能要求の定義と目的
機能要求とは、システムやサービスが実現すべき振る舞いを、具体的な観点から記述した要求事項である。入力に対してどのような処理を行い、どのような出力や状態変化を返すかを示すことで、開発者が実装方針を組み立てやすくなり、調達側も比較・評価の材料を得やすくなる。さらに、検証や受入試験に必要な観点が定まり、合否判定の曖昧さを減らすことが目的となる。
1.2 機能要求と非機能要求の違い
1.2.1 機能（やること）と品質（良さ）の整理
機能要求は「何をするか」、非機能要求は「どれほど良く行うか」に相当することが多い。前者は帳票を作成する、申請を承認する、検索条件に合致する結果を返すといった振る舞いに焦点が置かれる。後者は性能、可用性、保守性、安全性などの品質特性に関する目標を扱うため、両者は別の軸で整理されるのが一般的である。
1.2.2 要件文書での役割分担
要件文書では、機能要求を中心に「ユーザの目的を達成するための作業」と「システム内部の振る舞い」を記す。非機能要求はそれを支える制約条件や到達水準として位置付く。結果として、設計では機能の実現方法を検討しつつ、非機能の制約を満たす設計へ落とし込む流れが作りやすくなる。
1.3 機能要求の特徴（明確性・検証可能性）
機能要求が有用であるためには、解釈の幅が小さく、検証可能であることが重要となる。明確性とは、誰が読んでも同じ前提で理解できる状態を指す。検証可能性とは、テストやレビューにより「満たした／満たさない」を判断できる形に整っていることを意味する。曖昧な表現を避け、判断基準や例外条件を含めることで、後工程の手戻りを抑制できる。
2 体系化と表現方法
2.1 要求の粒度
2.1.1 レベル設計（概要・詳細・入出力）
要求は粒度を揃えることで管理しやすくなる。概要レベルでは、主要な目的や大まかな流れを示し、詳細レベルでは処理手順や条件を掘り下げる。さらに、入出力を明確に定義すると、境界が理解されやすくなる。たとえば「入力として何を受け取り、出力として何を返すか」「中間状態として何が変化するか」を書き分けることで、実装や連携の設計が進む。
2.1.1.1 ユーザーストーリーと機能仕様の対応
ユーザーストーリーは、利用者の意図に基づく短い記述として扱われることが多い。一方で機能仕様は、実装と検証に必要な粒度へ展開した詳細記述である。実務では、ストーリーを要求の起点として整理し、受入条件や振る舞いを抽出して機能仕様へマッピングする。これにより、利用者の価値と実装上の具体がつながる。
2.2 典型的な記述形式
2.2.1 入力・処理・出力（I/O）での記述
I/O形式は、入力、処理、出力の順に振る舞いを構造化する方法である。入力として必要な項目、処理で適用される規則や内部手順、出力として返す情報や表示内容、さらにエラー時の振る舞いを含めやすい。特に外部連携やAPI設計では、I/Oの定義が後工程の実装整合に直結する。
2.2.2 ユースケース記述（事前条件・事後条件）
ユースケースでは、特定の目的を達成する一連の行動を記述し、事前条件と事後条件で成立条件を明確化する。事前条件は開始時点で必要な状態（入力の妥当性、利用者の権限など）を示し、事後条件は完了時に期待される状態（データ更新、通知送信、画面遷移など）を定義する。これにより、正規経路だけでなく逸脱時の扱いも設計しやすくなる。
2.2.3 ルール・制約の明文化
機能の振る舞いは、一般手順だけでなくルールや制約で支えられる。たとえば「入力値の範囲」「禁止事項」「重複時の扱い」「整合性を保つための条件」などを文章で明記する。ルールが曖昧だと実装者の判断に依存しやすいため、例や前提を併記して解釈のばらつきを抑えることが望ましい。
2.3 曖昧さの排除
2.3.1 用語集と定義の統一
曖昧さは、用語の解釈差から生じることが多い。用語集を用意し、主要概念（例：承認、取消、未処理、期限超過、同一人物の判定基準など）を定義しておくと、文書全体の整合が取れる。定義は可能な限り測定可能な条件や具体例を伴う形で記載する。
2.3.2 判断基準の明確化（例外条件・境界値）
判断基準は「何が起きたら成功とみなすか」を定める要素である。正規ケースだけでなく例外条件も含め、境界値（上限・下限、閾値、時刻や数量の境界など）を明確にすることで、テスト設計が容易になる。加えて、エラー時のメッセージ体系やログ記録の有無なども、判定に関わるなら要求に含める。
3 要求の作成プロセス
3.1 利害関係者の把握
3.1.1 利用者（現場）と運用者（保守）の観点
利用者は日々の業務目的に基づいて要望を持ち、運用者は継続稼働や保守の容易さに関心を持つ。機能要求を作る際は、両者の視点を同時に取り込むことが重要である。たとえば画面操作の負荷や、問い合わせ対応に必要な情報、障害時の切り分けに役立つログなどは、機能要件に反映されやすい。
3.1.2 業務部門・開発部門・調達部門の連携
業務部門は業務上の価値や手順を説明し、開発部門は実装の現実性を評価し、調達部門は見積・仕様化・評価の観点で整理を行う。連携が欠けると、価値は高いが作れない、あるいは作れるが検証できないといった不整合が起こりやすい。要求作成では、レビューの場や成果物の粒度基準をあらかじめ決め、役割ごとの判断を揃える。
3.2 現状分析と課題抽出
現状を把握せずに新しい機能を要求すると、既存の業務摩擦を見落とす危険がある。業務フロー、データの流れ、運用体制、既存システムの制約を整理し、どこで時間がかかるのか、品質問題がどこで発生するのかを特定する。課題は原因と結び付けて言語化し、その解決に必要な機能要求へと導く。
3.3 要求の導出と優先度付け
3.3.1 価値とコストの観点での優先度
優先度は、価値の大きさと実現に要するコストのバランスで決まることが多い。価値はユーザの効果だけでなく、リスク低減や業務効率化、法令対応のような間接的要素も含みうる。コストには開発だけでなく、運用や教育、移行の負担も含めて見積もることで、実行可能な計画になりやすい。
3.4 要求の合意と変更管理
3.4.1 要求変更の影響評価
要求は作成中に変化しうるため、変更を受けたときの影響範囲を評価する必要がある。影響は機能の追加や削除だけでなく、画面、データモデル、外部インタフェース、テスト範囲、教育資料、運用手順まで及ぶ。変更管理では、依存関係を確認し、優先度やスケジュールへの波及を数値または理由で説明できる形にする。
3.4.2 承認フローと履歴管理
承認フローは、誰が最終判断を行うかを明示する仕組みである。履歴管理は、変更前後の差分、根拠、決定者、適用時期を追跡できるようにする。これらは後日の説明責任や監査対応にも関わるため、要求文書とともに管理対象を定めることが望ましい。
4 検証と運用への接続
4.1 受入基準（アクセプタンス）との整合
受入基準は、機能要求が達成されたと判断するための条件である。要求文書の記述と受入基準が一致していない場合、実装は完了しても受入で不成立となる可能性が高い。したがって、受入基準は要求の本文に紐づく形で作成し、測定方法や判定手順を明確化することが重要である。
4.2 テスト可能な要求への落とし込み
4.2.1 テストケース設計の考え方
テスト可能性を高めるには、要求を観点と条件に分解する。正常系、異常系、境界値、回帰観点を設け、入力条件と期待される出力を対にして考える。さらに、状態遷移が関わる機能では、前提状態からどのように遷移し、最終状態がどうなるべきかをテストシナリオとして整理する。要求段階でこの分解ができているほど、設計・実装後のテスト工数は抑えられる。
4.3 トレーサビリティ（追跡可能性）
トレーサビリティとは、要求が設計、実装、検証、そして運用結果へと追跡できる状態を指す。具体的には、機能要求ごとに対応する設計要素、テストケース、受入結果、欠陥の扱いを紐づける。これにより、変更が入ったときにどこを見直すべきかを迅速に判断でき、品質管理を体系的に行える。
4.4 導入後の見直し
4.4.1 現場フィードバックの反映手順
導入後は、実利用に基づく評価が可能になる。現場からの報告を収集し、要求に対する達成状況、運用負荷、改善余地を整理する。反映にあたっては、変更要否の判断基準を設け、必要なら要求更新、テスト再実施、運用手順の改訂へとつなげる。学習を次の案件へ活かすことで、要件定義の精度が段階的に向上する。