devlove発表資料

要件定義と開発プロセスの接点

頭でっかちで役に立たない要件定義にならないために

そのチームにとって適切な要件定義とは

㈱バリューソース代表取締役神崎善司zkanzaki@vsa.co.jpFacebook page：要件定義の散歩道https://www.facebook.com/youkennotsubo?ref=hltwitter：@zenzengood

普段は要件定義関連のコンサルセミナー講師（要件定義、オブジェクト指向、モデリング）

わたしは…

今日お話しすること

決め方

いつから作るできるだけ手戻りを減らすために、どこまで要件をつめればいいか

要件定義を素早く精度高く行うには…

精度の高い要件定義を短期間に行うためには…

要件を素早く決める

要件を決める

全体を俯瞰する

システムの地図

地図が伝えるもの全体をつかむために

宅地

商業地

枝葉の情報を省き重要な情報を載せる

詳細化するために分類する

これは当たり前でもExcelでつくられた巨大な図を見かけませんか

全体を俯瞰する

ＵＣ：ユーケース

情報をつなぎシステムの骨格をつかむ

データ

入出力

要求

機能

機能外部システム外部シ

ステム外部システム

要求から機能とデータまでをつなげる

要件定義の枠組みから要件を素早く決める

決め方を決める

要件分析の枠組み

要件定義には何を定義すればいいのか

「要件定義の対象をシステムとシステムを取り巻く環境」と考える

システムシステム

システムを取り巻く環境

要件定義書

要件定義では何が定義されないといけないのか

システム

もの

サービス

機能

データ

機能

利害関係者

ユーザ

外部システム

業務

•その機能が使用するデータは？•システムに必要な機能は？•その時の入出力情報は？•上記の環境とシステムとの接点は？

•どのような外部システムと関わるのか？•どのような人に使われるのか？•このシステムの目的（価値）は？

•どのような業務でシステムは使われるのか？

もの

サービス

要件定義の構造を定義する

システム

機能

データ

機能

利害関係者

ユーザ

外部システム

システム価値

ものサービス

利害関係者

ユーザ

システム外部環境

外部システム

システム境界

機能データ

機能

•システム価値•システム外部環境•システム境界•システム

要件定義の構造

•その機能が使用するデータは？

•システムに必要な機能は？

•その時の入出力情報は？

•システムとの接点は？

•どのような外部システムと関わるのか？

•どのような人に使われるのか？

•このシステムの目的（価値）は？

•どのような業務でシステムは使われるのか？

なぜ４つに分けるのか

システムの要件をまとめるとは...

システム境界を明確にする必要がある

システムの外部環境を把握する必要がある

対象業務の関係者と関係する外部システムを洗い出す

システムに必要な機能とデータを定義する

その外部環境がもつ価値や役割を定義する

システム価値

ものサービス

利害関係者

ユーザ

外部システム

システム境界

機能データ

機能

要求価値

そのためには…

要件分析の枠組み各々の視点に必要な情報は

１．【システムの価値】を捉える

•対象業務に関わる人を洗い出す•関係する外部システムを洗い出す•要求を捉える

２．【システム外部環境】を捉える

•対象業務の流れを捉える•対象業務に関わる概念を明らかにする•システムの利用シーンを明らかにする

３．【システム境界】を捉える

•ユーザインターフェースを明らかにする•外部システムとのインターフェースを明らかにする

４．【システム】を定義する

•機能を明らかにする•データを明らかにする•ドメインの構造を把握する

システム価値システム価値

ものサービス

利害関係者

ユーザ

要求

価値

外部システム

機能データ

機能

システム境界

システム価値からシステムの機能とデータをつなぐ手段としてUMLを拡張したモデルを利用する

システムの全体像をとらえるRDRA：Relationship Driven Requirement Analysis

act アクティビティ

システム主体者１システム主体者２システム主体者３

Ｘｘｘｘｘ７Ｘｘｘｘｘ４

開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２

Ｘｘｘｘｘ９Ｘｘｘｘ３

