ホーム >  要求工学 >  2009年3月号 >  第53回：試験工程での要求発見

概要

今回は試験と要求の関係について考えてみよう。

米国のJet Propulsion研究所では、Safety Critical ソフトウェアに関する試験結果に基づいて要求を発見する方法を提案している[1]。この論文が興味深いのは、普通は試験といえば、要求されたことが正しいことを確認することだとしか考えないのに、試験で摘出されたことには、それ以上の意味があることを指摘していることだ。どういうことかと言えば、私も経験があるが試験では、試験で発見された欠陥が実はすべてソフトウェアの誤りではないということだ。ソフトウェアの誤りではない試験結果についてどう考えるかということである。以下では、この問題について前述の論文に基づいて説明しよう。

要求と試験の関係

要求と試験の関係を図１に示した。試験結果には２つの場合がある。

（１）要求どおりの結果になった。つまり、要求が正しく実装されていることを確認した。

（２）要求どおりの結果にならなかった。つまり、要求が正しく実装されていないことを確認した。

ところで、試験結果が正しいかどうかを誰が確認するのだろうか？普通は試験担当が誤りかどうかをまず判断するわけだ。ここで解釈の取り違えが発生する可能性が出てくる。

試験担当は誤りだと指摘するが、実際には誤りではないことがある。逆に、試験担当は誤りではないと指摘しなかったが、実は要求範囲外であって、誤りであった可能性もある。

この関係を整理すると図１のようになるだろう。

要求の範囲内について、試験結果が正しいか（◎）そうでないか（×）
要求の範囲外について、試験結果が正しいか（△）そうでないか（○）

要求の範囲内について実装しているにもかかわらず、試験担当に誤りとして指摘された×の場合には、ソフトウェアを修正する必要はない。

しかし、要求範囲外の実装になっていないということで誤りがあるとして指摘されたとしても、ソフトウェアを訂正する必要はないと考えるだろう。

また要求されていない動作をソフトウェアがしているにもかかわらず、試験担当が正しい動作だと見逃すこともある。

要求発見

試験結果によって発見できる要求を表１に示した。この表では、要求発見の分類と変更対象の関係と主な原因を示している。

要件漏れ

要件漏れを発見している可能性がある。たとえばインタフェース漏れなどである。

想定外の相互作用

複数の要求間の相互作用によって、あってはならない結果にいたる場合がある。要求の振る舞いや事前条件、事後条件の抜けなどが考えられる。

運用手順を見直すことで対処することもできる。

取違え

要求が意味することを試験担当が理解できないために、誤りを指摘する場合がある。文書を修正して意味が伝わるようにする必要がある。

問題票の構成

次に、要求を発見するための問題票を構造化した例を表２に示そう。

問題

試験工程で検出した問題に関する記述では、発見工程、発見契機、発見内容を記述する。発見工程では、結合試験や総合試験などの試験工程なのかを選択する。発見契機では、単一コマンドや機能を試験しているときなのか、ある一連のコマンド操作などを試験しているときに検出した問題なのかを選択する。問題理由には、なぜ誤りだと判断したかを具体的に記述する。

試験担当が問題内容を記述する。

調査

調査内容では、指摘された問題内容が正しいかどうかを要求と比較して判断した結果を記述する。

分析担当が調査内容を記述する。

対処

対処内容として対象サブシステム、修正種別、修正内容を開発担当が記述する。修正対象にはソフトウェア修正、運用手順修正、文書修正がある。修正種別では、何を修正したかという誤り分類を記述する。

これについては、次に述べよう。

誤り箇所の分類例

JPLの例では要求誤りを次の４種に分類している。

• 代入と初期化
• 機能とアルゴリズム
• インタフェース
• タイミング

たとえば火星探査車のソフトウェアの例では、300K行のソフトウェアに対して400個の要求があり171件の問題票を分析したと報告している。この結果、統合試験と総合試験では代入・初期化がそれぞれ17件と６件で、機能アルゴリズムがそれぞれ15件と８件でいずれも誤りが多い。これに対して、インタフェースがそれぞれ６件と１件で、タイミングもそれぞれ５件と２件であり、ともに少なかったようである。

取違えの具体例

火星探査車の問題票の事例では、次のような取違えがあったとしている。

【取違え１】

遠隔装置がオフのとき、コマンドを発行したところリジェクトできず、遠隔装置をリブートしたら処理を完了した。要求どおりの振る舞いであったが、こういう事態があることを補足説明することも考えられる。

【取違え２】

分散コンポーネント間で相手から例外応答を受信した。タイムアウトなどの場合には例外ではなく通常応答である。

【取違え３】

