シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義
- システム要件定義の成果物〜設計へのインプットを作成する
- 要件定義とソフトウェアアーキテクチャ設計
- 要件定義とクラス設計
- 要件定義とデータベース設計
- 要件定義と画面設計
- 要件定義とAPI設計
- 要件定義とバッチ処理設計
- 要件とは何か
- 非機能要件とは何か
- 要件定義を学ぶ人におすすめの書籍まとめ
- 移行要件とは何か
- 要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】（本記事）
TRACERYプロダクトマネージャーの haru です。
要件定義を成功させるためには、プロセス全体を見渡して理解することが重要です。
どのような情報を集め、どのような成果物を用意すべきかを明確にすることで、作業の抜け漏れを防ぎつつ、要件定義を入出力の観点で一貫して管理できます。
これにより、進捗や成果を数値や成果物で客観的に確認でき、関係者間の認識を揃えながらプロセス全体を確実にコントロールできるようになります。
本記事では、「要件定義とはそもそも何か」シリーズで解説してきた内容を整理し直し、要件定義プロセスの流れと成果物の位置づけを体系的に紹介します。
- 要件定義の流れ、全体像
- 要望から要件へ。事業・業務・システムで全体像を整理する
- 業務フロー図の作成〜ユースケース抽出
- ユースケースをロバストネス図で詳細化し、開発品目一覧作成、非機能要件の抽出
- 概念モデル、システム構成図の作成
- まとめ
要件定義の流れ、全体像
下図に、本連載で説明してきた要件定義の流れを示します。
本連載では、説明をわかりやすくするために、既存システムがすでに稼働しており、その機能追加や改修を行う場合を対象としています。
なお、本連載では扱いませんでしたが、システムを新規に構築する場合には、ステークホルダーや業務構成を一覧化し、外部システムを含めた全体像を明確に整理することから始めるとよいでしょう。
以降で、本連載で紹介した要件定義の流れを順に説明します。
要望から要件へ。事業・業務・システムで全体像を整理する
システム開発では、まずステークホルダーから要望をヒアリングします。
得られた内容は整理・統合し、要求として構造化します。
この際、事業・業務・システムの3階層でツリー状に整理すると、抜け漏れが少なく全体像を把握しやすくなります。
ここまでの流れを「企画プロセス」と呼びます。企画プロセスでは、関係者の要望を集め、開発の出発点となる要求を整理することが目的です。
次に、この要求をインプットとして進める「要件定義プロセス」では、構造化された要求に優先順位を付け、実現可能かどうかを検討したうえで、開発対象として合意したものを要件とします。
詳しくは、以下の記事をご参照ください。
業務フロー図の作成〜ユースケース抽出
要件定義のゴールは、「設計プロセスを円滑に進めるための明確で具体的なインプットを提供すること」です。*1
そのために最低限作成すべき要件定義の成果物は、次の3つです。
- 開発品目（画面、API、バッチ処理など）の一覧
- 各開発品目に対応するシステムの機能要件
- セキュリティ、性能、信頼性、可用性などの非機能要件の定義
これらを導き出す最初のステップが、業務プロセスを構想し、可視化する業務フロー図の作成です。
事業要件と業務要件を基に、業務フロー図を作成します。
業務フロー図を描くことで、事業要件や業務要件を満たすための、利用者の行動やシステム利用の流れが明確になり、そこからシステムのユースケースを抽出できます（下図）。
抽出されたユースケースは、三層構造におけるシステム要件に対応します。
詳しくは、以下の記事をご参照ください。
ユースケースをロバストネス図で詳細化し、開発品目一覧作成、非機能要件の抽出
ユースケースを起点に、ロバストネス図を用いてシステムを構成する要素（UI、機能、データなど）を抽出します。
この要素分解を進める過程では、処理性能や運用条件などの実現性も検討され、その結果として非機能要件が明確になります。
これらも併せて整理・リスト化します。
詳しくは、以下の記事をご参照ください。
概念モデル、システム構成図の作成
前節までに、要件定義で最低限作成すべき成果物が明示されています。
- 開発品目（画面、API、バッチ処理など）の一覧
- 各開発品目に対応するシステムの機能要件
- セキュリティ、性能、信頼性、可用性などの非機能要件の定義
これらが揃えば設計は始められますが、必要最低限の情報にすぎません。
設計をよりスムーズかつ精度高く進めるには、概念モデルやシステム構成図を準備することが効果的です。
これらを整備することで、システムの構造や関係性が具体的に可視化され、関係者が同じ理解を持てるようになります。
その結果、要件の解釈違いや設計段階での手戻りを大幅に減らし、開発全体を効率的に進められます。
詳しくは、以下の記事をご参照ください。
まとめ
本記事では、要件定義の全体像を整理しました。
要件定義の最低限の成果物は、開発品目一覧、機能要件、非機能要件の3点です。
これらを導き出すための出発点は、事業要件・業務要件を満たす業務プロセスを構想し、業務フロー図を作成することにあります。
業務フロー図に示されたアクションからユースケースを抽出し、さらにロバストネス図で詳細化することで、開発品目をリストアップできます。
加えて、設計や見積りの精度を高めるには、概念モデルやシステム構成図の整備が有効です。
これによりシステム像が明確になり、開発全体の効率性と信頼性が大きく向上します。
次回の記事では、要件定義プロセスと設計プロセスのつながりを整理し、両者の関係性を全体像として解説します。
*1:連載の過去記事：要件定義の目的とゴールとは - TRACERY Lab.（トレラボ）を参照のこと。
