Microsoft PowerPoint - REBOK-ReqSympo Final

Transcription

1 第 6 回要求シンポジウム 要求工学知識体系 (REBOK) 顧客要求をシステム開発へ活かす Win-Win Way 青山幹雄南山大学情報理工学部ソフトウェア工学科 JISA REBOK 企画 WG 座長 miko.aoyama@nifty.com シナリオ 5. さあ,REBOK で Win-Win Way へ for Success 1. 要求工学が成功の鍵 2. REBOK とは 4. REBOK を現場で活かすには 3. 2

2 要求工学が成功の鍵 要求工学の効果 200% 要求定義のコスト効果 : NASA のコスト要求定義統計データ * 超過率が不十分 開発コストで要求定義コストの効果 2-3% コスト超過 =80-200% 8-12% コスト超過 =0-50% 経済産業省 /JUAS の調査 ** 要求定義ができていない 100% 要求定義のコスト効果 予定通り =0%, 予定より超過 =60% 10% 20% [%] できている (N=96) 普通 (N=63) できていない (N=20) % 要求定義のコスト配分比率 予定通り完了ある程度は予定通り完了予定より遅延 出典 : *B. B. Roberts, et al., The Benefit of Integrated, Quantitative Risk Management, INCOSE, ** 企業 IT 動向調査 2011, 経済産業省 /JUAS, 要求工学が成功の鍵要求工学の 成熟化 要求工学研究者による大著 (700~800 ページ超 ) が続々刊行 国内でも 40 冊以上刊行これ1 冊で1.9Kg! 要求工学の習得は大変? 4

3 要求工学が成功の鍵 要求工学に関連する知識体系の出現と課題 要求定義に関する様々な知識体系 (BOK)/ 標準と認定制度 海外 : SWEBOK, BABOK(Business Analysis BOK), IREB のシラバス 国内 : ITSS[IT スキル標準 ] ほか 顧客要求からソフトウェア要求までカバーする知識体系の欠如 BOK SWEBOK(Software Engineering BOK) BABOK(Business Analysis BOK) IREB(Int l RE Board) ITSS(IT Skill Standard) 最新版 2004 V2(2009) V2(2009) V3(2008) 組織 IEEE CS( 米国 ) IIBA( カナダ ) IREB( ドイツ ) 経済産業省 /IPA 対象者 ( 人材 ) 内容 ソフトウェア開発専門家 ソフトウェア工学の中のソフトウェア要求工学 : 基礎知識 ビジネスアナリスト (BA) ビジネス分析 : 専門的手順 要求エンジニア (RE) 要求工学 : 基礎知識 コンサルタント, IT アーキテクト 情報技術とスキル 認定 CSDP*, CSDA CBAP*, CCBA CPRE 情報処理技術者 認定レベル * 学卒で4 年 (7,000 時間 ) 以上のソフトウェア開発実務経験 [ 大学で専攻の場合 2 年 ] * 高度専門家 : 7,500 時間以上のビジネス分析実務経験 初心者 (Foundation Level) 中 ~ 高度技術者 ( スキルレベルを設定 ) 5 要求工学が成功の鍵 日本は要求工学方法論の先進国 提供されている要求工学方法論の例 TERASOLUNA, MOYA(NTT データ ) Tri-shaping( 富士通 ) Ex( エクスペリエンス指向 ) アプローチ ( 日立 ) Openthology( 要求開発アライアンス ) 多くの社内方法論 ユーザ企業, ベンダ企業 要求工学を組織的に実践するには? 出典 : TERASOLUNA: Tri-shaping: Exアプローチ : Openthology: 6

