要求エンジニアリングは、あいまいな要求を取り込み、何を開発すればよいかを明確にし、文書化することを目的としている(注2)。また、本連載ではソフトウェア要求を取り上げるが、ソフトウェア要求はソフトウェアを含むシステム要求の一部として検討されることも多い。日本のものづくりの中核である車両機器、デジタル家電、携帯電話など、ソフトウェアによって製品の付加価値が決定づけられるような、ソフトウェアの比重が高いシステム製品では、ソフトウェアの要求エンジニアリングはますます重要になる。
要求エンジニアリングがその目的を達成するために実施する一般的なプロセスは、大きく「要求開発(Requirements Development)」と「要求管理(Requirements Management)」(注3)に分けて説明される。要求開発は要求を確定するプロセスであり、最終的に要求を明確にした「要求仕様書(SRS:Software Requirements Specification)」という文書をアウトプットする。多くの場合、このプロセスは要求開発プロジェクトが実施する。
実現したいソフトウェアを要求仕様書に記載したとしても、開発を担うプロジェクトが立ち上がらなければ要求を実現することはできない。要求仕様書を後続のプロジェクトにインプットし、開発が約束された要求を「ベースライン要求」と呼んでいる。ベースライン要求が明確になって初めて、後続の開発プロジェクトの実施を担保する予算・人的資源・必要なサーバや機器・ツールなどのリソースを割り当てることができる。
しかし、現実には明確にならないまま、あるいは明確にできないままに開発プロジェクトがスタートすることが多い。この場合、要求の追加・変更を覚悟しなければならない。プロジェクトは最初から失敗のリスクを抱えたスタートとなる。
このため、開発プロジェクトの実施中はベースになった要求を適正に管理することが必要になる。これを実施するプロセスが「要求管理」である。ベースライン要求に対する追加や変更を管理するだけでは足りない。要求の適正な実現が進んでいるかも追跡しなければならない。
要求開発の工程は、さらに「要求抽出」「要求分析」「要求仕様」「(要求の)妥当性確認」の4つのプロセスに分けて説明される。これらのプロセスは、要求を確定するプロジェクトの主要なプロセスである。
この4つをやや詳細にしたものが、「SWEBOK 2004年版」(注4)のソフトウェアエンジニアリングの知識領域の1つとして、その第2章「ソフトウェア要求」に記載されている(図3の「要求抽出」から「妥当性確認」までの4つの箱がこれに対応する)。
ここまでの記述から、読者は要求エンジニアリングの対象領域を確認することができるだろう。ここでもう一度、「自分の強み」に「要求エンジニアリング」を加えるという本連載の狙いを思い出そう。
Copyright © ITmedia, Inc. All Rights Reserved.