ダウンロード回線がカウンタの値を出力すると誤解したため、カウンタをリセットしても値がそのままになっていた。実際にはそれまでのカウンタ値の最大値を出力していたのである。

---

このように、問題票で見つかる取違えには重要な視点の違いが含まれているので、次のような要求発見ガイドラインが提案されている。

要求発見ガイドライン[1]

問題票が次の条件を満足するとき、問題票の内容を再検討して要求を発見できる可能性がある。

【条件１】

同じ状況が運用で再現する可能性がある。

【条件２】

相互作用に関する取違えがある。

---

問題票をソフトウェアの欠陥を発見する手段として見るだけでなく、要求発見や運用上のミスを防ぐための価値を求める視点でも重要だと思われる。このような観点から問題票をこれまで見ていなかったことが多いのではないだろうか？問題票には重要な知識が含まれているということを示した良いアプローチだと感心する。

筆者の経験でも指摘項目のうちで約半分くらいは「指摘誤り」や「再現性なし」ということで、それ以上の問題票の分析をすることなくそのまま放置していた。実は、このような指摘誤りの中に重要な要求の漏れがあったということになる。たとえば、試験環境では再現しないが現地の環境では動作しないという場合もあった。このときは、現地のハードウェア資源の不足やソフトウェアのバージョンの差異などということで要求外としていたことも多い。しかし、運用環境の資源に対する現状を考慮した要求にすべきではなかったかと反省する。開発側の仮説に現場の運用を合わせるのではなく、最初に運用環境の状況を前提にした仮説を設定すべきであろう。

運用に対する考慮点

誤りではないが誤りであると報告された問題票を擬陽性（false positive）という。擬陽性の問題票を識別することができれば、どこかに試験担当の取違えが含まれているから、この取違えに気づくことで運用における取違えを予防できることになる。

取違えとしては、操作インタフェースの誤解と操作説明の不足が多いということである。このような取違えは、安全性が要求されるソフトウェアでなくても起きることではないだろうか？筆者の経験でも問題票はソフトウェアの信頼性を向上させるためにあり、バグを修正するためだけに使っていた。この場合、バグの修正に使われない問題票は価値がないと思いがちである。しかし、バグ修正につながらない問題票には価値がないどころか、運用操作の信頼性向上に使える重要な知識が含まれている可能性があるのである。

システムと人による操作の相互作用

筆者も航空機の自動発券機の前でうろうろして、結局は人のいる発券カウンターに並んでしまうことがある。先日も成田空港でそうだった。このときは担当者がいて、発券カウンターの横にある自動発券機を使って、私のパスポートを自動発券機にかざして搭乗券を発行してくれた。自動発券機の操作はなかなか難しいものである。電車の自動発券機の前で、お年寄りがおろおろしている光景もときどき見ることがある。いずれもシステムの機能としては正しいに違いないが、一般客には操作が難しくて正しく利用できる可能性が低いということであろう。システムと人による操作の相互作用について要求抽出の段階から検討する必要がある。

ソフトウェアの信頼性と安全性

図２にソフトウェアと運用との関係を示した。ソフトウェアに誤りがあるかどうかは、ソフトウェアが要求を実現しているかどうかを試験することで確認できる。ところがソフトウェアが安全かどうかは、ソフトウェアを運用するときにどのような危険を運用側にもたらすか、もたらさないかで判断される。したがってソフトウェアに誤りがあっても安全な場合もあれば、逆にソフトウェアが正しくても安全ではない場合がある。

本稿で紹介した手法の基本的な着想は、試験担当がソフトウェアを試験する時と、ソフトウェアを運用担当が運用する時の類似性に基づいて、試験担当による取違えに由来する指摘誤りが、実は運用担当による操作誤りを推定できるだろうということである。

まとめ

本稿では試験工程で発見できる要求について紹介した。さらに試験工程で作成される問題票の構成を示した。このような問題票で、問題発見契機、修正対象、修正種別を分析することにより、試験担当と開発担当との解釈の取違えという考えに基づき、たとえソフトウェアが修正されない場合であっても、運用時における操作誤りを予防できる知識を獲得できることを説明した。問題票の知識を活用することにより、ソフトウェアの安全性を運用段階で向上できる可能性がある。

今後の課題としては、問題票からこのような運用知識を獲得するための手法を確立することであろう。また、試験段階でなくても、要求レビュや設計段階でソフトウェアの運用者の視点に立つことで要求の抜けや取違えを発見できる可能性もある。

---

■参考文献

• [1] Robyn R. Lutz, Ines Carmen Mikulski, "Requirements Discovery during the Testing of Safety-Critical Software," icse,pp.578, 25th International Conference on Software Engineering (ICSE'03), 2003