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

第2回「要求管理を確実に行うための知識と方法」セミナー

主催：スパークスシステムズジャパン株式会社

要求管理を確実に行う7つの技法

2012.3.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

要求管理の現状
n 個人的な所感
l  要求が原因で失敗するプロジェクトが後を絶たない
l  実は身近なところで要求管理が行われている
–  要求の優先度付け、スコープの管理など
–  ただし、場当たり的・暗黙的

n なぜ浸透しないか
l  要求管理の位置づけが曖昧
l  何を使えばよいか分からない（技法、ツール）


要求管理の位置づけ
n  要求工学に含まれる分野"
l  要求定義"
–  要求を収集し、仕様化する活動"
n  設計や実装などエンジニアリング作業と密接に関連"

l  要求管理"
–  要求で扱う要素とその活動を管理する活動"
n  プロジェクト管理や構成管理などの活動と密接に関連"

要求工学（Requirements Engineering）

設計・実装
要求定義テスト
要素の管理活動の管理
プロジェクト管理
要求管理構成管理


要求管理ツール「RaQuest」
n 要求管理ツール
l  要求管理の仕組みが実装されている
l  要求をデータとして扱うことができる
l  要求管理に必要なさまざまなビューを提供する

n RaQuest概要
l  要求管理をサポートするための専用ツール
l  要求管理のためのデータベース（リポジトリ）が付属
l  モデリングツールEnterprise Architectと連携が可能


要求管理の技法
n  要求管理にもプラクティス・技法は存在する
l  経験も重要だが、工学的なアプローチも有効
l  特に要求の要素を管理する分野は、技法・ツールを適用し易い

要求管理における主要な課題と対応する技法

課題解決するための技法
要求の蓄積技法1：リポジトリの利用
要求の分類技法2：要求パッケージの利用
要求の論理検証技法3：トレーサビリティの活用
要求の暗黙知技法4：要求属性の活用
要求の状態技法5：要求のステータス管理
要求スコープ技法6：要求のベースライン管理
変更への対応技法7：変更要求管理


課題1：要求の蓄積
n よくある事象"
「要求はとりあえず手元にあるメモに書いておこう」
–  紙、スプレッドシート、テキストエディタなど
「要求一覧はファイルで保存しておこう」
–  要求リストをファイルサーバに保管

n 起こりうる問題"
l  要求が埋もれてしまう
l  要求を後工程で再利用できない


技法1：リポジトリの利用
n 要求をリポジトリに蓄積する
l  個々の要求をデータとして一意に識別可能
l  さまざまな切り口で要求を参照し、更新できる

→要求管理を仕組みとして実施するための基盤

識識別された要求
要求の蓄積
内容の参照
要求の詳細

要求-001
要求の関連付け
要求-002
要求のグループ化
要求-003
・
・
・
要求リポジトリ


課題2：要求の分類
n よくある事象
「その要求、今議論するレベルなのか？」
–  やりたいこと？やるべきこと？
「ユーザさんの意見だけ聞けばいいよね」
–  性能は？運用保守は？

n 起こりうる問題
l  要求をまとめる単位が不明となりプロジェクトが迷走
l  要求が漏れてしまう


概念：要求の抽象度と分類
n 要求の抽象度⾼高

l  要望要望「利害関係者が抱えるニーズ」
抽
象「システムが提供するサービス」
レ要件
l  要件ベ
ル
仕様「設計の完全な入力」

l  仕様低

ユーザにとって有益な機能性を提供するために
機能要求「機能」
n 要求の分類
システムが行わなければならない行動
ユーザインターフースの統一性、
ェ習得のしやすさ、
「ユーザビリ」
ティヘルプ・サポート文書の必要性に関する要求

l  機能要求「性能」
応答時間、スループッ、
トキャパシティ
資源効率性に関する要求
、

利用可能性、可用性、データの正確性、
「信頼性」
l  非機能要求機能外要求
システムの安全性、データ保護に関する要求

