Relationship driven requirement analysis

要件定義は要義何をどう定義するのか？「リレーションシップ駆動要件分析」は網羅的に整合性を保ちながら、システマティックに要件を分析する方法です。方法です 2009/07/17 Relationship driven requirement analysis ⇒ RDRA（ラドラ）

わたしは  ㈱バリューソース  代表取締役社長  神崎善司  zkanzaki@vsa.co.jp  普段は  要件定義のコンサルテション要件定義のコンサルテーション  オブジェクト指向やUMLのセミナー開催  要件定義との関係は  ２０年ほど前からオブジェクト指向を中心にシステム開発全般のコンサルティングを行う  １０年ほど前から上流工程を中心としたコンサルティングを行う  その間一貫してモデル中心で行う  その経験を活かしてモデルを使った要件定義の手法をまとめる 2

今日のプレゼンの位置づけ要件定義上流工程問題の整のための具体的なの様々な理戦略的な方策現象方向性 3

システマティックに要件を定義するためにより混乱を少なく要件定義を行うためには…… ゴールを示し、そのための道筋を明らかにする。そして対象を視覚化する。そして対象を構造化、抽象化して議論を積み上げながら要件を形にする。 ★ゴールを明確にする ★視覚化し共有する要件分析のフレムワクフレームワーク ★議論を積 ★構造化、抽象化 ★構造化抽象化み上げるしながら分析する要件分析のプロセス ★顧客をリードする ★顧客をリドする ★方向性を合わせる 4

要件分析フレームワーク要件定義の枠組み上流工程での混乱を減らすために要件定義の枠組みが必要

要件定義には何を定義すればいいのか要件利害関係者定義書外部システムシステムものシステムをシステ機能機能サービス取り巻く環境業務ユーザム機能データ RDRAでは「要件定義の対象をシステムとシステムを取り巻く環境」と考える 6

要件定義では何が定義されないといけないのか利害関係者外部システム外部シムシステム機能もの機能サービス業務機能ユーザデータ •このシステムの目的（価値）は？ •どのような人に使われるのか？ •どのような外部システムと関わるのか？システムとの接点は？ •システムとの接点は？ •その時の入出力情報は？ •システムに必要な機能は？ •その機能が使用するデータは？ 7

要件定義の構造を定義する利害関係者外部システムシステム機能もの機能サービスサビス機能ユーザデータシステム価値利害関係者要件定義の構造ユーザものサービス •システム価値システム外部環境システム境界システム外部環境 •システム外部環境システム •システム境界機能システム •システム機能データデタ外部システム 8

要件分析の枠組みシステム価値１．【システムの価値】を捉える価値要求利害関係者 •対象業務に関わる人を洗い出すサービス •関係する外部システムを洗い出すものユーザ •要求を捉えるシステム外部環境２．【システム外部環境】を捉えるシステム境界 •対象業務の流れを捉えるシステムシスム •対象業務に関わる概念を明らかにする •システムの利用シーンを明らかにする機能機能３．【システム境界】を捉える３【システム境界】を捉えるデータ •ユーザインターフェースを明らかにする •外部システムとのインターフェースを明外部システムらかにする４．【システム】を定義する機能を明らかにする •機能を明らかにする •データを明らかにする •ドメインの構造を把握する 9

要件分析の枠組みにモデルを当てはめるシステム価値からシステムの機能とデータを求める手段として UMLを拡張したモデルを利用する

コンテキストモデルからシステム境界まで人（）人（アクター）要求モデル要求２．下記関係者の要求を要求把握する要求シスコンテキストモデルテム１．対象業務に関わる人と外部システムを把握する対象業務に関わる人と外部シス外部システムテムを要件定義の起点とする５．外部システムとのイベントを４．業務の中でシステムが３．業務を組み立てる捉える関わる部分を把握する６．外部システムとのプロトコルを整理業務モデルイベントモデル同じように利用シーンから 11 ユースケースを導き出すプロトコルモデル

画面・ユースケースから機能、データまでユースケースモデルユースケースモデルユスケスモデルイベントモデル７．ユースケースに関わるプロトコルモデルユーザーインターフェーズを洗い出すシステム９．アクションを機能に８．ユースケースを実現対応付けるする機能を洗い出す１１．機能とデータを付き合わせる機能モデル画面帳表モデル機能モデル１０．データを洗い出すデータモデル機能複合モデル機能複合デル 12 システム境界

