プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンクをメモ。

【参考】
「要件定義」の4つの構造と依存関係に着目した実践手法 （1/5）：CodeZine

要件定義工程の進め方 （1/4）：CodeZine

構造に沿って要件をUMLで具体的に定義する （1/3）：CodeZine

要件の精度を向上させる （1/3）：CodeZine

レビューを軸に駆動する （1/4）：CodeZine

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

既存システムを分析するための考え方と対処法 （1/5）：CodeZine

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

要件定義ツールを使った既存システムの分析 （1/4）：CodeZine

プログラムをマクロ（大域的）に分析する （1/3）：CodeZine

RDRA リレーションシップ駆動要件分析 | システム設計日記

Satohru Note: 要件開発の進め方～私のRDRA運用法～

[RDRA] - 神崎コンサルノート

【1】リレーションシップ駆動要件分析(RDRA)は、UMLの図を使って、要件定義を進める手法。
RDRAが優れていると思う点は、システム要件を浅く広く収集して、要件定義の資料の元ネタを作れる点だと思う。

【2】実際の要件定義の現場では、顧客の要求からの網羅性の確保と、要件の実現可能性の調査(フィージビリティスタディ)にかなりの労力を割く。
しかし、要件定義の工程では、少人数のチームで限られた時間内で、要件を決定しなければならない。

また、要件定義の資料は、大量のドキュメントを作ることを強いられる。
そのドキュメントも、自然言語で書かされる場合が多い。
でも、実際はそんな要件定義の資料はほとんど役立たない。

長ーい文章で書かれた要件を理解してみると、実は一言に過ぎない、とか、行間にたくさんの意味が隠れていた、とか、よくある。
その結果、設計工程以降のSEや開発者は、要件を勝手に推測してシステムを開発し、出来上がったシステムは、顧客の要望と似つかないものになってしまう。

さらに、要件定義フェーズで顧客にヒヤリングしたり、チーム内で議論する時、ホワイトボードで、絵を描く時が多い。
日本語で書いても伝わりにくく、むしろ、おおまかな絵を描いて、システムの関係、機能の関係、要求からのトレーサビリティを議論する方が多い。
その方が理解が進むし、実際の要件定義では、チーム内のメンバーで意見が割れないように、全員で理解できる方が重要だ。

【3】そんな経験を踏まえると、UMLの技法は要件定義フェーズで使える。
業務フローをアクティビティ図でアクター毎のフローで書いたり、システム境界と外部システムの関係をクラス図で書いたり、色々できる。

【4】でも、UMLを要件定義フェーズでどのように使うと便利なのか、要件定義フェーズのどの場面でどのダイアグラムを使うと効果的なのか、というノウハウが自分はしっくり来ていない。
一つのアイデアとしては、RDRAのような方針で、各種のダイアグラムをシステム要件・外部環境・システム境界・システム内部で使い分けることがあると思う。

RDRAが思い切った考え方をしているな、と思う点は、RDRAで書いたUMLのダイアグラムはユーザが理解できない資料で良しとし、要件定義の資料の元ネタであり、要件定義の資料は別途作成する、という方針であること。

【5】但し、10個近いダイアグラムを作るので、UMLモデリングツールは必須。
RDRAはEnterpriseArchitectを推奨している。
astahでできると尚良いな、と思っている。