astah* professional 6.1の要求図

astah* professional 6.1がリリースされた。
リリース内容で最も注目する機能が「要求図」。
アイデアをメモ。

【元ネタ】
astah* professional 6.1 リリースノート

チェンジビジョン、設計支援ツール「astah*」の新版をリリース--新たに要求図を追加 - builder by ZDNet Japan

要求追跡（要求工学：第9回）

モデリング言語 SysMLを概観する（1/2） － ＠IT MONOist

詳細は知らないが、要求図は、UMLを拡張したモデル技法SysMLの一部の機能らしい。
astah* professionalでは、Ver6.0の頃から、「要求」と「テストケース」のインスタンスを作ることができたが「要求図」はリリースされていなかった。
だから、「要求」と「テストケース」をどのように使うのか不明だった。

しかし、今回リリースされた機能である「要求図」によって、要求をダイアグラムで可視化できる。
そして、「要求」を「テストケース」や「ユースケース」「クラス」などに紐付ければ、要求からモデルやテストケースへトレーサビリティを実現できる。
すると、要件からモデル、そしてモデルから吐き出されたソース、更にはビルドされたモジュールまでのトレーサビリティを実現できるはず。

Redmine＋Hudson＋TestLinkを組み合わせたチケット駆動開発では、下記のトレーサビリティが実現出来ている。

TestLink要件
→TestLinkテストケース
→【Redmineチケット】
→SVNリビジョン
→Hudsonビルドモジュール

この時、TestLinkの要件やテストケースをCSV化し、astah* professional の「要求」や「テストケース」にインポートできれば、ユースケース図やクラス図などと紐付けることができるから、上流工程の設計モデルにもトレーサビリティを付与できる。
これは上流工程の成果物の品質向上に役立つはず。

何故なら、顧客の要求が設計モデルのどこに反映されているか、をチェックするのに、要求のトレーサビリティが使えるからだ。
実際の上流工程では、問題点←→要件←→仕様のトレーサビリティを実現するのは、N対Nで複雑な関係でとても面倒なため、要件漏れや設計漏れが頻発しやすいからだ。
つまり、設計モデルでの設計漏れに対し、要件カバレッジ機能を使って、漏れをチェックしたいのだ。

astah* professional以外のモデリングツールでは、UMLのダイアグラムを書くだけ、ER図が書けるだけで、要求管理や要求のトレーサビリティの概念を実現できていなかった。
だから、astah* professionalにはすごく可能性を感じている。

僕の興味としては、実装レベルに近いクラス図やシーケンス図よりも、RFPによるシステム提案や要件定義のような超上流工程で、astah* professionalの要求機能を使いたい。
イメージとしては、下記の使い方をやってみたい。

顧客からヒヤリングした要求を要件定義書としてまとめる
↓
要件定義書の要件をastah* professionalの「要求」として一括インポート
↓
astah* professional 上で、クラス図やユースケース図などのラフな概念モデルを書く。
それらの概念モデルに「要求」を紐づけて、要件漏れをチェックする
↓
ファンクションポイント法を使って、システムの規模を概算で見積もり、工数見積に使う
↓
作った概念モデルと要件定義書から、仕様へ詳細化していき、実装していく。
この過程でも、要件カバレッジ、仕様カバレッジを使って、要件漏れや仕様漏れをなくす。

チケット駆動開発によって、下流工程の成果物の品質は向上できている。
最後の課題である要件定義や設計などの上流工程の成果物の品質向上に、要求のトレーサビリティの概念を導入できないか、試してみたい。