Your SlideShare is downloading. ×
0
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
要求管理を確実に行うための知識と方法
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

要求管理を確実に行うための知識と方法

2,368

Published on

2012年3月にスパークシステムズジャパン株式会社主催の「要求管理を確実に行うための知識と方法セミナー」にて、SPEI三宅が講演した内容です。

2012年3月にスパークシステムズジャパン株式会社主催の「要求管理を確実に行うための知識と方法セミナー」にて、SPEI三宅が講演した内容です。

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,368
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1.  第2回「要求管理を確実に行うための知識と方法」セミナー  主催:スパークスシステムズジャパン株式会社 要求管理を確実に行う7つの技法 2012.3.2 ソフトウェアプロセスエンジニアリング(株) 三宅 和之
  • 2. 自己紹介n  三宅 和之(みやけ かずゆき) 銀行員から要求アナリストへ転身し、2003年にSPEIを設立。 「要求とアーキテクチャからシステム開発を変革する」をテーマに活動。 SPEIでは、主に要求プロセス・プロジェクトマネジメントを担当。 最適な要求プロセスとは何かを追求すべく日々プロジェクトに邁進している。 u ソフトウェアプロセスエンジニアリング(株)代表取締役COO u 「RaQuest」開発アドバイザー u グローバルナレッジネットワーク(株)非常勤講師 u PMI認定PMP u 著書:「要求」の基本原則(共著、技術評論社) u www.facebook.com/kazuyuki.miyake © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 2
  • 3. 要求管理の現状n 個人的な所感 l  要求が原因で失敗するプロジェクトが後を絶たない l  実は身近なところで要求管理が行われている –  要求の優先度付け、スコープの管理など –  ただし、場当たり的・暗黙的n なぜ浸透しないか l  要求管理 の位置づけが曖昧 l  何を使えばよいか分からない(技法、ツール) © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 3
  • 4. 要求管理の位置づけn  要求工学 に含まれる分野" l  要求定義" –  要求を収集し、仕様化する活動" n  設計や実装などエンジニアリング作業と密接に関連" l  要求管理" –  要求で扱う要素とその活動を管理する活動" n  プロジェクト管理や構成管理などの活動と密接に関連" 要求工学(Requirements Engineering) 設計・実装 要求定義 テスト 要素の管理 活動の管理 プロジェクト管理 要求管理 構成管理 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 4
  • 5. 要求管理ツール「RaQuest」n 要求管理ツール l  要求管理の 仕組み が実装されている l  要求を データ として扱うことができる l  要求管理に必要なさまざまな ビュー を提供するn RaQuest概要 l  要求管理を サポート するための専用ツール l  要求管理のためのデータベース(リポジトリ)が付属 l  モデリングツールEnterprise Architectと連携が可能 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 5
  • 6. 要求管理の技法n  要求管理にもプラクティス・技法は存在する l  経験も重要だが、工学的なアプローチも有効 l  特に要求の 要素 を管理する分野は、技法・ツールを適用し易い 要求管理における主要な課題と対応する技法 課題 解決するための技法 要求の蓄積 技法1: リポジトリの利用 要求の分類 技法2: 要求パッケージの利用 要求の論理検証 技法3: トレーサビリティの活用 要求の暗黙知 技法4: 要求属性の活用 要求の状態 技法5: 要求のステータス管理 要求スコープ 技法6: 要求のベースライン管理 変更への対応 技法7: 変更要求管理 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 6
  • 7. 課題1:要求の蓄積n よくある事象" 「要求はとりあえず手元にあるメモに書いておこう」 –  紙、スプレッドシート、テキストエディタなど 「要求一覧はファイルで保存しておこう」 –  要求リストをファイルサーバに保管n 起こりうる問題" l  要求が埋もれてしまう l  要求を後工程で再利用できない © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 7
  • 8. 技法1:リポジトリの利用n 要求をリポジトリに蓄積する l  個々の要求をデータとして一意に識別可能 l  さまざまな切り口で要求を参照し、更新できる →要求管理を仕組みとして実施するための基盤 識識別された要求 要求の蓄積 内容の参照 要求の詳細 要求-001 要求の関連付け 要求-002 要求のグループ化 要求-003 ・ ・ ・ 要求リポジトリ © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 8
  • 9. 課題2:要求の分類n よくある事象 「その要求、今議論するレベルなのか?」 –  やりたいこと? やるべきこと? 「ユーザさんの意見だけ聞けばいいよね」 –  性能は? 運用保守は?n 起こりうる問題 l  要求をまとめる単位が不明となりプロジェクトが迷走 l  要求が漏れてしまう © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 9
  • 10. 概念:要求の抽象度と分類n 要求の抽象度 ⾼高 l  要望 要望 「利害関係者が抱えるニーズ」 抽 象 「システムが提供するサービス」 レ 要件 l  要件 ベ ル 仕様 「設計の完全な入力」 l  仕様 低 ユーザにとって有益な機能性を提供するために 機能要求 「機能」n 要求の分類 システムが行わなければならない行動 ユーザインターフ ースの統一性、 ェ 習得のしやすさ、 「ユーザビリ 」 ティ ヘルプ・サポート文書の必要性に関する要求 l  機能要求 「性能」 応答時間、スループッ 、 ト キャパシティ 資源効率性に関する要求 、 利用可能性、可用性、データの正確性、 「信頼性」 l  非機能要求 機能外要求 システムの安全性、データ保護に関する要求 「セキュリ 」 ティ 機密性、保全性、セキュリ 可用性に関する要求 ティ –  ISO9126 「保守性」 変更のしやすさ 移植性、 、 再利用性、 ローカライズ可能性に関する要求 –  FURPS+ 「運⽤用性」 運用のしやすさ 監視のし 、 やすさに関する要求 「システム制約」 技術的制約、法律・規定への準拠に関する制約事項 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 10
  • 11. 技法2:要求パッケージの活用n 要求を抽象度と分類でパッケージ化する" l  扱いやすいリポジトリ構造を構築できる –  要求を蓄積・検証しやすい単位で保持できる –  漏れを防ぎ、整合性を確保できる →要求を管理するための基本構造 要望 要件 機能要件 抽象度によるパッケージ化 分類によるパッケージ化 非機能要件 仕様 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 11
  • 12. RaQuestデモ-1 1. 要求をリポジトリに保存 2. 要求をパッケージで整理 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 12
  • 13. 課題3:要求の論理検証n よくある事象 「要求が網羅されているかレビューしてもらおう」 –  レビュー以外に検証手段がない 「その変更って、どこまで影響する?」 –  変更による影響範囲が特定できないn 起こりうる問題 l  レビューに時間がかかりすぎる l  要求の漏れに気づかないままプロジェクトがむ l  変更による検証コストが高くつく © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 13
  • 14. 技法3:トレーサビリティの活用n 要求間にトレーサビリティを与える l  カバレッジ分析 による完全性の検証が可能となる l  要求の変更や修正に伴う 影響分析 が容易になる 要求トレーサビリ が管理理さ ティ れている状態 <前方追跡> ・要望の充足度評価 ティ (カバレッジ分析) 要望 ビリ ・変更による影響範囲評価 サ 要件 トレー <後方追跡> ・修正による影響範囲調査 仕様 ・適用技術の正当性評価 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 14
  • 15. RaQuestデモ-2 1. 関係図で確認 2. マトリクスで検証 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 15
  • 16. 課題4:要求の暗黙知n よくある事象" l  「その要求って誰が言ったの? そんなに重要?」 –  誰の要求? 優先度は? 実現可能か? l  「この要求の意図することは、実は・・・」 –  要求のタイトル以外にも伝えたいことはあったはずn 起こりうる問題" l  要求の認識統一ができない l  要求の整理・分析に手間がかかる © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 16
  • 17. 技法4:要求属性の活用n 個々の要求に暗黙知を表現できる属性を与える l  要求に対する認識を表現できる –  「優先度」「難易度」「作業量」「安定性」など l  識別された時点の意図や情報が残る 要求の暗黙知 要求の状態 要求 • 誰の要求か? • 承認さ れているか? • 誰が関係するか? • 実装さ れているか? • 背後にある問題は? • 明確になっ ているか? • いつ実装すべきか? 要求には様々な情報が • いつ発生し たか? • 実現できるか? 含まれている • いつ変更さ れたか? • どのく らい複雑か? • 変更さ れたこ があるか? と ・・・ ・・・ © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 17
  • 18. 課題5:要求の状態n よくある事象" 「あの要求、今どうなってるの?」 「その要求、変わってたのか・・・」n 起こりうる問題" l  プロジェクトの進捗を把握できなくなる –  現時点でどの要求が実現されているのか不明・・・ l  単純ミスを誘発してしまう –  古いバージョンの要求に基づく実装 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 18
  • 19. 技法5:要求のステータス管理n 要求に状態を表す属性を与える l  要求からプロジェクトの状況を正しく把握できる –  「状態」「更新日」など" l  要求の整合性を確保する –  「フェーズ」「バージョン」「リビジョン」など 要求の暗黙知 要求の状態 要求 • 誰の要求か? • 承認さ れているか? • 誰が関係するか? • 実装さ れているか? • 背後にある問題は? • 明確になっ ているか? • いつ実装すべきか? 要求には様々な情報が • いつ発生し たか? • 実現できるか? 含まれている • いつ変更さ れたか? • どのく らい複雑か? • 変更さ れたこ があるか? と ・・・ ・・・ © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 19
  • 20. RaQuestデモ-3 1. 要求の状態で進捗を把握 2. リビジョン、日付から 更新の状況を確認 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 20
  • 21. 課題6:要求のスコープn よくある事象" 「今回のリリースでは、どの要求が実装されるの?」 「それは変更ですか?追加ですか?」 –  何を変更とするかの基準が無いn 起こりうる問題" l  プロジェクトの基準が曖昧となる –  ユーザに提供する機能 –  スケジュール、コスト –  変更の基準 l  ベンダーや開発チームとの関係悪化 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 21
  • 22. 技法6:要求のベースライン管理n  実現対象の要求セットを「ベースライン要求」として識別 する l  何を設計・実装すべきかの基準が明確になる l  変更可否の判断基準が定義される →プロジェクトに明確な基準を提供 識識 別 実現が合意された要求 ベースライン要求 さ れ •ユーザに提供する機能の範囲 た •開発スケジュール立案の根拠 要 •開発コスト見積もりの根拠 求 実現・ 変更更されない要求 •変更の基準 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 22
  • 23. 課題7:変更への対応n よくある事象 「変更ですね。対応しておきます。」" 「次のリリースって、結局何が変更されたの?」" –  何が変更されたか残されていない"n 起こりうる問題" l  際限なく変更を受け入れてしまう" l  ベースラインが形骸化する" © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 23
  • 24. 技法7:変更要求管理n 変更要求を区別して扱う l  ルールに基づく変更管理をサポートする –  決められたルート・手続きでのみ変更できる環境 l  ベースラインの管理を維持できる" 当初のベースライン 変更更されたベースライン 実現が合意された要求 実現された要求 ベースライン要求 追加・ 変更更が合意された要求 追加・ 変更更要求 実現・ 変更されない要求 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 24
  • 25. RaQuestデモ-4 1. ルールに基づく変更 2. ベースラインによる差分確 認 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 25
  • 26. 補足:RaQuestの活用n Enterprise Architect(EA)と組み合わせて使う l  RaQuestは仕組み上、EAとデータを共有している l  EAの各ダイアグラムに置いた要求(EA要求要素)は 全てRaQuestから管理可能 l  RaQuestは単体で使うにはもったいない リポジトリ を共有 連携 © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 26
  • 27. 活用例1:業務フロー(EA→RaQuest)n  業務フローから要望一覧を抽出 ü  「業務フロー」に「要望」をマッピングさせながらモデリング(EA) すると、 RaQuestは要求一覧やマトリクス形式で出力できる 業務アクティビティと要望を 対応付け(EA) UML要素と要望の対応関係を マトリクスで検証 (RaQuest) © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 27
  • 28. 活用例2:ユースケース(RaQuest→EA)n  要件一覧からユースケースを作成 ü  ヒアリングなどで識別された要件(RaQuest)が実現できるように、 EAでユースケースをモデリングするヒアリングした要件を一覧で追加 要件を実現するための(RaQuest) ユースケースを作成 (EA) © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 28
  • 29. 活用例3:課題管理(RaQuest+EA)n  課題管理に活用 ü  発生した課題はEAモデル内に書き込んでいき、RaQuestで 課題一覧として出力 → 一元的に課題を管理できる 課題が発生したらダイアグラム上 に要素として書き込む (EA)   モデル上の 課題を集約し、 課題一覧から状況を確認する更新された課題をモデルから (RaQuest)確認する(EA)  © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 29
  • 30. 要求管理の実践に向けてn 要求の持つ特性を理解する" l  要求工学の理解" –  BABOK、ITIL、PMBOKも参考になります" l  プラクティスを少しずつ取り入れる" –  7つの技法を適用できるところから"n 環境を整備する" l  ツールの活用" –  まず、Excelの要求リストをインポートしましょう" l  要求プロセスの定義" –  体系的に要求管理を取り入れたい方はここから" © 2008 – 2012 Software Process Engineering Inc. All rights reserved. 30

×