ホーム >  要求工学 >  2007年11月号 >  第37回：要求レビュ 

ソフトウェア開発の最も困難な問題は、下流工程で要求仕様に起因する欠陥が検出され手戻りが発生することだといわれている。では要求仕様の誤りとは何か？それをどのようにして検出すればいいのか？

今回は、要求誤りの分類と要求レビュについて考えよう。

誤りの構造

そもそも誤りはどのようにして発生するのだろうか？人間の行動は知識に基づいている。ソフトウェア開発では、仕様やコードを記述するという行為と、行為の根拠となる知識が必要である。また上流工程の行為の結果に基づいて、下流工程の行為が実行されるという時間的な順序関係がある。

したがってソフトウェア開発における誤りには図１に示すような構造がある。

誤り（error）

知識の誤りと行為の誤りがある。行為が正しくても知識が間違っていれば、要求には欠陥が生じる。これに対して、正しい知識に基づいているが、正しくない行為によって作成された要求にもやはり欠陥が生じる。なお知識と行為がともに誤っていれば、欠陥が生じるのは当然である。

欠陥（defect）

知識や行為の誤りによって、文書やコードに現れる正しくない記述を欠陥という。

失敗（failure）

欠陥に基づいて発生した望ましくない結果を失敗という。文書の欠陥は、その文書を用いて作成された文書のレビュやコードの動作時に望ましくない結果を生じることになり、システム開発の手戻りをもたらす。コードの欠陥はシステムの実行時に望ましくない結果としてシステム障害をもたらす。

ここで、誤り、欠陥、失敗という用語はGilb[1]に従った。

このように、要求誤りを原因となる知識、行為、その帰結というように段階的に分類して理解しておくことで、これらの相互関係を分析することができるようになり、それに基づいて行動やプロセスを変革できるようになる。

失敗まんだら[2]

ところで、失敗といえば「失敗学」で有名になった畑村先生の「失敗まんだら」がある。失敗まんだらの構造を整理すると表１のように、原因、行動、結果になる。

原因には、個人、個人・組織以外、組織、誰の責任でもないという４種類がある。原因として知識だけでなく、組織も考慮している点が注目される。

行動には物への行動と人の行動として、操作、動作、行為に分けている。

知識に関する内容は、無知と未知だ。企画と価値観は知識の形成不良とも考えられる。適切な知識がないことが失敗原因になる。

これら以外は、行為である。したがって、失敗まんだらの原因は、知識と行為に分類できるだろう。

行動については、対象としての物と人に２分類している。ソフトウェア開発の観点で見ると、物がソフトウェアに相当する。この理由は失敗まんだらの要因をみると、計画・設計・製作・使用となっているからである。また失敗まんだらの人の行動要因をみると、操作や動作となっており、システムの利用に際してどのような行動をとるかが整理されていることがわかる。

結果についてみるとシステムの動作結果としてどのような失敗が発生するかが良く整理されている。

ただし、ソフトウェア開発に適用する場合には、次のような注意が必要である。

• 行動段階でソフトウェアを物に対応付ける。
• 行動段階の要因は対象と工程を示すだけである。特定の工程に関する詳細な行動を分類しているのではない。
• 原因の要因の中に知識と行為が混在している。

したがって、失敗まんだらを要求定義の失敗に応用する場合には、どのような知識に基づいてどのような行為の結果としてどのような欠陥が生じたのかを詳細に分析するために適切な拡張が必要になるだろう。

一番のポイントは、要求が記述される文書であることにあり、それに基づく欠陥とはなにかその帰結被害は何かを定義することだ。とくに要求レビュの目的は、可能な限り要求定義段階で要求誤りを発見することにあり、失敗に至る前の段階で欠陥と誤りを排除するしくみが必要になる。

要求誤りとは

