連載
» 2005年01月26日 12時00分 公開

要求管理のプロセスを追跡する(3)要求管理プロセスの流れを追跡するみんなが悩む要求管理(5)

[玉川憲,日本IBM]

 第4回「システムを定義する 初歩編」では、要求管理プロセスの全体像を理解するための2つのスキル“システムの定義”と“システム範囲の管理”を解説しました。今回は、“システム定義の詳細化”と“要求変更を管理”について解説します。

◆ スキル1: 問題の分析 (第3回)
◆ スキル2: 利害関係者のニーズの理解 (第3回)
◆ スキル3: システムの定義 (第4回)
◆ スキル4: システム範囲の管理 (第4回)
◆ スキル5: システム定義の詳細化 (第5回)
◆ スキル6: 要求変更の管理 (第5回)

スキル5 システム定義の詳細化

ALT 図1 要求のピラミッド 「問題の分析」

 「スキル5“システム定義の詳細化”」では、設計や実装を行うのに十分なレベルまで要求を詳細化します。要求を詳細化することで、開発チーム全体が現在構築中のシステムがどのようなものであるかを正確に理解でき、システムが利害関係者のニーズに一致しているかを確認することができます。

 さて、システムのソフトウェア要求を詳細化するということになるのですが、ここで一度要求タイプとその成果物の関係を整理しておきましょう。

ALT 図2 要求タイプと成果物の関係

 図2のように、ニーズや基本要件といった抽象度の高い要求タイプは、開発構想書という成果物に整理して記述されます。そして、ソフトウェア要求は機能要求と機能外要求に分けられ、機能要求の部分はユースケースモデル(アクター、ユースケース、ユースケース仕様書のセット:第4回参照)で記述し、機能外要求の部分は補足仕様書として記述します。

 成果物が整理できたところで、ソフトウェアウェア要求を詳細化する、ということに話を戻しますと、この“システム定義の詳細化”の段階で行う作業としては、“システムを定義する”の段階でアウトラインレベルまで作られたユースケースモデルをさらに詳細化し、また、機能外要求として補足仕様書を記述します。

 ここで押さえておきたいポイントは、すでに、高いレベルのシステム定義である基本要件を基に優先度を決め、開発範囲を設定していることです。開発対象となっている要求についてのみ、詳細化するためのリソースを投入することで無駄なリソースの投入を避けています。

スキル6 要求変更を管理する

ALT 図3 要求のピラミッド 「問題の分析」

 「スキル6“要求変更を管理する”」では、要求変更に対してその影響を評価し、変更を受け入れた場合はその影響を管理します。たとえ、どんなに注意深く定義しても、顧客のシステムに対する理解の変化や、環境の変化に応じて要求は変更されるものです。そのため、要求変更そのものを完全に受け入れないアプローチは現実的ではありません。要求変更自体が問題なのではなく、管理されない要求変更が問題なのです。

 さて、要求変更を管理するという視点を持ったときに重要になるのが、変更管理のプロセスです。システムに対する要求がある程度固まってくると、要求のスナップショットを作成し(これを要求のベースラインと呼びます)、それ以降の要求の変更は、すべて変更管理プロセスの下で行うようにします。

ALT 図4 変更管理プロセス

 さまざまな成果物に対して、さまざまな利害関係者から変更が入ってきますが、それらをすべて一元的に管理し、レビューして影響を分析し、承認するプロセスを作ります。小規模なプロジェクトではプロジェクト管理者がこの役割を担いますが、大規模プロジェクトでは複数名で構成された変更審査委員会が必要となるでしょう。

 ただし、実際に変更依頼( Change Request、変更要求とも言う)が起きた際に、変更依頼を受け入れるかどうか判断するために変更依頼に伴う影響の大きさを分析しようとしても、大規模なプロジェクトでは要求に対する影響の評価そのものを取ってみても難しい作業になります。

 この作業を緩和するのに有用な概念が“トレーサビリティ”です。図5の中で、基本要件とユースケース、基本要件と補足仕様の間のように、種類の違う要求タイプ間に矢印が引かれていますが、この関係が要求のトレーサビリティです(図5では、例としてテストケースまでトレーサビリティを引いています)。例えば、ある基本要件2を満たすためにユースケース1が存在するのであれば、その間にトレーサビリティが引かれます。その基本要件に変更があったときに、基本要件と関係するユースケース、そのユースケースと関連するテストケースをたどっていくことができ、変更依頼の影響評価(インパクト分析)が可能になります。

ALT 図5 種類の違う要求間に張られたトレーサビリティ例

 また、トレーサビリティは変更依頼に対するインパクト分析だけでなく、余分な要求が存在していないか、足りない要求がないか、というカバレッジ分析にも使えます。例えば、ユースケース2に対しては基本用件から1つもトレーサビリティが引かれていないので、このユースケースは余分な仕様ということになります。

 ところで、トレーサビリティを管理するのは非常に手間が掛かり、コストとメリットのトレードオフを考えねばなりません。そのため、どの種類の要求をトレーサビリティの対象とするのかというトレーサビリティ戦略を明確に定義することは大切です。必要に応じて、実装レベルのクラスまでトレーサビリティを管理することも可能ですが、管理の手間を考えるとあまり現実的ではないケースが多いでしょう。ある程度大規模なプロジェクトになると、トレーサビリティなど要求をさまざまな側面で効率的に管理するには要求管理ツール(IBM RationalのRequisitePro、BorlandのCaliberRM、TelelogicのDoorsなど)の導入も有用です。


 以上、今回は、要求管理プロセスの全体像を理解するシリーズの最後として、“システム定義の詳細化”と”要求変更を管理する”のスキルを見てきました。「スキル5“システム定義の詳細化”」では、設計や実装を行うのに十分なレベルまで要求を詳細化すること、「スキル6“要求変更を管理する”」では、要求変更に対してその影響を評価し、変更を受け入れた場合はその影響を管理することがポイントです。

著者プロフィール

玉川憲(たまがわけん)

 IBM東京基礎研究所に入所後、超小型腕時計型LinuxコンピュータWatchPadの研究開発に従事。現在は、IBM Rational事業部にて、RUP・要求管理・オブジェクト指向分析設計の講師としてコンサルティングを行っている。



Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