モデルベース要件定義　at bpstudy

モデルベース要件定義

地図を持たずに出かければ迷子になる

A-1株式会社バリューソース

copy right 株式会社バリューソース

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

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

わたしは…

2


お話しすること

システムの全体を表す地図について ⇒ RDRA

ビジネスキャンバスからシステム化へ

おまけ：保守用のモデル（時間があれば）

お話ししないこと

RDRAの詳細

ビジネスキャンバスの書き方

～～

今日お話しすることしないこと

A-3

A-4copy right 株式会社バリューソース

身近な話題から

4


この機能は全体とどうつながるの？

全体を語る資料がないので個々の機能の位置づけが分からない

どっちでもいいから早く決めて欲しい

開発が遅れてしまう…

えっこっちで要件を決めるの？

それって何をきめればいいの？

etc…

こんなことありませんか？

5

要件のまとめ方を知っていると何かと便利なことがあります


意思決定が遅い

決められない

袋小路から抜け出せない

～～

手戻りが多い

要件の整合性がとれていない

仕様の精度が悪い

～～

etc

何が問題なのか

A-6

今日は要件の決め方と精度の向上の２点を説明

します


要件定義として何をどこまで定義すればいいのか

じゃあどうする？

7


全体が見えていないから意思決定が遅い

システムの地図をつくり、地図を頼りに意思決定する

袋小路から抜け出す方法

問題の背後にある制約を変える

整合性はどうやって確認するか

手戻りを減らすために精度を高める

余計な時間をかけずに…

じゃあどうする

A-8

意思決定が遅い

手戻りが多い

システムの地図とは？

copy right 株式会社バリューソースcopy right 株式会社バリューソース

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

宅地

宅地

商業地

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

意思決定を早める


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



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

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

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

モデル名はRDRAベース

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


要求議論が袋小路に入ったら

A- 12

As-Is To-Beしがらみ

抽象化

具象化



システムの地図

ＵＣ：ユーケース

システムの整合性を保つ

A- 13

データ

入出力

要求

機能

機能

機能

機能

機能

機能外部システム外部シ

ステム外部システム

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

手戻りを減らす

A-14

具体的にどうすればいいの？


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

決め方を決める

要件分析の枠組み

15


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

A-16

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

システムシステム

システムを取り巻く環境

要件定義書


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

A- 17

システム

もの

サービス

機能

データ

機能

機能

利害関係者

ユーザ

外部システム

業務

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

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

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


もの

サービス

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

ものサービス利害関係者

ユーザ

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

A- 18

システム外部環境

外部システム

システム

機能

データ

機能

機能

利害関係者

ユーザ

外部システム


システム境界

機能データ

機能

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

要件定義の構造

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

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

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

•システムとの接点は？

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

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

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

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


なぜ４つに分けるのか

A- 19

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

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

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

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

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

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

システム価値


ものサービス

利害関係者

ユーザ

外部システム


システム境界

機能データ

機能

要求価値

そのためには…





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

ものサービス

利害関係者

ユーザ

要求

価値

外部システム

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

A- 20

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

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

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

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

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

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

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

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



機能データ

機能

システム境界


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

システムの地図を描くRDRA：Relationship Driven Requirement Analysis

21


act アクティビティ

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

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

開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２

Ｘｘｘｘｘ９Ｘｘｘｘ３

終了

システム主体者１




開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２


終了





開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２


終了





開始

Ｘｘｘｘｘ５

Ｘｘｘｘｘ６

Ｘｘｘｘｘ８

Ｘｘｘｘ１

Ｘｘｘｘ２


終了


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

A- 22

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

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 イベント一覧

タイムアウト

一周完了

停止

制御終了

制御終了

操作開始

移動終了

移動開始

電源オフ電源オン

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


タイムアウト

一周完了

停止

制御終了

制御終了

操作開始

移動終了

移動開始



イベントモデル

プロトコルモデル

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

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

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


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

A- 23

システム

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









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 機能モデル





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

RCRU

CRU

uc 機能モデル



- jj j1- jjj2- jjj3





Ｘｘｘｘ

<<datamodel>>AAA Ｘｘｘｘ１

- x1xx11- x1xx12- x1xx13

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

Ｙｙｙｙｙ機能



triger

CRUD CRUD

RCRU

CRU

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

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

ユースケースモデル

機能モデル

システム境界

１０．データを洗い出す

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

機能複合モデル


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

コンテキスト

利用シーン

業務

イベントプロトコル

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求


利用シーン＆ＵＣ

業務＆ＵＣ

ＵＣ：ユーケース

ＵＣ＆画面

ＵＣ＆機能

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

A- 24


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

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

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


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

ビジネスキャンバスからつなぐ

26


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

A-27

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

コスト構造収益の流れ

パートナー

顧客セグメント

価値提案

リソース

主要活動

チャネル

顧客との関係

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


コスト構造収益構造

パートナー


価値提案

リソース

主要活動

チャネル

顧客との関係

登場人物もの・サービス

配送手段決済手段

アクター外部システム

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

ビジネスキャンバス

RDRA

ビジネスモデル図

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

バリエーション分析

システム化の目的要求

概念

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

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


ビジネスルールの表現

