要件定義手法”RDRA”について調べてみた

今日は、リレーションシップ駆動要件分析 ( RDRA ) -- Relationship Driven Requirement Analysys -- がどんなものか調べてみることにします。
＃ただ読んでても頭に入らないので、つっこみをいれながらまとめていきましょう、というのが今日の趣旨です。


まず、読み方ですが、”ラドラ”というらしいです。ネーミングはあまり好きではありません。上の方にサクッと聞きとってもらえる名前の方がよさそうですね。「リレーションシップ・・・の略で・・」と説明を続けても、説明が終わるまで「何のリレーションシップ？」と疑問がとれません。（私がそうだっただけで、みんなそうとは限りませんけど。）


ざくっと理解した特徴を述べると、

  • ビジネスシステムからソフトウェアシステムまで、視点を変えながら、一連の流れを関係を保ちながらモデリングしていく
  • 要件を多面的に定義していく。機能要件（処理とデータ）と非機能の両面から定義します

といったあたりでしょうか。


視点を変えながらモデリングしていく”視点”とは以下の４つの視点です。

  • システム価値
  • システム外部環境
  • システム境界
  • システム


それぞれについて、以下に説明します。
説明文は、私が OO 寄りの視点で斜め読みして解釈した内容なので、誤解があるかもしれません。。。

システム価値

何を定義するか
アウトプット

ステークホルダーと要求を”コンテキスト図”にアウトプット。
UMLのユースケース図に「ユースケース」でなく「要求」が定義されている状態。

特徴

よいと感じる点

  • 「何を」定義するのかが明確
    • ステークホルダーを明確に意識する
    • システムに対する要件を定義する前に、要求をきちんと分けて定義する
  • アウトプットが利用しやすい
  • 機能だけでなく非機能もモデリングツールで管理できる
    • 要求を構造化して定義されるため利用しやすい

よいとも悪いとも評価しかねる点

  • HOW は定義されていないように感じる
    • ステークホルダーの抽出方法、機能要求・非機能要求の抽出方法については定義されていないため、他の手法を組み合わせることが必要と思われる

課題と感じる点

  • 「システム」ありきでスタートしているように見える。新しい業務やBPRのように、システムをイメージできていない場合には、事前の企画でシステムをある程度イメージすることが必要という想定か。この考えには賛同できないな。「人はドリルが欲しいのではない、穴が開けたいのだ」という考えに毒されているのか、私は。それともこの手法のスコープを正しく理解していないのか。

システム外部環境

何を定義するか

「システム価値」（＝要求。慣れない言葉だし、必ずしもいい用語と思えないので、いちいち”要求”と言い換えちゃいます）を踏まえ、どのようなビジネスになるのかを定義する。
※ここでの「システム」は「ソフトウェア」という意味の「システム」

アウトプット
  • 業務フロー
    • UMLのアクティビティ図で作成。アクティビティ間でやりとりされる／アクティビティのI/Oとなるオブジェクトは菱形で書いてるのな。
    • 情報一覧（オプション）
    • データオブジェクトの一覧。クラス図でいいじゃん！という気もする。この粒度のクラスを定義してモデリングツールからレポート出力すればよさそう。
  • 利用シーンモデル
    • 「システム価値」が書かれたユースケース図に利用されるシーンをコメントで記入したもの。私なら、重要なものであれば、シーンごとに業務フロー作成して業務フローの一覧レポート出力するほうが好みだな、工数かかるけど。一覧性は、RDRAで採用している方法の方が上だし、簡単なものはこちらのほうが向いているかも。
  • 概念モデル
    • いわゆる概念モデルです。用語と概念の関係を整理します。なら、なおさら業務フローに登場させてデータと業務の整合性を確保するのがよいよね。
特徴
  • システムがどのようなコンテクストで使われるのか、業務をフローおよびデータの両面から整理する点は、通常のOO開発と同様。
  • フローと概念・モノの整合性をあまり気にしていないように見えて、この時点ではちょっと不安。後で整合性を確保するのかな？

システム境界

何を定義するか
  • システム化の範囲
  • システムとシステム外とのインターフェース
アウトプット
  • ユースケースモデル
  • 画面・帳票モデル
    • サンプルでは、<<画面>>ステレオタイプをつけたクラスを定義していて、違和感なし。
    • 主要な画面・帳票を抽出して、画面・帳票数を把握する
    • 画面・帳票の主要な項目を定義する
    • ユースケースと画面・帳票の紐付きを定義する
    • 画面レイアウトを定義するわけではない
  • プロトコルとイベント一覧
    • プロトコルは、UML のステートマシン図で定義。１回で完結するものは書く必要なし
    • イベント一覧は、コンポーネントが提供するインターフェースの一覧だと解釈したらよさそう

特徴

  • 画面・帳票の「数」把握は面白いかも
  • 見積りのインプットとなることを意識していて、実用的と思われる
  • 外部インターフェース、しかもプロトコルをきちんと定義しましょう、と手順に盛り込まれているのはエクセレント。項目の定義は誰も忘れないけど、プロトコルは忘れがちだと感じるので。

システム

何を定義するか
  • 「システム境界の中」（＝ソフトウェア）のデータ、機能（ふるまいではなく！）、ビジネスルール

※「システムの内部構造」という言葉を使っているけど、あくまでも「要件定義」なので、「境界の中」という意。

アウトプット
  • データモデル
    • UML のクラス図です。「処理量」といったメトリクスを定義しましょう、と書いてあるのは嬉しい
  • 機能モデル

特徴

  • 機能とデータのつながり、ソフトウェアの「機能」と外部に提供する「ユースケース」のトレーサビリティを確保する
  • より上流ではユースケースとドメインモデルの関連は意識しなかったのに、このタイミングでくっつけるので、「システム境界」を定義する人と「システム」を定義する人が違う人の場合は、難易度が高そう
  • ソフトウェアが管理するデータが加わり、基本設計〜統合テストの見積りに必要な情報はだいたい揃うのかな（ファンクションポイントでもユースケースポイントでも、類推でも見積りができそう）

全体を見て

  • やはり、「システムありき」で開始するように見える点が気にかかる。既にある「システムに対する要求」の聞きだしからはじめ、業務フローはそれを検証するだけのように見える
  • 「システムありき」で始められる場合には、期待値⇒業務⇒提供するサービス⇒システム内 と順を踏んで、視点を変えながら定義していきましょう、という考えはよいと思う
  • トレーサビリティを保つ意識が強い
  • 機能・非機能の両面を定義しましょう、というプロセスなのはよい（ HOW はないので補う必要あり？？）
  • 動的・静的な要件の整合性を最後に確保するが、途中で整合性が確保できていないので難易度が高いと思われる
  • コンパクトに見積りに必要な情報をだそうという要件定義手法のように感じる


向いているシチュエーションは、

  • システム像がある程度明確な場合に、
  • ユーザのシステム部門が（IT屋の補助を受けたりしながら）、
  • RFPよりもう少しシステムに突っ込んだところまで定義して、ベンダーが見積りを誤ったり、要求を勘違いしたりするリスクを減らすに十分な情報を
  • コンパクトに定義するのに向いている

という印象を受けた。