Submit Search
What is RDRA
3 likes
1,465 views
Z
zenkan
リレーションシップ駆動要件分析の基本的な考え方を説明した資料です。 4つの視点から要件を分析するための考え方を示し、そこにUMLを当てはめる方法を示します。
Technology
Read more
1 of 9
1
2
3
4
5
6
7
8
9
More Related Content
PDF
Relationship driven requirement analysis
Kent Ishizawa
PDF
さくさく要件定義セミナー in 大阪
Zenji Kanzaki
PDF
DevLOVE発表資料
Zenji Kanzaki
PDF
モデルベース要件定義 at BPStudy
Zenji Kanzaki
PDF
Rdra in 東京
Zenji Kanzaki
PPSX
Rdra4越境アジャイル
Zenji Kanzaki
PDF
地図を片手にアジャイル開発
Zenji Kanzaki
PDF
越境アジャイル設立イベント:RDRA事例(BIGLOBE)
Zenji Kanzaki
Relationship driven requirement analysis
Kent Ishizawa
さくさく要件定義セミナー in 大阪
Zenji Kanzaki
DevLOVE発表資料
Zenji Kanzaki
モデルベース要件定義 at BPStudy
Zenji Kanzaki
Rdra in 東京
Zenji Kanzaki
Rdra4越境アジャイル
Zenji Kanzaki
地図を片手にアジャイル開発
Zenji Kanzaki
越境アジャイル設立イベント:RDRA事例(BIGLOBE)
Zenji Kanzaki
Viewers also liked
(10)
PPTX
プロフェッショナル要件定義の教科書』の内容が要件定義を考える上で大切だったのでまとめてみた
Ayumu Kohiyama
PDF
EC-CUBEユーザカンファレンス2016
Chihiro Adachi
PDF
Babokの4つの要求
akipii Oga
PDF
すくすくスクラム瀬戸内_要件定義の嘘_20100205
Sukusuku Scrum
PDF
要件定義すれば要求が理解できる、なんてことはない
Yusuke Suzuki
PDF
第74回名古屋アジャイル勉強会「後悔しない要件定義のまとめ方」
hiroyuki Yamamoto
PDF
Swift勉強会
Nagamine Hiromasa
PPTX
良いコードとは
Nobuyuki Matsui
PDF
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
PDF
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Yusuke Suzuki
プロフェッショナル要件定義の教科書』の内容が要件定義を考える上で大切だったのでまとめてみた
Ayumu Kohiyama
EC-CUBEユーザカンファレンス2016
Chihiro Adachi
Babokの4つの要求
akipii Oga
すくすくスクラム瀬戸内_要件定義の嘘_20100205
Sukusuku Scrum
要件定義すれば要求が理解できる、なんてことはない
Yusuke Suzuki
第74回名古屋アジャイル勉強会「後悔しない要件定義のまとめ方」
hiroyuki Yamamoto
Swift勉強会
Nagamine Hiromasa
良いコードとは
Nobuyuki Matsui
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Yusuke Suzuki
Ad
Similar to What is RDRA
(20)
PDF
基幹システムの可視化技法
Zenji Kanzaki
PDF
Rdra4 dddワークショップ
Zenji Kanzaki
PDF
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
Developers Summit
PDF
AI時代の要件定義
Zenji Kanzaki
PDF
プログラムの大海に溺れないために
Zenji Kanzaki
PDF
As-Isシステム分析は入出力から始めよ
Kent Ishizawa
PDF
要求モデル 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第42回】
Tomoharu ASAMI
PDF
Rdra2.0 redmine
Zenji Kanzaki
PDF
要求 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第12回】
Tomoharu ASAMI
PDF
要求/ユースケース 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第13回】
Tomoharu ASAMI
PDF
分析/イベント駆動 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第17回】
Tomoharu ASAMI
PDF
分析モデル 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第44回】
Tomoharu ASAMI
PDF
設計/UX/UI 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第29回】
Tomoharu ASAMI
PDF
設計/ドメイン設計(2) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第24回】
Tomoharu ASAMI
PDF
ユースケースからテスト駆動開発へ
Shuji Watanabe
PPT
要求分析20080824t
Wataru ONO
PDF
設計/アーキテクチャ設計 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第19回】
Tomoharu ASAMI
PDF
作業分野 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第10回】
Tomoharu ASAMI
PDF
行動計量シンポジウム20140321 http://lab.synergy-marketing.co.jp/activity/bsj_98th
Yoichi Motomura
PDF
テスト駆動開発のはじめ方
Shuji Watanabe
基幹システムの可視化技法
Zenji Kanzaki
Rdra4 dddワークショップ
Zenji Kanzaki
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
Developers Summit
AI時代の要件定義
Zenji Kanzaki
プログラムの大海に溺れないために
Zenji Kanzaki
As-Isシステム分析は入出力から始めよ
Kent Ishizawa
要求モデル 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第42回】
Tomoharu ASAMI
Rdra2.0 redmine
Zenji Kanzaki
要求 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第12回】
Tomoharu ASAMI
要求/ユースケース 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第13回】
Tomoharu ASAMI
分析/イベント駆動 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第17回】
Tomoharu ASAMI
分析モデル 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第44回】
Tomoharu ASAMI
設計/UX/UI 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第29回】
Tomoharu ASAMI
設計/ドメイン設計(2) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第24回】
Tomoharu ASAMI
ユースケースからテスト駆動開発へ
Shuji Watanabe
要求分析20080824t
Wataru ONO
設計/アーキテクチャ設計 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第19回】
Tomoharu ASAMI
作業分野 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第10回】
Tomoharu ASAMI
行動計量シンポジウム20140321 http://lab.synergy-marketing.co.jp/activity/bsj_98th
Yoichi Motomura
テスト駆動開発のはじめ方
Shuji Watanabe
Ad
What is RDRA
1.
「リレーションシップ駆動要件分析」は網羅的に整合性を保ちながら、システマティックに要件を定義する方法です。 Relationship
driven requirement analysis ⇒ RDRA
2.
要件定義には何を定義すればいいのか もの サービス
機能 データ 機能 機能 利害関係者 ユーザ 外部システム 業務 RDRA では「要件定義の対象をシステムとシステムを取り巻く環境」と考える システム 要件 定義書 システム システムを 取り巻く環境
3.
要件定義では何が定義されないといけないのか もの サービス
機能 データ 機能 機能 利害関係者 ユーザ 外部システム 業務 その機能が使用するデータは? システムに必要な機能は? その時の入出力情報は? システムとの接点は? どのような外部システムと関わるのか? どのような人に使われるのか? このシステムの目的(価値)は? システム
4.
要件定義の構造を定義する システム外部環境 外部システム
機能 データ 機能 機能 機能 データ 機能 システム価値 システム外部環境 システム境界 システム 要件定義の構造 もの サービス システム価値 もの サービス 利害関係者 ユーザ システム 利害関係者 ユーザ 外部システム システム システム境界
5.
システムの要件を得るためには システムの要件をまとめるとは ...
システム境界を明確にする必要がある システムの外部環境を把握する必要がある 対象業務の関係者と関係する外部システムを洗い出す システムに必要な機能とデータを定義する その外部環境がもつ価値や役割を定義する システム 外部環境 もの サービス 利害関係者 ユーザ 外部システム 機能 データ 機能 システム価値 システム システム境界 要求 価値
6.
システマティックに要件をまとめるために システム外部環境 もの
サービス 利害関係者 ユーザ 外部システム 機能 データ 機能 要件をシステマティックにまとめるためには、システム価値から、システム外部環境を定め、そこからシステム境界を明らかにし、それを実現する機能とデータを明確にする システム価値 システム外部環境 システム境界 システム システム価値 システム システム境界
7.
要件定義に整合性を持たせるためには 利害関係者、ユーザの要望、要求やもの、サービスなどの価値 システムの機能とデータ
システム価値 システム外部環境 もの サービス 利害関係者 ユーザ 外部システム システム システム境界 機能 データ 機能 要望 要求 価値 目的 整合性を維持してつなげる
8.
整合のとれた要件のつながり1 システム外部環境 もの
サービス 利害関係者 ユーザ 外部システム 機能 データ 機能 システムの価値を決めるためには ... 対象業務の関係者と外部システムを把握する。そして関係者の要望、要求からシステムの価値を明らかにする システムが使われる外部環境を明らかにするためには ... 上記関係者が関与する業務もしくは利用シーンを明らかにする システムが関わる部分を明らかにするためには ... 業務もしくは利用シーンでシステムが関わるところにユースケースをおき、そこに結びつくユーザインターフェース(画面、帳表)を明らかにする 外部システムに結びつくイベントを明らかにし、同時にイベント間のルールを明確にする システム価値 システム システム境界 要求 価値
9.
整合のとれた要件のつながり2 システム外部環境 もの
サービス 利害関係者 ユーザ 外部システム 機能 データ 機能 機能とデータを CRUD 表現で関係を洗い出す システムの機能とデータは ... ユースケースを実現する機能とデータを洗い出す イベントに対応するアクションを洗い出しそれを機能とする。 同時にそこで扱うデータも洗い出す 機能とデータの整合性は 要件を整合的にまとめるためには、システム価値から、システムまでを各情報をつなげながら定義します システム価値 システム システム境界 要求 価値
10.
要件定義の枠組み 1. 【
システムの価値 】 を捉える 対象業務に関わる人を洗い出す 関係する外部システムを洗い出す 要求を捉える 2. 【 システム外部環境 】 を捉える 対象業務の流れを捉える 対象業務に関わる概念を明らかにする システムの利用シーンを明らかにする 3. 【 システム境界 】 を捉える ユーザインターフェースを明らかにする 外部システムとのインターフェースを明らかにする 4. 【 システム 】 を定義する 機能を明らかにする データを明らかにする ドメインの構造を把握する システム価値 もの サービス 利害関係者 ユーザ 要求 価値 外部システム システム外部環境 システム 機能 データ 機能 システム境界
11.
システム価値を求め、そこからシステムの外部環境を定め、それにつなげる形でシステム境界を求め、最後にそのシステム境界を実現するシステムの機能とデータを持ち引き出す。 この考え方を実現する手段として UML
を拡張したモデルを利用する
12.
1.【システム価値】を捉える システム境界 コンテキストモデルを使い対象業務に関わる人と外部システムを洗い出す
要求モデルを使い関係者からの要求を洗い出す コンテキストモデル 要求モデル システムの価値はここで洗い出した人と外部システムにとっての価値を表す 要求を整理しシステムの価値を求める システム価値 システム外部環境 システム
13.
2.【システム外部環境】を捉える システム境界 アクティビティ図を使い業務フローを作成する
業務フローが書けないような場合はシステムを利用するシーンを洗い出す コンテキストモデルで洗い出したアクターと結びつける 業務上の概念をクラス図を使い整理する コンテキストモデルで洗い出したアクターと結びつける 利用シーンモデル 概念モデル システム価値 システム外部環境 システム 業務モデル
14.
3.【システム境界】を捉える part 1
システム境界 システム境界をユースケース図を使って洗い出す 業務モデルの中でシステム境界となるアクティビティにユースケースを結びつける ユースケースをユースケースモデルに集める 業務・ ユースケースモデル ユースケースモデル 利用シーンにユースケースを結びつける 利用シーン・ ユースケースモデル システム価値 システム外部環境 システム
15.
3.【システム境界】を捉える part2 システム境界
画面を画面モデルに集める 画面を使うものはユースケースに画面をつなげる 画面・帳表モデルをクラス図を使って表現する 画面モデル 画面・ ユースケースモデル 画面・帳表モデルを使って入出力情報を捉える システム価値 システム外部環境 システム
16.
3.【システム境界】を捉える part3
外部システム単位にイベントを整理する コンテキストモデルで洗い出した外部システム単位にイベントを導き出す 外部イベントのプロトコルをステートマシンを使って整理する イベントを遷移に結びつけイベントの整合性を保つ イベントモデル プロトコルモデル システム境界 システム価値 システム外部環境 システム
17.
4.【システム】を定義する part 1
ユースケースで使用する機能を捉える ユースケースを実現する機能をユースケースに結びつける ユースケース 機能モデル 機能モデル 機能モデルとして機能を整理する 機能を集めて機能モデルを作成する イベントに結びつく機能を捉える イベント& 機能モデル システム境界 システム価値 システム外部環境 システム
18.
4.【システム】を定義する part2 データモデル
ドメインモデル データを洗い出す ドメインを洗い出す 入出力情報やイベントの情報をからデータを求める 業務上扱うデータを構造化する システム境界 システム価値 システム外部環境 システム
19.
4.【システム】を定義する part3 機能を中心とした複合モデルを作成し内容を検証する
機能モデルから機能を持ってくる データモデル 機能モデル データモデル、ドメインモデルから持ってくる 機能複合 モデル 機能とデータのつながりをCRUDの文字で明示する システム境界 ドメインモデル システム価値 システム外部環境 システム
20.
システム価値からシステムまでの各モデルのつながりを理解する
21.
コンテキストモデルからシステム境界まで 1.対象業務に関わる人と外部 システムを把握する
コンテキストモデル 要求モデル 外部システム 人(アクター) システム 要求 要求 要求 2.下記関係者の要求を 把握する 4.業務の中でシステムが 関わる部分を把握する 3.業務を組み立てる 業務モデル 対象業務に関わる人と外部システムを要件定義の起点とする イベントモデル プロトコルモデル 5.外部システムとのイベントを 捉える 6.外部システムとの プロトコルを整理 同じように利用シーンからユースケースを導き出す
22.
ユースケースから機能、データまで システム 7.ユースケースに関わる
ユーザーインターフェーズ を洗い出す イベントモデル プロトコルモデル 8.ユースケースを実現 する機能を洗い出す 画面帳表モデル 機能モデル データモデル 9.アクションを機能に 対応付ける 画面・ ユースケースモデル ユースケースモデル 機能モデル システム境界 10.データを洗い出す 11.機能とデータ を付き合わせる 機能複合モデル
23.
システム価値 システム外部環境 システム境界
システム 全てのアクターが洗い出されているか 全ての外部システムが洗い出されているか 網羅性を確認する アクターが関わる主要な利用シーンが出されているか アクターが関わる全業務が洗い出されているか 外部システムと関わる全イベントが出ているか 関わるイベントが遷移として網羅しているか 業務、利用シーンに関わる全ユースケースは洗い出されているか 全ての入出力情報を満たすデータが洗い出されているか データのライフサイクルを満足する機能が洗い出されているか
24.
システム価値 システム外部環境 システム境界
システム アクターの要求が全て拾い出されているか 整合性を確認する アクターのロールと関わるシーンの関係がふさわしいか 利用シーン、業務フローで語られる概念の整理は終わっているか アクターのロールと関わる業務の関係がふさわしいか ユースケースに関わる主要な画面が出ているか 外部システムとの関わりが状態として全て洗い出されているか 業務、利用シーンとユースケースの関係は適切か データは必ず機能と結びついているか ドメインオブジェクトは必ず機能と結びついているか ユースケースは必ず機能と結びついているか アクションは機能として結びついているか
25.
RDRA全体像 UseCase UseCase
UseCase UseCase UseCase データモデル システム境界 イベント一覧 イベントルール化 入出力情報 業務フロー 業務に関わる概念 関心 イベント データ 情報 要求 各アクティビティでは概念にもとづいて作業を進める 機能モデル ユーザ 利害関係者 外部システム
26.
27.
リレーションシップ駆動要件分析の情報サイト http://k-method.jp <リレーションシップ駆動要件分析の情報サイト>
UML ツールの EnterpriseArchtect のテンプレートやプロファイルがダウンロード出来ます RDRA用テンプレート RDRA用プロファイル
28.
使用した UML ツール
http://www.sparxsystems.jp/ea.htm
29.
リレーションシップ駆動要件分析の詳細 顧客の要求を確実に仕様にできる 要件定義マニュアル
神崎 善司 ( 著 ) 出版社 : 秀和システム (2008/10/23) ISBN-10: 4798020990 ISBN-13: 978-4798020990 http://www.amazon.co.jp/dp/4798020990 詳しい情報は以下の本を参照
Editor's Notes
#2:
リレーションシップ駆動要件分析は網羅的に整合性を保ちながら、システマティックに要件を分析する手法です 以下この手法のことを RDRA と呼びます。 これは Relationship driven requirement analysis から来ています