終了

システム主体者１

開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２

終了

開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２

終了

開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２

終了

コンテキストモデルからシステム境界まで

１．対象業務に関わる人と外部システムを把握する

class システムコンテキスト

業務名

<<システム>>Xxxx システム

システム主体者１システム主体者２

システム主体者３

システム主体者４

業務主体者５

外部システム

class システムコンテキスト

業務名

<<システム>>Xxxx システム

業務主体者５

外部システム

コンテキストモデル

cus t om 機能要求

新しいサービスを開始したい

広告収入を増やしたい

小規模店舗が新しい市場だ

顧客へのサービスを向上させたい

難しい操作のシステムをいれるのは嫌だ

顧客とダイレクトにつなぎたい

XXXXXXXXXXXXXX

YYYYYYYYYYYYYYY

cus t om 機能要求

新しいサービスを開始したい

広告収入を増やしたい

小規模店舗が新しい市場だ

顧客へのサービスを向上させたい

難しい操作のシステムをいれるのは嫌だ

顧客とダイレクトにつなぎたい

XXXXXXXXXXXXXX

YYYYYYYYYYYYYYY

要求モデル

外部システム

人（アクター）

システム

要求要求

要求

２．下記関係者の要求を把握する

４．業務の中でシステムが関わる部分を把握する

３．業務を組み立てる

uc ユースケース

ＸｘｘｘをＹｙｙｙする

ＸｘｘｘをＷｗｗｗする

ＵｕｕｕをＬｌｌｌする

システム主体者２

Kkkk kをXする

Oを Onnnnする

Kkkk kをXする

Oを Onnnnする

開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２

終了

開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２

終了

業務モデル

act 入荷業務

発注処理

営業

物流

入荷商品の確認

入荷処理

開始

終了

発注処理

<<入荷システム>>入荷登録

在庫切れ　　在庫補充の発注

新規商品の発注

act 入荷業務

発注処理

営業

物流

入荷商品の確認

入荷処理

開始

終了

発注処理

<<入荷システム>>入荷登録

在庫切れ　　在庫補充の発注

新規商品の発注

対象業務に関わる人と外部システムを要件定義の起点とする

s tm 状態

State1

St ate2

開始

St ate3

St ate4

終了

Stat e5

State 6

Stat e7

ユースケース名と対応をとることもできる

St ate8

Sta te9

<<Use Case>>

eeeeee [ff<1000]

ＸｘｘｘをＷｗｗｗする[aaa=234]

s tm 状態

State1

St ate2

開始

St ate3

St ate4

終了

Stat e5

State 6

Stat e7

St ate8

Sta te9

<<Use Case>>

eeeeee [ff<1000]

stm イベント一覧

タイムアウト

一周完了

停止

制御終了

操作開始

移動終了

移動開始

電源オフ電源オン

コンテキストモデル::定点カメラ

タイムアウト

一周完了

停止

制御終了

操作開始

移動終了

移動開始

イベントモデル

プロトコルモデル

５．外部システムとのイベントを捉える

６．外部システムとのプロトコルを整理

同じように利用シーンからユースケースを導き出す

ユースケースから機能、データまで

システム

７．ユースケースに関わるユーザーインターフェーズを洗い出す

Kkkkkを Xする

Oを Onnnnする

Kkkkkを Xする

Oを Onnnnする

s tm 状態

State1

St ate2

開始

St ate3

St ate4

終了

Stat e5

State 6

Stat e7

St ate8

Sta te9

<<Use Case>>

eeeeee [ff<1000]

s tm 状態

State1

St ate2

開始

St ate3

St ate4

終了

Stat e5

State 6

Stat e7

St ate8

Sta te9

<<Use Case>>

eeeeee [ff<1000]

タイムアウト

一周完了

停止

制御終了

操作開始

移動終了

移動開始

タイムアウト

一周完了

停止

制御終了

操作開始

移動終了

移動開始

イベントモデル

プロトコルモデル

８．ユースケースを実現する機能を洗い出す

