レビューの前にするべきこと

レビューの前にするべきこと

　「先ほどのソフトウエア要求の初期案では、仕様の完全性に問題があるのでレビューできる状態にない。まずは、状態と入力イベントの組み合わせを網羅した仕様を作成すべきだ」と回答できた方は合格です。不完全な情報に基づいてレビューしても、後から追加された情報によって「仕様の問題」が変わってしまう可能性があるからです。不完全な情報に基づいてレビューしても、時間の無駄であり、本質的な問題解決からはほど遠い結果しか得られません。

　なお、これは、仕様の問題指摘を目的とした技術レビューの話であり、要求開発など他の目的であればこれとは異なる戦略が必要です。

　重要なのは、なぜこのような不完全なソフトウエア要求が提示されてしまったのか、その原因系に着目してプロセスや技法を改善することです。この例では、ソフトウエア要求の記述フォーマットが完全性の確保とは無縁であり、断片的な検討しかなされなかったのが問題でした。

　このシステムのように、入力イベントが与えられたときに、システムの状態に応じて異なる振る舞いをするシステムを、リアクティブシステムと呼びます。多くの組み込みシステムはこのタイプに分類されます。状態と入力イベントの組み合わせについて完全性を満たしたソフトウエア要求を考えるには、状態遷移表（図2）が便利です。

　状態遷移表は、表頭の状態において、表側の入力イベントが与えられたときに、表頭の状態から交点セルに示した状態へと遷移する、ということを表しています。図2では、例えばシステムの状態が「在室（正常）」のときに、入力イベント「外から施錠」が与えられると、システムの状態は「不在」へと遷移することを表しています。

　状態遷移表の表記法はさまざまですが、ここでは、状態が遷移しない（同じ状態のまま）場合は「－」で、ある状態において発生することがない入力イベントの組み合わせは「N/A」で示しています。なお、本来ならば状態遷移時に発せられるアクションも一緒に記述すべきですが、ここでは単純化のために省略しています。

レビュー演習（その2）

　さて、発注者に検討してもらった結果、ソフトウエア要求の改訂案として、図2の状態遷移表が作成されたとします。再び、仕様上の問題を指摘するという目的に絞って、この状態遷移表をレビューしてみましょう。あなたなら、どのようなレビュー戦略を立てますか？また、どのような観点について重点的にレビューしますか？