網羅性と整合性を確認する関係ダイアグラムシステム価値システム外部環境システム境界システム画面・帳表データ業務業務＆ＵＣＵＣ＆画面機能複合コンテキストモデル概念ユースケースＵＣ＆機能ドメイン要求利用シーン＆ＵＣプロトコル利用シーン機能ＵＣ：ユーケースイベント 13

要件の精度を高めるダイアグラムの検証ポイント問い検証内容Ｑ１０１ □背景要求の元となる関係者コ要件定義を網羅的に進めるためにその出発点となる関係者を洗い出す必要があるにはどのような人がいるンテ □確認ポイントか・全ての関係者がアクターとして洗い出されているか全ての関係者がアクタとして洗い出されているかキ・システムに関わらないが業務に関わるアクターも含まれているかス・アクター同士の関係が示されているかト・アクターは役割の名前がついているか・アクターの責務が明確になっているか Q102 コ □背景ンどのような外部システム外部システムとの連携もシステム化範囲を決めるための入り口になり、外部インターフェースの策定の出発点になると連携するのかテ □確認ポイントキ整合性をあわせるポイントス・外部システムはもれなく洗い出されているか・今後の調査の候補も洗い出されているかト・外部システムの役割が明確になっているか外部シテの役割明確なてる問いダイアグラム懸念事項 Q103 □背景利用シーンには必ずユース利用シーン利用シーンに結びつくユースケースがない場合はユースケースが抜けている可能性がある。どのような機能要求があ要システムが提供する機能として押さえておくべき事、方向性を要求、要件として示し、以後の各モデル策定の指針にすケースが結びついているかるか、それは誰（ロール）求るが要求しているのか利用シーンには必ずアクターがモ □確認ポイント利用シーン利用シーンに結びつくアクターが無い場合は必要なアクターが抜けている可能性がある結びついている・検証可能な表現で記述されているか検証可能な表現で記述されているかデ・要求の粒度は揃っているかユースケースには必ずアクティルユースケース・要求のもれだぶりはないかユースケースに関わるアクティビティがない場合は必要なアクティビティが抜けている可能性があビティが結びついているかる。・HowではなくWhatとして記述されているか Howは非機能要求として洗い出されているかユースケースには必ず利用・各ロールに応じた要求が洗い出されているかユースケースユースケースに関わる利用シーンがない場合は必要な利用シーンが抜けている可能性がある。シンが結びついているかシーンが結びついているかユースケースに結びついていなユースケースユースケースは画面か帳表、もしくは機能、データのどれかと結びついているはず。い画面は無いか 14

ツルの支援ツールの支援要件定義を行うために必要なツールや、要件を整理するたのテンプレート、並びに作成して要件定義のチェックツールを紹介します。

ＲＤＲＡテンプレート各ダイアグラム RDRAで作成する一作成するへのメニュー連のモデルをあらかじめパッケージとして分類レビュー用のダイアグラムも用意 16

ＲＤＲＡプロファイル RDRA専用のツールバー RDRA専用の関係づけクイックリンク 17

RDRAChekerプログラム  ＥＡで作成したモデルの関係をチェックする  厳密なチェックではなくあくまで関係性を確認しモデルを見直す EAを使うことで要件定義そのものを情報として扱える 18

要件分析プロセス要件定義をどのように進めるのかスケジュール管理と言えばガントチャートでも上流工程ではガントチャートはうまく機能しないことが多い

混乱する上流工程  あなたならどう答えますか？  なぜ上流工程のスケジュール作成は難しいのか  なぜスケジュール通りに進まないのか  そもそも上流工程のスケジュール管理をどのように行えばいいのか  そのヒントをガントチャートから考えてみましょう  スケジュール管理と言えばガントチャート  ガントチャートはどのような前提によって組み立てられるのか 20

ガントチャートがイメージさせるもの  ガントチャートを作成する（利用する）ときには以下のような考え方が背景にある  タク間は依存関係があり依存されてるものから先手をけるタスク間には依存関係があり依存されているものから先に手をつける  タスクにはそれを行うためのスキルが必要である  タスクの平行性を高めると期間を短縮できる  タスクを実現すれば想定している成果物を作成出来る  進捗が遅れていた場合にはその対策を行う  タスク間の依存関係に基づいてタスクを結びつけると完了日が明確になる  担当者は割り当てられたタスクだけをこなせばいい  全てのタスクは洗い出せる（出来ない時は猶予期間を用意する）  タスクは全て計画可能であり計画通りに実現可能であると考える  ガントチャトがうまく機能するための条件ガントチャートがうまく機能するための条件  タスクへのブレークダウンが適切にできる  ほぼ予定された時間内にタスクが終わる  上記の条件が満たされるときガントチャートはとても良くできた管理法である  しかし、上記の条件が満たされないときはガントチャートはうまく機能しない、記条件満されなきンチャうまく機能な 21

