要求工学イブニングチュートリアル
第4回
ゴール指向要求分析法
2004年4月22日
信州大学
海谷 治彦
第3版
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
1
目次
• 要求工学におけるゴール指向分析の役割
– ゴール分析の利点
• ゴール分析の基礎 – 典型的な記法等
• ゴール指向手法の代表例他
–
–
–
–
–
i* (I star)
KAOS
NFR framework
GQM
AGORA (時間があれば)
• まとめと論点
– RE04の紹介を少々
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
2
講師紹介
• 1999年~ 信州大学 工学部
– 要求工学を利害対立や妥協の観点から研究
• そのためのツールとしてゴール分析手法を利用
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
3
ゴール指向分析の役割
要求工学,ソフトウェア工学の
文脈において
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
4
要求工学 (復習)
• ソフトウェア工学の一部
• ソフトウェア要求を正しくまとめる(定義す
る)ための技術や技法の集大成
• ソフトウェア要求
–
–
–
–
要求は立場によって異なる
利用者は当たり前のことを言わない
要求は誤っていることがある
要求は変わることがある
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
5
要求定義のプロセス (復習)
要求管理
要求獲得
Stakeholderの識別
要求抽出
ネゴシエーション
モデル化
テスト・実行
記述
記述の解析
要求検証
要求記述
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
6
各段階で必要なこと
• 獲得
– 組織の現状(as-is)を理解する(利害関係者の識別等)
– 現状をどのように変化させたいのかを理解する
• 記述
– 組織の目標(ゴール)を,開発するシステムの機能や
性能(非機能)と関連付ける
• 検証 (verification and/or validation)
– 記述した(要求)仕様が利害関係者の本々の目標にあ
うかを確認する.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
7
ゴールの明示的記述
• ゴールを明示的に記述することで,獲得,
記述,検証で必要な活動を円滑に行うこと
ができる.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
8
ゴール(目標)とは
• the object of a person's ambition or effort
(辞書的な意味)
• 開発するシステムが達成しなければならな
いこと.[Jac95,Zav97]
• プログラムが仕様を実現するのと同様に,
ゴールは要求を実現する.[Kav02]
• ゴール=why, (要求)仕様=what, 実装=how
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
9
従来の分析手法
• プログラム技法をヒントにしている
– 「理由」や「目標」を明示する部分が無い
– 「what」に相当するものが一番抽象的.
• 構造化分析
– データフロー図(コンテクスト図)で機能と境界
を明確化
• オブジェクト指向分析
– ユースケース図で機能と境界を明確化
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
10
ゴール分析の基礎
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
11
典型的なゴール構造の記述法
• ゴールを木(または非循環有向グラフ)構造
で記述する.
– 下位構造が上位構造の詳細化となっている.
• 分解をAND/ORに区別する.
– AND 上位ゴールを達成するのに下位全ての
達成が必要.
– OR 上位ゴールを達成するのに下位どれかの
達成が必要.
• 人工知能での問題分析手法の流用.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
12
パターン
Goal A
SubGoal B
Why?
理由に着目
ゴール合成
SubGoal C
SubSubGoal D SubSubGoal E
How?
必要条件に注目
ゴール分解
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
13
例
国際会議を成功させる
AND
発表が優れている
参加者が多数
発表が多数
AND
OR
査読を
緩くする
投稿数を多数に
査読を
厳しくする
事前の日本語チュートリアルを開催
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
14
典型的なゴールの記述様式
• システムによって達成されるステークホル
ダの望むべき状態・状況を記述する.
– 上位のゴールはこの形態の場合が多い.
• その状態・状況にするために行うことを記
述する.
– 下位のはこの形態が多い.
– この形態で書かれたゴールは個々の要求項
目(例えばユースケースや機能項目)とみなし
てよい場合がある.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
15
ゴール以外の要素との関連
• ほとんどのゴール分析技法はゴール以外
の要素も記述する.
– ゴールの遂行者
– ゴール達成の利害関係者
– ゴールを達成するための手順や作業
– 手順や作業の実行に必要な資源
等
• 個々の技法でこれらは解説する.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
16
Stakeholder
• ステークホルダ,利害関係者
• (開発されるシステムの導入によって)起こりうる
変化に利害関係を持つ人,利益や損失が生じる
可能性のある人 [Mac96]
• ステークホルダは(UMLやDFDでの)アクターと
は異なる場合がある.
– 利害関係はあっても運用には関係ない人もいるため.
• 「誰の」ゴールなのか?を考えることがゴール分
析では重要となる.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
17
代表的なゴール分析手法
要求工学の文脈において
i*, KAOS, NFR, GQM, AGORA
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
18
i* (eye star)
• An agent-oriented modelling framework
• 要求獲得に役立つ.
– 現状のビジネスを理解
– システム導入による効果を分析
• 5種類の要素をグラフで表現し,システム
要求とそれに関連する情報を表現.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
19
5つの要素
• Actor: 処理の遂行者だけでなく,目的や理由,
言質を与える(コミットする)者(物)を表す.ステー
クホルダに近い.
• Goal: 遂行できるか否かを判断できる条件や状
態.機能要求にほぼ対応.
• Task: あるgoalを達成する特定の手順.
• Soft-goal: 遂行の可否が明確に判断できない
goal.非機能(品質や性能)要求に対応.
• Resource: goal達成(task遂行)に利用できる物や
情報.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
20
SD modelとSR model
• 現状(as-is)分析と望むべき状態(to-be)の分析を
するための記述.
– 前述の5要素を使ったグラフで記述する.
• Strategic Dependency (SD) model
– Actor間の依存関係(dependency link)をgoal, task,
resource, soft-goalそれぞれの観点から記述したグラフ.
– それぞれの観点からの需要供給関係がわかる.
• Strategic Rationale (SR) model
– 各actorが内部的にどんなgoalやsoft goalを持ち,どん
なtaskを遂行し,どんなresourceを持つかをモデル化す
る.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
21
SDモデルの例
このゴール達成したいの
はinitiatorで,それは
participantに依存してい
る.
提案するのはinitiator
だから,このresource
はinitiatorに依存する.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
22
SRモデルの例 (一部)
「会議が計画され
た状態にする」と
いうゴールは,
「会議を計画す
る」というタスクが
手段となる.
このタスクを
遂行するため
には,2つのタ
スク遂行,1つ
のゴール達成
が必要.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
23
i*による要求獲得戦略
• 現状の業務(as-is)をSD, SRモデルで記述.
– 矛盾や不具合,人への仕事の負荷がある.
• 作成されたシステムが導入された場合(tobe)を同様にモデル化する.
– 前述の,矛盾や不具合,負荷が軽減されてい
ればシステムの価値はある.
– 価値のあるようなシステムの要求を構築しな
ければならない.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
24
例: soft goal達成の改善
人が計画すると「早く」ないし「労
力」ばかりかかるが,
導入前
導入後
スケジューラーがやってくれると,これ
らのsoft goal達成が楽になる.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
25
KAOS
• Knowledge Acquisition in autOmated
Specification [Vl91]
• 識別したゴールを満足する要求項目を系統的に
導出できる.
• 導出された要求項目によってゴールが達成され
ることを形式的に検証(verify)できる.
• 形式的: 数理論理の利用
– 個々のゴール記述に様相論理を利用.
– ゴール分解に矛盾が無いことに数学的な証明を利用.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
26
KAOSでの要求分析の考え方
Why
Goal
operationalization
ドメイン知識
ゴール達成のための
操作の明確化
requirements
assumption
What
誰(何)が達成するかを割り当てる
この部分を
作るための
要求分析を
したことに
なる.
to-be
system
人や
機械
(環境)
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
Who
27
KAOSで利用する概念
• Goal: 目標とする状態.KAOSでは最終的にその
ような状態を論理式で形式化する.
• Object: UML等で言うObjectにほぼ同じ.
• Operation: Goalを達成するための操作.
• Agent 個々のゴール達成に責任を持つ存在.当
然,ある程度,詳細化・具体化しないと誰が責任
を持つか解らない.
• Requirements 開発するソフトウェア(to-be
software)が達成責任を持つゴール
• Assumption それ以外(環境)が達成責任を持つ
ゴール
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
28
KAOSでの要求分析の手順
1. 初期文書からのゴールの識別
2. ゴールの形式記述とオブジェクトの識別
3. Why質問で上位のゴールを識別
4. How質問で具体的なゴールを識別
5. Agentのゴール達成責任を識別
6. Agentが観測・制御可能な変数を識別
7. Operationを識別
その他,障害予測や対立解消も可能.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
29
1. ゴール識別
初期文書等からキーワー
ドをもとにゴールを識別.
ほとんどはsoft goalなので,
それを詳細化することで, 貢献
形式化可能なゴール
(formalizable goal)に分解
してゆく.
OR
衝突
ここでの例はBART(サン
フランシスコにある鉄道)
の分析をしている.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
30
形式化されたゴールを分類するキーワード
• Maintain
□ ( P → Q)
– (状態が変化しても)真偽値Pが成り立てば,Qも成り立
つ.
– 「→」は普通の論理的含意
• Avoid
□ ( P → ¬Q)
– いつでも,PがなりたっていればQはなりたたない.
• Achieve
□ ( P → ◇ Q)
– いつでも,Pが成り立っていれば,将来Qが成り立つ可
能性がある.
これらはゴールの傾向を示すマークに過ぎない.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
31
2. ゴールの形式記述・オブジェクト識別
Goal Maintain[TrackSegmentSpeedLimit]
InformalDef Trainは各TrackSegmentで決められた
SpeedLimit以下を維持しないといけない.
FormalDef ∀tr: Train, s: TrackSegment:
□( On(tr,s) → tr.Speed ≦ s.SpeedLimit )
上記のように形式化されたゴールを記述する.
記述にオブジェクトとその属性が必要なのでクラス図を書く.
Train
TrackSegment
On
Speed: SpeedUnit
・・・
SpeedLimit: SpeedUnit
・・・
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
32
5. Agentの責任識別
• 形式化されたゴールの達成責任があるAgentを
決める.
• 責任が決められない場合は,さらにゴール分解
する必要がある.
• 基本的には1つのゴールを1つのAgentが責任を
持つ必要がある.
左記は表記法の例
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
33
6. Agentが観測・制御可能な変数
• 形式化ゴールは論理式で記述されている.
• その式はオブジェクトの属性で構成されている.
• そのゴールに責任を持ったAgentは,
– 達成のため属性を制御できないといけない.
– 必要に応じて属性を観測できないといけない.
Goal Maintain[TrackSegmentSpeedLimit]
InformalDef Trainは各TrackSegmentで決められた
SpeedLimit以下を維持しないといけない.
FormalDef ∀tr: Train, s: TrackSegment:
□( On(tr,s) → tr.Speed ≦ s.SpeedLimit )
例えば,左記に責任を
持つAgentは,tr.Speed
を制御でき,
s.SpeedLimitを観測で
きないといけない.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
34
7. Operationの識別
• ゴールはオブジェクトの属性を状態変数と
した状態遷移機械とみなせる.
• ゴールを特徴付ける論理式が真となるよう
な(状態を変化させる)Operationを識別する.
• 開発するソフトウェアが責任を持つゴール
に対応するOperationをRequirementsとする.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
35
支援ツール Objectiver
• KAOSをベースにし
たREツール
• 昔はGRAILと呼ばれ
ていた.
• CEDITI社で作成
– Axel先生の教え
子の会社らしい
http://www.cediti.be/EN/
http://www.cediti.be/EN/Solutions_Services/
http://www.objectiver.com/
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
36
NFR framework
• NFR=Non-Functional-Requirements=非機
能要求
• 機能ではなく性能等に関するゴール(NFR)
の雛形をあらかじめ与えて,
• NFRの扱いを見落とさないようにする支援
とする.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
37
NFRの型
NFR型
効率
セキュリティ
コスト
ユーザー親和性
空間
Confidentiality
時間
Integrity
主記憶
補助記憶
スループット
レスポンス
Availability
プロセス管理時間
Accuracy
Completeness
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
38
Security NFR
時節柄,注意しなければいけないゴール
• Confidentiality 許可されていないアクセスから
データを守ること.
– 一番,よく使われるセキュリティの意味.
• Integrity 不正改竄されてないこと.
– Accuracy 正確である.
– Completeness 完全である.
• Availability 不正なサービス割り込みを抑制する
こと.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
39
ソフトゴール ⊃ NFR
• 充足されるか否かを判断する明確な定義
や基準がないようなゴールのこと.
– 定性的ゴールに似ているが,数値化できなく
ても,判断できるゴールはある.
• このようなゴールを無理に明確化せずに,
それらの間の因果関係を記録(記述)しよう
というのがNFRフレームワークの重要な考
え方.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
40
例: e-アカウントの分析
効率
セキュリティ
空間
時間
保存の空間
-
Integrity
Confidence
+
認証レスポンス
+
非圧縮形式
Available
この辺から
上は,事前
に気を付
けないとい
けないNFR
を知識
ベース化し
ておけば
半自動的
に導ける.
アカウント情報アクセスへの認証
+
インデッ
クス利用
アクセス経路・方法
等が適正か規則に
てらしあわせて確認
ユー
ザーを
認識
下層の太字枠のゴールは,「操作的ソフトゴール」.
機能ゴールと考えてよい.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
ユーザーア
クセスを正
当と認める
PINの利用
41
NFRのGORAへの貢献
• 非機能的要求は忘れやすく,また,扱いに
くいので,それを扱いやすくするという点で
貢献がある.
• NFRのパターンはアプリケーション分野等
を絞れば,さらに使い手のあるパターンを
そろえることができる.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
42
Goal-Question-Metrics法 (GQM)
• あるシステムが満たすべきゴールを充足してい
るか否かのデータ項目(metrics)を識別するため
の手法.
– G ⇒ Q ⇒ M の順に識別.
• ゴールが検証可能であることと,検証に必要な
測定対象を明確化する手段.
– 検証自体は実現後でないとできない場合もある.
• ソフトウェア自体だけでなく開発プロセスの評価
にも利用できる.
– むしろプロセスの評価に使うほうが多いかもしれない.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
43
GQMの背景
• 計測はトップダウンに行なわれるべきである.
– まずは計測目標(Goal)があって,その目標を遂行する
ために,尺度が定義され,計測がおこなわれなければ
ならない.
• データ分析は何らかの目的や仮説に基づいて行
われるべきである.
– 例えば,コスト予測の改善をたてるとか,コストを評価
するのか,その目的を明確にした上で分析が行われ
なければならない.
• 検証(測定)項目が明確化できないような要求仕
様は不備があるといってよい.それをGQMで確
かめることができる.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
44
G, Q, Mそれぞれの定義
• Goal(目標: 概念レベル) 計測の目標を,計測対
象,計測理由,品質モデル,視点,および環境に
基づいて明確にしたもの.
• Question(質問: 操作レベル) 特定のGoalの評価,
あるいは,達成する方法を明確にしたものである.
これにより,計測対象(プロダクト,プロセス,資
源)の特性を品質の観点から明らかにすることが
できる.
• Metrics(尺度: 量レベル) Questionに定量的に答
えるための,データの集合である.データは客観
的データ,主観的データに分かれる.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
45
GQMの評価ステップ
1.
2.
3.
4.
5.
6.
Goalの設定
 何のために評価を行うのか,その目標をGoalとして記述する.
