要件定義の位置づけ

要件定義

私の考える要件定義の位置づけは以下のようなものです。

　・要件定義行程の後には外部設計の工程がある。
　・要件定義行程の中の非機能要求に基づいて要件定義とは別にアーキテクチャ設計を行う。

ます要件定義の位置づけとして外部設計に先立つシステム化の方向性を決めるものとして位置づけています。
要件定義がマクロなWhat（システムが何をするのか）を決める行程、外部設計が詳細なWhatを決める行程と位置づけています。
そして、要件定義で洗い出された非機能要求を元にシステム全体のHowを決める行程としてアーキテクチャ設計を置いています。

次にマクロなWhatを決める要件定義にどのような情報を含めるかというと、システムの外部の環境とシステムの両方の情報を載せます。
これには前回示した要件定義書として満たすべき二つの特性が関わっています。

　　説明可能であること
　　次の行程（外部設計）の入力となること

■説明可能であること
要件を説明して理解してもらうためには以下の２つの事が大事です。

　・全体から詳細へとつながりをもって説明していく
　・システムが使われる環境を示し、その上でシステムが担うべき事を説明する

この二つのことを実現するためには要件定義として全体視点での情報とそれをブレークダウンした詳細情報へとつながりをもって示されていることが必要になります。
次にシステムを説明するためにはそのシステムが使われる環境を説明しないと理解が得られません。

このような理由からシステムの外部の環境（システムが使われる環境）とシステムの両方の要件が必要になります。

■次の行程の入力になること
要件定義は次の外部設計に先行して実施されるものという位置づけています。そして、要件定義でマクロなWhatを明らかにし、外部設計ではそれに引き続き詳細なWhatを決めていきます。

従って外部設計では要件定義の内容をブレークダウンする形で仕様を詰めていきます。このとき重要なのが、システムがどのように使われるのかと言うことです。外部設計においても「どのようなシステムにするか」というシステムの機能を組立て一貫性のあるシステムにする必要があるので、その判断材料となる情報が要件定義に含まれている必要があります。その判断が「どのようにシステムが使われるか」と言うことになります。

従って要件定義にはシステムが使われる環境とシステムについての要件が記述されている必要があると考えます。

■システム化の方向性を示す
要件定義では上記以外にも大事なことがあります。
それはシステム化の方向性を示していることです。これは要件定義をどの粒度で記述するかは関係なく、必ず方向性を示してなければなりません。

そうでなければ外部設計で仕様を詳細化するときに、議論がぶれてしまうからです。

今回要件定義とそれに続く外部設計ということで書きましたが、これをもってウォーターフォールの開発をイメージしないでください。
あくまでもマクロなWhatとミクロなWhatを分けているということであって進め方として必ず二つの行程で進むわけではありません。
これについては要件定義のプロセスとして後で述べたいと思います。

このような考え方のもと私はRDRAを考えました。

このRDRAの話を次回以降に書きたいと思います。