Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
RDRA for DDD
短期間にシステムの全体像をつかむ
2017/4/12
1
わたしは…
 ㈱バリューソース
 代表取締役 社長
 神崎 善司
 zkanzaki@vsa.co.jp
 要件定義の散歩道:https://www.facebook.com/youkennotsubo
 twitter:@zenz...
なんでこうなるのか?
RDRAができた背景
XXX
XXXX
XXXXX
XXXXX
XXXX
XXXXX
XXXXX
XXXXX
AAAAA
AAAAA
AAAAA
AAAAA
AAAAA
日付
担当者A
担当者B
担当者B
担当者A
タスク...
RDRA for DDDのスタンス
4
RDRAとドメインモデルの関係
 RDRAは本来開発方法を選ばない Howは扱わない
 RDRA for DDDのスタンス
 深い分析は開発側(ドメインの分析)に任せ、RDRAは整合のとれた要件を定義することに徹する
 RDRA 広く浅...
RDRAで枠組みを決める
6
 RDRAの役割
 構成要素の洗い出し 深い分析のための構成要素を洗い出す
 スコープ決め 構成要素をつなげスコープを見極める
 分類 コンテキストの見極め、業務分類の見極め
全体の枠組みを押さえながら進め...
要求側・開発側
7
 通常中規模以上のプロジェクトでは要求側(情シス)と開発側(ベンダー)は分かれる
 契約形態やスキルセットなどの要因で別れる
要求側 開発側
要件定義
開発計画 プロト プロト
構築
分析
設計
実装
テスト
分析
設計...
要件と開発の両輪でまわす
 要件定義と開発の両輪で回す
 要求側 ⇒ RDRAの構成要素を洗い出し、分類とスコープを識別する
 開発側 ⇒ 中核となる概念を中心に深い分析を行う
 2つのチームが外側と内側から並行して進める
開発
要件定...
RDRAとは
RDRA:Relationship driven requirement analysis
要件定義の仕組み
9
要件定義には何を定義すればいいのか
システム
もの
サービス
機能
データ
機能
機能
利害関係者
ユーザ
外部システム
業務
RDRAでは「要件定義の対象をシステムとシス
テムを取り巻く環境」と考える
システムを
取り巻く環境
システ
ム
要...
要件定義では何が定義されないといけないのか
システム
もの
サービス
機能
データ
機能
機能
利害関係者
ユーザ
外部システム
業務
•その機能が使用するデータは?
•システムに必要な機能は?
•その時の入出力情報は?
•システムとの接点は?...
もの
サービス
システム価値
もの サービス
利害関係者
ユーザ
要件定義の構造を定義する
システム外部環境
外部システム
システム
機能
データ
機能
機能
利害関係者
ユーザ
外部システム
システム
システム境界
機能
データ
機能
•シス...
システム価値
もの サービス
利害関係者
ユーザ
要求
価値
外部システム
要件分析の枠組み 構成要素
1.【システムの価値】を捉える
•対象業務に関わる人を洗い出す
•関係する外部システムを洗い出す
•要求を捉える
2.【システム外部環境】を...
コンテキストモデルからシステム境界まで
1.対象業務に関わる人と外部
システムを把握する
class システムコンテキスト
業務名
<<システム>>
Xxxxシステム
システム主体者1
システム主体者2
システム主体者3
システム主体者4
業務...
ユースケースから機能、データまで
システム
7.ユースケースに関わる
ユーザーインターフェーズ
を洗い出す
uc ユースケース
XxxxをYyyyする
XxxxをWwwwする
UuuuをLlllする
システム主体者1
システム主体者2
システム...
システム価値 システム外部環境 システム境界 システム
UC:ユーケース
全ての情報をつなげる
コンテキスト
利用シーン
業務
イベント
ユースケース概念
画面・帳表
機能
データ
要求
機能複合
モデル
利用シーン
&UC
業務&UC
状態
...
各要素がつなげる
17
画面
ユースケース
機能
データ・
ドメイン
外部システム
イベント
要求
関係が整合性、網羅性を確保する
システム地図の構成要素
利用シーン
システム価値 システム外部環境 システム境界 システム
UC:ユーケース
RDRA for DDD
コンテキスト
利用シーン
業務フロー
イベント
機能複合モデル
要求
状態
プロトコル
オプション
オプション
UC
情報
or
情報
画面
イ...
要求側と開発側でのモデルイメージ
19
 要求側:広く浅く分析するためのモデル
 開発側:深く分析するためのモデル
