要件定義の体系的な位置づけ

エンジニアリングのベースとしてCMMI、SWEBOK、SLCP共通フレームなどの体系を参照する訳だが、どうも要件定義だけは掴みどころが難しい。設計は、課題解決の原則と抽象レベルごとの段階的詳細化で容易に説明できる。またテストもテストレベルとＶ字モデルの関係で説明は容易だ。しかし、要件定義はそうは行かないのだ。

まずCMMIで要件定義を見てみよう。CMMIのエンジニアリング領域の中では、要件開発(RD)と要件管理(REQM)は勿論だが、要件定義はアーキテクチャ設計も関係するので、技術解(TS)も含むことになる。システム要求(顧客要件)、システム要件(成果物要件)、アーキテクチャ設計の結果に対して、検証(VER)と妥当性確認(VAL)も必要となる。整理すると、RD→TS→PI(成果物統合)という流れと並行してREQMが位置づけられ、各RD、TS、PIでは作業成果物に対してVERとVALを行う構成になる。RD→TSの流れは、システムアーキテクチャ設計、ソフトウェアアーキテクチャ設計、さらに各構成要素の仕様と設計の関係においても繰り返されるのだ。

SWEBOKでは、要求抽出→分析→仕様化→妥当性確認という流れと並行して要求管理が位置づけらている。実際には、要求は段階的特定を行うのでフィードバックや繰り返しが考慮される。CMMIとの単純なマッピングなら、要求抽出→分析→仕様化までが要件開発(RD)に相当し、妥当性確認は勿論VAL、要求管理はREQMに対応する。VERはSWEBOKではレビューなど別な領域で語られることになる。（※SWEBOKでは要求管理に対して、要求抽出→分析→仕様化→妥当性確認の流れを要求開発と呼ぶことがあるので注意のこと）

ここで面倒なのは、要件定義段階で行うシステムアーキテクチャ設計(＝システム方式設計)の扱いだ。アーキテクチャ設計はCMMIでは技術解(TS)にあたるが、SWEBOKでは要求分析の中に包含されている。正確には、SWEBOKでは、システムアーキテクチャ設計はソフトウェアエンジニアリングの対象外とされ、アーキテクチャ設計で識別された構成要素に対して要件を割り付ける作業のみを分析の中で扱うという位置づけになっているのだ。一方、CMMIは、ソフトウェアエンジニアリングもシステムエンジニアリングもハードウェアエンジニアリングも統合しているので、システムアーキテクチャ設計も当然、技術解(TS)で網羅されることになる。

また要件定義をSLCP共通フレームでみるとまた厄介だ。SLCP共通フレームの2007版から「要件定義」という活動の定義が変わり、上位を「要件定義」、下位を「システム要件定義」と「ソフトウェア要件定義」と呼ぶようになった。ネーミングが悪いのでないか。普通なら、抽象レベルで総称的に扱うべきなのに、ソフトウェア要件定義などと同じレベルの活動として「要件定義」を用いているのだ。いまCMMIとSWEBOKで話題にしていた要件定義は、SLCPの上位の要件定義に相当するのかというとそうではない。システム要件定義とソフトウェア要件定義を包含し、さらにSLCPの上位の要件定義もほぼ網羅することになる。しかし、SLCPの上位の要件定義は、企画段階の活動や上流の要求開発といわれる領域の活動も含んでおり、上流方向には若干範囲が広過ぎると言える。