Open Knowledge System(2)

　今日は次期基幹システムのデータ移行作業の日です。私の主な役割は不測の事態に備えた待機ですので、何事もなければ溜まった仕事をかなり片付けられるはずです。
　昨日から作業を始めたOpen Knowledgeが気になったので、脳を活性化する意味で、昨日作ったモデルを投稿することから始めたいと思います。

　前回は、Open Knowledgeのコンテキストモデルを掲載しました。次は、Open Knowledgeの価値である要求モデルを作成します。

　今の段階では、思いつくままに、つまり要望レベルで列挙すればいいと思います。RDRAの思想に則り、できるところから広く浅く作業を進め、広く浅くを積み重ねることによって、十分な要件が開発できればよいという訳です。
　
　＊要望、要求、要件の定義

• 要望　：　アイデア、思いつき
• 要求　：　要望の内、問題解決に必要なもの。
• 要件　：　要求の内、システムに実装するもの。

　Open Knowledgeのように小さなシステムでは、要望の一つひとつがそのままユースケースになりそうな感じです。

　次は、Open Knowledgeを使った業務の姿を業務シナリオでスケッチしてみます。これは、業務モデルを作るための事前作業と私は考えています。

　スケッチですのでこんな感じでちょうど良いのではないでしょうか？　既に、要求モデルにはない要求が盛り込まれていますが、これは後で要求モデルに反映させていきます。このように、静的な機能を想像して作った要求モデルと、動的な動きを想像して作った業務シナリオのふたつにより、あるべきシステムの価値を把握することができます。

　コンテキストモデル、要求モデル、業務シナリオの三つによって、Open Knowledgeのアウトラインが表れてきました。次は、Open Knowledgeの概念を整理しましょう。

　knowledgeという概念だけは、属性まで記述してみました。そのことが、今後の作業に重要だと考えたからです。他の概念については、今の段階で属性を気にすることはないでしょう。
　テキストと添付ファイルの概念は、knowledgeの属性と重複しますが、まあ、今の段階ではこのままにしてみましょう。モデリングに対する私の姿勢は、気になるのなら残しておけということです。不用なものを取るのは簡単ですが、ないものに気づくのは難しいからです。
　概念モデルができたら、これまでのモデルの言葉を概念モデルに合わせましょう。

　分析時に気をつけなければいけないことは、厳密にモデリングし過ぎることです。次の概念モデルはその例です。

　これは明らかな過剰分析です。いわゆる分析の罠、分析地獄です。要件開発の段階で、このような細かい概念を必要とすることはないでしょう。

続く…