要件定義 受入テスト
開発計画 プロト プロト 分析
設計
実装
テスト
分析
設計
実装
テスト
分析
設計
実装
テスト...
RDRA for DDD システム地図
要件としての整合性、網羅性を確保する
システム地図の構成要素
画面
ユースケース
情報
外部システム
イベント
利用シーン
20
要求側と開発側の関わりイメージ
21
 開発側のイテレーションに要求側メンバーが関わる
 イテレーション毎の分析で要求側メンバーと深く分析する
分析
要求側と開発側の密な
コミュニケーション
シナリオ
状態遷移図
ドメインモデル
要件定義
...
RDRA for DDDの適用
22
変化に耐えられる軸
 軸があれば変化してもぶれない
 要件定義 軸:RDRA 広く浅い分析
 開発 軸:ドメインモデル コンテキスト単位の深い分析
開発
要件定義
プロト非機
能要
求
プロト プロト
構築
分析
設計
実装
分析
設計
...
網羅は全てを洗い出すことではない
24
 網羅性が必要な理由
 ✖ 詳細な一覧ができたら開発できる
 ○ 全体を俯瞰できる主要な構成要素が見えたら開発を開始できる
開発
要件定義
非機能要求
アーキテクチャ構築
Or
先行開発
構築
受入...
RDRAで要件の整合を維持する
開発
要件定義
計画 プロト プロト
アーキテクチャ構築 Or 先行開発
構築
分析
設計
実装
テスト
分析
設計
実装
テスト
分析
設計
実装
テスト
分析
設計
実装
テスト
分析
設計
実装
テスト
受...
まとめ
26
頭のなかを可視化
RDRA for DDD
の構成要素
画面
ユースケース
情報
外部システム
イベント
利用シーン
メンバーの頭の中を可視化し、
統一した要件としてまとめる
27
RDRAの弱点
 ビジネスルール、シナリオを整理する枠組みが未整理
開発
要件定義
プロト非機
能要
求
プロト プロト
構築
分析
設計
実装
分析
設計
実装
分析
設計
実装
分析
設計
実装
分析
設計
実装
受入テスト非機能要求
ス...
ビジネスルールの整理の手順
シナリオの洗い出し
29
RDRA ワークショップ 2017/4/18
2時間でシステム地図を作成する
やっぱり手を動かさないとわからない
30
Upcoming SlideShare
Loading in …5
×

Rdra4 ddd

2,629 views

Published on

DDD向けにカスタマイズしたRDRA

