(前NTTデータ フェロー システム科学研究所長)山本 修一郎
国際要求工学委員会(Inter-national Requirements Engineering Board,IREB)[1]は、要求工学専門家を認定する制度を提供している。前回はIREBの概要と、提供されている要求工学知識に関する基礎レベルのシラバスから導入EU1、システム境界EU2、ツール支援EU9について紹介した。今回は、要求抽出EU3、要求確認EU7、要求管理EU8について紹介する。
基礎レベルのシラバスの構成
基礎レベルには、要求抽出、要求文書化、要求確認、要求管理についての共通知識が含まれている。さらに基礎レベルには、導入、システム境界、ツール支援についての共通知識がある。これらの知識に対するシラバスは、教育単位(Education Unit, EU)として整理されている。基礎レベルのシラバスの構成を図1に示す。
前回、EU1、EU2、EU9を紹介した。本稿では、EU3、EU7、EU8を紹介する。
今回紹介する基礎レベルのシラバスの内容をまとめて表1に示す。
以下では、教育単位EU3、EU7、EU8について説明する。なお、国際的な一貫性のある教育と試験ができるように、基礎レベルのシラバスには、①一般的な教育目標、②教育目標の説明と教育内容、③必要となる参考文献が記述されている。教育目標では、[L1]知っていること(knowing)、[L2]活用できること(mastering and using)、という2つの認知レベルが割当てられている。
図1 IREB基礎レベル シラバスの構成
表1 IREB 基礎レベル 講義項目(クリックで拡大)
EU3 要求抽出
EU3の教育単位と目標をまとめると、表2に示すようになる。
◆EU3.1 要求の情報源 [L1]
開発すべきシステムに関する要求の抽出は、要求開発活動の重要な活動である。要求抽出の基礎はシステム・コンテクストと要求の情報源からなる。多様な種類の要求の情報源が区別されている。可能な要求の情報源には、ステークホルダ、ドキュメント、既存システムなどがある。
多様な要求の情報源から、ゴールと要求を集めることが要求開発のタスクである。もし情報源が無視されたら、プロジェクトの全工程に重大な否定的結果をもたらすことになる。要求の情報源の文書化では、ステークホルダについて次の情報を少なくとも含む必要がある。
- 名称
- 機能(役割)
- 付加的な個人ならびにコンタクトのためのデータ
- プロジェクト進行過程での時間的空間的可用性
- ステークホルダの適合性
- 専門分野と専門性の程度
- プロジェクトについてのゴールと感心事
企業文化に応じ、ステークホルダとの合意において、口頭あるいは文書によって、タスク、責任、権限などを定義することが適切である。ステークホルダ合意から、各ステークホルダの権利と義務が生じる。ステークホルダに対応することで、動機の欠如や矛盾から要求抽出活動を効果的に守ることができる。プロジェクトによって影響を受けるだけでなく、ステークホルダをプロジェクトに参画させる必要がある。
◆EU3.2 狩野モデルによる要求分類 [L2]
要求抽出では、ステークホルダの満足について要求がどのような重要性を持つかを知ることが重要である。狩野博士のモデルに従って、この満足性を3つに分類できる。
- 基本要因(必須)
- 性能要因(満足)
- 感動要因(魅力)
◆EU3.3 抽出技法 [L2]
意識的、無意識的、そして半意識的なステークホルダ要求を発見するという目的を、抽出技法によって達成することができる。抽出技法の選択に影響する重要要因には、要求についてのリスク要因、人間的影響、組織的影響、機能内容の影響、意図している詳細性がある。多様な要求成果物に対して多様な技法が必要になる。
- 調査技法(インタビュー、質問項目など)
- 創造性技法(ブレインストーミング、ブレインストーミングパラドックス、視点変更、類推技法など)
- 文書指向技法(システム考古学、パースペクティブベースリーディング、要求再利用など)
- 観察技法(現場観察、実習など)
- 支援技法(マインドマップ、ワークショップ、CRCカード、音声映像記録、ユースケースモデリング、試作など)
適切な抽出技法の適用は、プロジェクトの重要なコンピーテンス要因である。多様な抽出技法の組み合わせによって最善の結果が達成される。
表2 EU3の教育と目標(クリックで拡大)
EU7 要求確認
EU7には、表3に示した6個の教育目標があり、それぞれに対して下位の研修単位が用意されている。
◆EU7.1 システム・コンテクスト、システム境界、コンテクスト境界
要求確認の目的は、要求開発で可能な限り早期に要求に含まれる誤りを摘出して修正するために、定義された品質基準(たとえば、正当性や完全性)を要求が満足するかどうかを確認することである。要求文書が後続する開発活動の基礎になるので、後続するすべての開発活動に対して、一つの未検出な要求誤りを修正する労力が開発過程で大きく増加するように、要求誤りが影響する。この理由は、要求の実際の誤りを修正すべきであるだけでなく、詳細設計、実装、テストケースなど、この要求に基づくすべての成果物をやり直す必要があるからである。
表3 要求管理の教育単位と目標(クリックで拡大)
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(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:保証ケース作成支援ツールの概要