ソフトウェア開発の最も困難な問題は、下流工程で要求仕様に起因する欠陥が検出され手戻りが発生することだといわれている。では要求仕様の誤りとは何か?それをどのようにして検出すればいいのか?
今回は、要求誤りの分類と要求レビュについて考えよう。
誤りの構造
そもそも誤りはどのようにして発生するのだろうか?人間の行動は知識に基づいている。ソフトウェア開発では、仕様やコードを記述するという行為と、行為の根拠となる知識が必要である。また上流工程の行為の結果に基づいて、下流工程の行為が実行されるという時間的な順序関係がある。
したがってソフトウェア開発における誤りには図1に示すような構造がある。
図1 ソフトウェア開発における誤りの構造
誤り(error)
知識の誤りと行為の誤りがある。行為が正しくても知識が間違っていれば、要求には欠陥が生じる。これに対して、正しい知識に基づいているが、正しくない行為によって作成された要求にもやはり欠陥が生じる。なお知識と行為がともに誤っていれば、欠陥が生じるのは当然である。
欠陥(defect)
知識や行為の誤りによって、文書やコードに現れる正しくない記述を欠陥という。
失敗(failure)
欠陥に基づいて発生した望ましくない結果を失敗という。文書の欠陥は、その文書を用いて作成された文書のレビュやコードの動作時に望ましくない結果を生じることになり、システム開発の手戻りをもたらす。コードの欠陥はシステムの実行時に望ましくない結果としてシステム障害をもたらす。
ここで、誤り、欠陥、失敗という用語はGilb[1]に従った。
このように、要求誤りを原因となる知識、行為、その帰結というように段階的に分類して理解しておくことで、これらの相互関係を分析することができるようになり、それに基づいて行動やプロセスを変革できるようになる。
失敗まんだら[2]
ところで、失敗といえば「失敗学」で有名になった畑村先生の「失敗まんだら」がある。失敗まんだらの構造を整理すると表1のように、原因、行動、結果になる。
段階 | 分類 | 要因(キーフレーズ) |
---|---|---|
原因 | 個人 |
□無知□不注意□手順の不遵守□誤判断□調査・検討不足 |
個人・組織意外 |
□環境変化への対応不良 |
|
組織 |
□企画不良□価値観不良□組織運営不良 |
|
誰の責任でもない |
□未知 |
|
行動 | 物への行動 |
□計画・設計□製作□使用 |
人への行動 |
□操作□動作□行為 |
|
例外 | 物への結果 |
□破損□不良現象□機能不全 |
外部への影響を伴う結果 |
□二次災害 |
|
人への結果 |
□身体的被害 |
|
組織・社会への結果 |
□組織の損失□社会の被害 |
|
これから必ず起こる結果 |
□未来への被害 |
|
起こるかもしれない結果 |
□起こりうる被害 |
原因には、個人、個人・組織以外、組織、誰の責任でもないという4種類がある。原因として知識だけでなく、組織も考慮している点が注目される。
行動には物への行動と人の行動として、操作、動作、行為に分けている。
知識に関する内容は、無知と未知だ。企画と価値観は知識の形成不良とも考えられる。適切な知識がないことが失敗原因になる。
これら以外は、行為である。したがって、失敗まんだらの原因は、知識と行為に分類できるだろう。
行動については、対象としての物と人に2分類している。ソフトウェア開発の観点で見ると、物がソフトウェアに相当する。この理由は失敗まんだらの要因をみると、計画・設計・製作・使用となっているからである。また失敗まんだらの人の行動要因をみると、操作や動作となっており、システムの利用に際してどのような行動をとるかが整理されていることがわかる。
結果についてみるとシステムの動作結果としてどのような失敗が発生するかが良く整理されている。
ただし、ソフトウェア開発に適用する場合には、次のような注意が必要である。
- 行動段階でソフトウェアを物に対応付ける。
- 行動段階の要因は対象と工程を示すだけである。特定の工程に関する詳細な行動を分類しているのではない。
- 原因の要因の中に知識と行為が混在している。
したがって、失敗まんだらを要求定義の失敗に応用する場合には、どのような知識に基づいてどのような行為の結果としてどのような欠陥が生じたのかを詳細に分析するために適切な拡張が必要になるだろう。
一番のポイントは、要求が記述される文書であることにあり、それに基づく欠陥とはなにかその帰結被害は何かを定義することだ。とくに要求レビュの目的は、可能な限り要求定義段階で要求誤りを発見することにあり、失敗に至る前の段階で欠陥と誤りを排除するしくみが必要になる。
要求誤りとは
要求誤りには、要求仕様書のレビュで指摘された項目のうちで、欠陥であることが確認された項目と、設計、コード化、試験などの下流工程やシステムの運用時に失敗として顕在化する要求仕様の欠陥の2つがある。
レビュ指摘項目と要求誤りの関係を図2に示す。レビュ指摘項目には、表現の違い、重複、指摘誤り、質問、改善提案がある。表現の違いは、要求仕様の作成者とレビュ者との間で異なる表記法を好むことに由来する。したがって、表記法について事前に統一しておくことが望まれる。類似する指摘項目を重複して計上することでレビュ作業の効率は低下する。したがって既出の指摘項目は計上しないようにすべきである。要求に誤りがあるように指摘内容そのものが曖昧だったり間違っていたりすることもある。このような指摘を削減するためにはレビュ参加者のスキルを向上するための手法が必要である。
図2 レビュ指摘項目と要求誤り
要求誤りとして指摘できるかどうか判断できない場合には、要求仕様作成者に質問する必要がある。また指摘項目の中には、開発スコープを越えた改善提案も含まれるかもしれない。
このように要求誤りにはレビュにより摘出できる誤りと摘出できず潜在的に残される誤りがある。指摘漏れとなった要求誤りは下流工程で欠陥が発見されることにより摘出される。
要求誤り原因の分類
Waliaらは、表2に示すように要求誤りの原因を要求誤り分類RET(Requirements Error Taxonomy)と呼んで個人、文書化、プロセスに分類している[3]。たとえば、 個人的な原因をコミュニケーション、参加、ドメイン知識、業務理解、プロセスの実行、認知に分類している。最初に述べた誤り分類に従えば、知識と行為に分けることができる。すなわち、ドメイン知識、業務理解、認知が知識に対応し、コミュニケーション、参加、プロセスの実行が行為に対応するだろう。また、プロセスの実行における誤りがなぜ発生したのかを考えることで、それを防止するために新たな規約を設けることなどが考えられる。
分類 | 要求誤りの原因 |
---|---|
個人 | □コミュニケーション □参加 □ドメイン知識 □業務理解 □プロセスの実行 □認知 |
文書化 | □構成 □標準 □仕様 |
プロセス | □手段 □管理 □抽出 □分析 □追跡性 |
RETを用いることで、次のような分析ができるようになる。
- ◆高頻度の要求誤りには何があるか
- ◆解決に時間のかかる要求誤りは何か
- ◆複数の欠陥を生じる要求誤りには何があるか
もし、要求レビュで指摘項目数だけしか計測していなければ、このような内容に踏み込んだ詳細な分析はできない。したがって要求仕様の品質も分からなければ、適切な改善策もできないことになる。
またRETを開発組織の構成員で共有することも重要である。そうしないと、指摘項目の内容がレビュ参加者によって大幅に異なり、要求レビュの質が保証できなくなるだけでなく、要求レビュプロセスもまた改善できなくなるからである。
要求レビュ
図2で示したように要求仕様書の品質を向上するためには、潜在的な要求誤りとして残される指摘漏れを0にすることが重要になる。しかし時間と資源の制約があるので、これを実現することは実際には困難である。このため表3に示すような要求レビュ手法が研究されている [4][5][6]。
手法 | 説明 |
---|---|
CBR | Checklist based reading レビュ参加者がチェックリストを用いて要求仕様書を検査する。 チェックリストの質問事項に回答することにより要求誤りを発見する。 |
DBR | Defect based reading 欠陥分類ごとに専門のレビュ参加者が要求仕様書を検査する。 |
SBR | Scenario based Reading 誤り分類ごとに摘出するための手続きとしてのシナリオを用いて要求仕様書を検査する。シナリオでは、役割と関心事、情報の抽出手順,抽出した情報についての質問を記述する。 |
PBR | Perspective based Reading ステークホルダの立場(Perspective)から要求仕様書を検査する。 ユーザー、設計者、試験者など立場ごとに異なる欠陥を発見することができる。 |
UBR | Usage based reading ユースケースごとに要求仕様書を検査する。ユーザーの視点に立つことで欠陥の発見を効率化する。 |
CBR Checklist based reading
レビュ参加者がチェックリストを用いて要求仕様書を検査する。チェックリストの質問事項に回答することにより要求誤りを発見する。たとえば表4に示すようなチェックリストを用意しておくことで、指摘項目の見落としがないことを確認できる。
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
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要