【RDRA復習】サンプル「図書館システム」を写経してみる
RDRA（読み：ラドラ、Relationship Driven Requirement Analysis / リレーションシップ駆動の要件分析）というモデルベースの要件定義手法がある。10年ほど前に知ってからシステム開発で要件を分析する際に好んで使っていたが、ここ数年はゼロから要件定義する機会がなくモデリングすることも少なかった。
最近、要件定義の考え方について雑談する機会があったが手元に見せられるサンプルがなかったので、資料作成を兼ねてひさびさに描いてみた。良いお題がなかったので、RDRA2.0の書籍に掲載されている図書館を題材にしたサンプルを写経することにした。
なお、本記事のゴールはRDRAの解説ではなく、写経で作成したダイアグラム例を共有するのみとします。ほんの少しでも誰かの参考になれば幸いです。
補足）「写経」はプログラミングの文脈で既存のコードを手で書き写す学習方法のこと
RDRAとは（参考情報のみ）
RDRAは株式会社バリューソースの神崎善司さん（ @zenzengood ）により考案されたUMLベースの要件分析手法である。
ここでは説明しないが、参考情報のみ共有する。
「RDRA」Webサイト
書籍はAmazonで購入可能
お題
冒頭でふれた通り、写経のお題はRDRA2.0でサンプルとして掲載されている図書館とする。
ツール
書籍でも紹介されているモデリングツール「Enterprise Architect」（EA）を使う。
なお、EAのRDRAアドインを試したが好みではなかったのでUMLの組み合わせで表現した。
写経
説明ゼロだと伝わらないと思うので、各図ごとに簡単な概要と作図の目的（顧客と合意したいこと）を記載しておく。
ビジネスコンテキスト図
概要：
システムが使われる環境を明らかにし、トップダウンで分析するための「業務」とビジネスルールに関わる「ビジネス要素」を明示する。
合意したいこと：
・全体としていくつの業務があるか
・各業務の大きさは適当か、粒度がそろっているか
・ビジネス要素に不足はないか
システムコンテキスト図
概要：
関係者の認識を合わせるために「アクター」と「外部システム」からシステムのスコープを明示する。
合意したいこと：
・価値を提供するアクター、それを支援するアクター
・価値を提供する外部システム
・システム化の目的
要求モデル図
概要：
要求を整理して要件化し、システム化の方向性を明らかにする。
合意したいこと：
・システムで実現しなくてはいけない重要な要件
ビジネスユースケース図
概要：
業務をブレイクダウンした「ビジネスユースケース」（BUC）を洗い出す。BUCは価値を届ける単位で、UC複合図（業務フロー付き）や利用シーン図の記述単位とする。
合意したいこと：
・価値を提供する単位になっていること
・業務をBUCに分割する根拠、および根拠に従った分割であること
業務：会員登録
業務：貸出・返却
業務：蔵書管理
情報モデル図
概要：
現場で使われている用語の関係性を可視化する。
合意したいこと：
・システムの目的を達成するのに必要な情報が網羅されていること
補足：
中途半端にクラス図的な表現を使ったが、本来は不要（関連が明示できればOK）
バリエーション・条件図
概要：
ユースケースが情報を操作する際の「条件」を明らかにする。また、システムの複雑さを計る。
合意したいこと：
・ビジネス上の主要な条件が明示と、その軸となるバリエーションとその値
補足：
EAで表を書けなかったので、Excel画像をはりつけた
状態モデル図
概要：
用語（情報）の中で状態を表すものを構造化する。また、ユースケースが実現する状態の変化を明らかにする。
合意したいこと：
システム対象の状態が網羅されていること
遷移に対応するユースケースが全てUC複合図で表現されていること
補足：
状態とユースケースを「遷移」で接続できず、妥協案として「use」を利用した。
UC複合図（業務フロー付き）
概要：
BUC単位でユースケースを中心に業務フロー、画面、情報、条件などを紐づけ、システムが行うべきことを明示する。
合意したいこと：
・ユースケースにつながる入出力と情報の関係が妥当であること
BUC：窓口貸出
BUC：Web予約
BUC：返却
BUC：会員登録
BUC：期限管理
BUC：棚卸&書籍補充
RDRA2.0のサンプルに合わせて省略する。
雑感（主にモデリング時のメモや気づき）
- 情報モデル図は、次回はもう少し解像度をあげて概念モデル（概念マップ）として描きたい※1
- Enterprise Architectは柔軟性が高く異なるUMLダイアグラムの要素を混ぜて描けるが、RDRAアドインとUMLの要素間は「接続」ができなかったので今回はUMLを選択した※2
- UC複合図で情報を画面と関連づけていたが、教科書通り（情報はユースケースに関連づける）に正した
※1：書籍内ではモデリングスキルを不要とするために情報の関連の整理に留めている旨が説明されている
※2：UC複合図で、業務フローをスイムレーンで表現したくアクティビティ図を使ったが「アクション」とRDRAアドインの「ユースケース」が接続できず断念した
