要求分析
（ようきゅうぶんせき、
英
:
requirements analysis
）とは、
システム工?
や
ソフトウェア工?
において新たな
システム
やシステム更新に際しての調査/定義に?わる工程を指す。要求分析は
システム設計
工程でも重要な部分であり、アナリストや
システムエンジニア
/
ソフトウェア開?者
が顧客の必要性や要求を特定する工程である。顧客の要求が特定されたら、システム設計者がその解決策を設計することになる。
主な技法
[
編集
]
?念上、要求分析には以下の3つの活動が含まれる:
- 要求を聞きだす: 顧客やユ?ザ?との?話によってその要求を聞きだす。
- 要求を分析する: 要求を必要に?じて明確化し、補い、矛盾点や問題点を明らかにする。
- 要求を記?する: 要求を文書化する。文書形式には通常の自然言語の文書以外に
ユ?スケ?ス
、
ユ?ザ?スト?リ?
などがある。
要求分析は時間のかかる忍耐を要するものとなる場合もあり、微妙な心理?的スキルを要することもある。新たなシステムは人間?係や環境を?えることもあるので、?係者全てを特定しておくことも重要であり、?係者全員のニ?ズを聞き出すと共に、彼らがシステムとどう?わるかを理解していることを確認する必要がある。アナリストは顧客から要求を聞きだすためにいくつかの技法を活用する。
インタビュ?
や
フォ?カスグル?プ
（要求ワ?クショップ）から要求リストを作成するのは古くからある技法である。やや新しい技法として
プロトタイピング
と
ユ?スケ?ス
がある。必要に?じてアナリストはこれらの手法を?使し、?係者の要求を正確に把握する。それによってビジネスの必要性に合ったシステムが開?される。
?係者インタビュ?
[
編集
]
?係者インタビュ?は要求分析の典型的な手法である。工?との兼ね合いで?係者の選?が一般に必要とされる。インタビュ?によってプロジェクトの開始時点で想定していなかった要求が明らかとなり、個?の要求の間で矛盾が生じることがある。
要求ワ?クショップ
[
編集
]
場合によっては?係者を集めた「要求
ワ?クショップ
」を開くのが有?である。ワ?クショップは?係者が集中できる環境で行うのが望ましい。司?役は議論が逸れないよう注意する。また、書記役が議論を記?しておくのがよい。司?役はプロジェクタ?と?作成ソフトウェアを使ったり、紙とマ?カ?による資料を使ったりする。司?役の重要な仕事として、個?の要求の優先順位付けが?加者の個性にあまり依存しすぎないように注意しなければならない。
契約型要求リスト
[
編集
]
要求を文書化する方法として契約型要求リストがある。複?なシステムでは、この要求リストが?百ペ?ジにもなることがある。
??可能な目標
[
編集
]
最善のプロジェクトでは、要求リストを?なる手掛かりとして扱い、繰り返し「何故このような要求が出てきたか」を問いかけて?のビジネスの目的を明らかにする。そして?係者と開?者で各目標の達成?況を測るための基準を設ける。これら目標は個別の（基準のない）要求リストよりも?化しない。重要な目標が達成されたとき、手早いプロトタイピングと開?によってプロジェクトの途中であっても?係者に成果として提供することがある。
プロトタイプ
[
編集
]
1980年代中ごろ、要求分析問題の解決策として「プロトタイピング」が注目された。プロトタイプとは、開?前にユ?ザ?に?してアプリケ?ションを視?化してみせるための?面表示などである。プロトタイプによってユ?ザ?はシステムがどのようなものかを具?的に描くことができるようになり、開?前に設計上の決定を行うことが容易になる。プロトタイプの導入によってユ?ザ?と開?者の?話が大いに改善された。最初に?面の見え方を示しておけば後工程での?更が少なくなり、全?としてコスト削減につながる。
しかしその後、次のような問題は解決できないことがわかってきた:
- マネ?ジャから見れば、プロトタイプが?座に出?てきたのに、?際の開?に時間がかかる理由が理解できない。
- 設計者は?際の開?にあたって一からやり直すことになるのを恐れて、プロトタイプのコ?ドをつぎはぎして?システムを作ることを?制されているように感じる。
- プロトタイプはユ?ザ?インタ?フェイスの設計などには有?である。しかし、本?の要求が何だったのかということとは無?係である。
- 設計者とユ?ザ?がユ?ザ?インタ?フェイスの設計に重点を置きすぎて、?際にビジネスを行うシステムがおろそかになる。
プロトタイプは、?際に動作する簡?なアプリケ?ションの場合もあるが、線?（ワイヤフレ?ム）の場合もある。線?では色をつけないようにして、最終的なシステムの見た目と混同させないようにするのがよいとされる。
ユ?スケ?ス
[
編集
]
ユ?スケ?ス
は、新システムやシステムの改善にあたっての要求を文書化する技法である。各ユ?スケ?スは1つ以上の「シナリオ」を提供し、その中でシステムやエンドユ?ザ?や他のシステムがどのように相互作用を行ってビジネスの目標を達成するかを描く。ユ?スケ?スでは技術的な?門用語を排し、
エンドユ?ザ?
やその分野の?門家にわかる用語を使うのが望ましい。ユ?スケ?スはソフトウェア開?者とエンドユ?ザ?が共同で執筆することも多い。
ユ?スケ?スはソフトウェアの?動を?明する?純なツ?ルである。ユ?スケ?スにはユ?ザ?がインタ?フェイスを通してソフトウェアを動作させる全ての方法に?する文章による記述が含まれる。ユ?スケ?スはソフトウェア?部の動きは記述されないし、どう??されるかも?明されない。?にユ?ザ?が何かをソフトウェアにさせる際の手順を示すだけである。このような形で全てのユ?ザ?とシステムのやり取りが記述されている。
1990年代
、ユ?スケ?スは機能的要求仕?を捉える手法として急速に?まった。特にその起源となったオブジェクト指向の世界で?著であるが、その利用は
オブジェクト指向
システムに限られたものではなく、ユ?スケ?ス自?はオブジェクト指向に縛られた手法ではない。
各ユ?スケ?スは1つのビジネス目標/タスクを達成する方法を描いている。??からの
ソフトウェア工?
の?点からすれば、1つのユ?スケ?スはシステムの1つの機能を描いていると言える。多くのソフトウェアプロジェクトでは、システム全?を記述するのに?十から?百のユ?スケ?スが必要であることを意味する。特定のソフトウェアプロジェクトの形式化の度合いやそのプロジェクトの工程によってユ?スケ?スをどこまで詳細に記述すべきかが決まる。
ユ?スケ?スは、あるビジネス目標を達成する際の外部のアクタ?と?象システムの相互作用を定義する。アクタ?とはシステムの外にあってシステムとやり取りをするものであり、ユ?ザ?だったり、別のシステムだったりする。
ユ?スケ?スではシステムを「ブラックボックス」として扱い、システム外から?測できるやり取りを扱う。これは意?的な方針であり、この方針によって要求仕?の記述が簡略化され、その機能がどのように??されるかという前提（先入?）を排除することができる。
ユ?スケ?スは以下のように記述されるべきである。
- ビジネスの目標を達成するためのビジネスタスクを記述する。
- 適切な詳細さで記述される。
- ソフトウェア開?者が一回のリリ?スで??出?る程度の量である。
ユ?スケ?スは
機能的要求仕?
にとってはよい手法だが、
非機能的要求仕?
には適さない。ただし、
パフォ?マンス?エンジニアリング
では、重要なユ?スケ?スにはそれに??した非機能的要求が存在するとされる。
ソフトウェア要求仕?
[
編集
]
ソフトウェア要求仕?
は、開??象システムの振る舞いを完全に記述したものである。これには、そのソフトウェアとユ?ザ?とのやり取りを全て記述したユ?スケ?スも含まれる。ユ?スケ?スは機能要求仕?とも呼ばれる。ユ?スケ?ス以外に非機能的要求仕?も含まれる。非機能的要求仕?は、設計や??に?する何らかの制限（性能要求、品質要求、設計上の制約など）である。
ソフトウェア要求仕?の記述に?する推?手法は IEEE 830-1998 で示されている。この標準はソフトウェア要求仕?の考えられる構造、望ましい目次、品質などについて記している。
?係者の特定
[
編集
]
1990年代
になって特に?調されるようになったのは、「?係者」の特定である。「?係者」とは?にそのシステムを?注した企業の社員だけに限られない点に注意されたい。他に考えられる「?係者」として次のような人?がいる:
- その企業と?等な?係で密に連携している（あるいはこれから連携が予定されている）企業
- 何らかの事務?理部門
- 組織上上位にある者
問題点
[
編集
]
?係者の問題
[
編集
]
Steve McConnell はその著書
Rapid Development
の中で、要求を集める作業をユ?ザ?が妨げる可能性を以下のように示した:
- ユ?ザ?は自らが何を欲しているか理解していないことがある。
- ユ?ザ?は要求仕?書に?わりたがらないことがある。
- ユ?ザ?は?にスケジュ?ルと費用が確定した?態で新たな要求を出してくる。
- ユ?ザ?との?話には時間がかかる。
- ユ?ザ?はレビュ?に?加したがらないか、?加できないことがある。
- ユ?ザ?は技術に疎い。
- ユ?ザ?は開?工程を理解しない。
このような要因によって要求仕?は開?が開始されてからも?更され?けることになる。
技術者/開?者の問題
[
編集
]
要求分析において技術者や開?者が次のような問題を引き起こすこともある:
- 技術者とエンドユ?ザ?は語彙の違いによって話が通じないことがある。結果として意思疎通できていないにもかかわらず、完全な合意に達したと勘違いしたまま開?を行うことがある。
- 技術者や開?者は要求を?存のシステムやモデルに?てはまるようにしようとする傾向があり、その顧客?用のシステムを開?するのを避けようとする。
- 分析を技術者やプログラマが行ってしまい、?象分野の?門家が?加しないためにユ?ザ?のニ?ズが正しく反映されないことがある。
解決の試み
[
編集
]
このような意思疎通問題の解決策としてそのビジネスの?門家やシステム分析の?門家が雇われることもある。
1990年代
に登場した
プロトタイピング
、
統一モデリング言語
(UML)、
ユ?スケ?ス
、
アジャイルソフトウェア開?
などの技法も??の手法の問題点を解決するべく導入されてきた。
アプリケ?ションのシミュレ?ションツ?ルや定義ツ?ルも市場に出回るようになってきた。このようなツ?ルはユ?ザ?とIT組織の意思疎通問題を解決するよう設計されており、?際にコ?ドを開?する前にアプリケ?ションを試してみることを可能にしている。これらツ?ルの特?は以下の通り:
- 電子ホワイトボ?ドでアプリケ?ションの流れを?示したり代替案を??する。
- ビジネスロジック
やデ?タの必要性を捉える能力
- 最終的なアプリケ?ションをかなりの精度で?現する高機能プロトタイプを生成する能力
- ?話性
- 文脈的な要求やコメントを追記できる機能
- 遠隔ユ?ザ?や分散ユ?ザ?がシミュレ?ションとやりとりする機能
?考文?
[
編集
]
?連項目
[
編集
]
外部リンク
[
編集
]
- 要求分析
山本修一?（NTTデ?タ）、月刊ビジネスコミュニケ?ション