資料1（要求分析とプロジェクト管理の概略／構造化分析）

要求分析とプロジェクト管理
（part 1）
手塚太郎
この資料は以下の場所にあります。
http://xi.kc.tsukuba.ac.jp/lec/RAPM1.pdf
なぜ要求分析とプロジェクト管理を学ぶか（１）
„ ソフトウェアの開発にあたっては、顧客（利用者）
の要求の正確な把握、期限内の完成、コストの
最小化などが強く要求される。
„ 実際に開発に携わりながら経験を積むだけでな
く、過去のプロジェクトから得られた知見に学ぶこ
とも可能。
本講義では要求分析とプロジェクト
管理の様々な技法を体系的に学ぶ
2
なぜ要求分析とプロジェクト管理を学ぶか（２）
„ 経験や社内のルールに基づく手法や用語を使ってい
ると、他社との関わりにおいて齟齬を生じる可能性が
ある。
„ 特にプロジェクト管理に関して資格（PMP等）が定めら
れており、これらを取得するためには理論的な知識も
必要。
3
注意事項
„ 要求分析やプロジェクト管理において、正解はひとつ
ではない。
„ ここで述べられる手順に必ず従わなくてはならないと
いうものではない。
„ これから挙げる各項目を暗記するのではなく、その意
義を理解することが重要。
„ なぜそのような概念や手続きが重要であるか。
4
ソフトウェア開発プロセスにおける
要求分析の位置づけ
ソフトウェア開発(Software Development)
„ 顧客の要求をソフトウェア製品に変換する作業
– 良いソフトウェアを効率的に構築
– 品質(良さ)とコスト(時間/お金)のバランスが重要
要求
ソフトウェア開発
プログラム
顧客
ソフトウェア
開発者
コンピュータ装置
(ハードウェア)
6
ソフトウェア開発プロセス
要求仕様書
要求記述
顧客
基本
設計
要求
仕様化
要求
獲得
要求分析
3
3
3 3
3 3
3 3 3
設計
3
3
3
運⽤・保守
納⼊
テスト
報告書
基本設計
仕様書
テスト
a = 0;
…
while ( ) {
if ( )
…
else
…
}
…
ソース
プログラム
詳細
設計
実装
詳細設計
仕様書
7
要求分析
8
要求分析
開発すべきシステム全体の仕様をできるだけ厳密に定義
開発者
z
要求
仕様書
z
利用者
z
z
z
情報処理技術の専門家
発注先
機能仕様書
経営責任者
エンドユーザ
発注者
分析者
z
要求定義をまとめる責任者
(開発者と独立)
9
要求分析
„Requirement analysis
„別名
– 要求定義（Requirement definition）
– 要求工学（Requirement engineering）
10
要求分析とは
„ 顧客や利用者の要求を見つけ，それを仕様化する作業
– 正確かつ厳密に定義することが重要
„ 設計工程や実装工程において誤ったソフトウェアを作成
„ 設計作業や実装作業のやり直しを発生
„ 要求(requirement)
– ソフトウェアを利用することで実現したい内容
– 利用する側からみたソフトウェアが実現すべき目標
„ 機能要求: 開発するシステムが何をするか
„ 非機能要求: 性能，使いやすさ，安全性，保守性，可搬性など
„ 仕様(specification)
– 要求を実現するために必要な機能や性能を提供する際の条件や
制約
– 要求を満たすためにソフトウェアが実現しなけければならない要件
11
なぜ要求分析が必要か
この機能がなければ
使いものにならない
じゃないか！
すぐ修正してくれ！
利用者
そうおっしゃられても、
設計書にはそのような
ご希望は書いておりません！
開発者
12
要求分析の困難さ
„ 顧客や利用者の要求を仕様に正確かつ厳密に反映することは困難
(理由1) 顧客や利用者の要求のあいまいさ
– 現状の業務形態やその問題に対する認識が不十分
– 真の利用者を特定することが困難
(理由2) 利用者と開発者のコミュニケーションギャップ
– 背景，知識，言葉の問題
„ 利用者: 業務の専門家
„ 開発者: システム開発の専門家
– 同じ仕様に対する解釈の違い
(理由3) 顧客や利用者の要求の変化
– はじめから要求を完全に把握することは無理
– 際限ない要求
– 市場や社会情勢，顧客や利用者の業務環境の変化
13
曖昧性の例
ここの機能は特に
高速にお願いします。
１回２秒くらいで
できるかな
技術的問題はありませんので、
お任せください。
２、３分かかっても
大丈夫だよね
14
要求分析の手順
要求獲得
・要求記述を作成
要求仕様化
・要求記述から要求仕様を作成
構造化分析
オブジェクト指向分析
形式的仕様記述
要求確認
・要求を満たしていることを検証
15
要求分析の手順
„ 要求獲得(requirements acquisition/elicitation)
– 顧客や利用者が望むものを引き出し，要求記述としてまと
める作業
„ 問題分析技法の適用
„ 要求仕様化(requirements specification)
– 要求記述から要求仕様を作成する作業
„ あいまいさを排除
„ 誤りや冗長を除去
„ 不足する情報を補足
„ 要求確認(requirements evaluation/verification/validation)
– 作成された要求仕様が正しいかどうかを検査する作業
„ 要求レビューの実施
16
要求獲得
要求獲得
システムの利用者が何を求めているかを明らかにしていく。
利用者
z
z
z
経営責任者
エンドユーザ
発注者
分析者
z
要求定義をまとめる責任者
(開発者と独立)
18
要求獲得の主要目標
要求の抽出
– 顧客自身が明文化できない要求も文書化
– 曖昧性のない共通理解の構築
要求の取捨選択
– すべての要求に応えると経費が膨大に。
– オプション（要求項目）の過不足の防止
– トレードオフの発見と解決
19
要求抽出の手法（１）
„ 資料収集
– 業務やシステムに関する資料の収集
„ インタビュー（ヒアリング）
– 顧客や利用者への質疑
„ アンケート
– 質問事項に対する回答
„ ブレーンストーミング
– 自由な意見交換と意見の整理
„ 現場観察
– 業務の体験や観察
20
要求抽出の手法（２）
„ プロトタイピング
– 試供品の提供
„ シナリオ
– 利用者の行動と，そこから得られる事象の記述
„ ユースケース
– 典型的な利用事例，シナリオを一般化したもの
„ 現行システム分析
„ 問題分析・ニーズ分析
„ 目的展開（ゴール指向分析）
– ゴール(目標)の明確化と分割
21
プロトタイピング （モックアップ）
„要求に基づきシステムのプロトタイプを作成
„顧客が機能や使い勝手を部分的に評価
利点：
文書だけでは伝えられない操作イメ
ージを伝えられる。
難点：
ソフトウェアの部分的な開発が必要
のため、分析者（仕様作成者）自身が
開発スキルを持つか、開発者との協
力のもとで行わなくてはならない。
22
シナリオ
„ システム利用時に誰がいつ、何を行い、どのように
状態が変化するかを示す。
„ 自然言語、アニメーション、動画等で表現する。
利点：
新しいシステムでの仕事の流れをイ
メージしやすい。
難点：
システム利⽤時のある特定の流れだ
けを記述しているため、その挙動に
関して網羅的でない。
23
シナリオの例
Contents Management System （CMS）の場合
24
シナリオの例
Contents Management System （CMS）の場合
コンテンツ更新
1
更新担当者はブラウザにURLを入力
2
システムはユーザIDとパスワードを要求
3
更新担当者はユーザIDとパスワードを入力
4
システムは現在のページを表示
５
更新担当者は編集ボタンをクリック
6
システムは編集用画面を表示
7
更新担当者はテキストコンテンツを編集
8
更新担当者は更新ボタンをクリック
9
システムは確認用画面を表示
10
更新担当者は了承ボタンをクリック
11
システムは更新されたページを表示
12
更新担当者はログアウトボタンをクリック
13
システムは一般向け画面を表示
25
ユースケース
„ システムの機能ごとに外部との相互作用を記述
– 文書や図で表現
„ UMLにおけるユースケース図など。
新規登録を⾏う
会員情報を
変更する
注⽂者
商品をカートに
追加する
ネット販売システム
⽀払完了を
通知する
<<include>>
ログイン認証を
<<include>>
⾏う
料⾦係
商品をカートから <<include>>
<<include>>
削除する
カートの内容を
確認する
注⽂を確定する
商品情報を
提供する
配送する商品を
確認する
倉庫係
26
現行システム分析
„現在の業務システムの構成要素を網羅的にリス
トさせる。（漏れが無いことが重要）。
„「業務システム」には現在、手動で行われている
作業も含んでよい。
手法例：
9業務フロー図
9
IDEF0
27
問題点分析・ニーズ分析
„ 現在の業務システムにおける問題やニーズを顧客にリ
ストアップしてもらう。
„ ボトムアップアプローチのため、漏れが生じる可能性が
ある。
28
目的展開（ゴール指向分析）
„ もっとも大きな目的から出発し、より詳細なものに展開し
ていく。
„ トップダウンアプローチ。
„ うまく利用すれば目的を網羅的にリストすることができ、
矛盾する目的の検知にも使える。
手法例：
9 i*（アイスター）
9 KAOS
29
ゴール木の例
インターネットを⽤いて商品を
安全に販売するシステムを作る
AND
Webを利⽤して
簡単かつ迅速に購⼊できる
セキュリティを
確保する
AND
AND
ショッピングカート
⽅式の採⽤
ユーザ登録
を簡単に
個⼈認証を
導⼊する
暗号通信を
利⽤する
OR
承認不要の
会員登録
登録不要
30
要求の選択が必要となる状況
„ トレードオフ
– 二つの要求が矛盾し、片方を実現するならもう片方を
実現できない時、選択が必要になる。
„ オプション
– いずれの形でも高次の要求を実現できる時、どちらを
採用するか選ぶ必要がある。
„ コスト制約
– すべての要求に応えていると、予算があまりにも大き
くなってしまうことがある。
31
トレードオフ
目的展開によって現れた項目の間で
両立が難しい組み合わせが生じることがある。
個⼈認証を
導⼊する
トレードオフの発生
登録不要
⽭盾
意思決定の必要性
32
オプション
„ 目的分析において、どちらを選んでもよい、OR関係にあ
る項目
„ ステークホルダーとの調整によっていずれを選ぶか決
定を行わなければならない。
ユーザ登録
を簡単に
OR
承認不要の
会員登録
登録不要
33
要求の選択手法
„ 交渉(negotiation):
– 合意形成による要求間の矛盾の解消
„ トリアージ(triage):
– 要求のふるい落とし
„ 意思決定（decision making）
– なるたけ合理的な形で決めることが求められる。
34
合意形成の手法
„ 要求分析以外でも使われている一般的な合意形成手法
が使用できる。
– デルファイ法
– AHP (analytic hierarchy process)
35
要求仕様化
要求仕様化の流れ
変換（BPR, Business process reengineering)
抽象化された業務内容
抽象化
業務内容
要求記述
AsIs
現⾏論理
モデル
(2)
(1)
現⾏物理
モデル
ToBe
(3)
新規論理
モデル
具体化
(4)
新規物理
モデル
要求仕様
(5)
現在のシステム
新規に開発するシステム
（計算機が含まれないこともあり）
論理的観点: どのような情報が必要であるかという要件（本質的）
物理的観点: その情報を得るための仕組みに対する要件（具体的）37
要求仕様化の手順
1) 現行物理モデルの構築
現状の業務(人手部分+機械化部分)を分析
9 物理的なレベル(ありのまま)で正確に表現
2) 現行論理モデルの構築
本質的な機能や問題の洗い出し
9 本質的でない部分(人，組織，タイミング，媒体など)を除外
9 本質的な部分の抽象的な概念への置換え
3) 新規論理モデルの構築
新たに開発するシステムで解決すべき問題の洗い出し
9 追加あるいは削除する機能の特定
9 機械化部分と人手部分の境界の決定
4) 新規物理モデルの構築
新規論理モデルを制約条件を満たすように具体化
9 機械化部分と人手部分の境界の最終決定
38
要求仕様化の手法
代表的なものとして、以下が挙げられる。
„構造化分析
„オブジェクト指向分析
„形式的仕様記述（フォーマルメソッド）
39
構造化分析以外の伝統的な視覚的表現
„ 業務フロー図（巻紙分析図）
– 国内で広く使われている
„ IDEF0
– 特に⽶国で広く使われている
40
業務フロー図（巻紙分析図）
業務の流れを視覚化
学生
学務
教員
データベース
作業の開始
履修登録票
提出
受付
単純ミス
修正
OK
ルール
チェック
入力
履修指導
要指導
登録票返却
作業終了
41
IDEF0 (Integration Definition for Function Modeling)
米国では広く使用されているシステム記述の標準的
様式
データの流れとシステムによる制御を記述
制約
入力
アクティビティ
出力
機構
42
IDEF0による記述の例
履修手引き
問題のある
履修登録票
教育課程表
履修指導
教員
修正された
履修登録票
学生
このような図を大量に書くことでシステムを記述する。
43
構造化分析
構造化分析
„構造化プログラミングを参考に作られている。
„要求を段階的に詳細化していく。
構造化プログラミング
45
構造化プログラミング
構造化プログラミング(structured programming) [IBMの技術規範IPT]
記述が容易 → 理解が容易なプログラムの構築技法
(1) 分割統治(divide and conquer):
大きく複雑なプログラムを小さく簡単なプログラム(モジュール:module)
の合成によって実現する。
(2) 段階的詳細化(stepwise refinement):
要求プログラムを抽象データ型を仮定して作成し，上位の
抽象データ型を下位の抽象データ型で繰り返し具体化
46
構造化分析で使用する図式
機能に着目したモデル化:
9 データフロー図(DFD, data flow diagram)
9
データ辞書(data dictionary)
9
プロセス仕様書(process specification)
9
ユースケース
この3つはセットで使う。
データに着目したモデル化:
9
実体関連図(ER図, entity relationship diagram)
状態変化や制御手順を含む時系列動作のモデル化:
9
状態遷移図(state transition diagram)
9
リアルタイム用データフロー図
47
構造化分析の一般的な流れ
全体文脈図（コンテキスト図）
DFDレベル1
データフロー図
データ辞書
DFDレベル2
DFDレベル3
……
詳細化
プロセス仕様書
48
データフロー図
z 構⽂: 4つの基本記号のグラフ表現
z 意味: 各記号に付加された名称(情報)に依存
フロー1
源泉
（エンティティ）
プロセス1
フロー6
フロー4
フロー3
吸収
（エンティティ）
データストア
フロー2
プロセス2
フロー5
49
データフロー図 (cont’d)
„ プロセス(process) = バブル(bubble)
– 入力データから出力データへの変換処理を表現
– 個々のプロセスには，その処理内容を表す名称を付与
„ フロー(flow)
– プロセス間の定常的なデータの流れ(移動)を表現
– 矢印にデータの意味を表す名称を付与
„ データストア(data store) = ファイル(file)
– データを格納する場所
– 格納するデータの名称(入出力フローの名称と同じ)を付与
„ 名称は省略可
„ エンティティ(entity)
– システムの外部に存在する機器，組織，人間などを表現
– 内容を表す名称を付与
„ 源泉(source): データの発生元
„ 吸収(sink): データの最終的な行き先
50
データフロー図の例
„ プロセス
– ネット販売
„ エンティティ
– 注文者，料金係，倉庫係
注⽂者情報（個⼈情報）
⽀払完了通知
メッセージ
ログイン情報（ID／パスワード）
注⽂者
商品検索キーワード
ネット販売
商品⼀覧
注⽂情報
料⾦係
商品管理情報
発送依頼メッセージ
倉庫係
商品
51
データフロー図の階層化
„ 全体文脈図(context diagram)
– データフロー図の記述の出発点(DFDレベル0)
– システム全体を1つのプロセスで表現
– システムと外界(エンティティ)とのデータのやりとりを表現
„ 階層化の方法
– プロセスの詳細化
„ プロセスの内部処理を詳細化(DFDレベル1, 2, 3, …)
„ 1つのプロセスを複数のプロセスに分割
„ 分解したプロセス間のデータの流れを明確化
– データの詳細化
„ 1つのデータを複数のデータ要素に分割
52
プロセスの詳細化
z 詳細化における約束
‹ プロセスの⼊出⼒フローは，詳細化の前後で維持
b
プロセスpの
詳細化
p
a
e
d
c
q
f
プロセスqの
詳細化
d
b
q2
c
q3
p2
a
p1
p3
e
c
q1
q4
f
53
データフロー図の限界
„ 制御フロー(制御の流れ)を表現できない
– プロセス間の処理に関する時間的順序や条件選択は記述不可能
cf. フローチャート(flowchart): 制御フローを表現
„ データフローの入出力に関する対応関係を表現できない
– どの入力フローがどの出力フローにつながるのか不明確
– プロセスの分割で対処
„ 入出力データフローに関する順序やタイミングは表現できない
– イベントや同期のための制御信号は扱わない
„ すべてのデータフローを明記する必要がある
– 特定の条件においてのみ必要なデータフローを区別不可能
– データフローが多すぎて煩雑になることもある
54
要求記述の例（１）
ネット販売業務の要求記述
„注文者は，事前に注文者情報を新規に登録する必要がある．注文者情
報とは，注文者の氏名，住所，電話番号，初期パスワードをあわせたデ
ータを指す．新規登録において，会員管理係は，注文者情報を受け取る
と，その注文者がすでに会員であるかどうかを検査する．もし会員でなか
ったら，会員番号を発行し，注文者情報とともに会員情報ファイルに登録
する．
„注文者は，会員情報を変更することができる．その際，注文者は会員管
理係にログイン情報を送付して，会員認証に成功していなければならな
い．ログイン情報とは，注文者の氏名とパスワードを合わせたデータを指
す．
„注文受付係は，注文者から受け取ったログイン情報により会員認証を行
う．会員認証に成功した注文者だけが，商品の検索や注文ができる．
„注文受付係は，注文者から商品検索キーワードを受け取ると，商品管理
ファイル内部の商品より該当する商品を検索し，それら商品一覧を注文
者に返送する．
55
要求記述の例（２）
„注文者は，注文受付係に注文情報を送ることで，希望する商品を注
文することができる．
„注文受付係は，注文情報を受け取ると，その注文に関する振込完了
通知メッセージの到着を待つ．注文者が商品の購入代金を料金係に
支払うと，料金係は支払完了通知メッセージを注文受付係に送る．
„注文受付係は，支払完了通知メッセージを受け取ると，それに該当す
る商品の発送情報を商品管理係に送る．
„商品管理係は，発送情報を受け取ると，倉庫係に発送依頼メッセージ
を送る．
„倉庫係は，発送依頼メッセージを受け取ると，注文者に商品を送付す
る．
„商品管理係は，倉庫係から商品管理情報を適時受け取り，商品管理
ファイルに格納する．商品管理情報には，取扱商品情報や，それらの
商品の入庫情報および出庫情報が含まれる．
56
全体文脈図の例
„ プロセス
– ネット販売
„ エンティティ
– 注文者，料金係，倉庫係
代⾦
注⽂者情報
⽀払完了通知
メッセージ
ログイン情報
注⽂者
商品検索キーワード
ネット販売
商品⼀覧
注⽂情報
商品管理情報
発送依頼メッセージ
商品
料⾦係
倉庫係
57
課題： 以下の要求記述からデータフロー図を作成せよ
„会員管理係は，注文者から注文者情報を受け
取ると，会員番号を発行し，注文者情報とともに
会員情報ファイルに登録する．
„注文受付係は，注文者から受け取ったログイン
情報により会員認証を行う．
„注文受付係は，注文者から注文情報を受け取
ると，その注文に関する振込完了通知メッセー
ジの到着を待つ．注文者が商品の購入代金を
料金係に支払うと，料金係は振込完了通知メッ
セージを注文受付係に送る．
58
DFDレベル1の例（一部）
注⽂者情報
会員情報
1
会員管理
ログイン情報
会員情報ファイル
ログイン情報
注⽂者
会員情報
料⾦係
⽀払完了通知
メッセージ
2
注⽂受付
注⽂情報
„会員管理係と注文受付係はITシステムの導入以前に
は人間あるいは人間の集まり（部門）であった。
„ITシステムにおいてはこれらはプロセスとみなされ、プ
ログラムのモジュールという形で実装される。
59
DFDレベル1の例（全体）
注⽂者情報
1
会員管理
ログイン情報
料⾦係
会員情報ファイル
ログイン情報
注⽂者
商品検索キーワード
商品⼀覧
注⽂情報
2
注⽂受付
⽀払完了通知 商品管理ファイル
メッセージ
発送
情報
商品
3
商品管理 管理情報
発送依頼
メッセージ
倉庫係
60
DFDレベル2の例
„ 「2 注文受付」プロセスに着目し，詳細化
– 2 → 2.1, 2.2, 2.3
2.1
ログイン情報 ログイン
処理
会員情報ファイル
注⽂情報
注⽂者
商品⼀覧
2.3
商品購⼊
商品⼀覧
料⾦係
注⽂情報
商品検索キーワード
2.2
商品検索
⽀払完了通知
メッセージ
商品管理ファイル
3
商品管理
„注文受付係をひとつの部署とみると、それを複数の
担当者の仕事に分解できることに相当する。
要求記述の詳細化の例（１）
ネット販売業務の要求記述(商品購入時の手順を詳細化)
„注文情報は，商品選択情報（選択する商品の商品番号
と商品選択メッセージ），商品取消情報(選択を取り消す
商品の商品番号と商品取消メッセージ)，注文確認メッセ
ージ，注文確定メッセージに分けられる．
„商品選択係は，注文者から商品番号を受け取ると，それ
をカート情報に追加する．
„商品取消係は，注文者から商品番号を受け取ると，それ
をカート情報から削除する．
62
要求記述の詳細化の例（２）
„注文確認係は，注文者から注文確認メッセージを受け取
ると，カート情報に存在する商品群に関する商品情報を
商品管理ファイルから取り出し，注文者に商品一覧として
送る．
„商品確定係は，注文者から注文確定メッセージを受け取
ると，カート情報に存在する商品群の商品番号を取り出し
，それらを注文情報として振込確認係に送る．
„振込確認係は，料金係から送られる支払い完了通知メッ
セージを待つ．支払完了メッセージを受け取ると，注文確
定係から受け取った注文情報を商品管理係に送る商品
管理情報には，取扱商品情報や，それらの商品の入庫
情報および出庫情報が含まれる．
63
DFDレベル3の例
„ 「2.2 商品購入」プロセスに着目し，詳細化
– 2.2 → 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5
2.2.1
商品選択
商品選択
メッセージ
注⽂者
商品番号
商品番号
2.2.2
商品取消
商品取消メッセージ
注⽂確定
メッセージ
カート情報
商品管理ファイル
注⽂確認メッセージ
商品⼀覧
2.2.3
注⽂確認
2.2.4
注⽂確定
注⽂情報
料⾦係
⽀払完了通知
メッセージ
2.2.5
振込確認 注⽂情報
3
商品管理
64
プロセス仕様書
z プロセス仕様書 (process spec) = ミニ仕様(mini spec)
–
–
プロセス分割の終着点
データフロー図の最下層のプロセスの基本処理の内容を表現
„ 構造化言語: 連接，選択，反復の3つの構造により手続き的に記述
„ 決定表(decision table): 特定の条件と，それが成立するときのシス
テムの動作の対応を表で表現
„ 計算式
「2.2.1 商品選択」に関するプロセス仕様
構造化⾔語による例
1 受け取った商品番号に該当する商品をカート情報から取得し，
以下のいずれかの処理を⾏う．
1.1 もし，該当商品が⾒つかった場合，以下の処理を⾏う．
1.1.1 該当商品の個数をカート情報から取得する．
1.1.2 該当商品の個数を1つ増加する．
1.1.3 新しい個数をカート情報に保存する．
…
65
データ辞書
„ データ辞書(data dictionary)
– データフロー図に現れるデータ項目間の関係や構造を表現
„ a=b : aはbに等しい(等価，is equivalent to)
„ a+b : aとbからなる(連接，and)
„ [a|b]: aまたはbのどちらかである(選択，either-or)
„ (a) : aはあってもなくてもよい(任意，optional)
„ {a} : aを0回以上繰り返す(反復，iterations of)
– m{a}n; aをm回以上かつn回以下繰り返す
– m{a}; aをm回以上繰り返す
– {a}n; aをn回以下繰り返す
データ辞書の例
注⽂者情報 = ⽒名 + 住所 + (電話番号) + 初期パスワード
初期パスワード = 4{英数字}8
注⽂情報 = [商品選択情報 | 商品取消情報 | 商品確認情報 | 注⽂確定情報]
66
ユースケース
ユースケース(use case) [Jacobson]:
9 システムの機能ごとに作成
9
システムの利用者側(アクタ)からみた使われ方を表現したもの
z
アクタ:
システムに対して利用者が果たす役割(role)
役割ごとに異なるアクタが存在
外部システムでもよい
受益者(beneficiary)
9
利用者の目的に照らして結び付けられた一群のシナリオ
z
シナリオ: 利用者とシステム間の対話を表す一連の手順
ユースケースのインスタンス
67
ユースケースの例
システム境界
アクタ
ユースケース
予約する
予約者
予約を取り消す
予約を変更する
シナリオ
名称
予約する
開始アクタ 予約者
目的
ホテルの部屋を予約する
正常処理シナリオ
1. 予約者は予約可能かどうかを問い合わせる．
2. 予約者はホテル，日付，部屋種別を選択する．
3. システムは予約者に価格を提示する．
4. 予約者が予約を申し込む．
5. 予約者は名前と郵便番号を入力する．
6. 予約者はe-mailアドレスを入力する．
7. システムは予約を受け付け，予約番号を発行
する．
...
予約状況を見る
予約管理者
予約システム
例外処理
3. 空き部屋がない
a. システムは代替案を提示する．
b. 予約者は代替案から選択する．
....
68
実体関連図
機能中心: 同じデータを異なるファイルで重複して保存
同じデータの仕様が異なる
問題点
データ中心: データのモデル化
データ(data)
現実の世界に存在する実体を反映
z 固有の特性(属性)を有する
z 処理の仕方(処理手順)とは独立
z
実体関連図(ER図)
69
実体関連図
„ データ構造やデータ間の関係を表現
„ 関係データベース（Relational database）に変換しやすい。
„ 実体(entity)
– システム内に存在する管理対象(人，もの，お金，場所など)
– 名前をもつ長方形で記述
– 抽象的な概念や目に見えないものでもよい
„ 関連(relationship)
– 実体間の相互の結びつき
– 関連名を持つ菱形で表示
– カーディナリティ(cardinality)
„ 関連するインスタンスの数の比を表現(1:1, 1:N, M:N)
– モダリティ(modality)
„ 関連が必須であるかどうかを表現
70
実体関連図(cont’d)
実体関連図(ER図)
9 実体(entity): システム内に存在する管理対象(人，物，金，場所)
名前をもつ四角形で表示
9
関連(relationship): 実体間の相互の結びつき
関連名を持つ菱形で表示
実体
顧客
注文する
関連
商品
71
関連
カーディナリティ(cardinality)
関連するオブジェクトの数を表現 (1:1, 1:N, M:N)
複数の「店舗」が1つの「都道府県」に対応
都道府県
所在
店舗
1つの「都道府県」は複数の「店舗」に対応
モダリティ(modality)
関連が必須であるかどうかを表現
「修理作業」の発生には「顧客」が必須
顧客
依頼する
修理作業
「顧客」に対して「修理作業」が必要ない場合あり
72
実体関連図の例
注⽂者情報
登録する
インスタンスが1つ インスタンスが複数も可能
必須で⼀つ
注⽂者
必須で複数も可
商品
購⼊する
類似する
必須でない
必須でない
使う
必須で1つ
ネット販売
システム
実体
（再帰的）関連
管理する
関連
73
課題： 実体関連図を描く
„ twitterにおけるデータの実体関連図を描け。
„ ユーザ、プロフィール、ツイート、フォロー、リプライなど
を表現すること。
注⽂者情報
参考用
登録する
インスタンスが1つ インスタンスが複数も可
必須で1つ
購⼊する
注⽂者
使う
必須
商品
必須でない
必須でない
必須
ネット販売
システム
実体
類似する
（再帰的）関連
管理する
関連
74
解答例
プロフィール
登録
ユーザ
ツイート
フォロー
リプライ
75
状態遷移図
z システムが取りうるすべての状態(state)と，そのシステムに到着したイ
ベント(event)による状態の変化を表現
z リアルタイムシステム，制御系システム，通信システムに関する要求
の仕様化
z システム = 状態機械
– 状態
„ 円(あるいは四角形)で表現
„ システムは必ず1つの状態に属する(複合状態を除く)
– 遷移
„ 遷移を誘発させるイベントを付与した矢印で表現
„ イベントに対する遷移先は現在の状態によって変化
„ イベントは一瞬，遷移時間は無視
– アクション
„ 状態が遷移した際に実行される処理（副作用）
76
状態遷移図の例
状態
初期状態
終了状態
アクション
ログイン/メニュー表⽰
起動
終了
イベント
ログイン
画⾯
新規登録
会員
登録中
ログアウト
ログイン中
(注⽂中)
タイムアウト
登録完了/メニュー表⽰
遷移
77
課題： 状態遷移図を描く
„
„
„
„
„
2階建におけるエレベータの状態遷移図を描け。
上昇中、下降中などの状態を設けてもよい。
ドアが開いた状態で移動しないように注意。
初期状態・終了状態は1階でドアが開いた状態に結び付いている。
行き先階の指定は不要で、ドアが閉じたら自動で動き出すものとし
てよい。
状態
イベント
アクション
初期状態
終了状態
ログイン/メニュー表⽰
起動
終了
ログイン
画⾯
新規登録
会員
登録中
ログアウト
ログイン中
(注⽂中)
タイムアウト
登録完了/メニュー表⽰
参考用
遷移
78
解答例
初期状態
終了状態
起動
1階で
ドア開
閉ボタンを押す/
ドアが閉じる
2階で
ドア開
ドアが開く
上昇開始
1階で
ドア閉
到着
ドアが開く
上昇中
下降中
閉ボタンを押す/
ドアが閉じる
到着
2階で
ドア閉
下降開始
79
課題： 構造化分析その他で要求仕様化
„ グループになり、一人は利用者、残りは分析者となり、要求抽
出と要求仕様化を行え。ただし本講義で述べられた手法や図
式を使って仕様化を行うこと。システムは架空のものでよい。
手法と図式の例：
„ 業務フロー図
„ データフロー図
„ データ辞書
„ プロセス仕様書
„ 実体関連図
„ 状態遷移図
„ IDEF0
80