要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス
要求管理プロセスについて良い記事があったのでメモ。
【元ネタ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と要件管理機能を組み合わせれば、上記のプロセスを実装できるだろう。
ツールで要求管理をサポートする。
要求管理を含むチケット駆動開発こそが、仕様変更に強いアジャイル開発を更にパワーアップしてくれるはずだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント