連載
» 2004年09月17日 12時00分 UPDATE

みんなが悩む要求管理(2):ソフトウェア要求の詳細な分類

 前回「いまさら聞けない要求管理の基本」は、要求についてかなり漠然とした定義のみに触れましたが、今回はもう少し詳細に要求というものを見てみましょう。そもそも何を記述すればシステムの要求を完全に書いたことになるのか、ということから見ていきたいと思います。

[玉川憲,日本IBM]

要求は、システムの何を記述すればよい?

 システムを定義する詳細な要求を、RUPでは“ソフトウェア要求(Software Requirements)”と呼んでいます。つまり、ソフトウェア要求を完全に記述すれば、システムの要求(仕様)を完全に記述したことになります。

 ソフトウェア要求の定義は、システムをブラックボックスとする視点から、ユーザーやデバイスあるいは別のシステムのために、システムが遂行する能力/状態を記述したもの、となります。つまり、ソフトウェア要求を記述しようと思ったら、システムを外部から見た状態で(システムの中はどうなっているか分からない)、そのシステムが何を行うかを完全に記述する、ことを考えてみるのです。

 システムを完全に記述するためには、図1の5つのカテゴリに着目する必要があります。図の中の項目を定義していくことによって、ソフトウェア要求一式を決定することができます。

ALT 図1 ソフトウェア要求で記述する“システムの要素”

ソフトウェア要求ではないもの

 ここまで、ソフトウェア要求とは、外部の視点から見て、システムが何をしなければいけないかを開発者に伝えるもので、システムの入出力、機能、機能以外の属性、設計上の制約という側面から定義されることを説明しました。システムが何をしてくれるか(What)、を決めますが、システムがどのようにそれを実現するか(How)は決めないということが大切です。

 また、ソフトウェア要求に含めるべきでない情報には気を付けなければなりません。設計や実装についての情報、システムのテスト方法についての情報、プロジェクト管理に関する情報などは、ソフトウェア要求に含めないようにします(図2)。

 特に、設計や実装についての情報は、気付かないうちに入ってしまうので、十分に気を付ける必要があります。設計やアーキテクチャについての情報を要求に含めてしまうと、その情報に制限されて、アプリケーションにとって最適な設計方法を選択できなくなってしまいます。ただし、あらかじめシステムの内部的なことが決められている場合があります。例えば、組織が持つライセンス上の問題で、データベースとしてDB2を使用することが決められているケースがあります。その場合は、“設計上の制約(Design Constraints)”として記述します。

 大切なことは、設計上の制約はできるだけ少なくすることです。そうすることで、開発者は、最小限の制約に縛られるのみで、必要な機能を実装し指定された性能や信頼性を達成するシステムを設計することが可能になります。

ALT 図2 要求に含まないもの

要求の詳細な分類

 ソフトウェア要求に関してここまで見てきましたが、ソフトウェア要求と一言でいってもさまざまな種類の要求があることはお分かりだと思います。特に次のように3つに分類することができます。

  • 機能要求
  • 機能外要求
  • 設計上の制約

 また、図3のようにFunctionality(機能)、Usability(使いやすさ)、Reliability(信頼性)、Performance(性能)、Supportability(サポートのしやすさ)、の頭文字を取ってFURPS+の形で分類することも一般的に行われます。FURPS+の最後の+は、FURPSに含まれない設計上の制約を示しています。このFURPS+は、上の3つの分類でいうと、Fは機能要求、URPSが機能外要求、+が設計上の制約にそれぞれ相当することはお分かりだと思います。

 このような形に分類することにより、要求を引き出す際や、要求に対する理解を評価する際のチェックリストとなり、漏れや不完全さを防ぐことができます。

ALT 図3 要求の分類(FURPS+)

ソフトウェア要求以外の要求?

 前節まで、 “ソフトウェア要求”とは、システムを詳細レベルで定義した要求であり、ブラックボックス的視点からシステムの能力を記述した要求、として見てきました。また、ソフトウェア要求は、FURPS+の形に分類できることも見ました。しかし、顧客に満足してもらえるシステムを開発するには、ソフトウェア要求だけではなく、利害関係者(Stakeholder: プロジェクトと何らかの利害関係を持つ人、特にシステムのユーザーは重要な利害関係者に挙げられます)のニーズをとらえることが重要です。

 要求管理を効率的に行うために、詳細レベルの要求である “ソフトウェア要求”以外も要求としてとらえることが経験上有効であることが知られています。つまり、要求という言葉の対象を、システムの詳細定義である“ソフトウェア要求”だけでなく、利害関係者の“ニーズ(Needs)”にも拡大しているのです。そしてもう1つ、ソフトウェア要求より抽象レベルの高い要求として、“基本要件(Features)”も要求としてとらえます。ちょっとややこしいですが、 “要求タイプ” という概念を導入し、そのタイプの1つが“ニーズ”であり“基本要件”であり、“ソフトウェア要求”というわけです。基本要件は、ソフトウェア要求と比べて抽象度が高く記述されるため、基本要件を用いれば、システム全体を容易に把握でき、開発範囲を管理が楽になります。

 そうしますと、図4のように、ニーズ、基本要件、ソフトウェア要求と3段のピラミッド状に要求を要求タイプごとに体系化して記述することができます。受注管理を効率化する業務用アプリケーションを例にとりあげて、それぞれの要求タイプ別にサンプル要求が書くと図5のようになります。要求タイプごとのイメージをつかんで頂けると思います。