じゃあどうするの？ ⇒ 時間を軸足にする  変わらない軸として時間を用いる  一定期間をタイムボックスとして扱う定期間をタイムボクとして扱う  サイクルを重視する  作業にリズムを持たせて進行をスムズにする作業にリズムを持たせて進行をスムーズにする  サイクルの中で作業方法を見直す  ラフに決め直近の作業を柔軟に決めていく  そもそもパラメータ（人とタスク）の変化が大きいところでは、成果物の作成量を最大にするのではなく、変化に適切に対応することを目作成量を最大するな、変適切対するを目標とする方が効果的である  つまり  不正確なガントチャートに縛られて不適切な作業をするよりは、先々まで不正確なガントチャートに縛られて不適切な作業をするよりは先々までの詳細なスケジュールが見通せないけども、適切に軌道修正しながら進める方が有効であると考える 22

プロジェクトのゴールについて当初のゴール時間の経過と共にゴールが絞り込まその時点で明確になっているゴール Goal れて明確になるに向かって軌道修正しながら進む機能修正されたゴールイテレーション時間軸軌道修正の単位イテレーション後のフィードバックがより適切なゴールを導き出す 23

マイルストーンは状態として管理するマイルストーン候補候フェーズマイルストーンゴールを実現するためには、ど状況把握自己理解度を測るのような状態になっていないと現状分析いけないのかシステム化コア把握と方向性の確立への組立網羅性の確保整合性確保項目レベルで整合性確保状態状態状態状態要件定義のゴール要件定義チームを明確にする後の状態を実現するためには、どのような状態になっていないといけないのか 24

繰り返しをどのように管理するか  複数視点に対応するスケジュール管理  階層化した管理項目  人管理者リーダー担当者  時間マイルストーンイテレーション  管理項目状態成果タスク  状況に応じて組み合わせる時間：人：マイルストーン管理者マイルストーン (関係者) イテレーション管理項目：評価可能な状態リーダー評価可能な成果タスク担当者イテレーション 25

まとめ  要件分析フレームワーク  要件定義の枠組みを意識して要件を組み立てる  システム価値、システム外部環境、システム境界、システム  上記の枠組みには各々視点があり、その視点に適したモデルを使って要件を定義する  要件定義の各情報はつながっており、そのつながりを利用することでシステマティックに精度の高い要件定義が可能となる  それを何度も繰り返して要件を洗練化する  要件分析プロセス  「タスク」が安定しないのであれば、安定している「時」をベースに管理「タスク」が安定しないのであれば安定している「時」をベースに管理し、状況の変化に対応する方が有利である  タスク、時間、人をそれぞれ階層化したタイムボックスとして管理する  タイムボックス毎に軌道修正しながらゴールを明らかにし、納期に納めタイムボックス毎に軌道修正しながらゴールを明らかにし納期に納める  要件分析フレームワークの一連のモデルをマイルストーン単位に作成、洗練化を繰り返し精度を上げる 26

情報源

リレーションシップ駆動要件分析の情報 http://k-method.jp ＲＤＲＡ用テンプレートＲＤＲＡ用プロファイル書籍＜リレーションシップ駆動要件分析の情報サイト＞ UMLツールのEnterpriseArchtectのテンプレートやプロファイルがダウンロード出来ます 28

要件定義（RDRA）セミナー  要件定義入門セミナー  目的：  要件定義の基本的な考え方を習得する  内容  要件定義の基本的な考え方やプロセスを理解し、自分のプロジェクトに応用できる知識を身につけます。用識を身す。  実施形態  オンサイト  日数  １日６時間  要件定義実践セミナー  目的  UMLを使った要件定義を演習を通して実際に作成する  内容  実際の課題にもとづいて要件定義を行います。グループでUMLのツールを使い自分たちで考えたことを形にしていきます。使い自分たちで考えたことを形にしていきます  実施形態  オンサイト  日数  ２日１２時間 29

Relationship driven requirement analysis

by Kent Ishizawa on Jul 21, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 6

Statistics

Relationship driven requirement analysis — Presentation Transcript