後述のGoal記述のためのテンプレートが役立つ.
Questionの生成
 Goalを量的に表現したQuestionとして記述する.後述の3つの典
型バターンがある.
Metricの明確化
 Questionに答え,プロセスやプロダクトがGoalと一致しているか
どうかを調べる必要なMetricを列挙する.
データ収集法の開発,収集
 ツールによる自動化などは有効.
データの妥当性の確認,分析
データの事後分析
 Goalが達成されたかどうかを調べる.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
46
下線の部分がパラメタとなっています.
Goal作成用のテンプレート A
• 目的
– 計測対象(プロセス,プロダクト,資源)の,
• 例: 設計ドキュメント,テスト工程,保守担当者
– 理由を行うために,
• 例: 特徴づけ,評価,予測,動機付け,改善
• 観点
– その焦点を,
• 例: コスト,正しさ,バグ率,変更回数,信頼性,使いやすさ,
適時性
– 視点の立場から,
• 例: ユーザー,管理者,開発者,開発組織
• 環境
– コンテクストにおいて分析する.
• 例: 実験プロジェクト,実プロジェクト,開発現場,実験室,大
学
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
47
Goal 作成用のテンプレート B
• 対象
– 対象の,
• 例: ソフトウェアの修正依頼処理,システムテスト,最終プロ
ダクト,設計者
• 論点
– 焦点を,
• 例: コスト,正しさ,バグ率,変更回数,信頼性,使いやすさ,
適時性
• 視点
– 視点の立場から,
• 例: ユーザー,管理者,開発者,開発組織
• 目的
– 目的する.
• 例: 特徴づけ,評価,予測,動機付け,改善
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
48
Questionのパターン
• 「対象」そのものを「目的」から見て明確にするための質問.
– 例: 「修正依頼」に対する「現在の処理速度」は?
– 例: 「修正依頼処理」は,「本当に行われいる」か?
• 「対象」の属性を「観点(視点)」から見て明確にするための質問.
– 例: 修正依頼の「実際の処理時間」は,「予測とどれくらい食い
違って」いますか?
– 例: 修正依頼の「処理能力」は,「向上」していますか?
• 「対象」の特徴を「観点(視点)」から見て評価するための質問
– 例: 修正依頼の「処理能力」は,「プロジェクトマネージャー」から
見て,満足のゆくものですか?
– 例: 修正依頼の「処理能力」は,「目に見えて向上」しています
か?
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
49
Metrics 設定に関する留意点
• 既存データの量と質: 信頼できる既存データが存在する
場合は,できるだけ利用する.
• 計測対象の成熟度: 形式的に定義できる計測方法もある
程度確立されている対象に対しては,客観的尺度を用い
る.そうでない場合は主観的尺度を用いる.
• 学習: GQMモデルは常に洗練し,さまざまな場合に適用
させてゆく必要がある.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
50
Metricの例
• 修正依頼の処理時間の平均
• 上記の分散
• 処理時間があらかじめ定められた上限を超えた
件数
• 修正依頼処理が決められたとおりに行われいる
かどうかの,プロジェクトマネージャーの主観的
評価
• レビューによって明らかになった,修正依頼処理
が決められた通りに行われていない件数
修正依頼の平均時間
• 対象プロジェクトにおける 修正依頼の標準的な平均処理時間
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
51
簡単な例
Goal
あるGUIの,使いやすさを,ユー
ザーの観点から評価する.
Question
ある処理に平均してどれくらいの時間がかかるか?
Metric
必要なアクション数
(ボタン押し数等)
Metric
各アクションの
応答時間
Metric
イベントソース(ボタン
等)間の相対位置
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
52
AGORA: 属性付ゴール分析法
• Attributed Goal-Oriented Requirements Analysis
= AGORA
• 目的
– ステークホルダ間の対立,誤解等を検知を支援.
– 対立するゴールの取捨選択を支援.
• ゴールグラフの枝と節に属性値を付加
– 枝: 貢献度: サブゴールの親ゴールへの貢献の度合
い.
– 節: 好感度: stakeholder毎の節ゴールに対する満足度.
– 属性付けの根拠を付記 (Rationale)
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
53
例: ダメージ比較での衝突の回避
For customers
having Email accounts
For international use
ゴール分解の際,貢献度,非貢
献度を数値化して,ダメージの少
Web account system of high quality
ない法を選択する.
-7
+7
and
+10
Easy to register
an account
+7
こちらは次の伏線
Everyone can register
possible to resolve
this conflict
Difficult to
avoid this
conflict
one can complete to
register immediately
+10
No identification
-7
Safe
+3
others do not register me
+10
-10
Identification
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
54
例: 詳細化による衝突の回避
For international use
+5
+10
For customers
having Email accounts
Web account system of high quality
+7
Easy to register
an account
Safe
+7
one can complete to
Everyone can
register immediately
register
+5
+10
-10
Anyone who have
Email accounts
can register
No identification
Because `Everyone’ is not an
initial goal, it may be
weakened.
+3
others do not register me
+10
-7
Identification
上位レベルのゴールで衝突が起
こった場合,ゴール分解(より具
体的な手段)で回避できれば回避
する.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
55
Preference Matrix
• あるゴールをステークホルダが快く思っているか
否か(preference)を示す行列.
• 自分自身だけでなく他のステークホルダの
preferenceも予想してもらうことで互いの衝突や
誤解を検知する.
C,A,D
Evaluator
Evaluatee
C, A, D
8, -7, 0
10, 10,-10
5,-10, 0
C = Customer
A = Administrator
D = Developer
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
56
属性値(優先度)決定と誤解分析
one can complete to
Everyone can
register immediately
register
Anyone who have
Email accounts
can register
+10
+5
-10
+10
+10
+7
No identification
-7
others do not register me
8, -7, 0
10, 10,-10
5,-10, 0
Identification
-5
+7
Identification by return of Email
Imaging a return of Email manually
+10
Identification by SSN
Imaging a return of Email automatically
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
57
詳細化による誤解の解消
+5
Everyone Register immediately
+10
+7
Others do not register me
-10 +10
Anyone who have
Email account
-7
Identification
+7
No identification
+5
+10
8, -7, 0
10, 10,-10
5,-10, Identification
0
by
-7
return of Email Identification by SSN
+10
+10
By return of Email
automatically and immediately
8, 0, 0
10,10,-10
5,10,-10
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
58
International
use
+10
+5
+5
Anyone who have
Email account
-7
Customers
having Email
Easy to register
an account
Web account system of high quality
+7
Safe
+7
+3
Everyone Register immediately
-5,10,10
-5,-5,10
10,-5,10
Others do not register me
+7
+10
-10 +10
Identification
No identification
+10
+10
+7
+5
Input the user name and
password via Web page
by a user
3,-5,-5
3,10,-5
3,10,-5
Identification by
return of Email Identification by SSN
-7
+10
+10
By return of Email
automatically and immediately
OTP=One Time Password
Input user name and
Email address
8, 7, 0
8,10,-3
5,10,-5
+10
+10
Issue an OTP
and send it by Email
-2,10, 0
0,10,-5
0,10,-8
8, 0, 0
10,10,-10
5,10,-10
Register formally
with the OTP
-3, 7, 0
0,10,-3
0,10,-5
Input the user name, first name,
sir name and SSN
Identify the user
by SSN sub system
A Customer needs no less than
three steps for registration.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
59
(1)
ユーザー
AGORAに連結される
ユースケース図群
(3)
ユーザー名,パスワード
即時,無条件登録
ユーザー名,メアド
をウエブに登録
OTP自動送信
ユーザー
ユーザー名,パスワード
名前,SSN
をWebから登録
ユーザー
電子メール
サブシステム
OTPにより正式登録
(2)
名前,SSN
で本人確認・登録
SSN認証
サブシステム
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
60
ゴール階層から
要求仕様書の質を見積る
メトリクス
= ゴール階層から系統的に計算できる数値
特
性
Correctness
Unambiguity
Completeness
Inconsistency
Modifiability
Traceability
Sat Pos Cup Vdv Cov
0.5 0.3 0.2
1
0.6
Hdv Tre
Con
Rat
1
0.4
1
0.7
0.3
IEEE830等で定義されている要求仕様書が持つべき特性
行方向の和が1となるように正規化している.
係数自体の配分は主観的かつ経験的.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
61
メトリクス
• Vdv: 優先度行列の縦方向の分散の平均
• 本稿の要因は「大きいほど良い」ようにしている
ので,実際のVdvは,
– Vdv = 1 – 分散の平均
としている.
C,A,D
Evaluator
Evaluatee
C, A, D
8, -7, 0
10, 10,-10
5,-10, 0
Stakeholder間の共通
認識ができれいれば
小さいし,そうでなけ
れば大きい.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
62
品質要因: Unambiguity
• 定義: 仕様書が唯一の解釈をもつこと.
• Vdvからこの要因を計算してよいと思われ
る.
• 以下のVdv= 0.14 となる.
Input user name and
Email address
8, 7, 0
8,10,-3
5,10,-5
Issue an OTP
and send it by Email
-2,10, 0
0,10,-5
0,10,-8
Register formally
with the OTP
-3, 7, 0
0,10,-3
0,10,-5
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
63
支援ツール (試作段階)
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
64
エピローグ
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
65
まとめ
• ゴール指向分析は以下のような活動に役立つ.
– 要求獲得 (i*, AGORA 等)
– 要求記述 (KAOS 等)
– 要求検証 (KAOS GQM 等)
• (手続き型)プログラム技術と対応する分析技法
には無い視点である「why」を重視.
• いくつかの手法やツールが提案されている.
• シナリオ等,他の技法と組合わせた試みもいくつ
か見られる.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
66
皆さんの現状とゴール指向分析
• 本チュートリアルシリーズ第1回(本年1月15日)で参加者の皆さんに
簡単なアンケートに答えていただきました.
• その結果,
ビジネスモデリング,問題領域分析,要求分析が不十
分.
ビジネスルールや制約の獲得が不十分.
ユーザーが要求をわかっていないため要求定義がう
まくできない.
適切な技法がないため要求定義がうまくゆかない.
のような点を皆さんは要求工学での問題点と感じているようです.
(IBM 鎌田氏らの調査による)
• ゴール指向分析はこれらの一部の解決に貢献するもの
と考えられます.
アンケートに協力して頂いた皆様に感謝致します
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
67
問題点・懸念
• ゴール分析により「また」書き物が増える.
– 追加的な記述に見合う見返りがあるのか?
• 追跡管理の充実.
• 類似技法が死滅した理由
– 過去,IBISやQOC等,設計理由の記録技法
が流行ったが,ほとんど死滅している.
• 目標や理由はそれほど普遍でないからこそ記述す
べきなのか?記述しても無駄なのか?
• そもそもゴール識別自体,難しい.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
68
RE’04京都でのキーノート
ゴール指向要求分析で著名なAxel先生がキーノートをされ
ます.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
69
RE’04 私も発表します!
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
70
引用文献
• [Jac95] M. Jackson, Software Req. & Spec. – A Lexicon of
Practice, Principles and Pejudices, Addison, 1995.
• [Zav97] P. Zave 他, Four Dark Corners of Req. Eng. ACM
TOSEM, 1997, 1-30.
• [Kav02] E. Kavakli, Goal-Oriented Req. Engineering: A
Unified Framework, RE journal, 2002, 6: pp.237-251.
• [Mac96] L. Macaulay, Requirements Engineering, Springer,
1996.
• [Vl91] A. Lamsweerde他, The KAOS Project: Knowledge
Acquisition in Automated Specification of Software, Proc.
of AAAI Spring Symposium Series, Track: “Design of
Composite Systems”, Mar. 1991, pp.59-62.
他,下記ウエブページをご参照ください.
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
71
以上です
御質問・御意見等をお願いします
http://kaiya.cs.shinshu-u.ac.jp/2004/gora/
72
ダウンロード

PPT