要件の定義

要点と定義

要件定義は、業務で実現したいことを整理し、システムに必要な機能や性能、利用方法などを明確にする工程です。利用者や業務の関係者のニーズを聞き取り、内容を整理したうえで、関係者が合意できる形にします。ここで業務上の必要事項を正しく捉えられないと、業務ルールを誤ってシステムに反映するおそれがあります。

要件は、業務要件とシステム要件に分けて考えられます。業務要件は、業務上の目的や必要な業務のあり方を表します。たとえば、物流コストを下げるため出庫作業の自動化率を高めることは、業務上の目標です。

システム要件は、その業務を実現するシステムに求める内容です。システム要件には、業務を実現する機能要件と、品質や運用などに関する非機能要件があります。入出力データの種類や業務機能間のデータの流れは、システムが何を扱い、どう処理するかを表す機能要件です。

非機能要件は、性能、可用性、セキュリティ、運用などの条件です。バッチ処理の所要時間、年間停止時間の上限、障害時の許容復旧時間、システム監視の周期、データの暗号化などが例です。

要件定義では、必要な機能や性能だけでなく、利用者の具体的な使い方も分析します。例として、必要な帳票の種類や、データ確定から出力までの処理時間目標を利用者と明確にする作業が挙げられます。

IPAシラバス ver.6.5 では「要件の定義」はシステム企画の項目23（PDF p.29、印刷 p.25）に位置付けられています。

適用条件と例

要件を分類するときは、まず「業務で何を達成したいのか」と「システムに何をさせるのか」を分けます。たとえば、問い合わせ対応時間を短縮するのは業務上の目標です。そのために顧客情報を検索する機能を用意するなら、それは機能要件です。検索結果を一定時間内に表示する条件は、性能に関する非機能要件になります。目標をシステムの具体的な機能や品質条件に落とし込む関係です。

分類に迷ったら、要件が「処理・データ・操作」を具体的に定めているかを確認します。そうであれば機能要件である可能性が高く、「どの程度速いか」「どれだけ止まらないか」「どう監視するか」などの品質・運用条件なら非機能要件です。たとえば、入力された注文を出荷予定に登録する処理は機能要件、障害後に許容される復旧時間は非機能要件です。

要件の決定には、利用部門の参加が欠かせません。業務担当者からニーズを聞き取り、プロジェクト側で整理・要約した内容を業務責任者と確認して合意します。開発チームだけであるべき姿を決めたり、現状を報告したりするだけでは、必要な業務要件を確認したことにはなりません。

ライフサイクルの工程を見分けるときは、作業の目的を手掛かりにします。何を作るか、必要な機能・性能・利用方法を明確にするのが要件定義です。合意済みの要件を構造や方式に落とすのが設計、実装後に要件への適合を確かめるのがテスト、稼働後の変更や維持を扱うのが運用・保守です。

誤りやすい点

機能要件と非機能要件は、項目の言葉だけでなく、システムに何を求めているかで分類します。たとえば「自動化」は機能の内容ですが、「自動化で物流コストを削減する」は業務上の目標です。