Club-Zコラム第27回

【第27回】システム設計はサブシステムの開発目標を与える

株式会社RDPi　　代表取締役　石橋　良造

2009.12.17

図77 はサブシステムにブレークダウンしたシステムの内部構造です。図72で示したシステム要件一つひとつについて動作を検証したもので、サブシステム間にその一部を記載しています。細かなところまで見ると気になる点もありますが、説明用サンプルだと考えてください。

図の中心に位置している「操作管理サブシステム」について考えたいと思います。図を見ると、状態管理サブシステム、金銭授受サブシステム、金銭管理サブシステム、商品管理サブシステムのそれぞれとどのような関係でつながっているのかがわかります。図77 では多くを省略してしまっているので、改めて操作管理サブシステムだけを抽出したものが図78 です。

図78 の左欄は図77 を詳細化したもので、「操作管理サブシステム」の説明の「金額表示や商品選択ボタンとその操作を管理する」の具体的な内容です。もともとのシステム要件では Usability（使用性）や Reliability（信頼性）だったもののいくつかが Functionality（機能）になっていることにも注意してください。また、操作管理サブシステムとして新たに定義する必要がある要件も発生します。図78 の右欄に記述しています。この部分はシステム要件の時と同様に、FURPS+ を使って漏れがないように書き出します。

このようにして操作管理サブシステムの要件が整理できると、このサブシステムを担当しているサブチームは設計目標が明確になり、これによって仕様や機能や材料の検討などはじめとする具体的な開発作業をスタートできるようになります。操作管理サブシステム以外についても同様にして図78 のような要件を作成します。前述したように、このサブチームがこのレベルの要件では次に何をやったらいいのかわからないというのであれば、システム設計の担当は、回路やソフトなどの具体的な仕様にまでさらにブレークダウンする必要があります。