要求分析と要件定義

ねらい

「何を作るか」を確定させる工程を学びます。このレッスンを終えると、要求分析の基本的な手順と、業務要件・機能要件・非機能要件の区別、要件定義の代表的な手法を説明できるようになります。

要求分析

要求分析は、次の基本的な手順で進めます。

1. 要求項目の洗い出しと分析
2. システム化ニーズの整理
3. 前提条件や制約条件の整理
4. 解決策の検討と実現可能性の分析
5. 新しい業務モデルと業務フローの提案

要求を集める手段には、ユーザーニーズ調査、現状分析、課題定義、アンケート、インタビューがあります。インタビューには、質問をあらかじめ固定する構造化インタビュー、大枠だけ決めて掘り下げる半構造化インタビュー、自由に話してもらう非構造化インタビューという3つの形式があります。分析の結果は要求仕様書にまとめます。

要件定義：3つの要件

要件定義の目的は、システムや業務全体の枠組み、システム化の範囲と機能を明らかにすることです。要件は次の3つに分けて定義します。

業務の要求が先にあり、それを実現する機能が定まり、機能以外の品質条件が非機能要件として添えられる、という関係で捉えましょう。

複数の利害関係者がいて、それぞれに要求する内容や重みが異なることも、要件定義の難しさの本質です。

要件定義の手法

要件を分析・記述する手法には、大きく構造化分析手法とオブジェクト指向分析手法があります。

1. 構造化分析手法では、データの流れに着目するDFDや、条件と動作の組合せを表で整理する決定表（デシジョンテーブル）を使います。
2. オブジェクト指向分析手法では、UMLの各種の図を使ってシステムをモデル化します。
3. データの構造を中心に据えて分析するアプローチをDOA（データ中心アプローチ）と呼びます。

利害関係者要件の確認

定義された要件は、実現可能性、妥当性、情報システム戦略との整合性などを検証し、利害関係者（ステークホルダ）間で合意と承認を得ます。冒頭の例のように要求が対立するときは、中立の進行役が議論を促し合意形成を支援するファシリテーションが有効です。合意されない要件は、開発が進んでからの手戻りの火種になります。

例題

次の問いに答えてください。

問1 「検索は3秒以内に応答する」「システムの稼働率は99.5%以上とする」のような、性能や信頼性に関する要件を何といいますか。

問2 条件と動作の組合せを表の形で網羅的に整理する、要件定義やテスト設計で使われる手法を何といいますか。

解答と解説

問1の答えは非機能要件です。機能そのものではなく、性能・信頼性・移行要件といった品質や条件を定めます。

問2の答えは決定表（デシジョンテーブル）です。条件の組合せに漏れがないかを確認できます。

応用

本試験を意識した問題を解いてみましょう。

問 要件定義の活動として、定義した要件について利害関係者間で行うことはどれでしょうか。次の中から選んでください。

1. 実現可能性や妥当性を検証し、合意と承認を得る
2. プログラムの単体テストを実施する
3. 全体開発スケジュールに沿って製造を開始する
4. 運用テストの結果を評価する

解答と解説

答えは1です。定義された要件は、実現可能性、妥当性、情報システム戦略との整合性を検証したうえで、ステークホルダ間で合意し承認を得ます。これが要件定義の締めくくりです。2の単体テストと3の製造は、要件定義よりも後の開発プロセスの活動です。4の運用テストの評価も、開発の終盤に行う活動であり、要件定義の活動ではありません。