反復型開発における要求管理の流れみんなが悩む要求管理(6)

» 2005年03月12日 12時00分 公開
[玉川憲,日本IBM]

 第5回「要求管理プロセスの流れを追跡する」まで3回にわたって、要求管理プロセスの全体像を解説してきました。この要求管理プロセスは反復型の開発プロセスであるRUP(Rational Unified Process)にのっとったものなのですが、これまではあえて“反復”のことは考えず、単純化した流れの中で(RUPの)要求管理プロセスを見てきました。今回はいよいよ、反復型の開発における要求管理の流れを説明したいと思います。

RUPの要求ワークフロー

 前回まで下記のスキルを見てきました。要求を定義し、管理する一連の流れを理解していただけたと思います。ただし、勘違いしてはいけないのは、下記のスキル1〜6が、必ずしも時系列で1から6まで進み、終了ということにはならないということです。

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

 図1はRUPにおける要求ワークフローですが、上記のスキルがワークフロー形式で表現されているのが見て取れると思います。そして、これを見ると、必要に応じてすでに行った作業をもう1度行うということが分かります。

ALT 図1 RUPの要求ワークフロー

 図1はUMLのアクティビティ図のように表現されています。1番上の黒い丸が開始点です。上からたどって見てみましょう。開始点から横長の棒に入りますが、これは並行処理を表す“同期バー”と呼ばれるものです。同期バーから流れは分岐し、左側の矢印と右側の矢印に並行して進んでいきます。

 まず、同期バーから出ている2本の矢印のうち、左側のひし形に続く矢印を追いかけてみます。ひし形は“分岐”を表しており、“新規システム”と”既存システム”という2つの条件に応じて進路が分かれています(アクティビティ図では、この条件は“ガード条件”と呼ばれます)。“新規システム”の場合、“問題の分析”を行うことになります。

 そして、これが終わると、“利害関係者のニーズの理解”を行います。ここから次のひし形の分岐に飛び、“適切な問題を扱っている”ことが確認されると、“システムの定義”を行います。次に、“システムの開発範囲の管理”を行い、次の分岐に飛んで、“実現可能な開発範囲”を扱っていることが確認できると、“システム定義の詳細化”を行います。

 一方、右側の矢印を追いかけると、“新たな入力”のガード条件で“要求変更の管理”を行うとなっています。これは、要求に対する何らかの入力が入ると、要求変更の管理を行うことを意味しています。いつの時点でも“新たな入力”が発生することを考えると、左側の流れと右側の流れが同期バーとして表現されていることが理解できると思います。

反復型開発の特徴

 ここで簡単にRUPの反復型開発に触れておきましょう。反復型開発では、業務分析、要件定義、設計、実装、テストといった一連の作業を(RUPではビジネスモデリング、要求、分析設計、実装、テストと呼びます)順を追って1度だけ行うのではなく、何度か繰り返すことで開発を行います。この1回の繰り返しを“反復”と呼びます。ただし、単純に同じように繰り返していくわけではなく、プロジェクトを4つのフェイズに区切り、各フェイズにクリアすべきチェックポイント(マイルストーン)を定めています。つまり、プロジェクト全体での時期に応じてチェックポイントがあり、時期に応じて重要な作業を重点的に行うということです。

 図2のように、プロジェクトの初期の反復では、要求に関する作業が重点的に行われ、プロジェクトの後半の反復になると主に実装に関する作業が行われます。図2では、反復の回数は、方向付け1回、推敲(すいこう)2回、作成2回、移行1回となっていますが(これはRUPでは最も典型的な反復回数)、反復の回数はプロジェクトの性質によって変化します。

ALT 図2 フェイズに応じて作業の重み付けが変化

 図3は、各フェイズの終了時における、成果物の進ちょく度合いを示しています。方向付けでは重点的に要求関連の成果物が作成されている点など、それぞれのフェイズでの重み付けが理解できると思います。

ALT 図3 各フェイズ終了時における成果物の進ちょく度合い

