要求分析に表れるソフトウェア技術者の心：上を目指すエンジニアのための要求エンジニアリング入門（3）（2/3 ページ）
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。
IEEEの「要求分析プロセス」
基本的な要求分析プロセスを理解するために、IEEEのSWEBOK（ソフトウェアエンジニアリング基礎知識体系）に記述された要求分析プロセスを紹介する。SWEBOKの要求分析では、
- 要求同士の競合を検出し、解決すること
- システムの境界と、システムがどのように環境とやりとりをするのかを見つけること
- システム要求からソフトウェア要求へと詳細化すること
を主要なプロセスとしている。この表現は、「要求」にはシステム要求があり、その中にソフトウェア要求が混在していることを表している（図4）。そして、このサブプロセスとして、（1）要求のクラス分け、（2）概念モデルづくり、（3）アーキテクチャ設計および要求割り付け、（4）要求折衝を実施するように提唱している。
（1）要求のクラス分け
SWEBOKでは要求分類として、
などを挙げている。
一般に、分類としてこれで十分ということではない。例えばカール・E. ウィーガーズ氏の著書『Software Requirements』（訳書『ソフトウェア要求―顧客が望むシステムとは』）には業務要求（business requirement：ビジネス要求）が登場する。ビジネス要求はシステム要求やソフトウェア要求に比べ、もっと上位の要求であり、また要求範囲も広い。要求分析が難しいものであることをうかがわせている。前回の図5に「要求の階層」を図示したので、あらためて参照してほしい。
ビジネス要求には、いくつものシステム要求、従って複数のハードウェアやソフトウェアへの要求が含まれている。ビジネス要求は、経営成果を追求するために生まれた要求である。この目的のためにシステムが必要になり、そのシステムにハードウェアやソフトウェアが含まれる。そして、システムやソフトウェアを生み出すための開発プロセスも要求として含まれている（図4）。
図3をこの要求の階層で分類してみると、図4に示すように、それぞれの要求の階層に分けて示せるようになるだろう。現実の世界にはもっとたくさんの要求が存在している。素材としての要求は、まさに玉石混交の状態である。要求分析はその中から「これは」という要求を取り出す、あるいは要求の本質にあるものを探り当てる。そして要求をビジネスと結び付けるプロセスである。だから、非常に面白い。
プロダクト要求あるいはプロセス要求
要求の階層は、作り出すべき結果を軸にした分類である。結果の呼び名は階層によって異なって表現されることが多いが、要するに「結果」である。「ビジネス要求」では、ビジネス成果（outcome）と呼ぶ（プロダクトとは呼ばない）。また、業績（performance）と呼ぶこともある。この結果を生み出すための（ビジネス）プロセスや、生み出すために消費可能な資源やコスト、プロダクトやプロセスの品質、実現すべき時期も制約条件（constraints）として要求の一部となる（図4の右端の吹き出しを参照）。それぞれの階層に要求があり、結果があり、そしてプロセスがある。そして、品質や制約条件も付随する。全体は多層構造になっている。
機能要求あるいは非機能要求
機能要求と非機能要求は、要求分析でも定番の分類である。中でも機能要求（functional requirements）は、ある要求に基づいて生み出されるプロダクトに備わっている特徴・能力を表している。
一方、非機能要求（non-functional requirements）は、機能要求に基づいて生み出されるプロダクトに備わっていなければならない品質やコスト、納期などの制約条件を指している。品質の要求には多様な表現があるが、包括的にとらえるには後述のソフトウェア品質特性が大いに参考になるだろう（後出の図7-1から図7-3までを参照）。
（2）概念モデルづくり
問題（要求）領域（problem domain）を特定し要求を理解しやすくするために、通常、コンテキストダイアグラムのような概念モデルを用いた図で表す（図5の右側を参照）。ここで、要求が扱っている対象領域とそれを取り巻く環境とを分ける。対象領域に入っていなければ、要求に対する解決策が提示されないことを指している。
この対象領域は利害関係者の合意で決定する、とされている。実際には、利害関係者の確認が十分でないまま後工程で要求の定義漏れとして発覚し、問題となる。対象領域の決定、要求選択のプロセスを明確にしなければ、この問題を現実的に解決することは不可能である。しかし、多くの組織でこのプロセスを明確にしないまま、問題を生み出し続けている。読者の積極的な対応が望まれている。
また、モデリングに使用する図はコンテキストダイアグラムにとどまらない。ユースケース図、エンティティリレーションシップ図（ER図）、状態遷移図、クラス図、業務フロー図など、多様であり、それぞれの環境に適したものを選択する。
（3）アーキテクチャ設計および要求割り付け
SWEBOKは、要求分析の一部としてシステムとソフトウェアによる解決策にアーキテクチャの検討が必要であると記している。アーキテクチャは、これから作るものがハードウェアにせよソフトウェアにせよ、その構造をどうするかにかかわるものである。つまり、「要求エンジニアリング」では作るべき「what（何を）」と「why（なぜ）」を検討しているのに対し、「アーキテクチャ（構造）」では「how（どのように）」を議論することになる。だから、要求プロセスを完了してから議論するべきであると考えられることが多い。
しかし、要求を分析するプロセスは多くの場合、その要求をどのように満たすかも考えることが多い。だから、この段階でアーキテクチャが出てくるのである。要求アナリストである読者には、さらに「ソフトウェアアーキテクト」としての役割も期待される。読者はいっそう重要な役割を担うことになる。
（4）要求折衝
要求折衝をSWEBOKでは「競合の解決（conflict resolution）」といい換えている。例えば、ソフトウェア要求が増加するに伴ってメモリ容量に対する要求も増える。だから、ソフトウェア開発にはメモリ容量の拡張要求がよく登場する。他方、この拡張要求はハードウェアの制約やコストアップと関連し、要求間で競合が発生する。優先度などを考慮して、適切な妥協点を探さなければならない。
こうした問題は要求分析をしなくても知られている問題である。実際は、ソフトウェアの開発量が増加するに伴い、少しずつメモリ使用量が増え、いつの間にか制約条件を超える。従って、これは要求レベルで競合を解決したつもりでいても、実装してみないと分からない問題でもある。このように、要求分析には限界があることも理解したうえで、要求を実現する開発プロセスに競合状況を監視する仕組みを埋め込まなければならない。
Copyright © ITmedia, Inc. All Rights Reserved.