[asin:B07STQZFBX:detail]

RDRAによる要件定義の実際

• RDRAで解決できる種々の問題点

  • 「何かが決まったようでいて、結局何も決まっていない」
  • 要件定義でありがち
  • 議論が空中戦に終始し、具体で議論しないとこうなる
  • 要点定義書という「成果物」の目的化
  • ウォーターフォール開発でありがち
  • こと要件定義においては成果物の完成はゴールではなく、何度も見直す必要がある
  • 仕様の辻褄が合わない
  • アジャイル開発でありがち
  • 重要な部分・価値を出せる部分以外の仕様が「なんちゃって仕様」
  • 繋がりだすと辻褄が合わなくなる
  • 共通認識ができない
  • 仕様確認が不十分なまま実装するので、テスト段階で問題が発覚しだし、開発スピードが落ちてくる

RDRAの活用場面

• ウォーターフォール/アジャイル両方に対応できる

  • 要件の作り込み具合の違い
  • 実装した仕様をRDRAモデルにフィードバックするか否かの違い

要件の作り込み具合の違い

• システム化範囲の合意

  • 業務 -> ビジネスユースケース -> ユースケース の3段階で詳細化、開発範囲の明示
  • できるだけ早い段階から開発に移行したい場合、ビジネスユースケースまではRDRAで洗い出し、以降の詳細化はユーザーストーリーマッピング等の技法を使うことも

• ビジネスルールの整理

  • バリエーション、条件を使ってビジネスルールの仕様化までRDRAで表現

• システムの整合性確保

  • 情報モデル、状態モデル、ユースケースの辻褄が合っていることを確認し、精度を高める

実装した仕様をRDRAモデルにフィードバックするか否かの違い

• 開発時に明らかになった詳細な仕様をRDRAにフィードバック

• 開発中盤の開発スピード低下に対応できる

  • 仕様全体を俯瞰
  • 新規開発分に関わる影響度を事前に把握

RDRAを活かす方法

議論の土台を作る

• 闇雲にヒアリングしても議論がブレて時間がかかるだけ

• 事前に手に入る資料と、間違っていてもよいので仮設をベースにRDRAモデルを作ってみて、それをもとにヒアリングを行う

  • はじめて聞くことでも知識がつながる
  • 誤解や勘違いがはっきりする
  • 空中戦ではなく具体的な議論ができるようになる
  • 重要なことを意識しながら進められる

RDRAモデルをコミュニケーションツールにする

• 有識者と議論しながらその場で作成し同時に確認するのが良い

開発後も維持し保守開発に役立てる

• 開発中も随時更新し最新の要件として維持する

• 開発終了後も保守開発時に活用できる

  • 影響範囲調査

RDRAはツールを使って初めて効果がでる

• アイコンのつながりで意味を表す表記法なので、ダイアグラム横断的なつながりを分析できること

  • PowerPoint
  • VBAマクロで分析できる
  • Enterprise Architect
  • SQLで分析できる

アイコンからつながりをたどる

• つながりを分析することで得られる洞察の例

  • 開発者が、開発担当のユースケースに関して実装すべきこと
  • ユースケース周辺のつながりを分析する
  • 情報のライフサイクル
  • 情報につながっているユースケースを分析する
  • アクターの責務に沿った業務になっているか
  • アクターとアクティビティのつながりを分析する

要件定義を分析的にすすめる

• 要件定義の変更は整合性をとりながら進めていく必要がある

• アイコン同士のつながりを管理し、影響度を把握しながら進めるにはツールの支援が欠かせない

  • 【所感】アプリケーションコードに対するテストコードにような感じ。安心して変更を行えるようにする