cus tom 画面モデル

<<画面>>商品登録画面

- 商品名- 取引先- 荷姿- 発注単位- 商品カテゴリ

<<画面>>販売状況照会

- 月- 商品カテゴリ

<<画面>>発注登録

- 商品- 発注日- 発注数量- 入荷予定日

<<画面>>商品説明

- 商品カテゴリ

<<画面>>カート処理

- 受注番号

<<画面>>受注照会

- 顧客名- 受注日

商品売上詳細

- 商品- 売上数量- 売上金額

詳細説明

- 商品説明

カート内商品

- 商品- 数量

<<画面>>決済処理

- 顧客名- 住所- 決済方法

受注商品

- 商品- 受注数量

cus tom 画面モデル

- 受注番号

商品売上詳細

- 商品- 売上数量- 売上金額

詳細説明

- 商品説明

カート内商品

- 商品- 数量

受注商品

- 商品- 受注数量

uc ユースケース＆画面

受注照会

商品登録

商品説明＆受注

発注処理

販売状況照会

オーダー管理

営業

物流

顧客

- 受注番号

オーダー取り消しオーダー取り消し

- 受注番号

uc ユースケース＆画面

受注照会

商品登録

商品説明＆受注

発注処理

販売状況照会

オーダー管理

営業

物流

顧客

- 受注番号

オーダー取り消しオーダー取り消し

- 受注番号

画面帳表モデル

act 機能モデル

<<funct ion>>Uuuu機能

<<funct ion>>Zzzz機能

<<funct ion>>Ｘｘｘｘ機能

<<funct ion>>Ｙｙｙｙｙ機能

act 機能モデル

機能モデル

act 機能モデル

c la s s データモデル２

<<datamodel>>AAAＸｘｘｘ

- xxx11: int- xxx12: int- xxx13: int

Ｘｘｘｘ

<<datamodel>>AAAＸｘｘｘ１

- x1xx11- x1xx12- x1xx13

<<datamodel>>AAAＹｙｙｙ

- yyy1- yyy2- yyy3

Ｕｕｕｕ

- uuu1- uuu2- uuu3

<<datamodel>>AAAＪｊｊｊ

- jjj1- jjj2- jjj3

<<datamodel>>AAAＯｏｏｏ

- eeee1: int- eeee2: int- eeee3: int

Ｘｘｘｘ

<<datamodel>>AAAＸｘｘｘ２

- x2xx1- x2xx2- x2xx3

Ｘｘｘｘ

Ｘｘｘｘ３

c la s s データモデル２

Ｘｘｘｘ

<<datamodel>>AAAＸｘｘｘ１

- x1xx11- x1xx12- x1xx13

<<datamodel>>AAAＹｙｙｙ

- yyy1- yyy2- yyy3

Ｕｕｕｕ

- uuu1- uuu2- uuu3

- jjj1- jjj2- jjj3

Ｘｘｘｘ

<<datamodel>>AAAＸｘｘｘ２

Ｘｘｘｘ

Ｘｘｘｘ３

データモデル

uc 機能モデル

- jj j1- jjj2- jjj3

Ｘｘｘｘ

<<datamodel>>AAA Ｘｘｘｘ１

- x1xx11- x1xx12- x1xx13

<<funct ion>>Ｘｘｘｘ機能 <<funct ion>>

Ｙｙｙｙｙ機能

triger

CRUD CRUD

uc 機能モデル

- jj j1- jjj2- jjj3

Ｘｘｘｘ

<<datamodel>>AAA Ｘｘｘｘ１

- x1xx11- x1xx12- x1xx13

<<funct ion>>Ｘｘｘｘ機能 <<funct ion>>

Ｙｙｙｙｙ機能

triger

CRUD CRUD

９．アクションを機能に対応付ける

画面・ユースケースモデル

ユースケースモデル

機能モデル

システム境界

１０．データを洗い出す

１１．機能とデータを付き合わせる

機能複合モデル

システム価値システム外部環境システム境界システム

コンテキスト

利用シーン

