devlove発表資料
DESCRIPTION
RDRAの概要紹介と繰り返し開発と要件定義の接点を紹介 「手戻りを少なくするためにどこまで要件を定義すべきか?」 システムの全体像を俯瞰し、全体視点からの合意点を明らかにする考え方をRDRAの4つの視点から説明TRANSCRIPT
要件定義と開発プロセスの接点
頭でっかちで役に立たない要件定義にならないために
そのチームにとって適切な要件定義とは
㈱バリューソース代表取締役神崎 善司[email protected] page:要件定義の散歩道https://www.facebook.com/youkennotsubo?ref=hltwitter:@zenzengood
普段は要件定義関連のコンサルセミナー講師(要件定義、オブジェクト指向、モデリング)
わたしは…
2
今日お話しすること
A-3
決め方
いつから作るできるだけ手戻りを減らすために、どこまで要件をつめればいいか
要件定義を素早く精度高く行うには…
精度の高い要件定義を短期間に行うためには…
要件を素早く決める
4
要件を決める
A-5
全体を俯瞰する
システムの地図
地図が伝えるもの 全体をつかむために
宅地
宅地
商業地
枝葉の情報を省き重要な情報を載せる
詳細化するために分類する
これは当たり前 でもExcelでつくられた巨大な図を見かけませんか
全体を俯瞰する
UC:ユーケース
情報をつなぎシステムの骨格をつかむ
A- 7
データ
入出力
要求
機能
機能
機能
機能
機能
機能外部システム外部シ
ステム外部システム
要求から機能とデータまでをつなげる
要件定義の枠組みから要件を素早く決める
決め方を決める
要件分析の枠組み
8
要件定義には何を定義すればいいのか
A-9
「要件定義の対象をシステムとシステムを取り巻く環境」と考える
システムシステム
システムを取り巻く環境
要件定義書
要件定義では何が定義されないといけないのか
A- 10
システム
もの
サービス
機能
データ
機能
機能
利害関係者
ユーザ
外部システム
業務
•その機能が使用するデータは?•システムに必要な機能は?•その時の入出力情報は?•上記の環境とシステムとの接点は?
•どのような外部システムと関わるのか?•どのような人に使われるのか?•このシステムの目的(価値)は?
•どのような業務でシステムは使われるのか?
もの
サービス
要件定義の構造を定義する
A- 11
システム
機能
データ
機能
機能
利害関係者
ユーザ
外部システム
システム価値
もの サービス
利害関係者
ユーザ
システム外部環境
外部システム
システムシステム
システム境界
機能データ
機能
•システム価値•システム外部環境•システム境界•システム
要件定義の構造
•その機能が使用するデータは?
•システムに必要な機能は?
•その時の入出力情報は?
•システムとの接点は?
•どのような外部システムと関わるのか?
•どのような人に使われるのか?
•このシステムの目的(価値)は?
•どのような業務でシステムは使われるのか?
なぜ4つに分けるのか
A- 12
システムの要件をまとめるとは...
システム境界を明確にする必要がある
システムの外部環境を把握する必要がある
対象業務の関係者と関係する外部システムを洗い出す
システムに必要な機能とデータを定義する
その外部環境がもつ価値や役割を定義する
システム価値
システム外部環境
もの サービス
利害関係者
ユーザ
外部システム
システムシステム
システム境界
機能データ
機能
要求価値
そのためには…
そのためには…
そのためには…
そのためには…
要件分析の枠組み 各々の視点に必要な情報は
A- 13
1.【システムの価値】を捉える
•対象業務に関わる人を洗い出す•関係する外部システムを洗い出す•要求を捉える
2.【システム外部環境】を捉える
•対象業務の流れを捉える•対象業務に関わる概念を明らかにする•システムの利用シーンを明らかにする
3.【システム境界】を捉える
•ユーザインターフェースを明らかにする•外部システムとのインターフェースを明らかにする
4.【システム】を定義する
•機能を明らかにする•データを明らかにする•ドメインの構造を把握する
システム価値システム価値
もの サービス
利害関係者
ユーザ
要求
価値
外部システム
システム外部環境
システムシステム
機能データ
機能
システム境界
システム価値からシステムの機能とデータをつなぐ手段としてUMLを拡張したモデルを利用する
システムの全体像をとらえるRDRA:Relationship Driven Requirement Analysis
14
act アクティビ ティ
システム主体者1 システム主体者2 システム主体者3
X xxxx7 X xxxx4
開始
X xxxx5
X xxxx6
X xxxx8
X xxx1
X xxx2
X xxxx9X xxx3
終了
システム主体者1
act アクティビ ティ
システム主体者1 システム主体者2 システム主体者3
X xxxx7 X xxxx4
開始
X xxxx5
X xxxx6
X xxxx8
X xxx1
X xxx2
X xxxx9X xxx3
終了
システム主体者1
act アクティビ ティ
システム主体者1 システム主体者2 システム主体者3
X xxxx7 X xxxx4
開始
X xxxx5
X xxxx6
X xxxx8
X xxx1
X xxx2
X xxxx9X xxx3
終了
システム主体者1
act アクティビ ティ
システム主体者1 システム主体者2 システム主体者3
X xxxx7 X xxxx4
開始
X xxxx5
X xxxx6
X xxxx8
X xxx1
X xxx2
X xxxx9X xxx3
終了
システム主体者1
コンテキストモデルからシステム境界まで
A-
1.対象業務に関わる人と外部システムを把握する
class システムコンテキスト
業務名
<<システム>>Xxxx システム
システム主体者1システム主体者2
システム主体者3
システム主体者4
業務主体者5
外部システム
class システムコンテキスト
業務名
<<システム>>Xxxx システム
システム主体者1システム主体者2
システム主体者3
システム主体者4
業務主体者5
外部システム
コンテキストモデル
cus t om 機能要求
新しいサービスを開始したい
広告収入を増やしたい
小規模店舗が新しい市場だ
顧客へのサービスを向上させたい
難しい操作のシステムをいれるのは嫌だ
顧客とダイレクトにつなぎたい
XXXXXXXXXXXXXX
YYYYYYYYYYYYYYY
システム主体者1システム主体者2
システム主体者3
cus t om 機能要求
新しいサービスを開始したい
広告収入を増やしたい
小規模店舗が新しい市場だ
顧客へのサービスを向上させたい
難しい操作のシステムをいれるのは嫌だ
顧客とダイレクトにつなぎたい
XXXXXXXXXXXXXX
YYYYYYYYYYYYYYY
システム主体者1システム主体者2
システム主体者3
要求モデル
外部システム
人(アクター)
システム
要求要求
要求
2.下記関係者の要求を把握する
4.業務の中でシステムが関わる部分を把握する
3.業務を組み立てる
uc ユ ースケー ス
X xxxをYyyyす る
X xxxを Wwwwする
UuuuをLl l l す る
システム主体者1
システム主体者2
システム主体者3
システム主体者4
Kkkk kをXする
Oを Onnnnす る
uc ユ ースケー ス
X xxxをYyyyす る
X xxxを Wwwwする
UuuuをLl l l す る
システム主体者1
システム主体者2
システム主体者3
システム主体者4
Kkkk kをXする
Oを Onnnnす る
act アクティ ビティ
システム主体者1 システム主体者2 システム主体者3
X xxxx7 X xxxx4
開始
X xxxx5
X xxxx6
X xxxx8
X xxx1
X xxx2
X xxxx9X xxx3
終了
システム主体者1
act アクティ ビティ
システム主体者1 システム主体者2 システム主体者3
X xxxx7 X xxxx4
開始
X xxxx5
X xxxx6
X xxxx8
X xxx1
X xxx2
X xxxx9X xxx3
終了
システム主体者1
業務モデル
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]
XxxxをWwwwする[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]
XxxxをWwwwする[aaa=234]
stm イベント一覧
タイムアウト
一周完了
停止
制御終了
制御終了
操作開始
移動終了
移動開始
電源オフ 電源オン
コンテキストモデル::定点カメラ
stm イベント一覧
タイムアウト
一周完了
停止
制御終了
制御終了
操作開始
移動終了
移動開始
電源オフ 電源オン
コンテキストモデル::定点カメラ
イベントモデル
プロトコルモデル
5.外部システムとのイベントを捉える
6.外部システムとのプロトコルを整理
同じように利用シーンからユースケースを導き出す
ユースケースから機能、データまで
A-
システム
7.ユースケースに関わるユーザーインターフェーズを洗い出す
uc ユ ースケース
X xxxを Yyyyする
X xxxを Wwwwする
Uuuuを Ll l l する
システム主体者1
システム 主体者2
システム主体者3
システム主体者4
Kkkkkを Xする
Oを Onnnnする
uc ユ ースケース
X xxxを Yyyyする
X xxxを Wwwwする
Uuuuを Ll l l する
システム主体者1
システム 主体者2
システム主体者3
システム主体者4
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]
XxxxをWwwwする[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]
XxxxをWwwwする[aaa=234]
stm イベント一覧
タイムアウト
一周完了
停止
制御終了
制御終了
操作開始
移動終了
移動開始
電源オフ 電源オン
コンテキストモデル::定点カメラ
stm イベント一覧
タイムアウト
一周完了
停止
制御終了
制御終了
操作開始
移動終了
移動開始
電源オフ 電源オン
コンテキストモデル::定点カメラ
イベントモデル
プロトコルモデル
8.ユースケースを実現する機能を洗い出す
cus tom 画面モデル
<<画面>>商品登録画面
- 商品名- 取引先- 荷姿- 発注単位- 商品カテゴリ
<<画面>>販売状況照会
- 月- 商品カテゴリ
<<画面>>発注登録
- 商品- 発注日- 発注数量- 入荷予定日
<<画面>>商品説明
- 商品カテゴリ
<<画面>>カート処理
- 受注番号
<<画面>>受注照会
- 顧客名- 受注日
商品売上詳細
- 商品- 売上数量- 売上金額
詳細説明
- 商品説明
カー ト内商品
- 商品- 数量
<<画面>>決済処理
- 顧客名- 住所- 決済方法
受注商品
- 商品- 受注数量
cus tom 画面モデル
<<画面>>商品登録画面
- 商品名- 取引先- 荷姿- 発注単位- 商品カテゴリ
<<画面>>販売状況照会
- 月- 商品カテゴリ
<<画面>>発注登録
- 商品- 発注日- 発注数量- 入荷予定日
<<画面>>商品説明
- 商品カテゴリ
<<画面>>カート処理
- 受注番号
<<画面>>受注照会
- 顧客名- 受注日
商品売上詳細
- 商品- 売上数量- 売上金額
詳細説明
- 商品説明
カー ト内商品
- 商品- 数量
<<画面>>決済処理
- 顧客名- 住所- 決済方法
受注商品
- 商品- 受注数量
uc ユ ースケー ス&画面
受注照会
商品登録
商品説明&受注
発注処理
販売状況照会
オーダ ー管理
営業
物流
顧客
<<画面>>商品登録画面
- 商品名- 取引先- 荷姿- 発注単位- 商品カテゴリ
<<画面>>販売状況照会
- 月- 商品カテゴリ
<<画面>>発注登録
- 商品- 発注日- 発注数量- 入荷予定日
<<画面>>商品説明
- 商品カテゴリ
<<画面>>カー ト処理
- 受注番号
<<画面>>受注照会
- 顧客名- 受注日
<<画面>>決済処理
- 顧客名- 住所- 決済方法
オーダー 取り消しオーダー 取り消し
- 受注番号
uc ユ ースケー ス&画面
受注照会
商品登録
商品説明&受注
発注処理
販売状況照会
オーダ ー管理
営業
物流
顧客
<<画面>>商品登録画面
- 商品名- 取引先- 荷姿- 発注単位- 商品カテゴリ
<<画面>>販売状況照会
- 月- 商品カテゴリ
<<画面>>発注登録
- 商品- 発注日- 発注数量- 入荷予定日
<<画面>>商品説明
- 商品カテゴリ
<<画面>>カー ト処理
- 受注番号
<<画面>>受注照会
- 顧客名- 受注日
<<画面>>決済処理
- 顧客名- 住所- 決済方法
オーダー 取り消しオーダー 取り消し
- 受注番号
画面帳表モデル
act 機能モデル
<<funct ion>>Uuuu機能
<<funct ion>>Zzzz機能
<<funct ion>>X xxx機能
<<funct ion>>Yyyy y機能
act 機能モデル
<<funct ion>>Uuuu機能
<<funct ion>>Zzzz機能
<<funct ion>>X xxx機能
<<funct ion>>Yyyy y機能
機能モデル
act 機能モデル
<<funct ion>>Uuuu機能
<<funct ion>>Zzzz機能
<<funct ion>>X xxx機能
<<funct ion>>Yyyy y機能
act 機能モデル
<<funct ion>>Uuuu機能
<<funct ion>>Zzzz機能
<<funct ion>>X xxx機能
<<funct ion>>Yyyy y機能
c la s s データ モデ ル2
<<datamodel>>AAAX xxx
- xxx11: int- xxx12: int- xxx13: int
Xxxx
<<datamodel>>AAAX xxx1
- x1xx11- x1xx12- x1xx13
<<datamodel>>AAAYyyy
- yyy1- yyy2- yyy3
Uuuu
- uuu1- uuu2- uuu3
<<datamodel>>AAAJj j j
- jjj1- jjj2- jjj3
<<datamodel>>AAAOooo
- eeee1: int- eeee2: int- eeee3: int
Xxxx
<<datamodel>>AAAX xxx2
- x2xx1- x2xx2- x2xx3
Xxxx
X xxx3
- x3xx1- x3xx2- x3xx3
c la s s データ モデ ル2
<<datamodel>>AAAX xxx
- xxx11: int- xxx12: int- xxx13: int
Xxxx
<<datamodel>>AAAX xxx1
- x1xx11- x1xx12- x1xx13
<<datamodel>>AAAYyyy
- yyy1- yyy2- yyy3
Uuuu
- uuu1- uuu2- uuu3
<<datamodel>>AAAJj j j
- jjj1- jjj2- jjj3
<<datamodel>>AAAOooo
- eeee1: int- eeee2: int- eeee3: int
Xxxx
<<datamodel>>AAAX xxx2
- x2xx1- x2xx2- x2xx3
Xxxx
X xxx3
- x3xx1- x3xx2- x3xx3
データモデル
uc 機能モデ ル
X xxxをW wwwする
<<datamodel>>AAAJ j j j
- jj j1- jjj2- jjj3
<<datamodel>>AAAOooo
- eeee1: int- eeee2: int- eeee3: int
<<datamodel>>AAAX xxx
- xxx11: int- xxx12: int- xxx13: int
Xxxx
<<datamodel>>AAA Xxx x1
- x1xx11- x1xx12- x1xx13
<<funct ion>>Xxxx機能 <<funct ion>>
Yyyyy機能
<<funct ion>>Zzzz機能
<<funct ion>>Uuuu機能
triger
CRUD CRUD
RCRU
CRU
uc 機能モデ ル
X xxxをW wwwする
<<datamodel>>AAAJ j j j
- jj j1- jjj2- jjj3
<<datamodel>>AAAOooo
- eeee1: int- eeee2: int- eeee3: int
<<datamodel>>AAAX xxx
- xxx11: int- xxx12: int- xxx13: int
Xxxx
<<datamodel>>AAA Xxx x1
- x1xx11- x1xx12- x1xx13
<<funct ion>>Xxxx機能 <<funct ion>>
Yyyyy機能
<<funct ion>>Zzzz機能
<<funct ion>>Uuuu機能
triger
CRUD CRUD
RCRU
CRU
9.アクションを機能に対応付ける
画面・ユースケースモデル
ユースケースモデル
機能モデル
システム境界
10.データを洗い出す
11.機能とデータを付き合わせる
機能複合モデル
システム価値 システム外部環境 システム境界 システム
コンテキスト
利用シーン
業務
イベント プロトコル
ユースケース
概念
画面・帳表
機能
ドメイン
データ
要求
機能複合モデル
利用シーン&UC
業務&UC
UC:ユーケース
UC&画面
UC&機能
関係ダイアグラムシステムの地図
A- 17
システムの地図 モデルイメージ
画面・帳票モデル イベントモデル
プロトコルモデルデータモデル 機能複合モデル(CRUD)
モデル名はRDRAベース
全てのモデルを作るわけではない
モデリングツール リポジトリの利用
リポジトリを使って違うダイアグラムに同一アイコンを配置できる
リポジトリ上は一つのものとして管理されるA
要件定義も徐々に洗練化する(2ヶ月の要件定義の例)
1ヶ月目 2ヶ月目 3ヶ月目 4ヶ月目 5ヶ月目 6ヶ月目 7ヶ月目 8ヶ月目 9ヶ月目システムの開発期間
1週目 2週目 3週目 4週目 5週目 6週目 7週目 8週目 9週目
要件定義
1マイルストーン
第1マイルストーン 第2マイルストーン 第3マイルストーン
2マイルストーン 3マイルストーン 4マイルストーン
第4マイルストーン
システム価値
システム外部環境
システムシステム
システム境界
システム価値
システム外部環境
システムシステム
システム境界
システム価値
システム外部環境
システムシステム
システム境界
システム価値
システム外部環境
システムシステム
システム境界
要件のベースライン
見積もりをしなくてはいけない…
要件定義は繰り返し洗練化が必要
ウォーターフォールで考えてみるWBSにはめるため…
分割して統治せよサブシステム分割
業務フローが顧客に価値を届ける単位になるので、その単位でサブシステムを分割するとわかりやすい
サブシステム間の関係を記述する関係は1方向が望ましい
サブシステム分割のもとになった業務フローをサブシステムの配下に置く
サブシステム
サブシステム
サブシステム
システムの地図 ブレークダウン
・決める範囲をどのように決めればいいのか?
・そのチームにとって最も手戻りのコストが低い要件定義は?
・具体的に「ここが」と指せるものはあるか?
どこまで決めれば開発に移れるか
23
システム価値 システム外部環境 システム境界 システム
コンテキスト
利用シーン
業務
イベント プロトコル
ユースケース
概念
画面・帳表
機能
ドメイン
データ
要求
機能複合モデル
利用シーン&UC
業務&UC
UC&画面
UC&機能
開発サイクルとRDRAを対応させる
A- 24
手戻りを減らすためにどこまで決めておく必要があるか?
アーキテクチャの決まり具合は? 開発手法の決まり具合は?
いつから開発サイクルをはじめるか
アクターと要求がそろったところで開発サイクルを開始
業務が見えたところで開発サイクルを開始
インターフェースが見えたところで開発サイクルを開始
認識を合わせる
RDRAを要件の出発点として活用
要件仕様
What
How 設計実装
機能・データが見えたところで開発サイクルを
開始
Agileに対応させてみる
Agile開発
価値
価値を実現する主要な業務、主要なパス
動くもの(実装)で置き換えられる部分
インセプションデッキと対応させてみる
2.エレベータピッチコンテキスト図・要求を使ってシステムの目的や狙いを伝える
1.我々はなぜここにいるのかシステムの外部環境とシステム境界を説明し何を実現するためにいるのかを
説明
3.パッケージデザインキーとなる主要なシステム境界(画面、イベント)を使って、要求とつなげて価値を伝える
5.ご近所さんを探せ重要なアクターを業務フロー、ユースケースに関わるアクターから洗い出す。開発に関わるアクターは開発用のコンテキスト図を別途用意
対応しないもの4.やらないことリスト6.技術的な解決案を描く9.トレードオフスライダー10.何がどれだけ必要か
7.夜も眠れなくなるような問題トップダウン、ボトムアップで説明する中で「これだ!」と言えるものが無い…主要・重要の切り分けがついていない
8.期間を見極める4つの視点とマイルストーンを使って全体を把握しロードマップを明らかにする
モデルで考えるか 動くもので考えるか
考慮点・どこまで全体を俯瞰する必要があるのか・モデルで考えるのが早いか動くもので考える方が早いか・そのプロジェクトにとってHowを考えることが重要か否か・革新的か否か(実物を見ないと判断できない)~
図で考える 動くもので考える
表現方法
フォーカス
関心 What What&How
モデル動くも
の
ポイント不可逆な時間の中で「今」何を行う必要があるのか
不可逆な時間の中で手戻りを減らすために「決めすぎず、決めなさすぎず」
不可逆な時間の中で手戻りをどう減らすか
制約
制約制約
次の作業は前の制約の中で考えるシステム価値システム価値
もの サービス利害関係者
ユーザ
要求価値
外部システム
システム外部環境
システムシステム
機能データ
機能
システム境界
システム価値
システム外部環境
システムシステム
システム境界
システム価値
システム外部環境
システムシステム
システム境界
システム価値
システム外部環境
システムシステム
システム境界
システム価値
システム外部環境
システムシステム
システム境界
制約を作りこむ・4つの視点には依存関係がある・4つの視点と制約を合わせる・一度に決めない 徐々に洗練化する・力点を明確にする
RUPに対応させてみる
A B C D E
A B C D E
RDRA
方向づけ・推敲内の4つのイテレーション(A~D)で活用各々の要求・分析にRDRAのモデルを重点を変えながら対応させる
A B C
D
マイルストーン毎の力点の移動 (既存システムの再構築例)マイルストーン1 マイルストーン2
最重点モデル
最重点モデル
マイルストーン4
最重点モデル
網羅性
整合性
マイルストーン3
サブシステム分割
システム価値 システム外部環境 システム境界 システム
コンテキスト
利用シーン
業務
イベント プロトコル
ユースケース
概念
画面・帳表
機能
ドメイン
データ
要求
機能複合モデル
利用シーン&UC
業務&UC
UC&画面
UC&機能
関係ダイアグラムシステムの地図
A- 32
ここまでできたら開発に移行する具体的に対象を指し認識を合わせられることが重要
制約
制約制約
本日のまとめ
A- 33 システム
不可逆な時間の中で手戻りを減らす
4つの視点で制約を作りこむ
RDRA• 視点の異なる情報をつなげて素早く要件を決める• 全体視点で合意するべきところを明示し反復開発に
つなげる• システムの地図で全体を管理する
作業領域で制約を作りこむ
ビジネスキャンバスでビジネスモデルのポイントが示される
おまけ1ビジネスキャンバスからつなぐ
34
ビジネスモデルキャンバス
A-35
問題はここからどうシステム化するか
コスト構造 収益の流れ
パートナー
顧客セグメント
価値提案
リソース
主要活動
チャネル
顧客との関係
ビジネスモデルジェネレーションより
コスト構造 収益構造
パートナー
顧客セグメント
価値提案
リソース
主要活動
チャネル
顧客との関係
登場人物もの・サービス
配送手段決済手段
アクター外部システム
業務フロー・ワークフロー利用シーン
ビジネスキャンバス
RDRA
ビジネスモデル図
バリエーションの組み合わせから細かな条件が整理される
バリエーション分析
システム化の目的要求
概念
ビジネスキャンバスからRDRAモデルへ
ビジネスキャンバスから具体的なビジネスルールを導き出す
ビジネスキャンバスに対応するモデル
会社顧客
入金
商品
注文
請求
仕入先
コンテキスト
業務 プロトコル
ユースケース
画面・帳表
ドメイン データ
要求
イベント
概念
情報
情報
情報
商品
コスト構造 収益の流れ
パートナー
顧客セグメ
ント
価値提案
リソース
主要活動
チャネル
顧客との関係
バリデーション分析
モデルを使って具体的に分析する
保守で使えるモデル
視覚的なトレーサビリティを実現する
おまけ2トレーサビリティを確保したモデル
A-38
RDRA RDRA保守用
開発のV字モデル
変更の影響度を測る トレーサビリティ
変更
影響
影響
影響影響
影響
影響
影響
影響
実装としてのつながりを視覚化
A-40
画面 機能 データ
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-41
システム価値 システム外部環境 システム境界 システム
コンテキスト
利用シーン
業務
イベント プロトコル
ユースケース
概念
画面・帳表
機能
ドメイン
データ
要求
機能複合モデル
利用シーン&UC
業務&UC
UC&画面
UC&機能
トレーサビリティを手に入れるpkg 販売管理
DataModelView
<<table>>注文(Order)
(from 受発注管理(c))
<<table>>出荷/受領(inOut )
(from 出荷・受領・生産(m))
<<table>>パッケージ(package)
(from 出荷・受領・生産(m))
<<table>>割当(alloca t ion)
(from 受発注管理(c))
<<table>>請求(Invoice)
(from 受発注管理(c))
<<table>>手数料(comiss ion)
(from 受発注管理(c))
受注伝票
(from 見積受注管理)
注文(Order)
(from 受発注管理(c))
出荷納品伝票
(from 出荷納品管理)
売上請求伝票
(from 売上請求管理)
受発注管理(c)
(from データ)
出荷・受領・生産(m)
(from データ)
<<table>>製品
(from 製品(Product))
製品管理
(from マスタ管理)
出荷・受領(inOut )
(from 出荷・受領・生産(m))
支払い(Payment )
(from 受発注管理(c))
請求(Invoice)
(from 受発注管理(c))
<<table>>支払(Payment )
(from 受発注管理(c))
ここに入金用のビューを
置く
販売管理の主要パッケージ
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