 |
[ 2009 年 7 月号] |
|
[ 2009 年 7 月号] |
［オージス総研の本］
 |
実践ソフトウェア要求ハンドブック エレン・ゴッデスディーナー 著 |
 |
目次 |
|
本書の背景 |
|
本書の特徴 |
|
各章の概要 |
第 1 章：ソフトウェア要求の概要
第 2 章：要求開発の準備
第 3 章：要求の抽出
第 4 章：要求の分析
第 5 章：要求の仕様化
第 6 章：要求の妥当性確認
第 7 章：要求の管理
第 8 章：プロジェクトに合わせた要求プラクティスの調整
付録 A：参考文献、関連書籍、その他のリソース
付録 B：分析モデル
付録 C：要求モデルで使用する動詞や言い回し
付録 D：ソフトウェア要求仕様のインスペクションチェックリスト
付録 E：品質特性と評価指標
付録 F：品質特性を記述する際に避けた方がよいあいまいな言葉や言い回し
付録 G：要求を振り返るための質問
付録 H：用語集
 |
ページのトップへ戻る |
非常に有名な話であるが、1995 年に Standish グループが全世界の 365 のソフトウェア開発組織を対象にプロジェクトの成功と失敗の割合や、成功や失敗に影響した要因の調査を行った CHAOS レポートという調査結果がある。
CHAOS レポートは、大きな組織ではプロジェクトのうち成功したものは 9% にしか過ぎない等の非常にセンセーショナルな結果を報告しているが、その中で成功や失敗をもたらした大きな要因も報告している。表 1 は、CHAOS レポートで成功や失敗の要因として挙げられているものの上位 4 位までを列挙したものである。
| 成功要因 | 失敗要因 |
|---|---|
| 1.ユーザーの関与 | 1.ユーザからの情報が不足 |
| 2.経営陣のサポート | 2.要求や仕様が不完全 |
| 3.要求の明確な記述 | 3.要求や仕様が変化 |
| 4.適切な計画 | 4.経営陣のサポートが不足 |
この表を見ると、成功と失敗の要因のほとんどが「ソフトウェア要求の開発と管理」に関するものであることが分かる。従って、「ソフトウェア要求の開発と管理」を適切に行えるか否かが、開発の成否を決める大きな要因なのである。
本書では、「ソフトウェア要求の開発と管理」の作業を以下のように大きく分類している。
CHAOS レポートで述べられているような失敗に陥らないためには、これらの作業を行う中で以下のようなことができなければならないのである。
本書は、一言でいうならば“これらの「ソフトウェア要求の開発と管理」の基本的な作業とモデルをコンパクトに凝縮した教科書”だと言える。この本を最初に見たとき、限られたページ数にこんなにコンパクトに「ソフトウェア要求の開発と管理」が凝縮できたということが驚きであった。大げさだと思う人はぜひ書店で本書を手に取り、確かめてほしい。（私の上司は、「教科書ではなく、これぞ実践の書」だとの意見であるが、…）
「ソフトウェア要求の開発と管理」の基本的な作業とモデルは、本書において以下のような形で説明されている。
本書の章立ては、ソフトウェア要求の開発と管理の作業を行う順番に配置されている。
「ソフトウェア要求」の定義、要求の3つのレベル、誰が要求を作成するかが説明されている。要求の3つのレベルとは、以下のようにより根源的なものから詳細なものへとレベル分けをしたものである。
本書は、これらの 3 つのレベルのすべてを必ずしも行う必要はなく、プロジェクトの性格によっては「ユーザー要求」で留めてもよいというスタンスである。また、各レベルを 1 回だけ行うのではなく、複数回反復することを推奨している。
この章では、「ビジネス要求」である「構想記述」の書き方、「用語集」の形式が説明されている。さらに、前述した Standish グループの失敗要因に挙げられているような要求に付随するリスクを識別し、それらのリスクを軽減するための戦略を考える方法が説明されている。
この章では、以下のことが説明されている。
| 作業 | 作業成果 |
|---|---|
| ビジネスをモデリングする | 関係マップ、プロセスマップ、それらの組み合わせ |
| プロジェクトスコープを理解する | コンテクスト図、イベント応答表、ビジネスポリシー、それらの組み合わせ |
| ユーザー要求を詳細化する | アクター表、ユースケース、ダイアログマップ、データモデル、状態図、ビジネスルール、それらの組み合わせやバリエーション |
| 要求のトレードオフを協議する | 優先度を付けた要求 |
この章では、表 2 の 4 つの作業と作業成果を通じてユーザー要求の開発と優先付けを行う方法が説明されている。この表で、「プロセスマップ」は業務フローを表現するためのモデルであり、「ダイアログマップ」は画面遷移図である。モデルの構成としては、「ユースケース」などの UML で規定されているモデルだけではなく、「コンテキスト図」や「データモデル」などには UML 以外のモデルも併用されている。
要求を分析する際に、「ユースケース」の前段階で「プロジェクトのスコープを理解する」ために「コンテキスト図」や「イベント応答表」など抽象度が高く、全体が概観できるモデルを使うという方法が本書のセールスポイントの 1 つになっている。
この章では、「ユーザー要求」と「ソフトウェア要求」を文書化する方法が説明されている。説明の多くは、「ユーザー機能」をどのように「機能要求」へと分解し、分解された「機能要求」と「品質特性」をどのように関連付けていくかという点に割かれている。
この章では、要求の妥当性を確認するための以下の4つの方法が説明されている。
A は、ステークホルダーが集まって行う要求のレビューである。B は、「ユーザー受け入れテスト」で使用するテストケースを考えることで要求の妥当性を確認しようという方法である。C は、特定のシナリオを想定してモデルを辿って、期待する結果が得られるかを確認する方法である。D は、反復的な開発で作るような使い捨てではないプロトタイプを使ってソフトウェアの実現性や要求な不確かな部分を明らかにするというものである。
この章では、一般的な変更管理の手順と、要求に優先度、バージョンなどの属性を追加したり、要求追跡マトリックスにより要求間の依存性を記録する方法が説明されている。
この章では、「新規開発」、「保守」、「パッケージ開発」という異なる種類のプロジェクトにおいて本書で説明した要求プラクティスをどのように適用したらよいかというアドバイスが提供されている。さらに、小規模で基幹系ではなく要求の変更が発生しやすい「変更駆動」プロジェクトと、大規模、基幹系で要求を確定できる「リスク駆動」プロジェクトという 2 つの異なるアプローチのプロジェクトにおいて要求プラクティスをどのように適用すべきかが説明されている。
|
ページのトップへ戻る |
| © 2009 OGIS-RI Co., Ltd. |
|