業務

イベントプロトコル

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求

利用シーン＆ＵＣ

業務＆ＵＣ

ＵＣ：ユーケース

ＵＣ＆画面

ＵＣ＆機能

関係ダイアグラムシステムの地図

システムの地図モデルイメージ

画面・帳票モデルイベントモデル

プロトコルモデルデータモデル機能複合モデル（CRUD）

モデル名はRDRAベース

全てのモデルを作るわけではない

モデリングツールリポジトリの利用

リポジトリを使って違うダイアグラムに同一アイコンを配置できる

リポジトリ上は一つのものとして管理されるA

要件定義も徐々に洗練化する(２ヶ月の要件定義の例)

１ヶ月目２ヶ月目３ヶ月目４ヶ月目５ヶ月目６ヶ月目７ヶ月目８ヶ月目９ヶ月目システムの開発期間

１週目２週目３週目４週目５週目６週目７週目８週目９週目

要件定義

１マイルストーン

第１マイルストーン第２マイルストーン第３マイルストーン

２マイルストーン３マイルストーン４マイルストーン

第４マイルストーン

システム価値

システム境界

システム価値

システム境界

システム価値

システム境界

システム価値

システム境界

要件のベースライン

見積もりをしなくてはいけない…

要件定義は繰り返し洗練化が必要

ウォーターフォールで考えてみるWBSにはめるため…

分割して統治せよサブシステム分割

業務フローが顧客に価値を届ける単位になるので、その単位でサブシステムを分割するとわかりやすい

サブシステム間の関係を記述する関係は１方向が望ましい

サブシステム分割のもとになった業務フローをサブシステムの配下に置く

サブシステム

システムの地図ブレークダウン

・決める範囲をどのように決めればいいのか？

・そのチームにとって最も手戻りのコストが低い要件定義は？

・具体的に「ここが」と指せるものはあるか？

どこまで決めれば開発に移れるか

コンテキスト

利用シーン

業務

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求

業務＆ＵＣ

ＵＣ＆画面

ＵＣ＆機能

開発サイクルとRDRAを対応させる

手戻りを減らすためにどこまで決めておく必要があるか？

アーキテクチャの決まり具合は？開発手法の決まり具合は？

いつから開発サイクルをはじめるか

アクターと要求がそろったところで開発サイクルを開始

業務が見えたところで開発サイクルを開始

インターフェースが見えたところで開発サイクルを開始

認識を合わせる

RDRAを要件の出発点として活用

要件仕様

How 設計実装

機能・データが見えたところで開発サイクルを

開始

Agileに対応させてみる

Agile開発

価値

価値を実現する主要な業務、主要なパス

動くもの（実装）で置き換えられる部分

インセプションデッキと対応させてみる

２．エレベータピッチコンテキスト図・要求を使ってシステムの目的や狙いを伝える

１．我々はなぜここにいるのかシステムの外部環境とシステム境界を説明し何を実現するためにいるのかを

説明

３．パッケージデザインキーとなる主要なシステム境界（画面、イベント）を使って、要求とつなげて価値を伝える

５．ご近所さんを探せ重要なアクターを業務フロー、ユースケースに関わるアクターから洗い出す。開発に関わるアクターは開発用のコンテキスト図を別途用意

対応しないもの４．やらないことリスト６．技術的な解決案を描く９．トレードオフスライダー１０．何がどれだけ必要か

７．夜も眠れなくなるような問題トップダウン、ボトムアップで説明する中で「これだ！」と言えるものが無い…主要・重要の切り分けがついていない

８．期間を見極める４つの視点とマイルストーンを使って全体を把握しロードマップを明らかにする

モデルで考えるか動くもので考えるか

考慮点・どこまで全体を俯瞰する必要があるのか・モデルで考えるのが早いか動くもので考える方が早いか・そのプロジェクトにとってHoｗを考えることが重要か否か・革新的か否か（実物を見ないと判断できない）～

図で考える動くもので考える

表現方法

フォーカス

関心 What What＆Hoｗ

