ロボットシステムの設計について(2)：要件定義

ロボットに限らず、システムを設計する際は以下の流れになるはずです。

• 要件定義（Requirements）
• 全体設計（System-wide Design）
• 分割統治（Divide and Conquer）

ロボットシステムの要件定義について見てみましょう。

要求と要件

そもそも、「要求」と「要件」の違いってなんだか分かりますか？

一言でいうと、ユーザーがシステムに求めていることが要求であり、それを満たすために設計者がシステムに求めていることが要件です。要件を決めていく作業が、要件定義です。

要件は、上位の要求または要件を満たすために下位の要件が連なって、階層的なツリー構造になっています。下位の要件はだんだん具体的になっていき、要件が十分に具体的になれば、それは「仕様」として機能や性能を考えることができます。これらの要件を決めて、具体的な仕様レベルまで落とし込んでいかないとシステムの設計や実装に入れないし、入ってはダメです。

簡単そうに思えますが、正直いってこの部分が設計プロセスの中で一番難しいのではないかと思います。もしここでしくじると、最終的に出来上がったものが「コレジャナイ…」となってしまい、あとで挽回するのが非常に難しいからです。

なぜ難しいか

例として、「料理をするロボット」が要求ならば、「具材をフライパンに入れる」「フライパンで加熱調理する」「料理をお皿に盛りつける」が要件になり得ます。「なり得ます」と言ったのは、このレベルの「要求」と「要件」はまだ抽象的で、可能性や組み合わせがあまりにも多く、唯一の正しい解があるわけではないからです。

まず注意しなければいけないのは、そもそもの要求というのが常に曖昧であるということです。通常、要求を出す人はロボットやシステムの専門家ではないので、「なんかいい感じにしてください」としか言いません。欲しがってる側も、自分が何を欲しがってるかを分かっていないのです。これは、システム設計する人はいやというほど経験しているはずです。

その結果、隠れた要求が必ずあります。例えば、製品の価格はこれ以下じゃないと買えないよとか、このスペースに置けないとダメなんです、とか、最初は言わなかったのによく聞いたら要求がたくさん出てきます。これらを見逃すことが、ロボットが製品として成り立たなくなる原因の一つです。

また、要求に対する要件も、無限のパターンがあります。ロボットシステムの特徴である、「現実世界」の広さやハードとソフトの組み合わせを考えると、実現方法がたくさんありすぎる。「料理をするロボット」の要件として、具材は誰が切る？加熱にはフライパン？オーブンや電子レンジを使う？盛り付け用の皿は誰が用意する？ロボットは腕や手を持っているの？ ロボットの姿はまだ影も形もないので、どれが一番良いかも分からないし、そもそも実現可能なのすらよく分からない場合が多いです。

ループを回す

だから、この要件定義のプロセスは必ず、要求の確認→要件定義→要求の確認→要件定義…と繰り返していく必要があります。設定した要件の組み合わせで要求が満たせるのかを判断して、要求を満たしてない場合はまた要件定義を行い、また確認する、というループになります。要件定義が一発でできることは絶対にありません。

要件はある程度具体的にイメージできるものになっていくので、それなら要求を満たせそうだね、もしくは、それだと別の要求が満たせないね、ということが徐々に分かっていきます。最終的には定義された要件ですべての要求を満たせることが確認されるか、もしくは、要求の一部はあきらめてもらうことを検討するかもしれません。それらが解決すれば、やっと次の段階に進めます。

要求と要件定義の手法

要件定義には代表的なものとして以下のような方法があります。といっても、どれも要件定義のまとめ方のガイドライン的なものとテンプレートで、そこまでかっちりした方法ではないです。

• IEEE 830 (IEEE Std 830-1998)
• EARS
• USDM

最近は、USDMが良さそうだなと思い、USDM用のツールを自作してみたりしていました。

どれがロボットシステムの要件定義に適しているのか、もしくは他にもっといい方法があるのか… すいませんが、私自身もまだ答えを持っていません。むしろ良い方法があれば教えてほしいくらいです。ただ、どういう手法にせよ、ここで書いたような要求→要件→仕様のプロセスで手を抜かないことが、そのあとの設計や実装の効率を大きく左右することだけは確実に言えます。この観点が抜けていて実装だけをやりたがる人は、手戻りが多くなってしまうので注意しましょう…

次回は、全体設計について見ていきます。

初出：Note