反復型開発の各フェイズにおける要求ワークフローと成果物

 前節で、反復型開発においてはフェイズによって行う作業の重み付けが違うということをお話ししました。では、特に要求に着目してみると、各フェイズにおける反復での要求ワークフローや要求関連の成果物の重み付けはどのようになるでしょうか?

 図4は、新しいシステムを作成することを仮定して、フェイズごとの要求管理のワークフローを表現しています。方向付けフェイズではまず“問題の分析”から開始することになります。しかしこのフェイズではまだ要求が安定していないので、“要求変更の管理”はほとんど行われません。“要求変更の管理”は推敲フェイズの何度目かの反復で行われることになるでしょう。

 推敲フェイズでは、すでにそれまでの反復でシステムを作っているので、“新規システム”か“既存システム”という分岐では“既存システム”になるため、“利害関係者の要望の理解”から行うことになります。また、作成フェイズではもうすでに“システムの定義”までは固まっているので、“システム範囲の管理”から行うことになります。要求管理のワークフローだけを見てみても、フェイズによって作業の内容が変わってくるのが分かります。

ALT 図4 各フェイズにおける要求ワークフローの例

 また、表1は各フェイズ終了時における、要求関連の主な成果物の進ちょく度合いをまとめたものです。方向付けフェイズでは、開発構想書、用語集がほぼ完成されます。ユースケースについても主なものを定義し、アウトラインを作成します。推敲フェイズに入ると、開発構想書、用語集は必要に応じて更新され、ユースケース、補足仕様書が詳細化されていきます。

成果物/フェイズ   方向付け 推敲 作成 移行
開発構想書 主な要求、機能、制約を文書化 新しい情報で更新    
用語集 重要語句を文書化 新しい情報で更新 新しいユース ケースを発見すると更新  
ユースケースモデル 主なアクターとユース ケースを定義。重要なユースケースのみ、イベントフローのアウトラインを作成 全アクター、全ユースケースを定義。ほぼ全てのユースケース仕様書を作成 新しいユース ケースを発見すると更新  
補足仕様書     機能外要求を文書化    
表 各フェイズ終了時における要求関連の主要成果物の進ちょく度合い

反復ごとにユースケースのシナリオ単位で開発する

 ここで、もう1点押さえておきたいことは、RUPでは、ユースケースのシナリオ単位で開発を進めていくということです。ユースケースのシナリオとは、ユースケースのイベントフローの組み合わせであることを第4回「システムを定義する 初歩編」で解説しました。

 図5は各反復にユースケースシナリオを割り当てて開発をしていく例です。この例の場合、ユースケースA、B、Cの3つのユースケースが存在している中で、ユースケースAの基本フローと代替フロー1、ユースケースBの基本フローが重要という点で、まずはこれらのシナリオを初期の反復で実装しています。そして次の反復でユースケースBの代替フロー1を含めたシナリオ2を実装、さらに次の反復で、ユースケースA、B、Cの残りのシナリオを開発しています。

 さて、ユースケース仕様書について考えてみますと、ユースケース仕様書は最初から詳細に書かれるわけではなく段階的に記述され、その記述レベルとしては、概要の記述、アウトライン化、詳細の定義がありました(第4回「システムを定義する 初歩編」)。

 フェイズという側面からこれを見てみますと、方向付けフェイズで、主要なユースケースに関してアウトラインレベル(基本フローの簡潔なステップと代替フローの洗い出しレベル)まで書きます。そして、推敲フェイズでは、各反復で実装するユースケースシナリオごとに詳細化していくということです。

ALT 図5 各反復に割り当てられたユースケースシナリオの例

 今回は、反復型開発における要求管理の流れを説明してきました。反復型開発においては、そのフェイズのマイルストーンに応じて要求の作業を行い、成果物を作成していく点をポイントとして解説してきました。反復型開発だと、やらなければいけない作業がずるずると後ろに延びてしまうのではないか、という不安を抱く方が多いようですが、RUPにおける反復型開発ではフェイズごとのマイルストーンがあり、それをクリアするために作業していくので決して後ろ延ばしが許されるわけではない、ということを強調しておきたいと思います。

著者プロフィール

玉川憲(たまがわけん)

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


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