4 REBOK とは REBOK へ至る JISA 要求工学 WG の活動 [2006~2008 年度 ] JISA 要求工学調査検討 WG の活動 : のべ 100 名以上が参画 2006 年度 : 要求開発の組織的取組み : 要求開発コーディネ - タの提案と事例収集 2007 年度 : 要求工学ベストプラクティスの収集と整理 2008 年度 : REBOK の検討とユーザにおける事例収集要求工学の実践的知識の習得と人材育成の仕組み作り [2009 年度 ~] JISA REBOK WG の設立による REBOK 策定 現場の視点から要求工学のグローバルな知識ベースの活用 JISA 要求工学シンポジウムからのフィードバック 2007~2009 年開催 : 各 100 名以上の参加者 2009 年 10 月 2 日第 3 回シンポジウム [REBOK の検討結果の議論 ] 学会 国際会議での発表と討議によるレビュー 2010 年要求工学国際会議 ( REBOK 特別セッショングローバルな要求工学コミュニティとの連携 2011 年 6 月 REBOK 第 1 版刊行 REBOK はアールイーボックとお読み下さい 2010 年要求工学国際会議特別セッション 7 REBOK とは REBOK のミッション 要求工学の全体像 ( 地図 ) を示す スコープ : ビジネス / プロダクト要求, システム要求, ソフトウェア要求 実践の視点からグローバルな要求工学コミュニティの知識を編集 関連知識体系や標準と対応付け可能 :ISO/IEC 29148, ほか ビジネス要求をシステム / ソフトウェア要求へつなげる 高度専門家 初心者 要求展開 : ビジネス要求からシステム, ソフトウェア要求へ展開 人材育成 : 初心者から高度専門家へ ビジネス / プロダクト要求システム要求ソフトウェア要求ソフトウェア開発 BABOK と CBAP[IIBA] ビジネス要求 プロダクト ( 組込み ) 要求 REBOK SWEBOKと CSDP( 高度専門家 ), CSDA( 準専門家 ) [IEEE CS] CPRE[IREB] 参考文献 : ISO/IEC 29148:2011, Systems and Software Engineering Life Cycle Processes Requirements Engineering,

5 REBOK とは要求の 3 層モデル化と要求アナリストの役割定義 要求の 3 層モデル ビジネス / プロダクト要求, ( 情報 ) システム要求, ソフトウェア要求 要求アナリスト *: ユーザ, ベンダによらない要求工学の人材像 ビジネスアナリスト (BA), システムアナリスト, ソフトウェアアナリスト ビジネス 環境 : ステークホルダ, 市場 / ビジネス慣行, 法規制, ほか ビジネス要求 / プロダクト ( 組込み製品 ) 要求 ビジネス戦略 / ゴールビジネスプロセスデータビジネスルール ビジネスアナリスト [ ビジネス要求定義 ] 情報システム ( 情報 ) システム要求システムアナリスト業務要求 [ システム要求定義 ] ソフトウェア要求ハードウェアシステムソフトウェアハードウェア要求システム機能要求非機能要求ソフトウェアアナリスト [ ソフトウェア要求定義 ] * 要求アナリスト : ヨーロッパでは 要求エンジニア とも呼ぶ 9 REBOK とは インクリメンタルでイテラティブな要求工学プロセス インクリメンタル : 要求の 3 階に応じた要求工学プロセス 国際標準 (ISO/IEC 29148:2011) と整合 イテラティブ ( 反復 ): 各層内で要求工学プロセスを反復 要求獲得, 要求分析, 要求仕様化, 要求の検証 妥当性確認 評価 要求の源泉ビジネス戦略, ステークホルダ要求, 既存システム / 既存プロダクトなどの文書, ビジネス / IT 環境 ビジネス / プロダクト要求定義 システム要求定義 ソフトウェア要求定義 ビジネス / プロダクト要求定義書 システム要求仕様書 ソフトウェア要求仕様書インクリメンタル REBOK 要求工学プロセス ビジネス / プロダクト要求工学プロセス ( 情報 ) システム要求工学プロセス ソフトウェア要求工学プロセス 10 適用適用 適用

6 ステム構築実践 要求工学知識体系 (REBOK): REBOK とは REBOK の要求工学プロセス イテラティブ要求工学プロセス要求の源泉( ステークホルダ 文書 等) イテラティブ要求工学プロセス REBOK 共通知識カテゴリ 3. 要求獲得 REBOK 拡張知識カテゴリ 基礎知識 獲得要求 4. 要求分析 エンタープライズ分析プロダクト分析 2. 要求工学プロセス 1. 要求工学の基礎 7. 要求の計画と管理要求開発シ分析要求 5. 要求仕様化 知識 要求仕様書 6. 要求の検証 妥当性確認 評価 8. 実践の考慮点 11 REBOK とは REBOK コア ( 共通知識カテゴリ ) の 8 知識領域 SWEBOK を基礎に, 要求工学の内容を強化した知識体系化 知識カテゴリ : 共通のコア知識とドメインとの接点となる拡張とに分離要求工学知識体系 REBOK(Requirements Engineering Body of Knowledge) REBOK 共通知識カテゴリ (REBOK Core) REBOK 拡張知識カテゴリ 1. 要求工学の基礎 (Requirements Engineering Fundamentals) <<process>> 3 要求獲得 (Requirements Elicitation) <<process>> 5. 要求仕様化 (Requirements Specification) 7. 要求の計画と管理 (Requirements Planning and Management) 2. 要求工学プロセス (Requirements Engineering Process) <<process>> 4. 要求分析 (Requirements Analysis) 注 : 知識領域の番号は REBOK の章番号に対応 <<process>> 6. 要求の検証 妥当性確認 評価 (Requirements Verification, Validation, and Evaluation) 8. 実践の考慮点 (Practical Consideration) 12

7 REBOK とは REBOK コア ( 共通知識カテゴリ ) の 8 知識領域 技術知識 要求工学の基礎, 要求工学プロセス, 要求の計画と管理, 実践の考慮点 プロセス知識 要求獲得, 要求分析, 要求仕様化, 要求の検証と妥当性の確認, 評価 知識領域 内容 要求工学の基礎 要求とそのスコープや性質などの基礎的事項. 機能 / 非機能要求も含む 要求工学プロセス 要求定義と管理のプロセスと主要なアクティビティなどに関する知識 要求獲得 顧客を含むステークホルダを明らかにし, 会議やインタビューなどを通して要求を引出す技術に関する知識 要求分析 要求項目を整理し, その間の関係づけ, 優先順位づけなどを行い, 実現すべき要求を明らかにして絞り込みに関する知識 要求仕様化 分析された要求を規定の書式や表記法で記述する技術に関する知識 要求の検証 妥当性確認 評価 要求間の矛盾がないことや, 必要な顧客の要求項目を満たしていることの確認, あるいは, その達成の度合いを評価する技術などに関する知識 要求の計画と管理要求管理を計画し, 遂行や成果物を管理する技術に関する知識 実践の考慮点 要求工学を実践する上で知っておくべき知識やベストプラクティス 13 要求開発 要求開発 : 要求の獲得から妥当性確認に至る絞り込みと整合 企業戦略, 製品戦略 ステークホルダ ( ユーザ ) のビュー ( 要求の源泉 ) ステークホルダ 既存システム, A,.., Xの要求製品に関する文書 要求獲得 要求の集まり 文書化された要求の集まり 要求分析 要求仕様化 要求の検証 妥当性確認 評価 分析され, 構造化された要求仕様化された要求 ( 要求仕様書 ) 検証され, 合意された要求 ( 要求仕様書 ) 実現可能な要求のスコープ ベンダのビュー 14

8 ソフトウェアの機能要求 非機能要求充足 要求工学知識体系 (REBOK): 要求獲得プロセス 要求獲得 要求工学の原点 = ユーザ / ベンダ協調の出発点 要求獲得プロセス 要求獲得の諸技術を統合 : 単なる 引き出し ではない 3.3 現状システムのモデル化 3.2 現状システムの理解シナリオ分析 ステークホルダ分析 3.4 課題の抽出と原因分析 課題 現状 (As-Is) システム 3.1 ステークホルダの識別 課題解決 = 要求 ステークホルダ 3.5 課題解決に向けたゴールの抽出 ゴール ( 課題が解決された状態 ) 将来 (To-Be) システム 3.8 要求の記述と詳細化 ゴール分析 3.6 ゴール達成手段の抽出 3.7 将来システムのモデル化 15 エンタープライズの要求獲得 要求獲得 = 要求の源泉 獲得方法 獲得方法 ステークホルダ分析 3 つのコア技術 : ステークホルダ分析, ゴール分析, シナリオ分析 ドメイン固有技術 : ビジネス分析, プロダクト ( ドメイン ) 分析 要求の源泉 ステークホルダ 経営者企画 エンドユーザ 監督官庁 ドメイン知識 SME ドキュメント ゴール分析 ビジネス分析 ( エンタープライズ分析 ) シナリオ分析 獲得された要求の要素 ビジネス要求 ビジョン / ミッション ゴール ビジネスケース ビジネスプロセスビジネスルールビジネスデータ システム / ソフトウェア機能要求ユースケース画面遷移 SME: Subject Matter Expert( 当該分野の専門家 ) 16

9 ゴール分析の活用 : ゴールとは ゴール (Goal)[ 目標 (Objective), 目的 (Purpose)] システムのあるべき姿 : ゴールは状態として定義 例 : 常時顧客の欲しい商品を提供できる ゴールの意義 機能要求の前にゴールを合意する まずゴールを合意する : 課題解決とはゴールの達成 機能 / 非機能要求はゴール達成手段 ( 複数ある ) ゴール 機能 / 非機能要求よりゴールは上位で安定 ( 常時顧客の欲しい商品を提供できる ) ゴールの発見実現する 問題から : 現状システムの問題点, 機能 / 顧客クレーム, などリアルタイム顧客需要非機能在庫管理予測 機会から : 経営戦略, 市場調査, 要求新技術の導入実現するシステムの実装 17 ゴール分析の活用 : 戦略ゴールから機能要求へ ソフトゴール (Soft-Goal)[ 戦略的, 抽象的 ] 戦略的目標 システムが持つべき定性的な特性 ( 達成の可否は定性的 ) ハードゴール (Hard Goal)[ 戦術的, 具体的 ] ソフトゴール システム ( ビジネス ) のもつべき望ましい状態 ( 経営目標, 戦略 ) 到達可否や達成の定量的評価可能 ハードゴールの分類ハードゴールハードゴール ( 戦術, 具体目標 ) 達成ゴール : 現状から達成すべきハードゴール ( 戦術, 具体目標 ) ( 戦術, 具体目標 ) 状態への遷移を求める 維持 / 回避ゴール : 現状 ( 良い状態, タスク悪い状態の回避 ) を維持タスク ( 達成手段 ) タスク ( 達成手段 ) タスク (Task): ゴールの達成手段 ( 達成手段 ) 機能要求 18

10 ゴール分析の活用 : コンビニの事例 経営目標から情報システムへゴールとシステムの階層的展開 凡例 ソフトゴールハードゴールタスク ( 経営目標, 戦略 ) ( 戦術, 具体目標 ) 達成顧客 常時顧客の欲しい品を リアルタイム商品確保 提供できる全国規模店舗網 店舗 サプライチェイン管理 ニーズに即応する仕入れ 顧客需要予測 店舗のリアルタイム在庫管理 リアルタイム棚卸し 店舗毎, 商品毎顧客行動情報収集 本社 集配センタ 企業 納入業者 要求範囲 ( コンテキスト ) 入荷商品情報送信 顧客の性別, 齢層の入力 顧客のプロファイルと売り上げデータ 顧客情報 POS で商品情報の入力 POS 店舗 顧客店員商品 参考文献 : S. Bleistein, et al., Requirements Engineering for e-business Systems: Integrating Jackson Problem Diagram with Goal Modeling and BPM, Proc. APSEC 2004, IEEE CS Press, pp 要求の源泉 ( ステークホルダ ) 合意された要求 要求獲得 4.5 要求交渉 獲得された要求項目 要求分析 要求分析プロセス : 要求の合意へ至る要求工学技術の統合 4.1 要求の分類 : 獲得した要求項目を一定の基準に基づき分類 4.2 要求の構造化 : 要求間を関係づけ, 図表などに整理して表現 4.3 要求の割当て : 要求をアーキテクチャに割当て, 実現可能性を確認 4.4 要求の優先順位づけ : 重要度, 緊急度などに基づく優先順位づけ 4.5 要求交渉 : 重要度などに基づき仕様に盛込む要求をユーザと合意 合意 優先順位づけられた要求 4.1 要求の分類 4.2 要求の構造化分類された要求 構造化された要求 4.4 要求の優先順位づけ 4.3 要求の割当て 割当てられた要求 20

11 要求仕様化 要求を規定の書式や表記法で文書化 分析で得られた構造化された要求を規定の書式に従い文書化 国際標準に準拠した文書テンプレート ビジネス要求の文書化 : IEEE Std 準拠 システム要求の仕様化 : IEEE Std 準拠 ソフトウェア要求の仕様化 : IEEE Std 準拠 ステークホルダ要求ビジネス要求プロダクト要求 要求獲得要求分析 要求仕様化プロセスビジネス / プロダクト要求の文書化 ビジネス / プロダクト要求定義書 システム要求の仕様化 システム要求仕様書 ソフトウェア要求の仕様化 ソフトウェア要求仕様書 21 要求の検証 妥当性確認 評価 検証 (Verification)[ 正当性の確認 ] 要求仕様書を構造的, 意味的な特性に照らして正しいことを確認 妥当性確認 (Validation) 要求仕様書がステークホルダ要求を満たしていることを確認 評価 (Evaluation) 要求レビューの組織的実践 種々の要求評価基準に基づき, 要求の良さとリスクを評価 未検証の要求仕様書 検証の条件 検証の作業標準, 規定など 要求仕様書の関連資料, 知識 要求の検証 ステークホルダ要求 検証済み (Well-formed) 要求仕様書 検証報告書 要求の妥当性確認 妥当性確認済み (Valid) 要求仕様書 22

12 要求管理要求開発監視 コントロールプロセス群 要求管理計画書 要求の計画と管理 REBOK の要求管理と PMBOK のプロジェクト管理の融合 プロジェクト管理の計画を補完 : 要求仕様が計画の入力 (1) 要求開発 管理の計画 要求開発計画書 (2) 要求開発実行 ステークホルダ (a) 立上げ プロジェクト管理プロジェクト監視 コントロールプロセス群 要求仕様書 (b) 計画プロセス群 プロジェクト文書 (3) 要求トレース管理 (c) 実行プロセス群 (4) 要求変更管理 (d) 終結プロセス群 23 REBOK を現場で活かすには REBOK 活用のユースケース 要求工学とは何か, 知りたい要求工学の基礎をお読みください後の章は, 必要に応じてお読みください 要求工学の導入を推進したい REBOKで要求工学の全体像をつかんでください要求定義に必要な役割と行うべきアクティビティを理解して下さい 要求工学を適用して良い要求定義をしたい REBOKの中から開発に応じて必要な技術を選んでください全て適用する必要は ありません 要求工学を実践できる人材を育成したい REBOKで要求工学の人材育成コースを作りましょう 1 時間, 1 日,3 日など ステップアップしましょう 24

13 REBOK を現場で活かすには REBOK に基づく望ましい要求定義の構築 REBOK を規範とし, 現行要求定義 (RE-As-Is) の評価 現行の要求定義のプロセスと成果物の評価 要求の計画と管理 : プロジェクト管理との整合性評価 REBOK を利用し, 望ましい要求定義 (RE-To-Be) の構築 基本 4 プロセスの内容再構築と REBOK 知識要素の選択導入 ドメインへの対応 : テーラリングと知識付加 必要とする人材の育成 知識利用 評価規範 望ましい要求定義プロセスと方法 (RE-To-Be) RE 再構築現行の要求定義プロセスと方法 (RE-As-Is) 必要な人材 人材育成 現行の人材 25 さあ,REBOK で Win-Win Way へ ベンダとユーザの Win-Win Way REBOK: ユーザとベンダの共通理解の基盤 個人の経験知を体系的, 組織的な知識化 要求工学の組織的実践 良い要求定義 : ユーザとベンダの共通価値 ユーザ 調達力の向上 提案力の向上 ベンダ REBOK を基盤とし要求定義力の底上げ REBOK はフルセット必要な技術を選択して活用 26

14 さあ,REBOK で Win-Win Way へ 要求工学を成功の梃にしよう 上流工程を梃としよう : ドイツ自動車ソフトウェア開発の事例 総開発コスト : 27% 削減, 開発期間 : 36% 短縮 [%] コスト期間 出典 :M. Broy, Opportunities and Challenges in Software Engineering for the Next Generation Automotive, COMPSAC 2011 Panel, 27 さあ,REBOK で Win-Win Way へ REBOK の今後のロードマップ 要求工学知識体系 (REBOK) ガイドの編成 REBOKの解説と実践の手引き REBOKに基づく人材育成ガイドラインの策定 人材育成カリキュラムのモデル策定 REBOKベストプラクティスと現場からのフィードバック ベストプラクティスの収集と公開 要求工学のグローバルコミュニティとの連係 英語版の作成 アジア太平洋ソフトウェア工学国際会議 (APSEC)2011 [2011 年 12 月, ホーチミン市 ] におけるREBOK 講習会 28

15 さあ,REBOK で Win-Win Way へ 3 つの提言 要求の価値を活かそう 要求工学の本格的な実践を図ろう 要求工学の人材を育成しよう ドロミテ ( イタリアアルプス ) にて 29 REBOK WG メンバ REBOK 企画 WG 青山幹雄 南山大学 ( 座長 ) 斎藤忍 NTTデータ 中谷多哉子 筑波大学 小部山知伸 野村総合研究所 藤田和明 日立ソリューションズ 森田功 富士通 中崎博明 富士通 FIP 斉藤裕一 リコー ITソリューションズ 鈴木三紀夫 ソフトウェアテスト技術振興協会 鈴木律郎 情報サービス産業協会 ( 事務局 ) REBOK 普及 WG 青山幹雄 南山大学 ( 座長 ) 佐藤雅幸 伊藤忠テクノソリューションズ 桶谷貴弘 インテック 小林麻美 インテック 小池輝明 NECネクサソリューションズ 位野木万理 東芝ソリューション 玉置彰宏 日本情報システム ユーザー協会 平山貴子 日本情報システム ユーザー協会 小部山知伸 野村総合研究所 平石輝彦 パナソニック 藤田和明 日立ソリューションズ 大下義勝 日立ソリューションズ 眞木康裕 三菱総研 DCS 有本和樹 リコー ITソリューションズ 鈴木律郎 情報サービス産業協会 ( 事務局 ) 30

16 参考文献 [ 1] A. Abran, et al. (eds.), Guide to the Software Engineering Body of Knowledge, 2004 Version, IEEE Computer Society, [ ソフトウェアエンジニアリング基礎知識体系, オーム社, 2005]. [ 2] 青山幹雄ほか, 要求工学知識体系 (REBOK) の開発と評価, ソフトウェアエンジニアリング最前線 2010, 近代科学社,2010 年 8 月, pp [ 3] M. Aoyama, T. Nakatani, and S. Saito, REBOK Manifest: Towards a Requirements Engineering Body Of Knowledge, Proc. IEEE RE 10, IEEE Computer Society, Sep.-Oct. 2010, pp [ 4] 青山幹雄ほか, 要求工学のモデル論, 電子情報通信学会知能ソフトウェア工学,2011 年 3 月, pp [ 5] 青山幹雄, 要求工学知識体系 REBOK 第 1 版のご紹介,JISA Quarterly, Vol. 102, 2011 年 7 月, pp [ 6] 青山幹雄, 上流からの要求マネジメント, 情報サービス産業白書 , 日経 BP 社, 2011 年 10 月, pp [ 7] M. Aoyama, Requirements Engineering Based on Requirements Engineering Body Of Knowledge (REBOK), APSEC 2011 Tutorial, Ho Chi Minh City, Vietnam, Dec. 2011, [ 8] IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0, IIBA, 2009 [ ビジネスアナリシス知識体系ガイド Version 2.0, IIBA 日本支部, 2009]. [ 9] IREB, Syllabus: IREB Certified Professional for Requirements Engineering Foundation Level, Ver. 2.0, Oct. 2009, [10] ISO/IEC 29148:2011, Systems and Software Engineering Life Cycle Processes Requirements Engineering, [11] JISA REBOK 企画 WG, 要求工学知識体系, 第 1 版, 近代科学社,2011. [12] 経済産業省 /JUAS, 要求仕様策定ガイドライン, [13] 大西淳, 郷健太郎, 要求工学, ソフトウェアテクノロジーシリーズ,Vol. 9, 共立出版,2002. [14] K. E. Wiegers, Software Requirements, 2 nd ed., Microsoft Press, 2003 [ ソフトウェア要求 : 顧客が望むシステムとは, 日経 BPソフトプレス,2003]. [15] 山本修一郎, ゴール指向による!! システム要求管理技法, ソフトリサーチセンター,