前回のシステム設計6に続いて解説します。
検証作業の基本は、考えたサブシステム構成に対してシステム要件の一つひとつに対してどのような振る舞いになるのかを確認することです。まず、FURPS+ で整理したシステム要件のうち、図70に示している機能 (Functionality) について検証したいと思います。再度、図70を下記に示します。
図70. システム要件
図を見ると、機能の最初のシステム要件である「取り扱い商品の確認」は、「お金の投入前はすべての商品をライトアップする」（システム要件 F1.1 とします）と「自販機の中の在庫が切れた場合はその商品はライトアップしない」（システム要件 F1.2 とします）という２つの要件に分かれていることがわかります。それぞれの要件についてサブシステムの振る舞いを考えます。図75 を見てください。
図75. サブシステム構成の検証（その1）
まずシステム要件 F1.1 です。「状態管理サブシステム」がお金が投入される前の待機状態が正常であることを確認して「操作管理サブシステム」に知らせます。知らせを受けた「操作管理サブシステム」は商品のライトをすべてオンにしてユーザからの操作を待ちます。ちなみに、要件 F1.1 には記述していませんが、自販機に異常が見つかった場合には、今の振る舞いと同様に「状態管理サブシステム」は「操作管理サブシステム」に異常であることを知らせ、「操作管理サブシステム」は商品ライトを全部消して何も操作ができないようにする必要があるでしょう。
このように、ある要件を検証するときに関係する新たな要件が出てくるときがあります。このような要件は派生要件としてシステム要件に加えます。今の場合であれば、システム要件 F1.1.1 として「自販機に異常が見つかった場合は商品ライトを消して操作できないようにする」を追加します。
次にシステム要件 F1.2 を考えます。「商品管理サブシステム」は商品在庫があるかどうかを把握し、在庫が切れている商品があれば「操作管理サブシステム」に知らせます。知らせを受けた「操作管理サブシステム」はその商品のライトを消しその状態を維持します。
以上のシステム要件の振る舞いを記述したサブシステム構成の図を使って、サブシステムが受け持つ役割（機能）がシンプルかどうか、サブシステム間のやりとりがシンプルかどうかを確認します。たとえば、「商品管理サブシステム」の役割は「在庫がない商品を確認する」となっていますが、これは、「商品管理サブシステム」が商品ごとのストッカーにセンサーを持ち、商品がないことを知らせるための信号線を確保することでシンプルに実現できそうです。ストッカーなどのハードウェアは化粧品に合うように作り直す必要がありますが、センサーなどの仕組みは既存の自販機から流用できそうです。同様に、「操作管理サブシステム」は在庫がない商品を教えてもらえれば、在庫がある商品だけにライトをつけることは問題ないですし、「状態管理サブシステム」も自販機の状態を常にモニターしているわけですから正常かどうかを判断するのは適切です。どちらもサブシステムも役割としてシンプルなものになっています。
さらに、サブシステム間のやりとりについて検証します。「商品管理サブシステム」は「操作管理サブシステム」に対して「在庫がない商品を知らせる」ことになっていますが、在庫は「商品管理サブシステム」が把握できるデータなので問題はありません。ただ、「操作管理サブシステム」には商品が特定できる...
ちよだプラットフォームスクエア（東京都千代田区神田錦町）を予定
