Open Knowledge System(3)

　前回までで、コンテキストモデル、要求モデル、業務シナリオ、概念モデルを作成しました。RDRAではこの後、業務フローモデル、利用シーンモデルを作成するのですが、業務シナリオを見ると、フローよりもシーン、私の言葉でいうとフローよりもストック系の業務が大部分のように見えるので、業務は業務シナリオで把握できたという仮説のもと、ユースケースモデルの作成に移りたいと思います。ユースケースを考える中で、必要があれば業務モデルに戻ることにしましょう。

　業務シナリオを見ながら、ユーザーとシステムとの接点をユースケースとして表し、その関係性をprecedesとinvokesで表現します（ユースケースの関係表現は、ICONIXプロセスに基づいています）。また、ユースケースのアクターも関係線により明記しておくのがよいでしょう。

　次は、ユースケースシナリオを記述します。人によっては、随分と冗長な作業をするなぁ、と感じるかもしれませんが、これは、ひとつのことを違う視点で考察することにより、分析の品質を上げることができるためです。例えば、図で表現したことを文章にしてみることで、気づきが生じることがあると思います。
　＊冗長な作業…とは、業務フローモデル、利用シーンモデルを作成した上で、さらにユースケースシナリオを詳細に記述することを前提とした表現です。本文だけでは言葉足らずと気づき、加筆しました。なお、私が定義している要件開発時のライフサイクルについては、こちらを参照してください。

　しかし、ユースケースシナリオをより良く作り上げるために、私は画面イメージをスケッチしたくなりました。

　このように、概念モデルと対比させるような形でスケッチすると良いでしょう。また、HTML対応という「設計」をこの段階に持ち込むことには異論のある方もいると思いますが、私はICONIXの予備設計という概念を参考に、要件開発に設計の要素を適度に加えることにしています。また、要件開発の前工程であるVP（情報化構想立案）やSP（システム企画）では、既にシステム アーキテクチャーの概要が検討されているはずですので、これを考慮した要件開発には正当性があります。言い方を変えると、設計や実装をまったく考慮しない要件開発は現実的ではないと私は思います。

続く…