[asin:B07STQZFBX:detail]

• 20年来、要件定義ではこうなりがち:

  • 要件定義工程なのに要件の変更ができない
  • 定義変更の影響範囲が見えないためにドキュメントの修正ができない
  • 必要な要件が漏れる
  • 不要な要件が残る
  • 結合試験になるまで要件の相互の関わりが見えてこない
  • アジャイルの名のもとに開発だけが先行して、半年もたたないうちに手戻り開発が増えて新規分の開発がままならなくなる

• 全体視点から相互の関係性を意識しながらモデリングを行うことでこれを克服する

  • 関係者が集まってその場でモデリングする

RDRA2.0とは

• RDRA1.0

  • システムの全体像を素早く整合性を保ちながら明確にする

• RDRA2.0

  • ダイアグラムのシンプル化
  • 軽く、最速で要件定義を行うことを目指す
  • 業務フロー、利用シーンを洗い出す方法の明示

  • ビジネスルールの記述方法の明示

    1.0を知らないので読み飛ばし

要件定義では何を定義するのか

• 要件は相互に依存する

  • この要求を実現するためにはこの仕事が必要
  • この仕事でシステムを使うからこのユースケースが必要
• 依存関係を使って素早くシステマティックに要件定義を行うのがRDRA

要件定義で定義するもの

• 会社秘伝のフォーマットを埋めることが要件定義ではない

  • システム側の記述に終始し、「Why」を欠きがち
  • 実運用が見えてこず、当然の結果として実運用に耐えないシステムができあがる
• 要件定義ではシステムの方向性を決め、具体的な仕様を決めるための材料を提供する必要がある

システム化仕様のための根拠を提供

• RDRAでは、システムと同時に、システムを取り巻く環境も記述する

  • 誰が何のためにこのシステムを使うのか
  • システム化対象の業務はどういうものか
  • システムとの接点になる入出力にはどういうものがあるのか
  • 【所感】ロバストネス分析でいう「バウンダリ」
  • 入出力を満足する情報は何なのか
  • 【所感】DOA的
  • システムで再現したい業務上の状態は何か

要件の構造: RDRAレイヤー

• 上記を整理したもの

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