だまし絵を描かないための 要件定義のセオリー
[購入動機]
転職後、ユーザSEとして、業務要件定義を行う事となったため、下記の点について整理したく、購入しました。
・業務要件定義の進め方
・要件定義工程で必要とされる成果物
また、次工程以降、前工程への手戻りを極力抑えられるよう、要件定義工程で必要な検討事項を、体系的に漏れなく整理する必要があると考えています。
[要約]
要件定義とは、システムで実現すべき制約を明確にし、「要件」として確定すること。
具体的には、①ToBeモデルを作成し、②Asisを分析して、制約を加味して、③新ToBeモデルを作成すること。
要件定義の目的は、以下の２点。
・構築すべき仕様（データ、プロセス、機能）を明確にする。
・要件を設計へ移行可能な状態にする。
要件定義を開始する前に実施しておくこと。
１．システム化企画/業務分析
①目的、対象、効果の明確化
②ToBeモデルの作成
・プロセスの概要フロー、概念データモデルの作成
③現状分析
(1)非機能要件
(2)データ構造
(3)コード体系
(4)業務フロー
２．要求の明確化
①各要求の一覧化
②要求のブレークダウン
ビジネス要求→業務要求→システム要求
③要求の精査
※技術的困難、コスト、納期の制約により実現が難しい要求を洗い出す
④ToBeモデルのブラッシュアップ
要件定義にて実施すること。
①要求範囲の明確化
・各要求をシステム要件へと整理。
※新ToBeモデル（プロセスモデル、データモデル、機能、UI）を想定できる要件
②システム全体図の作成
・外部連携の明確化
③業務フローの作成
・トップダウンアプローチにて骨組みを明確化し、ボトムアップアプローチで肉付けする
④業務プロセス要件の明確化
・各業務プロセスの5W2Hをを定義する。
※ここでいう業務プロセスは、最下層の業務フローを構成する要素（1つのアイコン）
⑤UI機能要件の明確化
・業務プロセス定義の5W2Hを実現するための機能を明確にする。
また、UIは、業務プロセス定義を支援する機能を成立させるために存在する。
・UIにて、データ操作（CRUD)を明確にする。
※バッチは例外として、業務プロセスとして定義されているか確認する。
・ユーザシナリオをユースケースの記述形式で書く。
⑥データの明確化
・概念データモデルから論理データモデルを作成。
※概念データモデル…ER図
論理データモデル…ER図の各エンティティの属性を明確にし、正規化する。
※属性は主要なものだけでもOK
⑦CRUDマトリクスの作成
・エンティティのライフサイクルを確認する。
・プロセス・機能に関して、データ操作漏れが内科確認する。
⑧非機能要件の定義
・操作性、信頼性、性能、保守の容易性、セキュリティ要件、移行要件、運用要件の定義。
※非機能要件は、業務プロセスからも洗い出す。
⑨システムインフラアーキテクチャの定義
・システム形態（Web、クラサバ、スマホアプリ…）の定義
・サーバの設置場所（オンプレ、クラウド（Iaas, Paas, SaaSなど）…）の定義
・分散方針の定義
・移行要件、運用要件の定義
⑩アプリケーションアーキテクチャの定義
・標準化（画面UI, 画面遷移、業務フロー表記、業務プロセス5W2H、データモデル表記、PG言語、通信プロトコル、排他制御、ログ）の定義
※業務プロセスは、ビジネスの動的側面で、データモデルはビジネスの静的側面。
要件定義にて定義した内容の妥当性確認および合意形成
(1)妥当性確認
・要求から要件として整理された各要件の妥当性確認
・システム要件に基づき、機能/非機能要件が適切に定義されているか。
・機能/非機能要件を満たすアーキテクチャとなっているか。
・業務要件を満たすToBe業務フロー及びプロセス定義（プロセスモデル）となっているか。
(2)合意形成
・要件化されなかった先送り事項となった要求の明確化および、ビジネス要件、業務要件への影響の把握。
・ビジネス要件→経営層、ビジネス責任者。業務要件→ビジネス責任者、担当者。システム要件→担当者。への合意形成。
[気づき]
本書では、エンターブライズ、コンシューマ向けの2タイプの形態に対して、また、新規、カスタマイズの側面から、要件定義の進め方および必要となる成果物について述べられたいた。
前半は、要件定義とは何であるか、なぜ必要なのか、どのように進めればいいのかといったことについて、概念的な内容で著者の考えが述べられており、しっかり読み込まないと、理解が難しいと感じたが、じっくり読むことで、頭の中を整理することができた。中盤あたりから、業務定義で具体的に何をするかが述べられており、具体的な進め方および成果物をイメージすることができ、前半で述べられていた筆者の考えを、より深く、理解することができた。
私はこれまで、エンタープライズ領域において、既存の業務フローが存在するなかで、一部の業務を見直す、あるいは追加するといった要件定義しか経験したことがなかった。そのため、要件定義では、業務フロー、要件一覧、非機能要件一覧を作成すればOKという認識でいました。
しかし、本書を読んだことで、超上流工程から始まり、要件定義工程にて必要となる考え方を理解し、整理することができた。
特に、これまでUI工程にて定義すれば良いと考えていたデータモデルの設計についても、安定的なビジネスに必要不可欠な要素で、ここを早期に定義することで、後々の手戻りも抑えることができる理解できた。さらに、苦手であった、非機能要件についても、業務プロセスモデルから洗い出すことができるということや、業務プロセスを5W2Hで整理することで、業務プロセスを実現可能かという観点で機能を洗い出せ、また、機能を成立させるUIを整理することができると知ることができた。
[今後]
現在取り組んでいる、モバイルアプリ開発案件において、以下のことを実施する。
・プロセス定義（各プロセスの5W2Hの明確化）
・論理データモデルの作成
・CRUD図の作成（データライフサイクルを意識）
・非機能要件の定義（業務プロセスからの洗い出し）
・インフラ、アプリケーションアーキテクチャの定義
（
