システム設計7 プロジェクト管理の仕組み (その39)

更新日

投稿日

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

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
クレーム率シングルppmをゼロに(5) 【快年童子の豆鉄砲】(その60)

【対策前の効果】 1.はじめに 体質系不具合の原因として、職場体質の欠陥が把握できた時点で効果に言及するのは時期尚早との声が聞こえてきそうですが、...

【対策前の効果】 1.はじめに 体質系不具合の原因として、職場体質の欠陥が把握できた時点で効果に言及するのは時期尚早との声が聞こえてきそうですが、...


アイデアは手書きで洗い出す 新規事業・新商品を生み出す技術戦略(その73)

   数多くの先人達が手書きの効果を示している事例を見聞きしたことはありませんか?  私の経験から、頭の中にぼんやり浮かんだアイデアは、...

   数多くの先人達が手書きの効果を示している事例を見聞きしたことはありませんか?  私の経験から、頭の中にぼんやり浮かんだアイデアは、...


メカトロ設計の3要素 【連載記事紹介】

  ◆メカトロ設計 高度化するとは、メカトロ化することに等しいのです。メカトロニクスは物質(メカ)、エネルギー(エレキ)、情報(ソフト)...

  ◆メカトロ設計 高度化するとは、メカトロ化することに等しいのです。メカトロニクスは物質(メカ)、エネルギー(エレキ)、情報(ソフト)...


「技術マネジメント総合」の活用事例

もっと見る
‐産学交流からの開発テ-マと市場の観察‐  製品・技術開発力強化策の事例(その7)

 前回の事例その6に続いて解説します。産学交流による開発テ-マの探索や共同開発に関心が寄せられています。 大学には基礎研究の面で優れた開発テ-マの候補にな...

 前回の事例その6に続いて解説します。産学交流による開発テ-マの探索や共同開発に関心が寄せられています。 大学には基礎研究の面で優れた開発テ-マの候補にな...


仕組み見直しとグローバル化(その2)

◆「気づき」能力向上のカギは製品開発経験の活用    前回のその1に続いて解説します。「気づき」能力は、擦り合わせ型開発を行う上で技術者が備...

◆「気づき」能力向上のカギは製品開発経験の活用    前回のその1に続いて解説します。「気づき」能力は、擦り合わせ型開発を行う上で技術者が備...


システム設計1 プロジェクト管理の仕組み (その33)

 コンサルタントとして多くの開発現場に入ると、普段使っている単語、もしくは意味しているものが開発現場によって想像以上に違うことを実感します。たとえば、「レ...

 コンサルタントとして多くの開発現場に入ると、普段使っている単語、もしくは意味しているものが開発現場によって想像以上に違うことを実感します。たとえば、「レ...