はじめに
この記事は要件定義の流れや成果物、要件定義の工程で重要なことなどをまとめたものです。
対象読者
- 初めて要件定義に関わるエンジニア
要件定義とは
要件定義とはシステム開発やプロジェクトの一番最初の工程で「何をつくるのか」を明確に定義すること。
顧客（ユーザー）がシステムを使って何をしたいのか（目的）、なぜそれが必要なのか（背景）をヒアリングし、それを実現するために必要な機能（例：ログイン機能、検索機能）や、性能・品質（例：処理速度、セキュリティ、使いやすさ）などを具体的に洗い出して文書化する。
この成果物は「要件定義書」と呼ばれ、開発プロジェクトを進める上での「設計書の元」になる。
要件定義の流れ
1. 要望のヒアリング
顧客（ユーザー）がシステムを使って何をしたいのか（目的）、なぜそれが必要なのか（背景）をヒアリングする。
主な成果物
- 業務フロー図（As-is）
- 課題管理表、QA 表
2. 要望の整理
顧客からヒアリングした情報をもとにシステムで実現したいことを整理し、優先順位付けをする。
主な成果物
- 要望一覧
3. 要件の定義
顧客の要望をもとにシステムで「実現すべき仕様」に変換をする。
主な成果物
- 機能要件一覧（ログイン機能、検索機能、登録機能）
- 非機能要件一覧（性能、セキュリティ、運用）
- 業務フロー図（To-be）
- 画面イメージ、画面遷移図
- データモデル（ER 図）
- 外部 IF 仕様書
4. 要件の合意
作成した要件定義書を一つのドキュメントにし、関係者全員で読み合わせて合意形成を行う。
主な成果物
- 要件定義書
要件定義で重要なこと
1. 要件定義の段階で出来るだけ全ての要件を洗い出す
「要件定義 -> 基本設計 -> 詳細設計 -> 実装 -> テスト -> リリース」の順番に後の工程になるほど、要件の抜け漏れによる手戻りが大きくなったり、調整が困難になる。
また、開発期間が長い案件や、多くの関係者が絡む案件ほど、後工程で要件の抜け漏れが発生した場合の影響が大きいため、要件定義の段階でなるべく詳細なイメージを用いて要件の抜け漏れや認識のズレがないように注意をすることが重要。
2. 外部システムとの連携を行う場合は明確な IF の取り決めを行う
外部システムとの連携や接続時の認識の齟齬や不具合については、連携テストの段階まで発覚しにくく、不具合時の影響が大きくなる。
外部システムとの連携や接続を伴う場合は、外部 IF の各項目や接続方法、認証、エラーコード等、認識の齟齬がないように全て文章化し、必ず社外を含めた合意形成を行う。
3. 後工程に大きな影響を与える要素については詳細に検討する
要件の難易度によって、データ構造やインフラ構成などに大きな影響を与えうるものに関しては、要件定義の段階で簡単な ER 図や、インフラ構成図などを作成し、納期や予算内で実現が可能か見積を行う。
要件によって実現が難しい場合は、要件の見直しや簡素化を提案する。
おわりに
この記事では要件定義について簡単におさらいしました。
5 分で完全に理解することはできませんが、今回紹介した流れや重要なポイントを意識することで、より良い要件定義を目指していきましょう。
株式会社Inner Resource のエンジニアブログです。 忙しい研究者・研究施設の業務効率化のためのクラウド購買管理ソフト「リプルア」を開発しています。
Discussion