「セキュリ」
ティ機密性、保全性、セキュリ可用性に関する要求
ティ

–  ISO9126 「保守性」
変更のしやすさ移植性、
、再利用性、
ローカライズ可能性に関する要求

–  FURPS+ 「運⽤用性」運用のしやすさ監視のし
、やすさに関する要求

「システム制約」技術的制約、法律・規定への準拠に関する制約事項


技法2：要求パッケージの活用
n 要求を抽象度と分類でパッケージ化する"
l  扱いやすいリポジトリ構造を構築できる
–  要求を蓄積・検証しやすい単位で保持できる
–  漏れを防ぎ、整合性を確保できる

→要求を管理するための基本構造

要望

要件機能要件
抽象度によるパッケージ化
分類によるパッケージ化

非機能要件
仕様


RaQuestデモ-1

1. 要求をリポジトリに保存

2. 要求をパッケージで整理


課題3：要求の論理検証
「要求が網羅されているかレビューしてもらおう」
–  レビュー以外に検証手段がない
「その変更って、どこまで影響する？」
–  変更による影響範囲が特定できない

n 起こりうる問題
l  レビューに時間がかかりすぎる
l  要求の漏れに気づかないままプロジェクトがむ
l  変更による検証コストが高くつく


技法3：トレーサビリティの活用
n 要求間にトレーサビリティを与える
l  カバレッジ分析による完全性の検証が可能となる
l  要求の変更や修正に伴う影響分析が容易になる

要求トレーサビリが管理理さ
ティれている状態

＜前方追跡＞
・要望の充足度評価
ティ
（カバレッジ分析）
要望
ビリ

・変更による影響範囲評価
サ

要件
トレー

＜後方追跡＞
・修正による影響範囲調査
仕様
・適用技術の正当性評価


RaQuestデモ-2

1. 関係図で確認

2. マトリクスで検証


課題4：要求の暗黙知
l  「その要求って誰が言ったの？そんなに重要？」
–  誰の要求？優先度は？実現可能か？
l  「この要求の意図することは、実は・・・」
–  要求のタイトル以外にも伝えたいことはあったはず

l  要求の認識統一ができない
l  要求の整理・分析に手間がかかる


技法4：要求属性の活用
n 個々の要求に暗黙知を表現できる属性を与える
l  要求に対する認識を表現できる
–  「優先度」「難易度」「作業量」「安定性」など
l  識別された時点の意図や情報が残る

要求の暗黙知要求の状態
要求
•
誰の要求か？ •
承認されているか？
•
誰が関係するか？ •
実装されているか？
•
背後にある問題は？ •
明確になっているか？
•
いつ実装すべきか？
要求には様々な情報が •
いつ発生したか？
•
実現できるか？含まれている •
いつ変更されたか？
•
どのくらい複雑か？ •
変更されたこがあるか？
と
・・・・・・


課題5：要求の状態
「あの要求、今どうなってるの？」
「その要求、変わってたのか・・・」

l  プロジェクトの進捗を把握できなくなる
–  現時点でどの要求が実現されているのか不明・・・
l  単純ミスを誘発してしまう
–  古いバージョンの要求に基づく実装


技法5：要求のステータス管理
n 要求に状態を表す属性を与える
l  要求からプロジェクトの状況を正しく把握できる
–  「状態」「更新日」など"
l  要求の整合性を確保する
–  「フェーズ」「バージョン」「リビジョン」など

要求の暗黙知要求の状態
要求
•
誰の要求か？ •
承認されているか？
•
誰が関係するか？ •
実装されているか？
•
背後にある問題は？ •
明確になっているか？
•
いつ実装すべきか？
要求には様々な情報が •
いつ発生したか？
•
実現できるか？含まれている •
いつ変更されたか？
•
どのくらい複雑か？ •
変更されたこがあるか？
と
・・・・・・

