ビジネス運営定義フェーズでのビジネスルール定義

システム運用をビジネスフロー図とビジネス要求定義書に記述していく過程で、トップダウン分析で漏れていたビジネスルールが追加定義されます。

追加ルールが発生する要因は二つあります。

一つは、漠然と現状分析を行っていたトップダウン分析フェーズに比べて、システム化作業は大きく前進し、ユーザとＳＥとの情報交流も活発になっていることです。

この時点では、ユーザはトップダウン分析の結果、どのようなものをルール化するのかを知っていますし、それを定義することは自分達（ユーザ）のためになることも理解しています。

つまり、ビジネスルールに対して敏感になりつつあるわけです。 さらに、業務工程の詳細（目的、要領など）を検討する過程で、各種の入出力情報（新システムにおけるアウトプット以外）に触れることは、関係するビジネスルールを思い出すきっかけとなります。

ＳＥとユーザとの協調関係が正常であれば、ユーザのほうからビジネスルールを提示してくれるはずです。つまり、トップダウン分析フェーズでいきずまっていたビジネスルールの洗い出し作業が、円滑に再始動されることになるわけです。

もう一つのビジネスルールの発生要因は、ビジネスルフロー図の作成に伴って、工程が細分化されたことにあります。工程が細分化されることによって、細分化された工程間に共通する認識（情報）という概念が生まれます。生まれるというよりは、もともとあったものが明らかになったといったほうが正しいかもしれませんが．．．。

工程をまたがって共通になりえる認識（情報）は、ビジネスルールとして成立する可能性があります。これは、ビジネス要求定義書に何度も同じことを書くのは無駄だという発想で、ビジネスルールブックに記述されることで実現します。

また、工程が細分化されて具体化されることで、工程と工程の間に存在するビジネスルールが浮き彫りになることもあります。　

ビジネス要求定義書には、基本的には該当工程での純粋なビジネス要求を記述し、ビジネスルールはビジネスルールブックに記述します。 受注業務と出荷業務を概念で捉えていた時点では、思い出せなかったものが、受注データをもとに出荷指示を行うという具体的な形で表現された場合に『受注残の管理は？』という形で浮かんできます。このような、単独のビジネス要求定義書では表現しきれない業務要求（仕様）は、ビジネスルールブックに記述します。