要求分析方法

要求分析は、要求抽出の次のフェーズです。
主な目的としては、抽出された要求を分類して要求間の競合を解決する事にあります。
要求の優先順位が正確に割り当てられていれば、要求間の競合の解消や、開発コストの見積もりが楽になります。
この２つだけはどうしても進めたいではだめ。まずこちらを第一優先に進めるという考え方でなくてはいけません。
※仮に優先順位に優劣が付けられない複数の機能がある場合は、視点を大きくとれば一つの要求になることもあります。

要求分析後、各要求はランク付けされると共に、以下の４つにレベル分けされます。
・必須（mandatory）
・強く望ましい（highly desirable）
・望ましい（desirable）
・任意（optional）

分析する上で必要な観点は以下の4点です。
・要求の必要性
→目標に対して、この要求はどれだけ必要なのか、明確に定義されている事。
・要求間の類似性
→抽出された要求間で、類似性は存在しないかを確認する。
・要求間の一貫性
→抽出された要求同士の一貫性は保たれているか？互いに矛盾しあっていないかを確認する。
・要求の完全性と実現可能性
→要求が正確に抽出されており、全ての要求は現在のリソースで作成可能かを確認する。

上記の観点を持って、以下のプロセスを歩んでいきます。
1.要求の分類を行い、種類ごとに整理する。
2.要求の確認を行い、類似性、一貫性、完全性、必要性を確認する。
3.関係者の合意を得る。

いわゆるお仕事を進める上で、当たり前と言えば当たり前なプロセスです。
概念自体は実体験に基づけるので、イメージしやすいと思います。

最後に、要求分析で用いられる概念モデルの方法を羅列します。
たくさんある概念モデルの中から、適材適所で選択出来るかどうかが要求分析のキモなので、頭の片隅に入れておいても損はしないかと思います。

1.データフローモデル
システムの外部環境やプロセス間で入出力されるデータの流れに基づいて構成要素間の関係をモデル化する方法です。
データをモノとして捉えられるため、認識のすり合わせに最適な手法です。

2.制御フローモデル
プロセス間の制御の流れに基づいて構成要素間の関係をモデル化する方法です。
条件分岐に焦点が当てられる手法のため、有識者同士のすり合わせ向けです。

3.状態モデル
イベントによる状態遷移に基づいて構成要素間の関係をモデル化する方法です。
頻繁に通信を行ったり、リアルタイム更新性のあるシステムにおいて有用です。

4.イベントシーケンスモデル
イベントとその応答の時間的な順序系列に基づいてモデル化する方法です。
使用用途は状態モデルと被るケースが多い。イベント視点かオブジェクト視点かで使い分けましょう。

5.オブジェクト指向モデル
オブジェクトを構成する属性とその操作に基づいて構成要素間の関係をモデル化する方法です。
プログラマーが最も好む手法かと思われますが、オブジェクトの数が増えてくるにつれ作成難易度が上昇します。
システムの堅牢性に自身があるのであればオブジェクト指向モデル一択かと思います。

6.ゴール指向モデル
システムの完成を全体のゴールと捉えて、要所をサブゴールと捉えてモデル化する方法です。
要所と要所間で見積もりを取ることが出来、各目標値の遅れが全体にどう影響するかを把握しやすい事が利点です。

7.概念データモデル
システムが処理対象とするデータの構造を論理的に分析する方法です。
平たく言うとDB設計書に近いです。作成する上で重要な点はエンティティ間の関係であり、
1：1、1：多、多：多なのかを明確に定義しなければいけません。

8.形式的モデル
オブジェクト指向モデルをより厳格化したものです。要求機能や振る舞いを表現するだけでなく、意味も数学的観点から定式化する必要があるそうです。
形式的モデルに基づいてコードを自動生成することを狙いとしている分野もあるらしく、
「ソースコード is 仕様書」となりがちな一般論のアンチテーゼである、「仕様書 is ソースコード」を推進している模様です。
作成難易度は最高レベルかと思われます。

9.ビジネスモデル
ビジネスに関するプレーヤ間の取引関係をモデル化する方法です。オブジェクト指向モデルはシステムに重きを置いてますが、こちらはシステムを使用する人に重きを置いています。
性質上BtoB向きかと思われます。

10.ビジネスプロセスモデル
ビジネスモデル + ゴール指向モデルです。
システムリリース後の事まで視野にいれた考えであり、このモデルを採用する場合は立派なシステムができてもシステムを使いこなすビジネスプロセスがなければ経営課題は解決できないだろうという考えが必要です。
ある程度先見の明が必要となってくるため、難易度は高めかと思われます。