要求誤りには、要求仕様書のレビュで指摘された項目のうちで、欠陥であることが確認された項目と、設計、コード化、試験などの下流工程やシステムの運用時に失敗として顕在化する要求仕様の欠陥の２つがある。

レビュ指摘項目と要求誤りの関係を図２に示す。レビュ指摘項目には、表現の違い、重複、指摘誤り、質問、改善提案がある。表現の違いは、要求仕様の作成者とレビュ者との間で異なる表記法を好むことに由来する。したがって、表記法について事前に統一しておくことが望まれる。類似する指摘項目を重複して計上することでレビュ作業の効率は低下する。したがって既出の指摘項目は計上しないようにすべきである。要求に誤りがあるように指摘内容そのものが曖昧だったり間違っていたりすることもある。このような指摘を削減するためにはレビュ参加者のスキルを向上するための手法が必要である。

要求誤りとして指摘できるかどうか判断できない場合には、要求仕様作成者に質問する必要がある。また指摘項目の中には、開発スコープを越えた改善提案も含まれるかもしれない。

このように要求誤りにはレビュにより摘出できる誤りと摘出できず潜在的に残される誤りがある。指摘漏れとなった要求誤りは下流工程で欠陥が発見されることにより摘出される。

要求誤り原因の分類

Waliaらは、表２に示すように要求誤りの原因を要求誤り分類RET（Requirements Error Taxonomy）と呼んで個人、文書化、プロセスに分類している[3]。たとえば、 個人的な原因をコミュニケーション、参加、ドメイン知識、業務理解、プロセスの実行、認知に分類している。最初に述べた誤り分類に従えば、知識と行為に分けることができる。すなわち、ドメイン知識、業務理解、認知が知識に対応し、コミュニケーション、参加、プロセスの実行が行為に対応するだろう。また、プロセスの実行における誤りがなぜ発生したのかを考えることで、それを防止するために新たな規約を設けることなどが考えられる。

RETを用いることで、次のような分析ができるようになる。

• ◆高頻度の要求誤りには何があるか
• ◆解決に時間のかかる要求誤りは何か
• ◆複数の欠陥を生じる要求誤りには何があるか

もし、要求レビュで指摘項目数だけしか計測していなければ、このような内容に踏み込んだ詳細な分析はできない。したがって要求仕様の品質も分からなければ、適切な改善策もできないことになる。

またRETを開発組織の構成員で共有することも重要である。そうしないと、指摘項目の内容がレビュ参加者によって大幅に異なり、要求レビュの質が保証できなくなるだけでなく、要求レビュプロセスもまた改善できなくなるからである。

要求レビュ

図２で示したように要求仕様書の品質を向上するためには、潜在的な要求誤りとして残される指摘漏れを0にすることが重要になる。しかし時間と資源の制約があるので、これを実現することは実際には困難である。このため表3に示すような要求レビュ手法が研究されている [4][5][6]。

CBR　Checklist based reading

レビュ参加者がチェックリストを用いて要求仕様書を検査する。チェックリストの質問事項に回答することにより要求誤りを発見する。たとえば表４に示すようなチェックリストを用意しておくことで、指摘項目の見落としがないことを確認できる。

DBR　Defect based reading

欠陥分類ごとに専門のレビュ参加者が要求仕様書を検査する。たとえば、Porterらは欠陥分類ごとに、摘出するためのシナリオを用意している[7]。またVilbergsdottirらは操作性に対する問題分類を提案している[8]。

SBR　Scenario based Reading

誤り分類ごとに摘出するための手続きとしてのシナリオを用いて要求仕様書を検査する。シナリオでは、役割と関心事、情報の抽出手順、抽出した情報についての質問を記述する。

PBR　Perspective based Reading

ステークホルダの立場（Perspective）から要求仕様書を検査する。ユーザー、設計者、試験者など立場ごとに異なる欠陥を発見することができる。PBRはSBRの一種である。

UBR　Usage based reading