業務プロトコル概念ドメインデータ

手順のルール情報構造のルール計算式規約基準

表形式の一覧

在庫あり

在庫なし

在庫引当登録[在庫＜１]

受注引落し[在庫＜１]

ランクA ランクB

0～200 10,000円 5,000円

201～300 20,000円 15,000円

受注引落し

在庫引当登録

フライト

空港

2

イベント画面

会員 Y Y Y N

購入合計＞10000 Y Y N Y

過去購入回数＞２ Y N N Y

割引率５％ X - - -

割引率3％ X X - -

割引なし - - X X

デシジョンテーブル

ビジネスルールを３つの形式で整理する


システム化イメージからの分析

会社登場人物

登場人物

登場人物

登場人物

登場人物

登場人物

会社内の登場人物

部署

部署

部署

部署

会社外の登場人物

会社内の登場人物

登場人物が提供するサービス

部署が提供するサービス or インターフェース

サービスを分解するとビジネスルールが見えてくる


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

会社顧客

入金

商品

注文

請求

仕入先

コンテキスト

業務プロトコル

ユースケース

画面・帳表

ドメインデータ

要求

イベント

概念

情報

情報

情報

商品

コスト構造収益の流れ

パートナー

顧客セグメ

ント

価値提案

リソース

主要活動

チャネル

顧客との関係

バリデーション分析

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


バリエーション分析の起点直目する視点手順のルール情報構造のルール計算式基準規約

分析視点

作業の順番など、順序や進行に条件がある場合にこの方式で分析する

情報に構造があり、情報間のつながりに多重度があるときにこの方式で分析する

独立した計算式や条件の場合は一覧形式で整理する

登場人物

会社、人、組織、外部のシステムなどで識別しているものを洗い出す人、組織間でやりとりに着目する

登場人物間にやりとりが発生するときワークフローが発生する例：

部門間のワークフロー承認ワークフロー

登場人物には個々に特性があり構造化できる例：顧客：一般・会員～

登場人物の関係性で決まるもの外部のシステムが規約として決めているもの

商品サービス

商品の種類や特性に着目する

サービスの前準備でワークフローが必要なものがある例：

インターネットの接続工事サービスのローテーションルール

ものやサービスで扱う情報を構造化する例：

伝票の構造サービスと附帯物の関係

もの、サービスに関わる計算もの、サービスのバリエーションからくる計算の差異利益率などもの、サービスのバリエーションからくる処理の差異

お金

支払入金

決済方法などお金に関わる特性に着目する例：

残管理：消し込み

商品（サービス）の販売から入金までの流れ１回払いと継続払いの手続きの違い

もの、サービスとお金の対応つけ複雑な決済方法の構造化

金額計算値引き率自動継続

時間時間、時期、期間、日付によって特殊性がでるものを分析する

期間にまつわるルール例：期限が１週間...

時期による振る舞いの違い例：季節キャンペーン

定周期のイベント例：日時週次月次

期間や時期にまつわる関係の変化を構造化する

時間にまつわる計算式例：

実稼働時間の計算方法時間あたりの単価

場所場所によって条件が変わるものや特殊性が発生するものを分析する

国内取引と海外取引の手続きの違い地域特性による手順の相違例：

海外取引における乙仲の存在海外品の返品の省略

場所による構造の違い例：

通過、時間の違い国内と海外取引の伝票の違い

場所による計算式の違い例：

場所による仕様の違い場所による税率の違い温暖地と寒冷地仕様の条件

環境制約

法律や業界の自主規制などの制約に着目し分析する

会計基準例：

顧客の検収を持って売上げ計上する

情報間の多重度が制約になる制約のルールが複雑な場合に構造化して分析する

単独で存在するルール税率


どこから情報を手に入れるのか

ビジネス環境（制約）

ビジネスポリシー

契約

規約

ビジネスルール

組織・体制

ビジネスの価値

登場人物間の関係

要件定義手順のルール

情報構造のルール

計算式基準規約

ビジネスモデル

経営哲学

依存

組織図

コスト構造収益構造

パートナー


価値提案

リソース

主要活動

チャネル

顧客との関係

表現する方法

ビジネスキャンバス

ビジネスモデル図

要件分析フレームワーク

情報源情報の依存関係

パンフレット

規約

契約書

伝票

既存システム資料

社員教育用資

料

営業用資料

業界情報本・ネット


本日のまとめ

A-34

４つの視点をモデルで分析

ポイントは各情報をつなげること

登場人物をモデルで具体化する

主要な登場人物を洗い出す

システムとして全体をつなげる

アーキテクチャ

開発


保守で使えるモデル

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

おまけ

A-35

RDRA RDRA保守用

開発のV字モデル


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

A-36

画面機能データ

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_uom

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

拡張性の実現

データの広がり

コードにつなぐ


使用したモデル

A-37

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

コンテキスト

利用シーン

業務

イベントプロトコル

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求


利用シーン＆ＵＣ

業務＆ＵＣ

ＵＣ＆画面

ＵＣ＆機能


トレーサビリティを手に入れる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_uom

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

モデルベース要件定義 at bpstudy

Technology

モデルベース要件定義　at bpstudy