表形式のRDRA定義

表形式でダイアグラムを再現

ダイアグラムのような自由度は無いが素早く定義できる表形式でRDRAを定義する

複数のダイアグラムを以下のシートで実現する

表形式で構造化する

ダイアグラムは自由にアイコン間の関連を表現することができるが、表形式ではRDRAで必要な関連を同じ行に並べることで実現する。ダイアグラム方式は自由度が高いが、配置の問題が残る。表形式は制約が多いが定義に集中できるので定義が容易になる。

ユニークに管理するモデル毎にシートを分け、シート間で同じ名前の列は同じものと捉える。こうすることで情報のようなユニークに表現するものとUCに情報をつなげる

行とシート間で関連を表す

シート間の関係を以下に示す

アクターと外部システムを明らかにする 

最初にシステムに関わる人(役割)をアクターとして洗い出し、価値につながる外部システムを洗い出す。

アクターが思いつかない場合はシステムに関わる組織をアクターとみなしてもよい(後で変更する可能性あり)

価値につながる外部システムとは、ビジネス上の取引をシステム間連携で行う相手システムを外部システムと呼ぶ

業務とBUCを洗い出す 

システム対象の業務を洗い出し、その中で業務フローの単位をBUC(ビジネスユースケース)として洗い出す。

同じ業務でも関わるアクター、外部システムが異なると仕事の流れが変わるので、業務フローが変わりBUCが分かれます。

業務が不明な場合は組織(アクター)が行うことに名前を付けて一旦業務(後で見直す)とし、関わるアクターと外部システムの組合せから一旦BUCを洗い出す

情報と状態を洗い出す 

システム対象の業務が見えてきたので、ビジネスで扱う情報と状態を洗い出し、システムで管理すべきことを把握する

情報と状態はID単位に洗い出す。IDとは請求書番号や受注番号などビジネスで管理するためのキーとなるものを情報とする。その情報の変化を状態として扱い、管理したいことを明らかにする。

情報と状態シートのAカラムは各々を分類するコンテキストを記述し、両者のコンテキストの名前を合わせ、関連する情報と状態をまとめ、ビジネスの管理単位を明らかにする。

アクティビティ、UC、

アクター、外部システムを洗い出

業務、BUC、情報、状態が把握できると、スコープが明らかになるので、ここからは業務と情報をつなぐための組立を行っていきます。そのためにBUCで価値を届けるステップをアクティビティとして定義する。アクティビティでシステムを使う場合は同じ行のUC列にUC名を「XXXをYYYする」として洗い出す。

アクティビティ、UCに関わるアクター、外部システムを記述しBUCを駆動する対象を明らかにする。この過程でBUCの分割や統合を行い、業務、BUCの見直しを行いながら精度を上げていく。

表形式でのRDRA定義の場合は複雑なフローを想定しておらず、E列に「↓」を記述することで上から下に流れるフローを表現する。C列とE列に同じラベルを付けることで、簡単な分岐を表現できる。

UCに情報/画面/イベントをつなげる 

システムが行うことをUCに入出力と情報をつなげて表現する。

H列、J列のアクター、外部システム、情報に設定する名前は各シートで定義したものを使用する

条件とバリエーションを洗い出す 

ビジネスルールを条件とバリエーションで表現する。条件はBUCシート(H列)に記述し、アクティビティ、UCに条件をつなげてルールを表現する。

条件は消費税のような単独の式で表されるものや、バリエーションや状態の組合せで表現するものがあり、その関係を条件シートに記述する。バリエーションはアクターなどの様々なものを分類して管理するために用いる。

ビジネスの変化はバリエーションの値の追加、変更として現れることが多い。適切にバリエーションを洗い出せるとシステムの変更をパラメタ的に扱えるようになり保守性がよくなる。

状態にUCをつなげ情報間の関連を付ける 

システムが保持するものを情報として扱い、情報の変化を状態として扱うことでシステムが管理すべきことを明らかにする。「UCが情報を操作(BUCシート)することで状態を変える」と考える。UCがどの状態を変えるかを状態シートの遷移UC列に設定する。

この設定を行いながらBUCシートのUCを追加・削除し、UCと情報の関係を見直す