ALT 図4 要求のピラミッド(ニーズ、基本要件、ソフトウェア要求)と各要求タイプの定義

【ニーズ】 利害関係者の望むものをシステム(ソリューション)に依存しないかたちで表現したもの

【基本要件】 システムが外部に提供するサービスを表現したもの。これらは、1つ以上の利害関係者のニーズをサポートしている

【ソフトウェア要求】 開発者が設計、実装、検証できる程度まで詳細に記述された要求。これらは、1つ以上の基本要件をサポートしている

ニーズ
・受注管理業務にかかるコストを削減すること
・在庫問い合わせに即座に対応することができる
基本要件
在庫確認機能:システムを用いると、受注担当者は、商品カテゴリ、もしくは、商品名、メーカ名、商品コードから、在庫数を確認できる
ソフトウェア要求 機能要求
(1) 受注担当者は商品カテゴリを選択する
(2) システムは商品名の一覧を提示する
(3) 受注担当者は商品名を選択する
(4) システムは商品在庫情報(商品名、メーカ名、商品コード、在庫数)を提示する
機能外要求
システムはユーザーにオンライン・チュートリアルを提供する
図5 要求タイプ別の例(受注管理システム)

 “要求タイプ”を、もう一度簡単にまとめておきましょう。まず、顧客の問題を確実に解決できるように、システムの背後にある“ニーズ”をシステムに依存しない形で捉える。そして、システムの大きな機能のくくりである“基本要件”を捉えることでシステム全体を理解し、開発範囲の管理を容易にする。さらに、詳細なシステム定義である“ソフトウェア要求”を定義することで開発者がシステムを設計、実装、検証できるという訳です。特に、“ニーズ”を記録しておくことにより、この“基本要件” はそもそもどこからきたのか、“ソフトウェア要求”は何のためにあるのか、という視点がもてることは非常に重要です。例えば、開発者に対して何らかの変更依頼があったときに、もとの“ニーズ”という視点から実装方法を検討できるのとできないのでは大きな違いがあります。

  さて、今回は要求の分類分けについてみてきましたが、次回は、要求管理プロセスの流れを解説し、ワークフローとして整理したいと思います。

【コラム】 小学校の校門前の横断歩道

  先日、お客様と要求管理の話をさせて頂いたときに、要求のタイプである“ニーズ”、“基本要件”のサンプルとして良い例を伺いましたので紹介したいと思います。


  校門の前に大きな道路がある小学校は全国にたくさんあると思われますが、やはり気になるのはその安全面です。


  ここで、“児童が校門の前の道路を安全に渡ることができる”をニーズとみると、それを解決するソリューションの基本要件としては、“校門前の道路は信号で制御される”、または“校門前の道路は歩道橋でしか渡れない”、もしくは“みどりのおばさんが横断歩道を監視する” ( 黄色い旗を持って通学路を見張るお母さんのことを、著者の出身地の大阪では“みどりのおばさん”と呼んでいました ) があり得ます。


  ニーズを解決しさえすれば、どの基本要件でそのニーズをサポートするかはソリューションの問題であり、プロジェクトの予算などと相談する話となります。非常に分かりやすいのではないでしょうか?


  ところで、田舎に住む友人からこんな話も聞ききました。


  「僕の田舎の道路には、普通、信号なんかないのですよ。大きな事故があったりすると、そこにやっと信号ができます(少し物騒な話しで申し訳ございません)。ただ、小学校の校門の前にはなぜか必ず信号があります。これはそこで必ず事故があったからという訳ではなくて、児童が大きくなって都会に出たときに信号を見て困らないように、教育用に作られているそうですよ」。


  ちょっと某番組に出品したいネタですね。この話の真偽のほどは定かではありませんが、教育用にあえてある制約を課すというのは、システム開発の世界でもよくある話だなあ、としみじみと考えてしまいました。



著者プロフィール

玉川憲(たまがわけん)

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



Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