生き残るために「要求エンジニアリング」を学ぶ：上を目指すエンジニアのための要求エンジニアリング入門（1）（2/3 ページ）
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。
要求エンジニアリングのアウトライン
要求エンジニアリングは、あいまいな要求を取り込み、何を開発すればよいかを明確にし、文書化することを目的としている（注2）。また、本連載ではソフトウェア要求を取り上げるが、ソフトウェア要求はソフトウェアを含むシステム要求の一部として検討されることも多い。日本のものづくりの中核である車両機器、デジタル家電、携帯電話など、ソフトウェアによって製品の付加価値が決定づけられるような、ソフトウェアの比重が高いシステム製品では、ソフトウェアの要求エンジニアリングはますます重要になる。
要求エンジニアリングがその目的を達成するために実施する一般的なプロセスは、大きく「要求開発（Requirements Development）」と「要求管理（Requirements Management）」（注3）に分けて説明される。要求開発は要求を確定するプロセスであり、最終的に要求を明確にした「要求仕様書（SRS：Software Requirements Specification）」という文書をアウトプットする。多くの場合、このプロセスは要求開発プロジェクトが実施する。
要件開発の固有プラクティス：
・SG1：顧客要件を開発する
・SG2：成果物要件を開発する
・SG3：要件を分析し妥当性を確認する
要件管理の固有プラクティス：
・SG1：要件を管理する
実現したいソフトウェアを要求仕様書に記載したとしても、開発を担うプロジェクトが立ち上がらなければ要求を実現することはできない。要求仕様書を後続のプロジェクトにインプットし、開発が約束された要求を「ベースライン要求」と呼んでいる。ベースライン要求が明確になって初めて、後続の開発プロジェクトの実施を担保する予算・人的資源・必要なサーバや機器・ツールなどのリソースを割り当てることができる。
しかし、現実には明確にならないまま、あるいは明確にできないままに開発プロジェクトがスタートすることが多い。この場合、要求の追加・変更を覚悟しなければならない。プロジェクトは最初から失敗のリスクを抱えたスタートとなる。
このため、開発プロジェクトの実施中はベースになった要求を適正に管理することが必要になる。これを実施するプロセスが「要求管理」である。ベースライン要求に対する追加や変更を管理するだけでは足りない。要求の適正な実現が進んでいるかも追跡しなければならない。
要求開発の工程は、さらに「要求抽出」「要求分析」「要求仕様」「（要求の）妥当性確認」の4つのプロセスに分けて説明される。これらのプロセスは、要求を確定するプロジェクトの主要なプロセスである。
この4つをやや詳細にしたものが、「SWEBOK 2004年版」（注4）のソフトウェアエンジニアリングの知識領域の1つとして、その第2章「ソフトウェア要求」に記載されている（図3の「要求抽出」から「妥当性確認」までの4つの箱がこれに対応する）。
SWEBOKと対象分野が異なるが、プロジェクトマネジメントにかかわる基本的な知識を整理した「PMBOK」がグローバルに普及している。PMBOKにとってソフトウェア開発プロジェクトが主要な適用分野であるとしても、これに特化したものではなく、広くプロジェクト全般を対象としている。また、PMBOKの日本語訳ではこの知識の対象領域（knowledge area）を「知識エリア」、他方SWEBOKでは「知識領域」と訳している。
ここまでの記述から、読者は要求エンジニアリングの対象領域を確認することができるだろう。ここでもう一度、「自分の強み」に「要求エンジニアリング」を加えるという本連載の狙いを思い出そう。
Copyright © ITmedia, Inc. All Rights Reserved.