モデル動くも

ポイント不可逆な時間の中で「今」何を行う必要があるのか

不可逆な時間の中で手戻りを減らすために「決めすぎず、決めなさすぎず」

不可逆な時間の中で手戻りをどう減らすか

制約

制約制約

次の作業は前の制約の中で考えるシステム価値システム価値

ものサービス利害関係者

ユーザ

要求価値

外部システム

機能データ

機能

システム境界

システム価値

システム境界

システム価値

システム境界

システム価値

システム境界

システム価値

システム境界

制約を作りこむ・４つの視点には依存関係がある・４つの視点と制約を合わせる・一度に決めない徐々に洗練化する・力点を明確にする

RUPに対応させてみる

A B C D E

方向づけ・推敲内の４つのイテレーション（A～D）で活用各々の要求・分析にRDRAのモデルを重点を変えながら対応させる

マイルストーン毎の力点の移動 (既存システムの再構築例)マイルストーン１マイルストーン２

最重点モデル

マイルストーン４

最重点モデル

網羅性

整合性

マイルストーン３

サブシステム分割

コンテキスト

利用シーン

業務

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求

業務＆ＵＣ

ＵＣ＆画面

ＵＣ＆機能

関係ダイアグラムシステムの地図

ここまでできたら開発に移行する具体的に対象を指し認識を合わせられることが重要

制約

制約制約

本日のまとめ

A- 33 システム

不可逆な時間の中で手戻りを減らす

４つの視点で制約を作りこむ

RDRA• 視点の異なる情報をつなげて素早く要件を決める• 全体視点で合意するべきところを明示し反復開発に

つなげる• システムの地図で全体を管理する

作業領域で制約を作りこむ

ビジネスキャンバスでビジネスモデルのポイントが示される

おまけ１ビジネスキャンバスからつなぐ

ビジネスモデルキャンバス

問題はここからどうシステム化するか

コスト構造収益の流れ

パートナー

顧客セグメント

価値提案

リソース

主要活動

チャネル

顧客との関係

ビジネスモデルジェネレーションより

コスト構造収益構造

パートナー

顧客セグメント

価値提案

リソース

主要活動

チャネル

顧客との関係

登場人物もの・サービス

配送手段決済手段

アクター外部システム

業務フロー・ワークフロー利用シーン

ビジネスキャンバス

ビジネスモデル図

バリエーションの組み合わせから細かな条件が整理される

バリエーション分析

システム化の目的要求

概念

ビジネスキャンバスからRDRAモデルへ

ビジネスキャンバスから具体的なビジネスルールを導き出す

ビジネスキャンバスに対応するモデル

会社顧客

入金

商品

注文

請求

仕入先

コンテキスト

業務プロトコル

ユースケース

画面・帳表

ドメインデータ

要求

イベント

概念

情報

商品

コスト構造収益の流れ

パートナー

顧客セグメ

ント

価値提案

リソース

主要活動

チャネル

顧客との関係

バリデーション分析

モデルを使って具体的に分析する

保守で使えるモデル

視覚的なトレーサビリティを実現する

おまけ２トレーサビリティを確保したモデル

RDRA RDRA保守用

開発のV字モデル

変更の影響度を測るトレーサビリティ

変更

影響

影響影響

影響

実装としてのつながりを視覚化

画面機能データ

c lass 受注伝票

<<ADWindow>>Sales Order

<<ADTab>>Order Line

<<ADTab>>Order

<<ADTab>>Order Tax

<<ADTab>>POS Payment

<<ADTab>>Payment Schedule

<<interface>>注文(Order): : I_C _Order

<<interface>>注文(Order) : : I_C_OrderLine

<<interface>>注文(Order) : : I_C_OrderTax

<<interface>>支払い(Payment ): :I_C_POSPayment

<<interface>>注文(Order): : I_C_OrderPaySchedule

注文(Order) : :c_order

注文(Order): :c_orderline

注文(Order): :c _ordertax

注文(Order): :c_orderpayschedule

