要求定義には,数多くのノウハウや技法が存在する。それらを体系的に集大成したのが要求工学である。

 皆さんは,ソフトウエア工学(ソフトウエア・エンジニアリング)をご存じだろうか。これは,ソフトウエア開発に関する先人の知恵と研究者の研究結果,言い換えれば「ベストプラクティス」を体系的にまとめたものである。

 「要求工学」は,このソフトウエア工学を構成する重要な領域の1つだ。実際,ソフトウエア工学としてどんな領域があるのかを米IEEE Computer Societyがまとめた「SWEBOK」(Guide to the Software Engineering Body of Knowledge)でも,序章に続く第2章で要求工学を取り上げている。

 もっとも,要求工学はまだ発展途上であり,PMBOKなどのように全体がきれいに体系化されているわけではない。様々な研究者やエンジニアが日々新たな考えを示したり,良いプラクティスを紹介したりしている状態で,用語の統一もまだ不完全だ。つまり,1つの標準的な「要求工学」があるわけではない。

 だが工学としてまとまりを見せつつあるのも確か。先人たちがまとめた研究や書籍の中には,現場ですぐに応用できる要求定義の手順や技法,ノウハウやTIPS(チップス)が豊富に詰め込まれている。

 そこでここでは,主に米国のコンサルタント,Kerl E.Wiegersの著書「ソフトウェア要求」に沿って,要求工学のエッセンスを説明したい。

要求の種類を分類

 要求工学ではユーザーの「要求」を扱うが,一口に要求と言っても,業務上の目標から,ユーザーが新システムでやりたいこと,新システムに実装すべき機能など,さまざまなレベルがある。要求定義を難しくしている1つの理由は,こうした様々なレベルの要求を明確に分離しないままに,要求定義を進めることにある。

 このため要求工学では,まず「要求の構造」を明らかにする。例えばWiegersは,要求を「機能的要求」と「非機能的要求」に大きく分類している。そのうえで,機能的要求を(1)解決すべき経営課題を表す「業務要求」,(2)新システムで実現しなければならないユーザーの仕事や目標を表す「ユーザー要求」,(3)システム全体の最上位レベルの要求を表す「システム要求」,(4)開発者がシステムに作り込まなければならないソフトウエア機能を表した「機能要求」に分類。もう1つの非機能的要求を(1)規則や慣例など新システムが従わなければならないルールをまとめた「業務ルール」,(2)性能や保守性,信頼性などの「品質属性」,(3)他のシステムとのインタフェースを表す「外部インタフェース」,(4)特定の開発言語など設計・実装時の制限となる「制約」に分類している(図1)。

図1●Wiegersによる要求の種類と関係
図1●Wiegersによる要求の種類と関係

 このように,「要求」の種類を明確に分類することで,要求に対する認識のズレや,定義すべき事柄が重なったり漏れてしまう事態を防げる。