要件管理が必要な理由

要件管理が必要な理由についてメモ書き。
＃後でまとめる。

要件管理の機能で最も重要と思われる成果物は、要件と機能のトレーサビリティマトリクス(TM)だ。
イメージは、下記の記事の図3 トレーサビリティマトリクス（追跡可能性マトリクス）に相当する。

＠IT：みんなが悩む要求管理（8）要求管理ツールの賢い使い方

イメージとしては、上位要件を行、下位要件を列にしたマトリクスを作り、上位要件に紐づく下位要件がある場合、そのセルに印を付ける。
このマトリクスがトレーサビリティマトリクス(TM：追跡可能マトリクス)であり、このTMがあれば、要件に変更が生じた場合、下位要件、更にはそれに紐づくテストケースの影響範囲が一目瞭然になる。
上記の図にある「サスペクトリンク」は、そういう機能だ。

実際の開発では、要求仕様と基本仕様、基本仕様と機能仕様のように、隣り合う要件ドキュメント(フェースタイプテーブTblのフェーズ)でトレーサビリティマトリクスを作ればいいだろう。

清水吉男さんが提唱する派生開発プロセスXDDPでは、トレーサビリティマトリクス(TM)が成果物の一つであり、TMで変更要求と機能が交差した箇所で修正が必要な場合、変更設計書が作られる。
ここで、変更設計書は、実際のソースの修正手順まで含んだドキュメント。

XDDPでは、TMによって変更箇所を洗い出し、更に変更手順まで設計プロセスで作成するというプロセスを含んでいるのが秀逸。
つまり、派生開発という仕様変更を要件から開発・テストまできちんと追跡するプロセスがあるのだ。

要件管理では、要件漏れ・テスト漏れがないかという要件カバレッジ、つまりMECEの観点が一番大事だ。
要件カバレッジがあるからこそ、要件からソースコードやテストケースまでのトレーサビリティが実現される。
逆に、バグが発生した場合、バグの影響範囲を要件カバレッジによって即座に見極められるので、ブロッキングバグの修正・検証工数も最終的には計算できる。

つまり、両方向のトレーサビリティツリー機能によって、ブロッキングバグに影響する要件、更にはそれに紐づくテストケースや機能が分かり、最終的には、ブロッキングバグの修正・検証工数も計算でるはず。
この手法はブロッキングバグの影響調査だけでなく、仕様変更による影響調査にも使えるので、精度の高い変更管理が可能になる。

即ち、要件管理を仕様変更に伴う影響調査として使い、設計工程の品質Upやリスク管理に応用したいのだ。

そして、その機能は、手作業ではなく、ツールでサポートすべきであると思う。
何故なら、要件が数百、テストケースが数千もある場合、もはや手作業でカバーできないからだ。
これが、TestLinkの要件管理機能は現在は不十分でも、すごく潜在性を感じる理由でもある。