プログラマの思索

RDRAセミナーが1/24(土)に開催されるのでメモ。

【元ネタ1】
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナー - アジャイルウェア | Doorkeeper

(引用開始)
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナー

＜日時＞

2015/1/24（土）13:30?17:00（13:00開場）

＜会場＞

NSE 梅田店B
大阪市北区曽根崎2-5-10 梅田パシフィックビル6階

＜協賛＞

株式会社アジャイルウェア

＜セッション概要＞

モデルベースの要件定義を体験します。
システムの全体像を短時間でつかみ、要件を組み立てるためのモデリングをご紹介します。

要件を組立るための考え方を知ると要件定義がさくさく進みます。

１時間のレクチャーに続きグループ作業で要件定義のモデリングを行います。
EAを持っている方はEAで、持っていない方はRDRA用のツールを使って作成します。

内容は「モデルベース要件定義テクニック―要件定義書がスラスラ作れる」のエッセンスになります。

要件定義に興味のあるかたはお気軽にご参加ください。

※参加者にはRDRAツール(ベータ版)を差し上げます。

＜講演者＞

神崎 善司 (かんざき ぜんじ)
株式会社バリューソース
(引用終了)

【元ネタ2】
既存システムを分析するコツは「システムの地図」を作ること （1/3）：CodeZine

UMLを使った既存システムの分析 （1/3）：CodeZine

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

【1】RDRA(リレーションシップ駆動要件分析の略)で注目する点は、UMLの各種ダイアグラムを使って、システム提案や要件定義の資料の元ネタを作れること。

システム提案や要件定義フェーズでは、現行の業務システムを洗い出し、新システムの要件や方式を決定する作業が多い。
この作業の技術的課題は、ゴールやスコープが定まらないと、いつまでやってもキリがないことだ。
だから、短時間で、広く浅く新システムの特徴を見極めて、後工程の作業へスムーズにバトンを渡すのが重要になる。

このフェーズの役割の人は、アーキテクトないしITコンサルタントと言われる人が多いだろう。
彼らは、自分の経験を踏まえて、自分なりの手法を身に付けているが、その手法は第三者に共有されていない。
だから、新人のアーキテクトはいつも苦労する。
この辺りの手法をもっと共有できないものか、といつも思っている。

【2】RDRAという手法が最上の解決策とは思わないが、一つの手法を提示していると考える。
個人的に気に入っているのは、UMLの各種ダイアグラムを使って、「システム価値」「システム外部環境」「システム境界」「システム内部」の4つの観点でシステムを分析する手法を提示している点だ。

システムには利害関係者が求める要求があり、それが「システム価値」になる。
システムの運用の立場では、業務フローや利用シーンがあり、それが「システム外部環境」になる。
もちろん、外部システム連携などの外部システムも含まれる。

また、ユーザとシステムの接点はユースケースだったり、画面・帳票などのユーザインターフェイス、外部システムの接続I/Fだったりする。
それらは、「システム境界」に相当する。

さらに、システム内部の機能へ詳細化すると、機能モデル・データモデル・ドメインモデルになり、それが「システム内部」になる。

つまり、「システム価値」「システム外部環境」「システム境界」「システム内部」の4つの観点で作られた成果物は相互にリンクしており、トレーサビリティを意識して作られている。
換言すれば、自分が今どのスコープの成果物を作っているのか、を常に意識させてくれるので、無駄な成果物を作る作業が省かれやすい。

RDRAを使った手法が使いやすい場面は、既存システムのリバース・エンジニアリングだろう。
広く浅くシステム要件を理解したい時に使えると思う。
「既存システムの調査分析はシステムの地図を作ることだ」という指摘は同意する。

【3】但し、いくつか注意点はある。
一つは、システム要件を広く浅く理解する時には役立つが、開発方式やアーキテクチャなどには触れていない点だ。
この点は、RDRAという手法の前提条件として、「方式は記述しない」と既に明示されている。

その理由は、既存システムの要件をリバースした後、新システムを作り直す場合、既存の開発方式をベースに作り直すケースは少ないし、既存の方式に囚われていては、新システムをリプレースする意味もないからだ。

しかし、新システムの方式設計を描きたい時もあるし、新旧のシステムのアーキテクチャを比較検討したい時もある。
その場合は、他の手法を使うしか無いだろう。

もう一つは、RDRAの成果物の粒度を決めにくい点だ。
RDRAの成果物は顧客に提出する資料とは別であり、資料の元ネタになるものと位置づけられている。
だから、広く浅く作るために、粒度はおおまかになりやすい。
ある程度の詳細化は必要だろうが、要件を詳細化し始めると、後工程の作業に入ってしまうので、要件定義のゴールやスコープからずれてしまう。

その意味では、粒度をどのレベルで落としこむか、というのは難しい所だと思う。

この辺りも実際のセミナーで聞いてみたいと思う。