前回のシステム設計7に続いて解説します。
システム要件の一つひとつについて、サブシステム構成における振る舞いを記述し、各々のサブシステムの役割とサブシステム間のやりとりを検証していきます。ここではもう一つだけ、最後に追加したシステム要件「停電時の商品とお金の保証」について検証作業をやってみましょう。再度、FURPS+のブレークダウンを図73に示します。
図73. FURPS+のブレークダウン
このシステム要件には「停電を検出し補助電源を起動させる」（システム要件 R1.1）「停電を検出したときに投入されたお金を返却口に返す」（システム要件 R1.2）「停電を検出したときに商品口をロックする」（システム要件 R1.3）の３つの要件が含まれています。それぞれの要件についてサブシステム構成にその振る舞いを記述したものが図76です。
図76. サブシステム構成の検証
今回も、まずサブシステムの役割を検証します。図ではみ出してしまっているように、「補助電源を起動する」という役割を果たすサブシステムがないことがわかります。「状態管理サブシステム」の一部にすればサブシステム構成を変える必要はありませんが、自販機の状態をモニターする役割である「状態管理サブシステム」に補助電源の扱いを任せてしまうのは機構的にも電気的にも複雑なことになりそうです。主電源の管理も含めて補助電源を管理するサブシステムを追加した方が良いのではないかという指摘が出てくるでしょう。
次にシステム間のやりとりを見てみます。図では「？」をつけていますが、システム要件 R1.2 の、「商品管理サブシステム」から「金銭管理サブシステム」に「受け取っていない商品を知らせる」というやりとりに注目してください。このお知らせのためには、「商品管理サブシステム」はユーザが選択した商品で商品口にまだ届いていない商品がないかどうかを把握しておく必要があります。商品口の管理は「操作管理サブシステム」の役割の１つだと考えられるので、商品口に商品があるかどうかを「商品管理サブシステム」が管理するのは問題があるという指摘が出るでしょう。さらに、受け取っていない商品を「金銭管理サブシステム」に知らせるのは、その商品を特定できるデータとなるわけですが、その場合、「金銭管理サブシステム」はその商品の値段を把握していないと投入された金額のうちの商品を受け取っていない分を返却口に返すことができません。つまり、金銭管理サブシステムは商品価格を把握していなくてはいけないことになります。商品価格の設定を金銭管理サブシステムに対して行うのは疑問が残ります。
このようなことから、今考えているサブシステム構成では「停電時の商品とお金の保証」というシステム要件をシンプルな振る舞いで実現できないことがわかります。それではどのようなサブシステム構成にすれば良いのかという試行錯誤が必要になるわけです。例題ではかなり簡素化した内容にはなっていますが、作成した一つひとつのシステム要件を使ってシステム構成の妥当性を検証する必要があること、そして、その検証ができることがよりよいサブシステム構成を考え出すための試行錯誤を可能にしていることがわかっていただけたのではないでしょうか。
このような方法をとっていないように見える場合でも、システム設計をやっている人は同様のことを頭の中でやっています。しかし、システム設計をやっている人の暗黙知のままでは、自分自身システム設計スキルを上げていくことは難しいですし、ましては、他の人と協力してシステム設計をやることも、システム設計ができる人を育てることも困難です。現在、どのようにしてサブシステム構成を設計しているのか確認してみて、それが暗黙知に支えられているものであれば、今回のような仕組み化を検討してください。
さて、前回と今回とで説明しているのはシステムエンジニアリングの部分です。実は、この後の工程であるハードウェアエンジニアリングやソフトウェアエンジニアリングの部分も考え方は同じです。システムエンジニアリングはシステム全体をサブシステムにブレークダウンするというシステム設計作業ですが、サブシステムをブロックに、ブロックをハードウェアモジュールとソフトウェアモジュールにというように徐々に小さな単位にブレークダウンするのも同じ考え方で進めます。どのような単位に分解されるのかというだけの違いです。また、分解されるものの呼び方の違いだけです。そういう意味では、システム設計工程を説明している部分は参考程度に考...
