(前NTTデータ フェロー システム科学研究所長)山本 修一郎
連載132回、133回では、要求のまとめ方について紹介した。今回は、いろいろな要求手法が満たすべき品質特性のうち、とくに、適切性を考える。まず、7つの適切性条件を明らかにする。次いで、具体的な要求分析手法について、この適切性条件を評価しよう。
手法が適切である7つの理由
手法の活動には、目的と成果物、ならびに、活動で用いる知識が対応している。したがって、適切な手法であるためには、図1に示す7条件が必要である。
以下では、この7条件について説明する。
図1 手法の活動が適切である理由(クリックで拡大)
(1)知識を適切に利用していること
手法が用いる知識名とその内容が一致している必要がある。たとえば、Kという既存の知識がXであることを主張しているのに、XではないYを知識Kであるとして利用すると、既存知識を誤用していることになる。このように、知識を誤用した手法は不適切である。
(2)活動が合目的的であること
活動手段が活動目的を達成するように構成されている必要がある。目的の達成基準が明確に定義されていないと、目的を達成できない活動内容が記述されているかもしれない。この場合、手法の適用者が目的を達成できていないことに気付かない可能性がある。目的を達成できないような活動を実施してしまうと、活動の偽装になってしまう。
(3)活動が合理的であること
手法に活動PとQがあるとする。このとき、Pの成果物がAを入力とする活動Qの成果物がBである場合、AとBが異なることが期待される。たとえば、BはAのある要素を削除しているか、Aにはないなにか他の要素が追加されているはずだ。そうでなければ、よほど時間や要員の余裕がない活動では、活動Bを実施する意味がない。異なる活動が冗長ではないことが必要である。冗長な活動を実施する時間と人手があれば、早く分析を終わってほしいと願うのが現場である。
(4)活動基準があいまいではないこと
ある活動の成果物が満たすべき条件(活動基準)を明確にする必要がある。この場合、ある成果物に対する活動基準は、類似する対象成果物に対しても適用できるべきである。
たとえば、ある用語Wを含む要求Rが不適切だとする。Wに類似する用語Vを含む要求Sが不適切でないとする。このとき、要求Rと要求Sの種別が同じなら、Wが不適切でVが適切であるとする境界線が明確でなくてはならない。また、要求Rと要求Sの種別が異なる場合、要求種別ごとに適切な用語の範囲が異なることになる。したがって、要求と用語の適切な関係を明確に定義すべきである。
(5)活動が全体的に最適化されていること
ある成果物Aの内容が適切であることを確認する活動では、Aの内容が適切である根拠Eが必要である。しかし、複数の成果物AとBがある場合、成果物ごとに根拠を作成するだけでは、成果物全体に対する根拠を個別的な判断の組合せで構成できるかどうか不明である。
たとえば、活動PとQがあり、Pの成果物AとQの成果物Bがある場合、Pに続いてQを実施するとする。このとき、成果物AとBが最適な内容であることを保証するには、全体的な確認活動が必要である。活動PとQを実施して成果物AとBを作成した場合、成果物ごとに適切であるという根拠を作成するだけでは、成果物全体に対して適切であるとする根拠にはならない。個別的な判断の組合せだけで、成果物の全体が最適であることを保証できるかどうか不明である。
(6)活動と成果物の説明が対応していること
複数の活動と成果物がある場合、これらの活動と成果物の関係が明確に対応している必要がある。たとえば、活動AとB、成果物XとYがあるとする。また、成果物Xの要素がU、V、Wで、活動AがVを作成し、BがWを作成するであるとする。さらに、要素Yを用いてXの要素Uの具体化を支援するとしよう。このとき、最終成果物がX、中間成果物がYである。
この場合、Uの具体化という中間成果物に対応する活動が定義されていなくてはならない。ところが、活動がAとBしか提示されていないので、活動と成果物の対応関係が不明確である。
(7)成果物が合理的であること
複数の要素からなる成果物では、最終成果物の内容に、中間活動の要素が寄与する必要がある。たとえば、活動の入力成果物から、最終成果物が容易に作成できる場合、中間活動の成果物は最終成果物の作成には、不要である。したがって、中間活動要素を削除することにより、手法活動を合理化する必要がある。
手法の適切性の7条件をまとめると、表1のようになる。この適切性条件は手法に対する品質要求でもある。
表1 手法が適切であること(クリックで拡大)
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。
- 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:保証ケース作成支援ツールの概要