© 2008 – 2012 Software Process Engineering Inc. All rights reserved.

19

RaQuestデモ-3

1. 要求の状態で進捗を把握

2. リビジョン、日付から
更新の状況を確認


課題6：要求のスコープ
「今回のリリースでは、どの要求が実装されるの？」
「それは変更ですか？追加ですか？」
–  何を変更とするかの基準が無い

l  プロジェクトの基準が曖昧となる
–  ユーザに提供する機能
–  スケジュール、コスト
–  変更の基準
l  ベンダーや開発チームとの関係悪化

技法6：要求のベースライン管理
n  実現対象の要求セットを「ベースライン要求」として識別
する
l  何を設計・実装すべきかの基準が明確になる
l  変更可否の判断基準が定義される

→プロジェクトに明確な基準を提供

識識
別実現が合意された要求ベースライン要求
さ
れ •ユーザに提供する機能の範囲
た •開発スケジュール立案の根拠
要 •開発コスト見積もりの根拠
求実現・
変更更されない要求 •変更の基準


課題7：変更への対応
「変更ですね。対応しておきます。」"
「次のリリースって、結局何が変更されたの？」"
–  何が変更されたか残されていない"

l  際限なく変更を受け入れてしまう"
l  ベースラインが形骸化する"


技法7：変更要求管理
n 変更要求を区別して扱う
l  ルールに基づく変更管理をサポートする
–  決められたルート・手続きでのみ変更できる環境
l  ベースラインの管理を維持できる"

当初のベースライン変更更されたベースライン

実現が合意された要求実現された要求
ベースライン要求

追加・
変更更が合意された要求

追加・
変更更要求
実現・
変更されない要求


RaQuestデモ-4

1. ルールに基づく変更

2. ベースラインによる差分確
認


補足：RaQuestの活用
n Enterprise Architect(EA)と組み合わせて使う
l  RaQuestは仕組み上、EAとデータを共有している
l  EAの各ダイアグラムに置いた要求（EA要求要素）は
全てRaQuestから管理可能
l  RaQuestは単体で使うにはもったいない

リポジトリ
を共有

連携


活用例1：業務フロー（EA→RaQuest）
n  業務フローから要望一覧を抽出
ü  「業務フロー」に「要望」をマッピングさせながらモデリング(EA)
すると、
RaQuestは要求一覧やマトリクス形式で出力できる

業務アクティビティと要望を
対応付け（EA）

UML要素と要望の対応関係を
マトリクスで検証（RaQuest)


活用例2：ユースケース（RaQuest→EA）
n  要件一覧からユースケースを作成
ü  ヒアリングなどで識別された要件(RaQuest)が実現できるように、
EAでユースケースをモデリングする

ヒアリングした要件を一覧で追加要件を実現するための
（RaQuest）ユースケースを作成（EA）


活用例3：課題管理（RaQuest+EA）
n  課題管理に活用
ü  発生した課題はEAモデル内に書き込んでいき、RaQuestで
課題一覧として出力 → 一元的に課題を管理できる

課題が発生したらダイアグラム上
に要素として書き込む（EA）

モデル上の課題を集約し、
課題一覧から状況を確認する
更新された課題をモデルから（RaQuest）
確認する（EA）


要求管理の実践に向けて
n 要求の持つ特性を理解する"
l  要求工学の理解"
–  BABOK、ITIL、PMBOKも参考になります"
l  プラクティスを少しずつ取り入れる"
–  7つの技法を適用できるところから"

n 環境を整備する"
l  ツールの活用"
–  まず、Excelの要求リストをインポートしましょう"
l  要求プロセスの定義"
–  体系的に要求管理を取り入れたい方はここから"


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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (11)

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

Ähnlich wie 要求管理を確実に行うための知識と方法 (20)

Mehr von Kazuyuki Miyake

Mehr von Kazuyuki Miyake (12)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

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