ユースケースごとに要求仕様書を検査する。ユーザーの視点に立つことで欠陥の発見を効率化する。UBRもSBRの一種である。

要求仕様のレビュ手法ではないが、野中がコードレビュに対してUBRとDBRを融合したTCBR（Test Case Based Reading）を提案している[9]。

要求レビュの留意点

レビュ手法を組織やプロセスを含めたソフトウェア開発プロジェクトの特性に応じて最適化する必要がある。たとえば開発プロセスへのレビュ手法の融合、系統的なレビュ手法の教育、目的に応じたレビュ手法の選択が重要であるとされている[10]。

要求仕様の完成度を高めるために要求をレビュする。このとき要求レビュの速度（どれだけの時間でどれだけの文書を検査するのか）や要求誤り摘出数、摘出速度やそれらに基づくレビュ終了基準などをどのように設定するのか、機能テストや結合テストとの役割分担をどうするのかなどの課題に取り組むことで開発プロセスにレビュ手法を融合する必要がある。

また詳細設計してみないと、インタフェース、チェック、タイミング、アルゴリズムなどについては誤りを検出しにくいことも事実である。これらの誤りが欠陥として摘出された時点で、それが要求誤りであるとどのようにして判断すれば良いのかについても議論する必要がある。アルゴリズムは詳細設計で作成するとしてもその元となる知識は要求仕様で定義されているはずだ。アルゴリズムを構成する知識のどこまでが要求で定義されているのか？

その責任の分解点が問題になる。

まとめ

今回は要求誤りの分類と要求レビュについて説明した。要求仕様のレビュは古くから行われているが、要求のモデリングに比べると要求仕様をレビュするための手法についてはまだ十分に実践されているとは言いがたい。

要求レビュの実践的な研究と現場での活用が進展することを期待したい。

---

■参考文献

• [1]Tom Gilb, Dorothy Graham著　伊土誠一，富野壽監訳，ソフトウェアインスペクション，共立出版,1999
• [2]独立行政法人科学技術振興機構（JST）失敗知識データベース整備事業，失敗まんだらとは?，http://shippai.jst.go.jp/fkd/Search
• [3]Gursimran S. Walia, Jeffrey Carver, Thomas Philip , Requirement Error Abstraction and Classification: An Empirical Study, Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering ISESE '06
• [4]Biffl, S.; Halling, M., Investigating the defect detection effectiveness and cost benefit of nominal inspection teams, Software Engineering, IEEE Transactions on, Volume 29, Issue 5, May 2003 Page(s):385?397
• [5]Tomas Berling, Thomas Thelin, A Case Study of Reading Techniques in a Software Company, Proceedings of the 2004 International Symposium on Empirical Software Engineering (ISESE’04), 2004
• [6]Shull, F.; Rus, I.; Basili, V., How perspective-based reading can improve requirements inspections, Computer, Volume 33, Issue 7, July 2000 Page(s):73-79
• [7]Porter, A.A.; Votta, L.G., An experiment to assess different defect detection methods for software requirements inspections, Software Engineering, 1994. Proceedings. ICSE-16., 16th International Conference on, Date:16-21 May 1994, Pages: 103-112
• [8]Sigurbjorg Groa Vilbergsdottir, Ebba Thora Hvannberg, Effie Lai-Chong Law, Classification of usability problems (CUP) scheme: augmentation and exploitation , Proceedings of the 4th Nordic conference on Human-computer interaction: changing roles NordiCHI '06, 2006
• [9]野中誠, 設計・ソースコードを対象とした個人レビュー手法の比較実験, 情報処理学会研究報告 SE-146-4, November 2004, www.se.mng.toyo.ac.jp/jp/archives/public/nonaka_sigse146p.pdf
• [10]Ciolkowski, M.; Laitenberger, O.; Biffl, S., Software reviews, the state of the practice, Software, IEEE, Volume 20, Issue 6, Nov.-Dec. 2003 Page(s):46-51