要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス
要求管理プロセスについて良い記事があったのでメモ。
【元ネタ1】
@IT:みんなが悩む要求管理(8) 最終回 要求管理ツールの賢い使い方
まず、要求をWordのような文書ソフトで管理すると、要求の属性や履歴の管理が難しく、要求間でトレーサビリティが設定できないという欠点があります。
一方、要求を表計算ソフトで管理すると、要求を文脈の中で表現することが難しく、要求間でトレーサビリティを設定するのが難しいという欠点があります。
いっそのこと、要求を管理するためにデータベースをカスタマイズしたツールを使うケースがありますが、この場合でも、要求を文脈の中で表現することが難しく、ツールの保守にコストがかかります。
ある程度、大規模なシステム開発の場合は、市販の要求管理ツールを用いた方がメリットの出るケースが多いと思います。
IBM Rational RequisiteProを使った要求管理の事例。
興味深いのは、トレーサビリティマトリクス(追跡可能性マトリクス)だ。
これは、清水吉男さんが提唱する派生開発プロセスXDDPにもあるTM(トレーサビリティマトリクス)と同じだ。
TMは、上位要件を行、下位要件を列で表示したマトリクス。
上位要件に下位要件が紐づいている場合、マトリクスのセルに印が付く。
このセルがトレーサビリティを示す。
つまり、TMで印を付ける作業が、上位要件に紐づく下位要件の過不足が無いかを確認する作業に相当する。
これこそが要件カバレッジだ。
この要件カバレッジ機能を意識して設計すれば、要件を詳細化していくプロセスで、要件漏れや設計漏れをなくして、設計プロセスの品質を高めることができる。
【元ネタ2】
テスト管理のベスト・プラクティス 要件ベースのテストを使用する
要件管理では、要件漏れ・テスト漏れがないかという要件カバレッジ、つまりMECEの観点が一番大事だ。
要件カバレッジがあるからこそ、要件からソースコードやテストケースまでのトレーサビリティが実現される。
逆に、バグが発生した場合、バグの影響範囲を要件カバレッジによって即座に見極められるので、ブロッキングバグの修正・検証工数も最終的には計算できる。
特に、後者の機能は、要件カバレッジを利用して、バグから本来の要件に遡って、バグが発生した要件に関係する要件から修正対象ソースへ追跡できるという点で重要だ。
この手法は仕様変更にも使えるからだ。
そして、要件カバレッジの機能は、手作業ではなく、ツールでサポートすべきだ。
理由は、要件が数百、テストケースが数千もある場合、もはや手作業でカバーできないから。
TestLinkの要件管理機能は現在は不十分でも、すごく潜在性を感じる理由でもある。
【元ネタ3】
@IT:みんなが悩む要求管理(7) 第7回 要求管理と変更依頼管理の違いを理解しよう
変更依頼管理プロセスと要求管理プロセスの関係の図が素晴らしい。
変更依頼管理や要求管理は最終的には、ITILの変更管理に落ち着く。
大規模プロジェクトほど、ユーザからやって来る膨大な改善要望や障害修正の要求は、一旦溜め込んで、すぐに判断しない。
要件定義や設計チームの代表者が集まった変更審査委員会(CCB:Change Control Board)が、一旦貯めた要求リストから、次バージョンで実現すべき要件を抽出し、優先順位付けしていく。
開発者は優先順位付けされた要件リストに従って開発し、テスト担当者は検証していく。
つまり、上記の計画プロセスと実装・検証プロセスは、ITILの変更管理とリリース管理にピッタリ当てはまる。
要求管理や変更依頼管理は、ITILの変更管理プロセスできちんと追跡できるように管理すべきなのだ。
また、要求を一旦溜め込んで優先順位付けするプロセスは、Scrumのスプリント計画やXPのイテレーション計画に相当する。
すなわち、プロダクトバックログにまずはユーザの要求を溜め込んでおき、どのスプリントで実装するかは保留にしておく。
スプリント計画を立てる時に、プロダクトバックログからスプリントバックログへ実現すべき要求を移す。
これが本来のマネジメント、あるいは要求管理になる。
そして、このプロセスはツールで実現されるべきだ。
大量の要求の一覧を優先順位付けして、どのバージョンでリリースされたか、追跡できるようにするには、Excelで手作業で行うのはもはや難しい。
ツールのサポート無しでは作業漏れも発生しやすい。
このインフラは、おそらくチケット駆動開発で実装できる。
つまり、BTSと要件管理機能を組み合わせれば、上記のプロセスを実装できるだろう。
ツールで要求管理をサポートする。
要求管理を含むチケット駆動開発こそが、仕様変更に強いアジャイル開発を更にパワーアップしてくれるはずだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
「TestLink」カテゴリの記事
- テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか(2020.11.02)
- TestLinkにExcelのテスト項目書をインポートする方法(2017.06.01)
- TestLink Tutorialのリンク(2016.03.12)
- TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法(2016.01.31)
- エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること(2015.03.14)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント