「要件定義ヒアリング成功の鍵はできあがりイメージを合意すること」では、定義すべき要件にもいろいろあると書きました。

本記事では、要件定義にまつわる言葉をかんたんに整理します。

ポイントは要求から具体的な要件へ、さらに詳細な仕様へと段階的に詳細化される流れです。

段階的に詳細化される要求、要件、仕様

「要件定義を担当しているけどお客さんが要件決めてくれない（コンサルタント）」

「要件決めようにも業務部門の要求が定まってない（ユーザ企業IT部門担当者）」

「仕様固めてもらわないと設計が進められない（ITベンダー）」

こういった声を聞くことはありませんか？

ひとくくりに「要件が決められない」といっても少しずつ違いがあります。会社間やプロジェクト内で認識違いを生まないためにも言葉の定義を合わせておきたいです。

それぞれの定義は以下の通りです。

要求、要件、仕様の違い（要求＋合意＝要件、要件＋設計観点＝仕様）

• 要求：顧客が作ってほしいものの条件
• 要件：顧客が作ってほしいものが満たすべき条件
• 仕様：要件を実現手段と紐づけた詳細な条件

要求をもとにユーザとベンダで要件定義を行い、最終的にベンダにて仕様に落とし込み、ユーザレビューを経て合意する、という流れになります。

なので本記事では、先の定義をもとに

• 合意された「要求」　＝　「要件」　→　要件定義フェーズで定義
• 「仕様」＝　「要件」を満たすシステム機能、性能　→設計フェーズで定義

と位置づけます。

業務の目線に立つ業務要件とシステム機能の目線に立つシステム要件

要件にも2種類あります。業務要件とシステム要件です。

• 業務要件：　　　対象業務のフロー、業務定義、入出力情報
• システム要件：　業務要件を満たす機能要件、非機能要件

業務フローとは、定義対象の業務の流れに沿って記述した図です。

顧客から受注し、出荷し、請求を行う業務を例にするとそれぞれの業務を箱で記述し、矢印でつないで前提後続関係を明らかにします。受注がない中での出荷が発生しえないように前提事項を明確にしていきます。

業務フローの表現手法はいろいろありますが、スイムレーンと呼ばれる書式は、業務の担当者（部門）で行を分けて表現します。営業部門、物流部門、経理部門といったように行を分け、担当する業務をその行に配置します。

関連記事：業務プロセスは目的に応じた粒度で書く

それぞれの業務の箱は、必要に応じて詳細化します。さらに詳細な業務フローで表現することもあれば、業務定義書として言葉で記載する業務もあります。これとセットで、各業務における入力情報と出力情報を記載しておきます。

現行システムの項目全てを漏らさず書くことは主目的ではありません。該当する業務を行うのに必要な業務情報としての項目などは補足情報として記載しておきます。

終わりに

要件定義の進め方のコツは、段階的な詳細化とトレーサビリティ（追跡可能性）にあります。要求が要件に、要件が仕様に詳細化されていく過程で情報が途絶えないよう成果物フォーマットやプロセス、それから個々人の意識で整合性を保っていくことが重要です。

次記事「システム要件定義を効果的に進めるためのチェックリスト」では、システム要件定義について解説します。