POS Payment : :c_pos payment

見積受注管理(c) : 見積受注管理(c)

画面機能

Interfaceデータ

dm 注文(order)

c_cashplanl ine

c_order

c_orderline

c_orderpayschedule

c_ordersource

c_ordert ax

c_payment term

c_payschedule

m_warehouse

c_act iv it y

c_campa ign

c_bpartner_locat ion

c_currency

c_charge

m_product

c_t ax

c_project

m_promot ion

m_shipper

c_bpart ner

ビジネスパートナーとの関係

受注先 business partner

納品先 dropship

請求先 bil

支払先 pay

プログラム（変更・拡張点）

データの広がり

コードを確認

使用するモデル

コンテキスト

利用シーン

業務

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求

業務＆ＵＣ

ＵＣ＆画面

ＵＣ＆機能

トレーサビリティを手に入れるpkg 販売管理

DataModelView

<<table>>注文(Order)

(from 受発注管理(c))

<<table>>出荷/受領(inOut )

(from 出荷・受領・生産(m))

<<table>>パッケージ(package)

<<table>>割当(alloca t ion)

<<table>>請求(Invoice)

<<table>>手数料(comiss ion)

受注伝票

(from 見積受注管理)

注文(Order)

出荷納品伝票

(from 出荷納品管理)

売上請求伝票

(from 売上請求管理)

受発注管理(c)

(from データ)

出荷・受領・生産(m)

(from データ)

<<table>>製品

(from 製品(Product))

製品管理

(from マスタ管理)

出荷・受領(inOut )

支払い(Payment )

請求(Invoice)

<<table>>支払(Payment ）

ここに入金用のビューを

置く

販売管理の主要パッケージ

pkg 業務分析

販売管理

購買管理

マスタ管理

返品管理

c lass 受注伝票

<<ADWindow>>Sales Order

<<ADTab>>Order Line

<<ADTab>>Order

<<ADTab>>Order Tax

<<ADTab>>POS Payment

<<ADTab>>Payment Schedule

<<interface>>注文(Order): : I_C _Order

<<interface>>注文(Order) : : I_C_OrderLine

<<interface>>注文(Order) : : I_C_OrderTax

<<interface>>支払い(Payment ): :I_C_POSPayment

<<interface>>注文(Order): : I_C_OrderPaySchedule

注文(Order) : :c_order

注文(Order): :c_orderline

注文(Order): :c _ordertax

注文(Order): :c_orderpayschedule

POS Payment : :c_pos payment

見積受注管理(c) : 見積受注管理(c)

dm 注文(order)

c_cashplanline

c_order

c_orderline

c_orderpayschedule

c_ordersource

c_ordertax

c_paymentt erm

c_payschedule

m_warehous e

c_act iv it y

c_campaign

c_bpartner_locat ion

c_currency

c_cha rge

m_product

c_t ax

c_pro ject

m_promot ion

m_shipper

c_bpart ner

ビジネスパートナーとの関係

受注先 business partner

納品先 dropship

請求先 bil

支払先 pay

devlove発表資料

Technology

devlove 20100930

「キャンプ指導者入門」資料理論編第3章...

座談会資料(趣旨説明資料) 20161022

devlove 20111008

devlove関西2012 drive　講演資料（ibook）

資料2 - 首相官邸ホームページ...資料2...

devlove hangerflight

- 1 - 4 - 19...資料編資料1...

資料1資料2 - ome · 2020. 5. 8. · 1 資料1資料2....

開放資料暨資料視覺化 (d3.js)

2011.12.06 devlove 社内勉強会×勉強会講演資料

参考資料...参考資料 ... 参考資料 …

devlove hangarflight -springbomb-

資料編seiryuen/img/kentousiryou1.pdf資料編目次...

devlove kansai aws

pmma 技術資料（資料編）mt04

yaskawa siemens cnc シリーズ0...iv 資料の編成...

devlove 20101218 oitomo

localytics 資料

黃三益 2007 資料庫的核心理論與實務第三版...