BABOK 2.0 #7 要求(Requirements)

BABOK2.0についての記事もいろいろ出てきているようだ。BABOKを理解する上で、2つの点に注意すべきだろうと思う。1つは、BABOKは開発ベンダー側視点ではなく、顧客側視点が強調されているということだ。要求開発アライアンスなどでは開発側がどう関わるかに重点があるが、BABOKはあくまで顧客側視点である。開発ベンダー側にいいように振り回されるなという意図が感じられる。

もう1点は、BABOKはPMBOKのように広い知識体系であり、システム開発上流に特化したアプローチの1つではないということだ。もともと方法論には言及されていないし、エンタープライズ分析は1つの知識領域に過ぎない。ソリューションをデリバリした後での評価や、ライフサイクルにおいての継続的な改善も考慮されており、開発の上流のみにとどまってはいない。広い範囲のプロセス領域をスコープとするディシプリンと捉えるべきだろう。

BABOKを理解する上では、まず「要求(Requirements)」をどのようにクラス分けして捉えようとしているかを把握することがポイントになるだろう。ビジネス要求、利害関係者要求、ソリューション要求、移行要求というタイプに分けられている。定義に違和感はない。CMMIでいうなら利害関係者要求は顧客要件であり、ソリューション要求が成果物要件である。IT化を前提とするなら、利害関係者要求はシステム要求であり、ソリューション要求がシステム要件である。

ビジネス要求 (Business Requirements)

ビジネス要求は、企業の高次なゴールや目標やニーズだ。これらはプロジェクトを立ち上げるための理由になり、プロジェクトが達成する目標となり、成否を測るための尺度になる。ビジネス要求は、組織のニーズを全体的に記述するものであり、特定のグループや利害関係者のニーズの記述ではない。ビジネス要求は、エンタープライズ分析において開発され定義される。

利害関係者要求 (Stakeholder Requirements)

利害関係者要求は、特定の利害関係者や利害関係者クラスのニーズだ。利害関係者のニーズと、利害関係者がソリューションに対してどのように関わるかを記述する。利害関係者要求は、ビジネス要求と多様なソリューション要求との間を橋渡しするものになる。利害関係者要求は、要求分析において開発され定義される。

橋渡し(Brige)するという表現がとられているが、これはビジネス要求→利害関係者要求→ソリューション要求のトレーサビリティを前方／後方においても重視するということだろう。

ソリューション要求 (Solution Requirements)

ソリューション要求は、ビジネス要求と利害関係者要求に合致するソリューションの特性(characteristics)を記述するものだ。ソリューション要求は、要求分析において開発され定義される。ソリューション要求は、ソフトウェアソリューションを記述する際には、一般に機能要求と非機能要求のサブカテゴリに分けられる。

機能要求(Functional Requirements)は、ソリューションが管理するふるまいと情報を記述する。個々のふるまいや操作（特定のITアプリケーションのアクションやレスポンス）を実行できるシステムの能力を記述する。

非機能要求(Non-functional Requirements)は、ソリューションのふるまいや機能性に直接関係しない条件を取り扱い、ソリューションが効率を保持すべき環境条件やシステムが確保すべき品質を記述する。品質要求とも補足要求(supplementary)とも言われている。これらには、キャパシティ、スピード、セキュリティ、可用性、情報アーキテクチャ、ユーザーインタフェースに関係する要求を含んでいる。

移行要求 (Transition Requirements)

移行要求は、企業の現状から望まれる将来の状態への移行を手助けするためにソリューションが持たなければならない能力だ。移行は1回で完結する必要はない。移行要求は他の要求タイプとは異なっている。移行要求は、常に一時的であり、既存と新規のソリューションの両方が定義されるまで開発できない。典型的には、既存システムからのデータコンバージョン、スキルギャップをあてがうこと、望まれる将来の状態にいたる他の関連する変更作業を伴う。移行要求は、ソリューションの評価と妥当性確認において開発され定義される。

機能／非機能がソリューション要求のサブカテゴリとして明示されているが、利害関係者要求として非機能要求もあるだろうし、移行要求も非機能要求に分類されるかもしれない。ソリューション要求のみを機能／非機能に分けるということではないだろう。