要件定義とは？
- 要件＝注文。作って欲しい人が、作る人に出す依頼事項である。
- 発注側と受注側の間で合意した納品検収条件。
- 「何がどうなれば良いのか」を明確に定めたもの。
- 納品時にNGをくらって「それ先にちゃんと言っておいてよ」とならないために必要である。
要件定義の概要
- （発注者の）願望・困っていること…「こんなのが欲しい」「こんなことができればいいな」「こんな風になりたいな」
- （発注者の）要望…≠願望。願望を検討した結果定まったもの。
- （発注者の）要求…要望を言語化し、ドキュメントに起こして受注者に伝えられるようになった状態。
- （受注者の）提案…要求に対して専門家として検討した結果を伝えること。「できる／できない」「こうした方がいい」という専門家の知見から述べる。
- 再要求〜再提案の繰り返し…合意形成を図っていく
- （受注者の）要件…合意結果をドキュメント化したもの。
定義すべき要件の内訳
定義すべき要件を一言で表すと次の通り。
プログラマがソフトウェアを完成させるために必要な情報
P18
具体的には3点をこの順にドキュメントに起こしていく。
- UI…画面、帳票（UIが最も重要）
- 機能…ソフトウェアができること
- データ…ソフトウェアが保持すべきデータ
UIについて定義すべきこと
- データ項目…画面（や帳票）が何を表示するか
- 操作項目…どんな操作ができるか
- レイアウト…手書きで良い
各画面について上記を洗い出す。
画面ごとに操作項目に対するイベントを書き出し、画面間を矢印で繋ぎ、画面遷移図として仕立てる。
各画面のモックアップ（ラフイメージ）、画面遷移図、各画面の項目一覧が出来上がる。
機能について定義すべきこと
機能は主に、画面の操作に対して1つの機能として洗い出していく。
機能ごとの、入出力–処理の定義を書き出す。
各機能の入出力と処理が定義されたドキュメント（機能処理定義書）が出来上がる。
データについて定義すべきこと
画面ごとに必要な項目をER図に書き出していく。
観点としては、イベント系（注文、予約など）とリソース系（商品、在庫、会員、扱うものなど）の両方から見ていくと良い。
画面ごとに洗い出し・正規化しながら、必要に応じてテーブルを統合していく。
ER図が出来上がる。
要件定義の最初に準備すること
- 企画書
- 企画名
- なぜ（目的）
- 何を（目的達成のために作るものは？、利用する人、利用する人が得られる便益）
- どのように（体制、納期）
- ユースケース図（利用者と利用者が行うことがわかるもの）
- サブブロック図（システム構成図、サブシステムがわかるもの）
- 実装技術一覧（アーキテクチャ図）
- やりたいことの一覧
- 業務フロー図
- 概念データモデル図（ER図。エンティティだけ凡そ記載されているもの）
はじめよう！要件定義 ビギナーからベテランまでの感想
著者の羽生生章洋さんの経験に基づいた要件定義である。一般的な要件定義を体系的に学ぶ目的や実際の大規模案件での要件定義を学ぶ目的の場合は、本書だけでは不足感を得るであろう。
ただし、経験に基づいているため、本書の内容でも要件定義として成立するため、一読の価値はあり。個人開発〜小規模案件であれば十分な内容である。
極めて平易な文章であるため、要件定義をさらっと押さえておきたいという場合は数時間で読了できるため、有用と思う。
Amazonのレビューでも記載されているように、UIを要件定義に含むかという議論が起こるのも読めば納得できた。
本書が有用なのは、羽生さんの実際の開発に基づいているからであり、本書で説明されている要件定義の3点セット（UI、機能、データ）があれば、後工程を進められるからである。
開発者（プログラマー）が仕事を進めるために必要なものを要件定義で作成するという観点が入ってるように感じたため、個人〜中規模くらいなら、本書で十分であると感じた。
ただし、ここまでやったら基本設計でやることないんじゃない？と感じたため、案件によってどこまでやるかは応相談になるだろう。