要求管理のプロセスを追跡する（2）システムを定義する 初歩編：みんなが悩む要求管理（4）

[玉川憲，日本IBM]

　第3回「システムが解決すべき問題を整理する」は、要求管理プロセスの全体像を理解するシリーズの1回目として、“問題の分析”と“利害関係者のニーズの理解”のスキルを見てきました。今回は、システムを定義するノウハウとシステム範囲の管理方法を解説します。

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

スキル3 システムの定義

　「スキル3“システムの定義”」では、作成するシステムの位置付けを明確にし、システムが持たなければならない能力を記述して整理します。図1において、ニーズと基本要件の間から点線が引かれていることに注意してください。これは、ニーズが問題領域に存在するのに対し、基本要件がソリューション領域に存在していることを示しています。つまり、この“システムを定義する”段階で初めてソリューション領域のことを考えます。

　 まずは、システムの位置付けを簡潔に記述してみましょう。第3回に紹介した「問題の分析」や利害関係者の要望をベースに、システムの位置付けを明確にします。RUPでは下記の表形式の「システムの位置付けの記述（Product Position Statement）」を用います。

対象者	受注担当者
対象者のニーズ	受注担当者は、Web上で受注入力、受注残管理、在庫問い合わせを行うことができ、複数サイトや複数人で処理してもデータにずれが生じないことを望んでいる
「受注管理システム」の範疇	A社の販売管理システムの一部となる
このシステムの機能	受注入力、受注残管理、在庫問い合わせをWeb上で行える
現状や競合製品	ほとんど書類ベースで行われており、一部市販ソフトが使われている
新システムの付加価値	Web上で処理を行うことができ、データにずれが生じない。また、処理に必要な手順や情報もオンラインで提供される
「システムの位置付けの記述（Product Position Statement）」の例（受注管理システム）

　次に、システムの能力を表現した抽象度の高い要求である基本要件（第2回「ソフトウェア要求の詳細な分類」）をリストアップします。

　そして、リストアップした基本要件を基に、システムのユースケースをアウトラインレベル（補遺「ユースケースモデルの概要」を参照）で記述します。ユースケースを用いることで、ユーザーから見たシステムへの要求を明確にできます。

スキル4 システム範囲の管理

　「スキル4“システム範囲の管理”」では、システムの要求の優先順位を付けてシステムの開発範囲を管理します。プロジェクトをうまく管理するには、プロジェクトの開発範囲を利用可能なリソース（時間、人材、予算）に合わせて管理することが大切です。プロジェクトの開発範囲は、どの要求まで実現するのかによって決まってきますので、要求に対する優先順位を設定し、開発すべき範囲に対して顧客の合意を得ることが大切です。

　　ここで、システムの開発範囲を設定するのに有用な“要求属性”という概念を紹介しましょう。おのおのの要求に、優先度（顧客の視点）、作業量（開発チームの視点）、リスク（スケジュールや予算に無理が発生する確率）などの項目を要求属性として付加し、それらの属性をメンテナンスしておきます。そうすることで、要求の範囲に関して顧客と合意を得る際の良い道具になります。

	優先度	作業量	リスク
基本要件7	高	中	中
基本要件13	中	低	高
基本要件22	低	低	低
要求属性の例

---

　以上、今回は、要求管理プロセスの全体像を理解するシリーズの2回目として、“システムの定義”“システム範囲の管理”のスキルを見てきました。“システムの定義”では、作成するシステムの位置付けを明確にし、システムが持たなければならない能力を記述して整理すること、“システム範囲の管理”では、システムの要求を優先順位付けしてシステムの開発範囲を管理すること、がポイントでした。また、ユースケースや要求属性など、重要な概念についても紹介しました。次回は、“システム定義の詳細化”“要求変更の管理”を解説したいと思います。

[補遺] ユースケースモデルの概要

　本文中にユースケースモデルについての言及があります。要求仕様をまとめる際にユースケースモデルの中身が徐々に発展していく段階を知ることは非常に重要ですので、補遺として少し詳しく解説をします。

　図3の点線より上部分がユースケース図と呼ばれるものです。システムに対してある役割（ロール） を持つ人をアクターとし、そのアクターが望むサービスが1つのユースケースです。そして、アクターとシステム間におけるデータや処理の流れを、ユースケースごとにストーリー形式で記述します（この文書をユースケース仕様書と呼びます）。ユースケースモデルという言葉は、ユースケース図だけでなく、ユースケース仕様書を含むことに注意してください（情報量のほとんどが図ではなく、テキストにあります）。

　ユースケース仕様書の中身は、アクターとユースケース間のやり取りが記述されますが、まずは図4（a）を見てください。ユースケースにとって典型的な流れを考え、それをステップごとに記述します。しかし、実際にシステムを作る際には、典型的な流れのほかに、バリエーションをたくさん考慮しなければなりません。ユースケースを用いることで、基本フローを中心に、そのバリエーションとして代替フローを書く、という形式を取ることで、実際にシステムを利用したときに無数のシナリオをまとめて書くことができます。似たような処理の流れを、整理して書く方法ととらえてもよいかもしれません。基本フローに加えて代替フローを付け加えたものが図4（b）になります。

　シナリオとフローという言葉が出てきたので整理しておきましょう。図5において、ひとかたまりのステップ群がフローです。そして、フローを組み合わせて開始から終了まで順序付けられた一連のステップがシナリオです。この図5の場合、シナリオは3つ書かれていますが、実はもう1つあることに気付かれると思います。

　図6は、ユースケースの中身が発展していく段階を示しています。最初から代替処理や失敗処理の中身まで完全に書くのではなく、段階を追って発展させていきます。