RDRAについて学んだことのメモ

何となく最近見かけることが増えたRDRAについて少し勉強してみたのでメモを残しておきます。何回かシリーズになるかもしれません。また、原典の書籍？にはまだ手を出していません。ネットでわかる範囲で。

リレーションシップ駆動要件分析(RDRA) - Qiita

まずはネットで検索したこちらの記事を参考にしてみます。

リレーションシップ駆動要件分析(RDRA)とは、要件定義において重要なこれらの３要素を高いレベルで実現するための要件分析フレームワークです。

要件定義のためのフレームワークなのですね。要件分析と要件定義の言葉の違いはまだちょっと理解できていませんが、そのうち明らかになるのでしょう。名前から推測するに、関係性が大事ということのようですね。何と何の関係性なんだろう。わくわく。

RDRAでは要件定義を4つの構成要素に分け、UMLを拡張した表現方法で要件分析を行います

構成要素が4つあり、UMLを拡張する。なるほど。仕様についての**MLというとSysMLが思い浮かぶのですが何か明らかに違う点があるのでしょう。どこまで形式化しているかわかりませんが、もしかしたらMBTにもつながったりするのかな。

RDRAでは、要件定義の構成要素として「システム価値」「システム外部環境」「システム境界」「システム」の4つを定義します。

4つとはこれらですね。ちょっと意外でした。システムの中を分けるのかと思ったら、システムは一つでその外（と境界）を分割するのですね。間違っていることを承知の上でこの時点で発言してみると、システム価値はざっくり言うといわゆる「要望」のようなもので、システム外部環境は制約に近いものかなぁ、と。システム境界はシステムの外部IFになるのでしょう。

システム価値では、システムと関係する人や外部システムを捉え、要求を明らかにします。
ここではコンテキストモデルと要求モデルを考えます。

要求を明らかにします、ということなので上の推測は一部正しかったようですね。記法はコンテキストモデルと要求モデル、とのことです。コンテキストモデルというものを使ったことがないのですが、誰が関わるのかを明らかにするためのモデルでしょうか。要求モデルは要望から要求への細分化に見えます。

システム外部環境では、システムを取り巻く環境(業務や作業)を明らかにします。
ここでは、業務モデルまたは利用シーン、概念モデルを考えます。

業務モデルはアクティビティ図に類似していると思われます。この時点では、システムとの相互作用というわけではなく、やりたいことを実現するための流れを純粋に書くのだと思われます。自動車業界にいるので、「業務」と言われるとエンプラかな、と思ってしまいますが特にそういう意図はないと理解しています。

システム境界では、システムとの接点を明らかにします。
アクターと関わるものがユーザーインターフェース、外部システムと関わるものがシステムインターフェースとなります。
ここでは、ユースケースモデル、画面・帳票モデル、イベントモデル、プロトコルモデルを考えます。

ここでユースケースが出てくるんですね。画面・帳票はGUI仕様とかが該当するでしょうか。システム外部環境から、システムのすぐ外という切断面で切ったものと理解するのが良いでしょうか。

ここまででシステムに必要な前提条件が揃ったので、システムの機能とデータを明らかにします。
ここでは、機能モデル、データモデルを考えます。

ここまでで明らかになったシステムの要件を実現するための機能とデータモデルを考える、ということです。ここは部分的に内部の話になりますね。

そして、これらのモデルが相互に関係をして、要件定義のモデルが完成する、というのがRDRAの全体像とのことです。

段階的にシステムに肉薄している感じは理解しやすそうだな、という感覚と、すべてモデルで表現するというところは後につながりそうなのでよさそうだな、という気がしています。もう少し他の記事もよんでみます。