カンマニのWEB銭

マンガ「グラゼニ」が大好きな、ウェブ系の何でも屋さん「カンマニ」が綴る、仕事とか、読んだ本のこととか、日常とか、世の中に関する忘備録。

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

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

目次

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 まとめ

 

感想

 

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

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

 

まずは20ページ

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


同じく20ページ

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


25ページ

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

 

で、32ページ

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


76ページ

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


77ページ

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


80ページ

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


82ページ

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


84ページ

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


87ページ

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


89ページ

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


91ページ

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


94ページ

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

 

95ページ

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


96ページ

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


133ページ

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


137ページ

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

 

142ページ

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


143ページ

作成する成果物は何種類あるのか?各々の成果物の種類毎にどの程度つくらないといけないのか?個々の成果物はサブシステム等で分類できるか?その分類したものを何人に割り当てていくのか?そのために必要なスキルはどのようなものか?どの作業が並行的に進められるのか?


296ページ

要望:こうできたらいいな 思いつきレベルのもの
要求:検討対象として合意されているもの、すでに共通認識として認識されているもの
要件:今回の開発で実施すると決めた重要なもの

 

299ページ

要求を機能要求、非機能要求に分ける
要求を分類する(要求のレベル、カテゴリマスターで分類)
要求を抽象化する(ゴール分析のテクニックを使う)
要求の依存関係を見極める
要求に優先度をつける


いや、覚えることはたくさんありますな。

 

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

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

 

タイトル:要件定義マニュアル
著者:神崎善司
発売元:秀和システム
おすすめ度:☆☆☆☆☆(すごい本ですよ)