Published in: Engineering
  • Hello! High Quality And Affordable Essays For You. Starting at $4.99 per page - Check our website! https://vk.cc/82gJD2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Rdra4 ddd

  1. 1. RDRA for DDD 短期間にシステムの全体像をつかむ 2017/4/12 1
  2. 2. わたしは…  ㈱バリューソース  代表取締役 社長  神崎 善司  zkanzaki@vsa.co.jp  要件定義の散歩道:https://www.facebook.com/youkennotsubo  twitter:@zenzengood  要件定義手法の開発  RDRA Relationship driven requirement analysis  普段は  システム企画・要件定義などの支援  既存システムの可視化支援  セミナー開催(要件定義、モデリング)  要件定義用ツールの開発 2
  3. 3. なんでこうなるのか? RDRAができた背景 XXX XXXX XXXXX XXXXX XXXX XXXXX XXXXX XXXXX AAAAA AAAAA AAAAA AAAAA AAAAA 日付 担当者A 担当者B 担当者B 担当者A タスク 担当者 この方向に圧縮 する思考になる 変更の影 響が大きい 早い段階から個人 ワークが始まる 辻褄が合っていない 大量のドキュメント 誰も説明 できない 要件を変えたくて もどこに影響が出 るか分からない 要件定義の途中 から要件が変え られなくなる
  4. 4. RDRA for DDDのスタンス 4
  5. 5. RDRAとドメインモデルの関係  RDRAは本来開発方法を選ばない Howは扱わない  RDRA for DDDのスタンス  深い分析は開発側(ドメインの分析)に任せ、RDRAは整合のとれた要件を定義することに徹する  RDRA 広く浅く分析  ドメイン分析 深く分析 ガツンと中心となる概念 をつかんで、育てていく RDRA Domain RDRAが外から攻め ドメインモデルが中核から攻める ドメインモデル RDRA 広く網を張り徐々に固めていく 5
  6. 6. RDRAで枠組みを決める 6  RDRAの役割  構成要素の洗い出し 深い分析のための構成要素を洗い出す  スコープ決め 構成要素をつなげスコープを見極める  分類 コンテキストの見極め、業務分類の見極め 全体の枠組みを押さえながら進める RDRAで外枠を固めて安定したサイクル (タイムボックス)が回るようにする タイムボックスで育てていく
  7. 7. 要求側・開発側 7  通常中規模以上のプロジェクトでは要求側(情シス)と開発側(ベンダー)は分かれる  契約形態やスキルセットなどの要因で別れる 要求側 開発側 要件定義 開発計画 プロト プロト 構築 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト プロト 継続的インテグレーション 受入テスト要求側 開発側 アーキテクチャ構築 Or 先行開発 フィード バック プランニング のベース • 要件を固めるまでに試行錯誤がある • ステークホルダーの意見調整に時間がかかる • 多くの場合要求側はソフトウェアエンジニアに 慣れていない • 決まったことを教えてほしい • 情報の詳細度ではなく決めたことを教えてほしい
  8. 8. 要件と開発の両輪でまわす  要件定義と開発の両輪で回す  要求側 ⇒ RDRAの構成要素を洗い出し、分類とスコープを識別する  開発側 ⇒ 中核となる概念を中心に深い分析を行う  2つのチームが外側と内側から並行して進める 開発 要件定義 計画 プロト プロト 構築 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 受入テスト プロト 継続的インテグレーション 要求側 (情シス) 開発側 8 RDRA ドメインモデル
  9. 9. RDRAとは RDRA:Relationship driven requirement analysis 要件定義の仕組み 9
  10. 10. 要件定義には何を定義すればいいのか システム もの サービス 機能 データ 機能 機能 利害関係者 ユーザ 外部システム 業務 RDRAでは「要件定義の対象をシステムとシス テムを取り巻く環境」と考える システムを 取り巻く環境 システ ム 要件 定義書 10
  11. 11. 要件定義では何が定義されないといけないのか システム もの サービス 機能 データ 機能 機能 利害関係者 ユーザ 外部システム 業務 •その機能が使用するデータは? •システムに必要な機能は? •その時の入出力情報は? •システムとの接点は? •どのようにシステムは使われるのか? •どのような人、外部システムと関わるのか? •このシステムの目的(価値)は? 11
  12. 12. もの サービス システム価値 もの サービス 利害関係者 ユーザ 要件定義の構造を定義する システム外部環境 外部システム システム 機能 データ 機能 機能 利害関係者 ユーザ 外部システム システム システム境界 機能 データ 機能 •システム価値 •システム外部環境 •システム境界 •システム 要件定義の構造 12
  13. 13. システム価値 もの サービス 利害関係者 ユーザ 要求 価値 外部システム 要件分析の枠組み 構成要素 1.【システムの価値】を捉える •対象業務に関わる人を洗い出す •関係する外部システムを洗い出す •要求を捉える 2.【システム外部環境】を捉える •対象業務の流れを捉える •対象業務に関わる概念を明らかにする •システムの利用シーンを明らかにする 3.【システム境界】を捉える •ユーザインターフェースを明らかにする •外部システムとのインターフェースを明 らかにする 4.【システム】を定義する •機能を明らかにする •データを明らかにする •ドメインの構造を把握する システム外部環境 システム 機能 データ 機能 システム境界 利用 シーン 13
  14. 14. コンテキストモデルからシステム境界まで 1.対象業務に関わる人と外部 システムを把握する class システムコンテキスト 業務名 <<システム>> Xxxxシステム システム主体者1 システム主体者2 システム主体者3 システム主体者4 業務主体者5 外部システム コンテキストモデル 要求モデル 外部システム 人(アクター) シス テム 要求 要求 要求 2.下記関係者の要求を 把握する 4.業務の中でシステムが 関わる部分を把握する 3.業務を組み立てる uc ユースケース XxxxをYyyyする XxxxをWwwwする UuuuをLlllする システム主体者1 システム主体者2 システム主体者3 システム主体者4 KkkkkをXする OをOnnnnする 業務モデル 対象業務に関わる人と外部シス テムを要件定義の起点とする イベントモデル プロトコルモデル 5.外部システムとのイベントを 捉える 6.外部システムとの プロトコルを整理 同じように利用シーンから ユースケースを導き出す 14
  15. 15. ユースケースから機能、データまで システム 7.ユースケースに関わる ユーザーインターフェーズ を洗い出す uc ユースケース XxxxをYyyyする XxxxをWwwwする UuuuをLlllする システム主体者1 システム主体者2 システム主体者3 システム主体者4 KkkkkをXする OをOnnnnする イベントモデル プロトコルモデル 8.ユースケースを実現 する機能を洗い出す custom 画面モデル <<画面>> 商品登録画面 - 商品名 - 取引先 - 荷姿 - 発注単位 - 商品カテゴリ <<画面>> 販売状況照会 - 月 - 商品カテゴリ <<画面>> 発注登録 - 商品 - 発注日 - 発注数量 - 入荷予定日 <<画面>> 商品説明 - 商品カテゴリ <<画面>> カート処理 - 受注番号 <<画面>> 受注照会 - 顧客名 - 受注日 商品売上詳細 - 商品 - 売上数量 - 売上金額 詳細説明 - 商品説明 カート内商品 - 商品 - 数量 <<画面>> 決済処理 - 顧客名 - 住所 - 決済方法 受注商品 - 商品 - 受注数量 画面帳表モデル act 機能モデル <<function>> Uuuu機能 <<function>> Zzzz機能 <<function>> Xxxx機能 <<function>> Yyyyy機能 機能モデル act 機能モデル <<function>> Uuuu機能 <<function>> Zzzz機能 <<function>> Xxxx機能 <<function>> Yyyyy機能 class データモデル2 <<datamodel>> AAAXxxx - xxx11: int - xxx12: int - xxx13: int Xxxx <<datamodel>> AAAXxxx1 - x1xx11 - x1xx12 - x1xx13 <<datamodel>> AAAYyyy - yyy1 - yyy2 - yyy3 Uuuu - uuu1 - uuu2 - uuu3 <<datamodel>> AAAJjjj - jjj1 - jjj2 - jjj3 <<datamodel>> AAAOooo - eeee1: int - eeee2: int - eeee3: int Xxxx <<datamodel>> AAAXxxx2 - x2xx1 - x2xx2 - x2xx3 Xxxx Xxxx3 - x3xx1 - x3xx2 - x3xx3 データモデル 9.アクションを機能に 対応付ける 画面・ ユースケースモデル ユースケースモデル 機能モデル システム境界 10.データを洗い出す 11.機能とデータ を付き合わせる 機能複合モデル 15
  16. 16. システム価値 システム外部環境 システム境界 システム UC:ユーケース 全ての情報をつなげる コンテキスト 利用シーン 業務 イベント ユースケース概念 画面・帳表 機能 データ 要求 機能複合 モデル 利用シーン &UC 業務&UC 状態 UC&画面 UC&機能 プロトコル 16
  17. 17. 各要素がつなげる 17 画面 ユースケース 機能 データ・ ドメイン 外部システム イベント 要求 関係が整合性、網羅性を確保する システム地図の構成要素 利用シーン
  18. 18. システム価値 システム外部環境 システム境界 システム UC:ユーケース RDRA for DDD コンテキスト 利用シーン 業務フロー イベント 機能複合モデル 要求 状態 プロトコル オプション オプション UC 情報 or 情報 画面 イベント 「システム境界」の詳細化と「システ ムの分析」は開発側に任す 18 データではなく情報 ユースケースを安定させるた めに「情報」を活用 状態遷移をユースケース に対応させてもよい 業務フローか 利用シーンの どちらか 業務フローか利用シーンご とに機能複合モデルを作る 情報の構造化 はしなくてよい、 構造化はドメイ ンモデルで行う 現場で認識して いる状態を明示 することが大事 ビジネスユースケー スと捉えてもよい
  19. 19. 要求側と開発側でのモデルイメージ 19  要求側:広く浅く分析するためのモデル  開発側:深く分析するためのモデル 要件定義 受入テスト 開発計画 プロト プロト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト プロト ドメインロバストネス図 機能連携図 UC 状態 状態遷移図 コンテキスト 業務フロー 要求 利用シーン ビジネスルール XXXXX XXXXXX XXXXXX XXXXX XXXXXX XXXXXX シナリオ XXXXX XXXXXX XXXXXX XXXXX XXXXXX XXXXXX シナリオ 要求側 開発側
  20. 20. RDRA for DDD システム地図 要件としての整合性、網羅性を確保する システム地図の構成要素 画面 ユースケース 情報 外部システム イベント 利用シーン 20
  21. 21. 要求側と開発側の関わりイメージ 21  開発側のイテレーションに要求側メンバーが関わる  イテレーション毎の分析で要求側メンバーと深く分析する 分析 要求側と開発側の密な コミュニケーション シナリオ 状態遷移図 ドメインモデル 要件定義 開発計画 プロト プロト 構築 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト プロト 継続的インテグレーション 要求側 設計・実装・テスト 開発側 要求側 開発側 受入テスト フィードバック 要件の深堀
  22. 22. RDRA for DDDの適用 22
  23. 23. 変化に耐えられる軸  軸があれば変化してもぶれない  要件定義 軸:RDRA 広く浅い分析  開発 軸:ドメインモデル コンテキスト単位の深い分析 開発 要件定義 プロト非機 能要 求 プロト プロト 構築 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 受入テスト非機能要求 要件定義の軸 開発の軸 23
  24. 24. 網羅は全てを洗い出すことではない 24  網羅性が必要な理由  ✖ 詳細な一覧ができたら開発できる  ○ 全体を俯瞰できる主要な構成要素が見えたら開発を開始できる 開発 要件定義 非機能要求 アーキテクチャ構築 Or 先行開発 構築 受入テスト ~ 計画 主要な構成要 素が見えた 計画 計画 計画 計画 計画 計画 計画 開発イテレー ションスタート 一覧
  25. 25. RDRAで要件の整合を維持する 開発 要件定義 計画 プロト プロト アーキテクチャ構築 Or 先行開発 構築 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 受入テスト プロト RDRAが開発のタイムボックスを回していく地図となる 広く浅く分析 深い分析 25
  26. 26. まとめ 26
  27. 27. 頭のなかを可視化 RDRA for DDD の構成要素 画面 ユースケース 情報 外部システム イベント 利用シーン メンバーの頭の中を可視化し、 統一した要件としてまとめる 27
  28. 28. RDRAの弱点  ビジネスルール、シナリオを整理する枠組みが未整理 開発 要件定義 プロト非機 能要 求 プロト プロト 構築 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 分析 設計 実装 受入テスト非機能要求 スムーズにイテレーショ ンを回すためにはビジ ネスルールの明確化が タイムリーに必要 28
  29. 29. ビジネスルールの整理の手順 シナリオの洗い出し 29
  30. 30. RDRA ワークショップ 2017/4/18 2時間でシステム地図を作成する やっぱり手を動かさないとわからない 30

×