顧客の要求を確実に仕様にできる要件定義マニュアル

著者：神崎善司
発売元：秀和システム

Chapter 01 要件定義の悩みとその解決に向けて理論編
1-1 要件定義の位置づけ
1-2 要件定義行程で何が起こっているのか
1-3 要件定義の混乱に対処するには
1-4 リレーション駆動要件分析の効果
1-5 リレーション駆動要件分析の構成要素
1-6 まとめ
Chapter 02 要件分析フレームワーク理論編
2-1 要件定義の構造
2-2 要件を捉える4つのステップ
2-3 モデルで要件を定義する
2-4 各ダイアグラムは関係を持つ
2-5 システムの目的・役割がシステムに方向性を与える
2-6 システム化範囲をどう決めるか
2-7 整合性のある要件を定義する
2-8 まとめ
Chapter 03 要件分析プロセス理論編
3-1 要件定義の基本的な進め方
3-2 要件をシステマティックに定義するには
3-3 要件定義行程をスムーズに進める管理方法とは
3-4 要件定義の精度を向上させるには
3-5 まとめ
Chapter 04 商品販売サイトの要件定義モデリング編
4-1 このケースの特徴
4-2 システム価値の把握
4-3 システム化の背景
4-4 システムの関係者を明らかにする
4-5 要求を整理する
4-6 システムの外部環境の把握
4-7 業務を明らかにする
4-8 概念を整理する
4-9 システム境界の把握
4-10 ユーザーとシステムの接点をユースケースを使って明らかにする
4-11 入出力情報を明らかにする
4-12 外部システムとのインターフェースを明らかにする
4-13 システム間の規約を明らかにする
4-14 システムの把握
4-15 システムで扱うデータを明らかにする
4-16 システムに必要な機能を明らかにする
4-17 ビジネスルールの作成
4-18 まとめ
Chapter 05 要件モデルチェックシステムの要件定義モデリング編
5-1 このケースの特徴
5-2 背景
5-3 システム価値を把握する
5-4 システムの利用者を想定する
5-5 要求を明らかにする
5-6 システム外部環境を把握する
5-7 システムの利用シーンを明らかにする
5-8 ビジネスルールを明らかにする
5-9 システム境界を把握する
5-10 システムとの接点をユースケースモデルを使って明らかにする
5-11 ユーザーインターフェースを把握する
5-12 システムの機能とデータを把握する
5-13 システムで扱うデータを明らかにする
5-14 システムに必要な機能を明らかにする
5-15 まとめ
Chapter 06 ケーススタディ実践編
6-1 取り上げるケース
6-2 背景知識の差異によるコミュニケーション問題
6-3 大手ユーザー企業による更新案件
6-4 未経験の領域の新規システム開発
6-5 まとめ
Chapter 07 要件分析フレームワーク詳細リファレンス編
7-1 コンテキストモデル
7-2 要求モデル
7-3 業務モデル
7-4 利用シーンモデル
7-5 概念モデル
7-6 ユースケースモデル
7-7 画面・帳表モデル
7-8 イベントモデル
7-9 プロトコルモデル
7-10 データモデル
7-11 ドメインモデル
7-12 機能モデル
7-13 機能複合モデル
7-14 まとめ
Chapter 08 要件分析プロセス補足リファレンス編
8-1 要件分析の道筋
8-2 検証のためのポイント
8-3 整合性を高めるポイント
8-4 タイムボックスでの管理例
8-5 タイムボックスでの管理手法
8-6 モデルの精度向上
8-7 使われ方の違いによる要件定義の差違
8-8 まとめ

感想

やはり世の中、知らない事だらけですな。

もはや、感想というよりは、重要な箇所のメモだけれど、まぁ、それはそれということで。

まずは２０ページ

要件定義が備えるべき特性は定義された要件なら、重複なく、そして各々の要件が整合しており、それが分かりやすく表現されているもの

同じく２０ページ

要件を定義するための２つの視点は「何を定義すべきなのか」「同定義していくのか」

２５ページ

プロジェクトを混乱させないためにも、総合的に見て妥当と思われる提案を予め用意し、会議の場で積極的に示していく必要があります。そして議論を適切な方向へ導いていきます。

で、３２ページ

議論を積み上げていくポイント
１）ゴールが継続的に明確化されている
２）共通認識の上で議論を組み立てる
３）異なる視点から内容を検証しながら進める
４）解決すべき本質的な課題を明らかにする

７６ページ

コンテキストモデルとはシステム化対象の業務に関わる人（組織）を洗い出す。この時の人とはロールを指し、この業務を進めるにあたって必要な役割を整理する

７７ページ

要求も出るとは関係者の要求をもれなくヒアリングし、構造化する。その中で粒度を調整しながら、問題、課題、本質的な要求を把握して、そして要求へと洗練化する

８０ページ

業務フローモデルとは業務視点で業務の流れを明確にするコンテキストモデルに現れたアクターがどのように関係するかを明らかにする

８２ページ

利用シーンモデルとはコンテキストモデルに現れたアクターがどのようにシステムを利用するのか、その結果どのような価値を生み出すのかを洗い出す。メンバーでイメージを共有しやすいように、できるだけ具体的に記述するのが良い。

８４ページ

概念モデルとは業務の中で認識されている概念を構造化し、メンバー間で認識を合わせる。

８７ページ

ユースケースモデルとはシステム境界として人が関わる部分をユースケースでモデル化する。全ユースケースを洗い出すことで人（組織）が関わるシステム境界を明確にしたことになる

８９ページ

画面・帳票モデルとは画面・帳票などの入力情報を洗い出し、システム境界で扱われる情報を明らかにする

９１ページ

プロコトルモデルとは外部システムとの連携を状態として明らかにし、そのやりとりをルール化する

９４ページ

データモデルとはシステムであるデータをクラス図を使い構造化する。データモデルの候補として以下のものから導きだす。業務フロー上の情報、画面・帳票の項目、イベント上の項目

９５ページ

ドメインモデルとは、ドメインはシステムの基本的なルールを持ち、整合性を維持し、個々のアプリケーションに依存しないシステム構造を保持している

９６ページ

ビジネスルールとは重要なビジネスルールを表現した任意のドキュメントです。「重要」なとはこのシステムの動作原理になるようなルールや制約など、システム化に当たって考慮しておくものを指します。

１３３ページ

要件は広く捉え、徐々に深堀する

１３７ページ

モデルは基本的にTo-Beモデル（将来の業務はこうなります）として作成する。現状がわからない時だけAs-isモデル（現状の業務の流れはこうなっています）を作成する。As-isモデルの作成は必要最小限なものにとどめ、時間をかけない。As-isモデルは全体を俯瞰できるレベルで、現状がマクロ的に理解できるレベルとする。現場について詳細が必要になったときにその部分にポイントを絞って調べる。マクロ的にAs-isモデルを作成するのは詳細を調べるときにその部分を把握できるようにするためである。

１４２ページ

タスク間には依存関係があり、依存されているものから先に手をつける。タスクにはそれを行うためのスキルが必要となる。タスクの並行性を高めると期間を短縮できる。タスクを実現すれば想定している成果物を作成できる。進捗が遅れていた場合にはその対策を行う。タスク間の依存関係に基づいてタスクを結びつけると完了日が明確になる。担当者は割り当てられたタスクだけをこなせばいい。すべてのタスクは洗い出せるし、できないときは猶予期間を用意する。タスクはすべて計画可能であり、計画通りに実現可能であると考える。

１４３ページ