読者の皆さんは，ソフトウエア工学（ソフトウエア・エンジニアリング）をご存じだろうか。これは，ソフトウエア開発に関する先人の知恵と研究者の研究結果，言い換えれば「ベストプラクティス」を体系的にまとめたものである。
「要求工学」注1）は，このソフトウエア工学を構成する重要な領域の1つだ。実際，ソフトウエア工学としてどんな領域があるのかを米IEEE Computer Societyがまとめた「SWEBOK」（Guide to the Software Engineering Body of Knowledge）注2）でも，序章に続く第2章で要求工学を取り上げている。
もっとも，要求工学はまだ発展途上であり，PMBOKなどのように全体がきれいに体系化されているわけではない。様々な研究者やエンジニアが日々新たな考えを示したり，良いプラクティスを紹介したりしている状態で，用語の統一もまだ不完全だ。つまり，1つの標準的な「要求工学」があるわけではない。
だが工学としてまとまりを見せつつあるのも確か。先人たちがまとめた研究や書籍の中には，現場ですぐに応用できる要求定義の手順や技法，ノウハウやTIPS（チップス）が豊富に詰め込まれている。
そこでここでは，主に米国のコンサルタント，Kerl E.Wiegersの著書「ソフトウェア要求」に沿って，要求工学のエッセンスを説明したい。
要求の種類を分類
要求工学ではユーザーの「要求」を扱うが，一口に要求と言っても，業務上の目標から，ユーザーが新システムでやりたいこと，新システムに実装すべき機能など，さまざまなレベルがある。要求定義を難しくしている1つの理由は，こうした様々なレベルの要求を明確に分離しないままに，要求定義を進めることにある。
このため要求工学では，まず「要求の構造」を明らかにする。例えばWiegersは，要求を「機能的要求」と「非機能的要求」に大きく分類している。そのうえで，機能的要求を(1)解決すべき経営課題を表す「業務要求」，(2)新システムで実現しなければならないユーザーの仕事や目標を表す「ユーザー要求」，(3)システム全体の最上位レベルの要求を表す「システム要求」，(4)開発者がシステムに作り込まなければならないソフトウエア機能を表した「機能要求」に分類。もう1つの非機能的要求を(1)規則や慣例など新システムが従わなければならないルールをまとめた「業務ルール」，(2)性能や保守性，信頼性などの「品質属性」，(3)他のシステムとのインタフェースを表す「外部インタフェース」，(4)特定の開発言語など設計・実装時の制限となる「制約」に分類している（図1[拡大表示]）。
このように，「要求」の種類を明確に分類することで，要求に対する認識のズレや，定義すべき事柄が重なったり漏れてしまう事態を防げる。
要求定義の手順も明確に
要求工学は，要求定義のプロセス（手順）も明確にしている。
Wiegersではプロセス全体を，まず要求仕様（成果物）を作成するための「要求開発」（要求定義と同じ意味）と，作成した要求仕様の変更管理／バージョン管理／追跡をプロジェクトの全期間にわたって実施する「要求管理」に大きく分類。さらに要求開発を，(1)ユーザーから要求を引き出す「要求の引き出し」，(2)引き出した要求を分析する「要求の分析」，(3)分析結果を文書や図にまとめる「要求仕様の作成」，(4)レビューやインスペクションで要求仕様を点検する「要求の妥当性確認」の4つの作業に分けている（図2[拡大表示]）。
この4つの作業は順番に進むわけではなく，分析から引き出しに戻ったり，妥当性確認から仕様作成や分析に戻るというように，行きつ戻りつを繰り返しながら要求仕様書を完成させていく。
こうした要求の分類や手順の定義は，Wiegers以外の要求工学の研究でもほぼ同様である。
ベストプラクティスを紹介
要求工学は，要求定義を効率的に実施するために，上で述べたようなプロセスに従って，様々なベストプラクティスを集大成しようとしている。
例えば，Wiegersは表1[拡大表示]に示したようなベストプラクティスを紹介している。上述した4つの作業に沿って紹介すると，まず「要求の引き出し」作業では，「ユーザークラス（システムから見て同じ要求を持ったグループ）を明確にする」，「要求の引き出しを促進するワークショップ（会議）を開く」，「ユースケースを明確にする」，「チャンピオン（ユーザークラスのキーパーソン）を選ぶ」，「仕事中のユーザーを観察する」といったプラクティスを紹介している。
また「要求の分析」作業では，「要求を明確にするためのソフトウエア・プロトタイプを作る」，「要求に優先順位を付ける」，「DFDやER図，UMLなどの図を使って要求をモデル化する」，「データ項目を明確にするためのデータディクショナリを作る」など，「要求仕様の作成」作業では，「SRS（Software Requirements Specification：ソフトウエア要求仕様書）のテンプレート（項目）を選ぶ」，「それぞれの要求に固有なラベルを付ける」，「要求の発生源を明確にする」，「業務ルールを記述する」，「品質属性（非機能要件）を明確にする」などのプラクティスを挙げている。
最後の「要求の妥当性確認」作業では，「仕様書（成果物）のインスペクションを行う」，「新システムの受け入れ基準を定義する」，「テストケースを作成して要求のモデルをテストする」といったプラクティスを紹介している。
要求工学では，さらに各プラクティスごとに，利用できる様々な技法やノウハウ，TIPSをまとめている。ここではあまり細かい内容までは紹介できないが，ぜひ表2[拡大表示]に示すような要求工学の書籍を読んで欲しい。これらの書籍に掲載されたベストプラクティスは，先人が実践し効果的と認められたものばかりである。こうしたベストプラクティスを利用しない手はない。
ただし，一度に要求工学で紹介されているすべてのプラクティスを実行しようと考えない方がよい。プロジェクトの特性や，自社の開発手法，開発プロセス，技術水準などに応じて，少しずつベストプラクティスを採用しながら，プロジェクトごとあるいは企業全体の要求定義プロセスを改善していくべきである。
渡部 洋子（わたなべ ようこ）／戦略経営ネットワーク協同組合 理事クロススペース代表。東北大学理学部卒。ソフトハウスなどでソフト開発を約20年続けた後，独立してクロススペース設立。ITコーディネータとして活動中。システム監査技術者。監訳書に「ソフトウェア要求」，「RFP入門」，「脅威モデル」がある |
