要求工学プロセスの知識に関する研究 妻 木 俊 彦

要求工学プロセスの知識に関する研究
－発見的知識の体系とそれを表現するためのフレームワーク－
妻 木 俊 彦
目次
はじめに ･･･････････････････････････････････････････････････････ 1
第 1章
要 求 工 学 の現 状 と課 題 に関 する調 査 ・・・・・・・・････････････ 13
1.1. 要 求 工 学 の課 題 ･･･････････････････････････････････････ 13
1.2. 要 求 工 学 技 術 の概 要 ･･･････････････････････････････････ 17
1.2.1. 要 求 獲 得 技 法 ･････････････････････････････････････ 17
1.2.2. 要 求 定 義 技 法 ･････････････････････････････････････ 25
1.2.3. 要 求 の進 化 と多 様 化 のための技 法 ････････････････････ 30
第 2章
要 求 工 学 プロセス知 識 の記 述 ････････････････････････････ 35
2.1. 発 見 的 知 識 の記 述 方 法 ･････････････････････････・・･････ 36
2.2. 要 求 獲 得 プロセスの構 造 ･････････････････････････・・･････ 37
2.3. プロセスパターンの形 式 ･･････････････････････････・･･････ 40
2.3.1. 状 況 セクションの形 式 ････････････････････････････････ 41
2.3.2. 課 題 セクションの形 式 ････････････････････････････････ 43
2.4. 況 遷 移 図 の形 式 ･･･・・･･･・･････････････････････････････ 46
2.5. 要 求 工 学 プロセスパターンの記 述 例
･･・・・･････････････････ 48
2.5.1. 状 況 セクションと簡 易 型 状 況 遷 移 図 ・・・・・・・・・・・・・・・・ 48
2.5.2. 課 題 セクションと完 全 型 状 況 遷 移 図 ・・・・・・・・・・・・･････ 51
2.6. 事 例 研 究 ： 航 空 運 輸 システム ･・・・・・・・・・・・・・・・・・・・・・･・･ 53
2.7. 関 連 研 究 ････・・・･･････････････････････････････････････ 57
2.8. 考 察 ････････････・・・･･･････････････････････････････････ 59
第 3章
要 求 工 学 技 法 の選 択 ･･･････････････････････････････････ 61
3.1. 要 求 獲 得 技 法 の分 類 ････････････・・･････････････････････ 62
3.2. プロジェクト特 性 への要 求 工 学 技 法 の適 合 性 ･･･・・･････････ 68
3.2.1. アプリケーションドメイン ･･････････････････････････････ 68
3.2.2. 要 求 技 術 者 タイプ ･･････････････････････････････････ 69
3.2.3. 情 報 資 源 ･･････････････････････････････････････････ 70
3.2.4. ユーザの参 加 ･･････････････････････････････････････ 71
ii
もくじ
3.2.5. 要 求 品 質 ･･････････････････････････････････････････ 72
3.2.6. 非 機 能 要 求 ･･･････････････････････････････････････ 73
3.3. 状 況 変 化 への貢 献 ････････････・・･･･････････････････････ 73
3.4. 事 例 研 究 ････････････････････・・･･･････････････････････ 75
3.4.1. 研 究 発 表 会 支 援 システム ････････････････････････････ 75
3.4.2. 原 子 燃 料 棒 管 理 システム ････････････････････････････ 80
3.5. 関 連 研 究 ･････････････・・･･････････････････････････････ 84
3.6. 考 察 ･････････････････････・・･･･････････････････････････ 86
第 4章
要 求 モデルの連 携 ･･････････････････････････････････････ 89
4.1. 要 求 モデル連 携 の枠 組 み ･･･････････・・･･････････････････ 90
4.2. モデル連 携 の構 造 ･････････････････・・･･･････････････････ 92
4.3. モデル連 携 の記 述 方 式 ･･････････････・・･････････････････ 97
4.3.1. 形 式 論 的 一 貫 性 の保 証 ･････････････････････････････ 97
4.3.2. 意 味 論 的 一 貫 性 の保 証 ････････････････････････････ 102
4.4. 事 例 研 究 ： 対 外 系 パッケージにおける要 求 変 更 管 理 ･････ 104
4.5. 関 連 研 究 ･･････････････････････････････････・・････････ 109
4.6. 考 察 ･･････････････････････････････････・・･････････････ 111
第 5章
まとめと関 連 する課 題 ･･･････････････････････････････････ 113
5.1. 研 究 のまとめ ････････････････････・・････････････････････ 113
5.2. 研 究 の評 価 ・・・・・・・・・・・・・・・・・・･・・･･･････････････････ 116
5.3. 関 連 する今 後 の課 題 ・・・・・・・・・・・･・・･･･････････････････ 120
5.3. 結 び ･･････････････････････････・・･････････････････････ 122
参 考 文 献 ････････････････････････････････････････････････････ 125
もくじ
iii
図一覧
図 -2.1
プロジェクトの概 要 ･････････････････････････････････････ 39
図 -2.2
構 造 化 シナリオ ･･･････････････････････････････････････ 39
図 -2.3
活 動 サイクルの構 造 ･･･････････････････････････････････ 40
図 -2.4
状 況 セクションの概 念 構 造 ･･････････････････････････････ 42
図 -2.5
状 況 セクションの記 述 形 式 ･･････････････････････････････ 43
図 -2.6
課 題 セクションの概 念 構 造 ･･････････････････････････････ 45
図 -2.7
課 題 セクションの記 述 形 式 ･･････････････････････････････ 45
図 -2.8
状 況 遷 移 図 の概 念 構 造 ･･･････････････････････････････ 47
図 -2.9
状 況 遷 移 図 ･･････････････････････････････････････････ 48
図 -2.10 状 況 セクションの例 ･･･････････････････････････････････ 50
図 -2.11 簡 易 型 状 況 遷 移 図 の例 ･･･････････････････････････････ 51
図 -2.12 課 題 セクションの例 ････････････････････････････････････ 52
図 -2.13 完 全 型 状 況 遷 移 図 の例 ･･･････････････････････････････ 53
図 -3.1
要 求 工 学 技 法 マップ ･･･････････････････････････････････ 67
図 -3.2
ドメインの安 定 性 ･･････････････････････････････････････ 69
図 -3.3
技 術 者 の気 質 ････････････････････････････････････････ 70
図 -3.4
情 報 資 源 ･･････････････････････････････････････････ 71
図 -3.5
ユーザの参 加 ･････････････････････････････････････････ 71
図 -3.6
要 求 品 質 ･･････････････････････････････・・････････････ 72
図 -4.1
ゴール指 向 モデル ････････････････････・・･･････････････ 95
図 -4.2
オブジェクトモデル ････････････････････････・・・･････････ 95
図 -4.3
ユースケースモデル ･･･････････････････････・・・･････････ 96
図 -4.4
メッセージシーケンスモデル ･･････････・・･････････････････ 96
図 -4.5
オブジェクトモデルの外 部 連 携 規 則 ・････････････・・･･････ 98
図 -4.6
ユースケースモデルの外 部 連 携 規 則 ･････････････････・･･ 98
図 -4.7
クラス図 における内 部 依 存 関 係 ････････････････････・･･･ 99
図 -4.8
オブジェクトモデルの内 部 連 携 規 則 ････････････････････ 100
図 -4.9
ユースケース図 における内 部 依 存 関 係 ･････････････････ 101
図 -4.10 ユースケースモデルの内 部 連 携 規 則 ・･･････････････････ 102
図 -4.11 モデル連 携 を表 す２つの依 存 関 係 ･････････････････････ 103
iv
もくじ
図 -4.12 モデル連 携 依 存 関 係 ･･････・・・・・・・・･･････････････････ 104
図 -5.1
知 識 の抽 出 と体 系 化 ･････････････････････････････････ 115
図 -5.2
知 識 の利 用 形 態 ････････････････････････････････････ 121
図 -5.3
要 求 工 学 支 援 ツールの機 能 構 造 ･･････････････････････ 122
もくじ
v
表一覧
表 -3.1 技 法 と次 元 空 間 ･･･････････････････････････････････････ 64
表 -3.2 要 求 獲 得 の問 題 ･･･････････････････････････････････････ 74
表 -3.3 マトリックスによる要 求 の整 理 ･････････････････････････････ 78
表 -4.1 相 手 先 起 動 集 信 のサブシナリオ階 層 構 造 ････････････････ 106
表 -4.2 モデル連 携 テーブル ・・・・・・・・・・・・・・・・・････････････････ 107
表 -5.1 知 識 フレームワークの定 性 的 評 価 ・・・・・・・・・・・・・・・・・･････ 117
はじめに
本 論 文 は，要 求 工 学 プロセスにおける偶 発 的 な問 題 を解 決 するために必 要 な
知 識 の体 系 化 と表 現 法 の試 みについて述 べたものである．
はじめに，こうした研 究 を行 うに至 った筆 者 の個 人 的 な経 緯 について簡 単 に述
べる．筆 者 は，旧 日 本 ユニバックに入 社 以 来 ，様 々なソフトウェアの開 発 に立 ち
会 い，要 求 の多 様 さとそれを定 義 することの難 しさを目 の当 たりにしてきた．オンラ
イン･トランザクションプロセッサの開 発 では，要 求 は開 発 者 自 身 がソフトウェアの
製 品 仕 様 に基 づいて独 自 に定 義 しなければならなかったし，アプリケーションパッ
ケージの開 発 では，要 求 をクライアント独 自 の要 求 と該 当 業 務 に共 通 した要 求 に
分 離 することの難 しさを知 らされた．また，エキスパートシステムの開 発 に携 わった
ときには，いわゆる領 域 の専 門 家 といわれる一 筋 縄 ではいかない人 たちを相 手 に，
専 門 的 な知 識 を聞 き出 し，システムの目 標 と機 能 を定 義 するには様 々な技 法 が
必 要 なことを痛 感 した．オブジェクト指 向 の分 析 設 計 手 法 の研 究 を行 いながら，
構 造 化 手 法 からオブジェクト指 向 への社 内 のパラダイムシフトを図 ったこともあった
が，静 的 モデルのような空 間 認 識 は，多 くの技 術 者 にとって習 得 の難 しい技 術 で
あるのに対 し，動 的 モデルのように対 象 の変 化 を認 知 することは容 易 な作 業 であ
ることを知 らされた．
こうした経 験 を通 して学 んだことは，単 一 の手 法 によってカバーできる問 題 の範
囲 は極 めて狭 いこと，また，人 の認 知 特 性 の違 いによって使 用 できる技 法 に適 性
があるということであった．一 方 ，OMGのプロセス工 学 WGでのソフトウェア開 発 プロ
セスのメタモデル化 の作 業 を通 して，個 々の手 法 は，独 自 に組 み合 わせて使 用
することが可 能 であることを学 んだ．さらに，個 人 的 な経 験 から，多 くの技 法 は，そ
の本 質 的 な性 質 を理 解 さえしていれば，応 用 範 囲 が格 段 に広 がるということも分
かった．
しかし，現 実 のソフトウェア開 発 の現 場 では，要 求 の重 要 性 が認 識 されながら，
プロジェクト失 敗 の原 因 の多 くが，相 も変 わらず，要 求 工 学 プロセスにあるという状
2
はじめに
態 から脱 皮 できないでいる．要 求 工 学 プロセスへの投 資 コストの少 なさを問 題 とす
る意 見 もあったが，筆 者 は，要 求 工 学 技 術 自 体 が抱 える２つの問 題 に注 目 した．
その1つは，要 求 工 学 技 術 の多 様 性 の問 題 である．要 求 工 学 はソフトウェアそ
のものの意 味 を扱 う唯 一 の技 術 であり，ソフトウェアの意 味 を定 義 するために，要
求 の発 生 源 である複 雑 で曖 昧 な現 実 世 界 と，要 求 された機 能 を実 現 する厳 密
で正 確 なソフトウェアという２つの異 なった世 界 を扱 わなければならない．ステーク
ホルダとの共 同 作 業 を通 して，ソフトウェアが備 えるべき機 能 や品 質 ，性 能 などを
明 らかにし，それを開 発 するのに必 要 かつ十 分 な情 報 を収 集 するのが要 求 分 析
者 の仕 事 である．しかし，決 められた期 間 内 に，問 題 領 域 の知 識 やソフトウェアへ
の要 求 を正 確 に理 解 するだけでなく，ステークホルダが欲 している要 求 の本 質 を
見 抜 き，あいまいな知 識 を明 確 にし，矛 盾 した要 求 を調 整 することも要 求 分 析 者
の仕 事 の一 部 である．要 求 工 学 が，論 理 学 やコンピュータサイエンスといった工
学 的 な技 術 から，認 識 論 や人 類 学 ，言 語 学 といった社 会 科 学 的 な知 識 をも含
む学 際 的 な技 術 であると言 われる所 以 である[105]．ソフトウェア開 発 の現 場 で
日 々忙 しく働 いている多 くの要 求 技 術 者 が，このように多 様 で膨 大 な要 求 工 学
技 術 を習 得 し，利 用 できるようにするにはどうすればよいかということが，筆 者 にと
っての1つ目 の課 題 であった．
もう1つの問 題 は，熟 練 技 術 者 が持 つ経 験 的 な知 識 や技 術 の取 り扱 いである．
実 際 のプロジェクトでは，要 求 技 術 者 が抱 えている多 くの問 題 を要 求 工 学 技 法
だけで解 決 することは難 しく，熟 練 技 術 者 がもっている知 識 やノウハウといった発
見 的 知 識 の助 けを借 りなければならないことが多 い．しかし，明 文 化 されていない，
その属 人 的 な知 識 の実 体 を把 握 することは極 めて難 しい．著 名 な要 求 技 術 者 ら
がどのように問 題 を解 決 しているかという Hikey らの調 査 によっても，豊 富 な経
験 とスキルにもとづいた熟 練 技 術 者 の振 る舞 いの本 質 が明 らかになったわけでは
なく，幾 つかの個 別 のノウハウが垣 間 見 えただけである[62]．実 際 ，熟 練 者 たちは
独 自 のノウハウによって，プロジェクトの状 況 を判 断 し，問 題 解 決 に有 効 と思 われ
る手 法 を適 切 に選 択 し，それらを上 手 に組 み合 わせて問 題 を解 決 している．もと
より，熟 練 技 術 者 のノウハウを一 般 の技 術 者 がそのまま受 け入 れることは容 易 な
ことではない．筆 者 にとっての要 求 工 学 のもう1つの課 題 は，要 求 工 学 に関 する
様 々な発 見 的 知 識 を，個 人 的 なノウハウから技 術 へと昇 華 することであった．
この2つの課 題 を解 決 したいというのが，本 研 究 を行 うことになった直 接 の動 機
はじめに
3
である．以 下 に，本 論 文 の研 究 目 標 について，簡 単 に述 べる．
研究目標
本 研 究 の目 標 は，多 様 な要 求 工 学 知 識 を容 易 に利 用 できるようにすることであ
り，実 際 のプロジェクトで必 要 とされる要 求 工 学 知 識 のフレームワークを提 案 する
ことである．高 度 情 報 化 時 代 の到 来 とともに，ソフトウェアに対 する要 求 は進 化 と
多 様 化 の波 に晒 され，それを定 義 するための作 業 はますます困 難 になりつつある．
複 雑 な問 題 を解 決 するために多 くの技 術 が開 発 され，提 案 されてきたが，技 術 の
多 様 化 は，一 方 で，過 酷 な現 場 で日 々の作 業 に追 われている要 求 技 術 者 たち
にとって，技 術 習 得 の障 害 となっている．本 研 究 で提 案 するフレームワークが，要
求 工 学 に関 する多 様 な知 識 に再 利 用 の道 を開 き，現 場 の技 術 者 たちを支 援 す
ることを期 待 している．
本 研 究 で提 案 するフレームワークは，工 学 的 知 識 と発 見 的 知 識 を含 む知 識 体
系 とその表 現 法 を含 んでいる．体 系 化 とは，複 雑 で理 解 が困 難 な問 題 を整 理 し，
理 解 を容 易 にするための技 術 で，分 割 や抽 象 化 ，構 造 化 といった方 法 がある
[18]．本 論 文 では，熟 練 技 術 者 が個 人 的 に持 っているが明 文 化 されていない経
験 則 を発 見 的 知 識 と呼 び，未 だ公 開 されていない個 人 的 な技 法 や，工 学 的 な
知 識 の効 果 的 な使 用 法 （第 3章 ），工 学 の対 象 外 の心 理 学 的 あるいは社 会 学 的
な知 見 をも含 んでいる．一 方 ，確 立 された要 求 工 学 技 法 によって規 定 され，明 文
化 され，公 開 された手 順 や制 約 に関 する知 識 （第 4章 ）のことを工 学 的 知 識 と呼
んでいる．これを技 術 とは言 わずに知 識 と呼 んでいるのは，規 則 そのものではなく，
それを習 得 した人 間 の知 識 体 系 に焦 点 を当 てようとしているからである．これらの
知 識 の何 れが欠 如 しても，問 題 を解 決 することは難 しい．学 而 不 思 則 罔 、思 而
不学則殆．
知識の体系化
本 論 文 では，要 求 工 学 技 法 の選 択 における発 見 的 知 識 と，モデルの変 更 にお
ける工 学 的 知 識 の体 系 化 について提 案 する．要 求 技 術 者 たちの個 人 的 な経 験
に根 ざした個 別 の発 見 的 知 識 を再 利 用 できるようにするには，その中 から普 遍 的
な知 識 を選 別 し，明 文 化 する必 要 がある．しかし，選 別 されただけの知 識 は，たと
え普 遍 性 を持 っていたとしても，依 然 として個 別 のままであることに変 わりはない．
4
はじめに
関 連 した知 識 を集 約 し，知 識 体 系 を整 備 することが，収 集 された個 別 の知 識 を，
より多 くの技 術 者 たちが有 効 に活 用 できるようにするための道 である．発 見 的 知
識 の体 系 化 でよく使 用 される方 法 は抽 象 化 である．もともと断 片 的 な知 識 である
発 見 的 知 識 を体 系 化 するには，知 識 が捨 象 されるリスクを回 避 するよりも，より本
質 的 な知 識 を発 見 することの方 が重 要 である．一 方 ，要 求 工 学 技 法 の中 で明 示
的 に定 義 された工 学 的 知 識 である制 約 条 件 を厳 密 に定 式 化 するのに有 効 な方
法 の1つは，規 則 化 である．技 法 を構 成 する規 則 は，それがどんな些 細 なもので
あっても捨 象 することは許 されない．それゆえ，工 学 的 知 識 を体 系 化 するための
方 法 として，規 則 の構 造 化 がよく用 いられる．規 則 の構 造 を定 義 するためにメタ
知 識 が用 いられることもある．しかし，メタ知 識 は規 則 全 体 の形 式 的 構 造 を統 語
的 に表 現 するだけで，その意 味 まで表 現 することはできない．
知識の表現法
体 系 化 された知 識 を再 利 用 できるようにするには，それらを何 らかの形 式 で表
現 し，明 示 化 することが必 要 となる．さらに，知 識 は，その性 質 によって表 現 の形
式 が異 なっている．多 くの表 現 法 の中 でもっとも自 然 な方 法 は，自 然 言 語 による
記 述 である．自 然 言 語 による記 述 には，冗 長 性 やあいまい性 が伴 う反 面 ，文 脈
や構 文 といった付 随 的 な機 構 による豊 富 な意 味 世 界 の表 象 が可 能 であり，属 人
的 な発 見 的 知 識 を表 現 するのに適 している．第 2章 では，パターンの記 述 に自 然
言 語 を使 用 している．
一 方 ，絵 や図 式 といった図 形 を使 った表 現 は理 解 の容 易 性 に優 れているが，
表 現 できる情 報 量 には限 界 があり，補 完 的 な手 段 が必 要 となる場 合 が多 い．第 2
章 の状 況 遷 移 図 や第 4章 のモデル連 携 依 存 関 係 は図 式 表 現 を使 用 することに
よって知 識 の全 体 像 を直 感 的 に表 現 しているが，それを理 解 するためには自 然
言 語 による詳 細 な説 明 が必 要 である．
対 象 同 士 の相 対 的 な関 係 を視 覚 的 に表 現 するために，座 標 空 間 を使 用 する
ことがある．座 標 空 間 上 の位 置 関 係 から，座 標 軸 以 外 の新 たな軸 を発 見 できるこ
ともある．第 3章 の要 求 工 学 技 術 マップは，座 標 空 間 を使 って要 求 工 学 技 術 の
特 徴 を視 覚 的 に表 現 している．
知 識 を規 則 の形 で表 現 する方 法 は，情 報 同 士 の論 理 的 関 係 を表 現 するのに
適 しており，機 械 化 も可 能 である．第 4章 では，規 則 表 現 の一 種 であるプロダクシ
はじめに
5
ョン･ルールを採 用 することによって，モデル連 携 規 則 の厳 密 な記 述 を目 指 してい
る．
論文の構成
本 論 文 では，第 2章 から第 3章 に亘 って次 の3種 類 の異 なった知 識 の体 系 化 と
表 現 法 について議 論 する．
・ プロジェクトにおける個 別 の問 題 解 決 のための知 識 （第 2章 ）
・ プロジェクトに適 した要 求 獲 得 技 法 の選 択 に関 する知 識 （第 3章 ）
・ 要 求 変 更 におけるモデルの一 貫 性 保 証 に関 する知 識 （第 4章 ）
これらの3種 類 の知 識 は，一 見 ，無 関 係 そうに見 えるかもしれない．しかし，本 論
文 のなかでは，発 見 的 知 識 と工 学 的 知 識 ，個 別 の知 識 と体 系 化 された知 識 とい
う議 論 によって，要 求 工 学 に関 する知 識 の全 体 像 を構 成 していることが示 される．
以 下 に，各 章 の概 要 を示 す．
第 ２章 では，プロジェクトにおける偶 発 的 な問 題 を解 決 するための発 見 的 知 識
について議 論 する．異 なった知 識 と経 験 を持 った人 たちが共 同 で作 業 を行 う要
求 工 学 プロセスでは，しばしば予 期 せぬ問 題 が発 生 する．提 案 されている多 くの
技 法 や手 法 は，予 想 可 能 な問 題 に対 する解 決 法 を提 示 してはくれるが，偶 発 的
な問 題 に対 しては多 くの場 合 無 力 である．手 法 による解 が期 待 できない問 題 に，
熟 練 技 術 者 の知 識 が有 効 な場 合 がある．本 章 では，ソフトウェア開 発 における個
別 の知 識 を記 述 するための方 法 として注 目 を集 めているパターン[53,54]を使 っ
て，発 見 的 な知 識 を再 利 用 する方 法 について提 案 する．しかし，これまでに提 案
されているパターンの多 くはソフトウェアの設 計 に関 する知 識 を記 述 したものであり
[29]，プロセス上 の問 題 を解 決 するための知 識 を記 述 したパターンの報 告 は少 な
い[59,142]．本 論 文 では，ソフトウェア開 発 プロセスにおける個 別 の知 識 を記 述 し
たパターンをプロセスパターンと呼 び，要 求 工 学 におけるプロセスパターン，すなわ
ち，要 求 工 学 プロセスパターンの形 式 について議 論 するとともに，パターンをプロ
セスの進 行 に沿 って体 系 的 に表 現 するための状 況 遷 移 図 を提 案 する．
第 ３章 では，プロジェクトの特 性 をもとに，適 切 な要 求 工 学 技 法 を選 択 するため
の基 盤 となる知 識 の体 系 と，それを表 現 するための方 法 を議 論 する[143]．プロジ
6
はじめに
ェクトを成 功 させる重 要 な要 因 の1つが，技 法 の選 択 にあることはよく知 られている
[62]．しかし，一 般 の要 求 技 術 者 にとって，多 様 な要 求 工 学 技 法 の中 から自 身
のプロジェクトにとって適 切 な技 法 を選 択 することは容 易 なことではない．本 章 で
は，代 表 的 な要 求 工 学 技 法 を，その性 質 によって特 徴 付 け，新 たなプロジェクト
が発 足 したり，プロジェクトの性 質 が変 化 した時 ，あるいは要 求 獲 得 作 業 中 に障
害 が発 生 した時 などに実 施 しなければならない適 切 な技 法 選 択 の基 盤 となるフレ
ームワークを提 案 する．ここで扱 う知 識 は，第 2章 で議 論 した要 求 工 学 プロセスパ
ターンの中 で個 別 に記 述 されていた手 法 選 択 のための発 見 的 知 識 を集 約 し，体
系 化 したものである．
第 ４章 では，複 数 の異 なった要 求 モデルを使 用 しているプロジェクトで，要 求 変
更 が発 生 した際 に，要 求 モデルの一 貫 性 を保 証 するのに必 要 な知 識 を取 り上 げ，
その記 述 方 式 と体 系 化 について提 案 する．状 況 の変 化 に応 じて異 なった手 法 を
使 用 し，異 なった要 求 モデルを作 成 したプロジェクトは，モデルの一 貫 性 ，すなわ
ち，要 求 モデル同 士 の間 に矛 盾 が無 いということを保 証 する必 要 がある．新 たな
モデルを作 成 する際 のモデル同 士 の一 貫 性 の保 障 に関 する研 究 はあるが[49]，
要 求 モデルの変 更 に関 する問 題 については，要 求 追 跡 の研 究 [141]以 外 ，これ
まであまり議 論 されてはこなかった．ここで扱 う知 識 は，第 3章 で扱 ったような意 思
決 定 のための知 識 ではなく，具 体 的 な作 業 を支 援 するための知 識 である．
これらの議 論 に先 立 ち，第 １章 では，要 求 工 学 プロセスにおける課 題 と，それを
解 決 するための要 求 工 学 技 術 の全 貌 を概 括 し，本 研 究 との関 係 について議 論
する．また，第 ５章 では，全 体 のまとめを行 い，本 論 文 の成 果 について議 論 し，さ
らに，今 後 の課 題 として，多 様 な形 式 で記 述 された要 求 工 学 知 識 を，実 際 のプ
ロジェクトに供 するための支 援 システムについて述 べる．
はじめに
7
用語
要 求 工 学 は，ソフトウェア工 学 の他 の領 域 に較 べ，その成 立 が遅 れたため，用
語 の慣 用 的 な使 用 が長 く続 き，その定 義 が必 ずしも統 一 されているとは言 い難 い
状 況 にある．ここで，本 論 文 で使 用 する若 干 の用 語 について言 及 しておくことに
する．
「要 求 」という用 語 は，英 語 の“requirements”の日 本 語 訳 である．国 内 ではし
ばしば，要 求 の代 わりに要 件 という用 語 が使 われることがある．要 求 は顧 客 が望
んでいること，要 件 は開 発 者 と顧 客 が合 意 したことなどという説 明 がなされることも
あるが，要 件 という言 葉 には，要 求 をソフトウェア側 から捉 えたという意 味 合 いが強
く現 れており，それゆえ，システム仕 様 を含 んで用 いられることが多 い．したがって，
本 論 文 では，requirements に対 する用 語 として，「要 求 」という用 語 を統 一 的 に
用 いる．ソフトウェア工 学 で使 用 する用 語 の定 義 をしている IEEE-610 における
「要 求 」の定 義 は次 のとおりである[68]．
“(1) a condition or capability needed by a user to solve a problem or
a c h i e v e a n o b j e c t i v e ; ( 2 ) a c o n d i t i o n o r c a p a b i l i t y t h a t m u s t be m e t o r
possessed by a system or system component to satisfy a contract, standard,
specification, or other formally imposed documents; (3) a documented
representation of a condition or capability as in (1) or (2).”
ここでは，要 求 とは，問 題 を解 決 し，目 標 を達 成 するための機 能 や条 件 のことで
あると定 義 されている． Southwell は要 求 を，その内 容 によって機 能 要 求 と非 機
能 要 求 に分 け，さらに非 機 能 要 求 を，効 率 ，信 頼 性 ，インタフェース，設 計 制 約
に分 類 した[130]．IEEE においても，機 能 要 求 に加 え，性 能 要 求 ，インタフェー
ス要 求 ，設 計 制 約 ，実 装 要 求 ，物 理 的 要 求 といった非 機 能 要 求 が定 義 されて
いる[68]．また，Robertson らは，要 求 をさらに詳 細 に検 討 することによって，機
能 要 求 ，感 覚 的 要 求 ，使 用 性 要 求 ，性 能 要 求 ，操 作 性 要 求 ，保 守 性 と移 植 性
要 求 ，安 全 性 要 求 ，文 化 的 政 治 的 要 求 ，法 的 要 求 といった9種 類 の要 求 に分
類 している[116]．本 論 文 の第 3章 では，非 機 能 要 求 のための技 法 の選 択 につい
ても議 論 する．
必 要 かつ十 分 な要 求 を正 しく定 義 し，それらを次 工 程 の設 計 者 たちに正 確 に
伝 達 するには，それなりの技 術 やプロセスが必 要 となる．要 求 工 学 は，要 求 に関
8
はじめに
わる技 術 を研 究 する領 域 である． Zave による要 求 工 学 の定 義 は，次 のようなも
のである[152]．
Requirements engineering is the branch of software engineering concerned
with the real-world goal for, functions of, and constraints on software
system. It is also concerned with the relationship of these factors to precise
specifications of software behavior, and to their evolution over time and
across software families.
この定 義 によれば，要 求 工 学 は単 に要 求 仕 様 書 を作 成 するだけではなく，要
求 の進 化 や再 利 用 にも関 係 している．Loucopoulos らも，要 求 工 学 を，問 題 を
分 析 し，観 察 の結 果 を文 書 化 し，理 解 の正 しさをチェックするためのシステム的 な
プロセスであると定 義 している[89]．
The term requirements engineering (RE) has been defined as the
systematic process of developing requirements through an iterative
co-operative process of analysing the problem, documenting the resulting
observations in a variety of representation formats and checking the
accuracy of the understanding gained. This definition is based on the
premise that the RE process involves aspects of concern along three
dimensions: the representation, cognitive and social dimensions.
要 求 工 学 の対 象 であるプロセスを，どのように定 義 するかというプロセスモデルの
研 究 も盛 んである．当 初 は，ウォーターフォール型 [38]やスパイラル型 [12]といっ
たソフトウェア開 発 プロセス全 体 の中 で捉 えられることが多 かったが，研 究 の進 化
に伴 い，要 求 工 学 プロセスそのものの実 行 方 式 が提 案 されるようになってきた．
Zeroualらは，要 求 獲 得 （eliciting）と要 求 表 現 （representing）という２つのステッ
プを定 義 し[153]，Kramer らは，要 求 獲 得 （elicitation），仕 様 化
（specification），検 証 （validation）という３つの繰 り返 し操 作 から構 成 されている
としている[85]．また，Rzepka は，要 求 獲 得 を，更 に，要 求 の所 有 者 の識 別 ，要
望 書 の収 集 ，要 望 書 の文 書 化 と詳 細 化 ，要 望 書 の統 合 ，非 機 能 要 求 の定 義 と
いう５つの活 動 に分 割 している[121]．情 報 処 理 学 会 要 求 工 学 ワーキンググルー
プでは，要 求 獲 得 ，記 述 ，検 証 ，管 理 という４つの大 きなステップを，スパイラルに
実 行 する方 式 を提 案 している[107]．また，繰 り返 し型 のアプローチとしては，事 実
はじめに
9
の発 見 ，要 求 収 集 と分 類 ，評 価 と論 理 化 ，優 先 順 位 付 け，統 合 と確 認 という作
業 を必 要 に応 じて自 由 に実 行 する方 式 [25]や，ソフトウェア開 発 プロセス全 体 の
中 で要 求 工 学 プロセスを必 要 に応 じて繰 り返 し実 行 することのできる方 式 [86]な
ども提 案 されている．スパイラル型 や繰 り返 し型 は，要 求 変 更 への対 応 を容 易 に
するために考 えられたプロセスである．
日 本 では，要 求 工 学 プロセスの作 業 は，要 求 分 析 と要 求 定 義 という２つの部 分
に分 けて考 えられてきた．要 求 分 析 は，ステークホルダがもっている漠 とした要 望
から，その意 図 を明 らかにし，要 求 として明 確 にしてゆくための作 業 であり，最 近
は，要 求 獲 得 （Requirements elicitation）と呼 ばれることが多 い．また，分 析 の結
果 をモデル記 述 言 語 や要 求 記 述 言 語 によって仕 様 として記 述 する作 業 は，要
求 定 義 あるいは要 求 記 述 と呼 ばれてきた．他 方 ，システム化 の目 的 やコストやス
ケジュールといったクライアントとの契 約 に関 わる問 題 は，システム化 計 画 という，
要 求 分 析 とは異 なったプロセスで行 われるものと考 えられてきた[138]．本 論 文 で
は，要 求 獲 得 と要 求 定 義 という用 語 を使 用 する．また，プロジェクトの管 理 に関 す
る問 題 についても議 論 の対 象 としている．
要 求 分 析 者 とは，ステークホルダから要 求 を聞 きだして，それを設 計 者 につなぐ
作 業 を担 当 する技 術 者 のことである[25]．システムの利 用 が限 られた人 たちに限
定 されていた時 代 は，要 求 はユーザから獲 得 されるものと考 えられていたが，情 報
化 時 代 の到 来 とともに，その影 響 が多 岐 にわたるようになり，要 求 の提 示 者 もステ
ークホルダと呼 ばれるようになってきた．すべてのステークホルダが，プロジェクトの
メンバーとなるわけではないが，真 の要 求 を知 っているステークホルダがプロジェク
トに参 加 しているかどうかは，要 求 の品 質 を大 きく左 右 する．Christel は，購 入
者 （customers / sponsors），ユーザ（users），開 発 者 （developers），品 質 査 定
チーム（quality assurance team），要 求 分 析 者 （requirements analysts）がステ
ークホルダに含 まれるとし[25]， Robertson らは，そのシステムの依 頼 者 （client），
ユーザ（user），購 入 者 （customer），システムの操 作 員 （operator），管 理 者
（administrator），プロジェクトの責 任 者 （owner），システムの開 発 者 （engineer）
を挙 げている[116]が，本 質 的 な違 いは無 い．むしろ，同 じステークホルダでも，そ
の背 景 や立 場 によって異 なった要 求 を持 っていたり，熟 練 した専 門 家 ，未 熟 な担
当 者 ，非 常 勤 の作 業 者 といったようなレベルの違 いによって持 っている知 識 や要
10
はじめに
求 が異 なったりする[127]．本 論 文 では，要 求 を提 示 する役 割 を担 っている者 のこ
とをステークホルダと呼 ぶことにしている．
最 後 に，要 求 とは直 接 の関 係 は無 いが，技 術 に関 係 する用 語 について述 べて
おく．本 論 文 では，techniquesに技 法 ，methodsに手 法 ，methodologiesに方 法
論 という用 語 を割 り当 てている．技 法 と手 法 の間 に厳 密 な区 別 は無 いが，技 法 は，
ドメイン分 割 やゴール指 向 分 解 [87]といった，原 始 的 な機 能 を提 供 するための方
法 を指 し，一 方 ，手 法 は，ユースケース法 [74]やi*法 [149]のような，特 定 の目 的
を実 現 するための方 法 を指 すといった使 い分 けをしている．しかし，どちらにも属
する方 法 がある．両 者 を指 すときは，より原 初 的 な技 法 という用 語 を使 用 している．
それに対 し，方 法 論 は，Objectory[74]やUnified method[86]のように，その実 行
方 法 まで規 定 した技 法 や手 法 の集 合 を指 している[25]．
はじめに
11
謝辞
本 論 文 をまとめるにあたり，終 始 ご指 導 とご教 授 を賜 りました，東 京 大 学 大 学
院 総 合 文 化 研 究 科 ，玉 井 哲 雄 教 授 には心 より感 謝 申 し上 げます．玉 井 教 授 に
は，先 生 主 催 のゼミへの参 加 をお誘 いいただき，ソフトウェア工 学 への扉 を開 いて
いただくとともに，論 文 の執 筆 を通 した技 術 的 な指 導 のみならず，その研 究 者 とし
ての姿 勢 をとおして筆 舌 に尽 くしがたい薫 陶 をいただき，今 日 ここまで来 ることが
できました．
本 論 文 のテーマは，日 本 ユニシス株 式 会 社 での経 験 や情 報 処 理 学 会 ソフトウ
ェア工 学 研 究 会 要 求 工 学 ワーキンググループでの研 究 活 動 を通 して培 ってきた
ものです．日 本 ユニシス株 式 会 社 の上 司 や同 僚 には，多 くの情 報 や示 唆 をいた
だき感 謝 いたします．なかでも，初 期 の段 階 で論 文 の執 筆 という世 界 へ誘 ってい
ただいた森 澤 好 臣 氏 （現 ，北 海 道 情 報 大 学 教 授 ），オブジェト指 向 分 析 設 計 の
共 同 執 筆 者 として叱 咤 激 励 くださった故 岩 田 裕 道 氏 ，ソフトウェア工 学 の何 たる
かを示 してくださった山 崎 利 治 氏 には大 変 お世 話 になりました．また，要 求 工 学
ワーキンググループの活 動 を通 して，大 西 淳 立 命 館 大 学 教 授 ，佐 伯 元 司 東 京
工 業 大 学 教 授 ，筑 波 大 学 の中 谷 多 哉 子 助 教 授 には，多 くの技 術 的 な指 導 をい
ただきました．さらに，要 求 工 学 企 業 人 グループ“mahoroba”のメンバー諸 氏 には，
実 務 に関 する議 論 を通 して多 くの示 唆 をいただきました．ここに，謹 んで感 謝 の辞
を呈 します．
12
はじめに
第 1 章
要求工学の現状と課題に関する調査
要 求 工 学 は，複 雑 なソフトウェアを開 発 するための中 核 技 術 であり[20]，そのゴ
ールは優 れた要 求 仕 様 書 を作 ることにある[25]．要 求 獲 得 ，定 義 ，検 証 といった
活 動 を支 援 するために，様 々な手 法 やプロセスモデルが研 究 され，提 案 されてき
た．しかし，それにも関 わらず，ソフトウェアの開 発 現 場 では，プロジェクトを破 綻 に
導 くような重 大 に問 題 に絶 えず直 面 している[133]．本 論 文 の目 標 は，現 場 で起
きている重 大 な問 題 に適 切 に対 処 できるように，要 求 工 学 に関 する工 学 的 知 識
と発 見 的 知 識 を整 理 することである．第 2章 以 降 の，要 求 工 学 知 識 の記 述 と体
系 化 の議 論 に先 立 ち，本 章 では，研 究 の背 景 となる主 要 な技 術 を概 括 し，本 論
文 の研 究 目 標 との関 係 について述 べる．
1. 1. 要 求 工 学 の 課 題
はじめに，プロジェクトが遭 遇 し，場 合 によっては破 綻 を引 き起 こすかもしれない
要 求 工 学 上 の問 題 を整 理 し，その原 因 について考 える．
政策的問題
ソフトウェア開 発 プロジェクトにおける最 初 の，かつ，最 も重 要 な仕 事 は，
作 成 するシステムがどのように使 用 されるのかを知 ることである．ステークホル
ダの関 心 は，コンピュータにあるのではなく，コンピュータが何 をしてくれるか
にある[41] ．それにも かか わらず ，システム 開 発 者 の 視 点 は，コンピュータ そ
14
第1章
要求工学の現状と課題に関する調査
のものに拘 束 されてしまって，システム化 の目 的 やシステム境 界 といった本
来 の目 標 が明 確 にされないまま要 求 獲 得 作 業 が始 まってしまう場 合 がある．
そのようなプロジェクトで定 義 された要 求 の中 には，実 現 の妥 当 性 のない要
求 や，不 要 な設 計 情 報 などが紛 れ込 んでいたりする[25]．
はじめに，目 標 を確 認 しておくことが重 要 である．しかし，上 位 管 理 者 の短
絡 的 な思 いや，現 場 からの風 評 だけに動 かされたプロジェクトでは，クライア
ントの責 任 者 に尋 ねてみても，システム化 の目 的 を明 確 にすることが困 難 な
場 合 がある．このように，問 題 そのものが不 明 確 な状 況 でも，ソフトな手 法
[24]を使 って課 題 を明 確 にすることもできる．しかし，その地 位 にしがみつこう
とする責 任 者 の下 で，目 標 を見 失 った多 くのプロジェクトは，波 間 に揺 れる
木 の葉 のように，時 間 の暗 闇 を漂 っているだけである．要 求 問 題 に入 る前 に，
明 確 な方 針 を策 定 することが急 務 である．
経済的問題
ステークホルダの要 求 を実 現 するには，それに見 合 ったソフトウェアを作 成
するための時 間 とコストが必 要 となる．しかし，現 実 のプロジェクトが使 用 でき
る時 間 とコストには制 約 がある．それにも関 わらず，分 析 者 は，しばしば，制
約 を無 視 した要 求 に遭 遇 することがある．無 謀 な要 求 は，計 画 された期 間
や予 算 内 での開 発 が難 しいと判 断 されると，実 装 段 階 で無 視 されることにな
る．これはプロジェクトにおける経 済 的 な問 題 である．プロジェクトの経 済 に影
響 を与 えるもう1つの問 題 は，要 求 の変 更 である．要 求 変 更 が発 生 すると，
開 発 や保 守 のためのコストが増 加 し，場 合 によっては代 替 案 を採 用 する必
要 が出 てくる．それゆえ，要 求 技 術 者 には，代 替 案 の選 択 とともに，ソフトウ
ェア開 発 に関 する時 間 とコストを見 積 もるための技 術 も必 要 とされる．こうし
た経 済 的 な問 題 から，要 求 プロセスでの手 抜 きが強 要 される場 合 がある．し
かし，手 抜 きによって生 じる誤 解 や見 落 としといったエラーは，開 発 プロセス
の後 半 に，より大 きなしわ寄 せとなって返 ってくることに注 意 すべきである
[11]．
これまで，経 済 的 な問 題 の原 因 の多 くはシステム化 計 画 段 階 での見 積 も
りのミスである場 合 が多 かったが，今 後 は，要 求 の進 化 と多 様 化 がその主 要
な原 因 となってくると予 想 される．経 済 的 な問 題 は，技 術 的 問 題 よりプロジ
ェクト管 理 的 な問 題 に発 展 することがある．第 2章 では，プロジェクトの環 境
第1章
要求工学の現状と課題に関する調査
15
に強 く影 響 を受 ける偶 発 的 問 題 を解 決 するための発 見 的 知 識 について議
論 する．
組織的問題
プロジェクトが失 敗 する主 要 な原 因 の１つに，ステークホルダのプロジェクト
への不 参 加 がある[133]．実 際 ，要 求 技 術 者 の多 くがステークホルダの非 協
力 的 な態 度 に困 惑 している．ステークホルダ不 在 の問 題 は，インタビューや
レクチャによる情 報 収 集 のときだけでなく，ゴール指 向 分 析 やブレーンストー
ミングといった，より本 質 的 な要 求 を発 見 するためのグループワークの際 など
に，より大 きな障 害 となる．真 の要 求 を知 っているステークホルダを発 見 する
ことは難 しく，そのうえ，多 忙 な彼 らの協 力 を得 ることは，さらに困 難 である．
しかし，問 題 領 域 に無 知 なステークホルダを参 加 させることは，ステークホル
ダの不 在 以 上 の混 乱 をプロジェクトに引 き起 こすことになりかねない[25]．
その原 因 がステークホルダ側 の問 題 であるにもかかわらず，クライアントとの
力 関 係 から，問 題 の解 決 が要 求 分 析 者 の側 に委 ねられる場 合 が多 い．要
求 技 術 者 の経 験 と能 力 が，もっとも必 要 とされる場 面 である．第 ３章 では，
プロジェクトの意 思 決 定 の構 造 を解 析 し，それを支 援 する方 法 について議
論 する．
文化的問題
プロジェクトの参 加 者 たちの間 に，予 期 せぬ誤 解 が生 じることがある．誤 解
の主 たる原 因 は，プロジェクト内 における意 思 疎 通 の欠 如 である場 合 が多 く，
その結 果 ，「要 求 された通 りのソフトウェアを作 っても，顧 客 が喜 ぶとは限 らな
い」[119]という反 省 だ けが残 るこ とになる．意 思 疎 通 を阻 害 する要 因 の1つ
は，メンバー同 士 のバックグラウンドの違 いである．知 識 や嗜 好 や立 場 の違
い が ， 意 見 の 衝 突 を 生 む [25] ． ス テ ー ク ホ ル ダ 同 士 の 視 点 の 違 い に よ っ て
生 じる衝 突 を解 消 するには，必 要 以 上 に多 くの労 力 を要 する場 合 が多 い
[14]．ステークホルダと要 求 分 析 者 とでは，問 題 領 域 に対 する知 識 のレベル
が異 なるので[25]，両 者 の間 で使 用 する知 識 や言 葉 の意 味 が異 なるという
場 合 もあ る[127]． 問 題 領 域 内 だけで使 用 される独 自 の 専 門 用 語 は，それ
を知 らない分 析 者 にさまざまな誤 解 を生 じさせる．また，会 話 の中 で使 用 さ
れる曖 昧 な日 常 語 も誤 解 を生 む原 因 の１つとなる[25]．俗 語 の使 用 も注 意
を要 する．ステークホルダの発 言 が，公 式 のものか非 公 式 のものかを判 別 す
16
第1章
要求工学の現状と課題に関する調査
ることも重 要 である[41]．一 般 常 識 と問 題 領 域 内 での常 識 が異 なっているた
めに，ステークホルダの省 略 した常 識 に分 析 者 が気 付 かないこともある[25]．
また，開 発 者 同 士 の非 公 式 の議 論 は，分 析 者 の目 標 に対 する理 解 を変 え
てしまうことがあるので注 意 を要 する[67]．だからといって，分 析 者 がステーク
ホルダに用 語 の意 味 をその都 度 確 認 しているようでは，作 業 が不 効 率 にな
るだけでなく，ステークホルダの不 信 を招 くことにもなる．
こうした問 題 を避 けるために，用 語 集 の作 成 や議 事 録 の確 認 などといった
様 々な方 法 が提 案 されている．しかし，現 象 は多 様 であり，問 題 が起 きてい
ることに気 が付 かない場 合 も多 い．問 題 の発 見 の仕 方 から解 決 法 までを包
含 した，広 範 な発 見 的 知 識 が必 要 となるが，集 約 化 することの難 しい知 識
の扱 いについては，第 ２章 の個 別 知 識 の体 系 化 で議 論 する
技術的問題
対 象 となる問 題 領 域 に関 する知 識 や，要 求 工 学 に関 する技 術 の欠 如 が，
プロジェクト崩 壊 の直 接 的 な原 因 となる場 合 がある．問 題 領 域 の特 性 やニ
ーズをよく理 解 していないステークホルダの存 在 は，不 適 切 で曖 昧 な要 求 の
原 因 となり，その結 果 繰 り返 される要 求 の訂 正 により，何 時 まで経 っても要
求 が確 定 されないという問 題 が発 生 する．また，情 報 技 術 に対 するステーク
ホルダの理 解 不 足 が，過 剰 な要 求 の原 因 となることもある．問 題 領 域 に対
するステークホルダの知 識 の不 足 を補 うための分 析 者 の知 識 や，隠 れた要
求 を引 き出 すための技 術 が期 待 される．反 対 に，情 報 量 の多 さが，問 題 の
焦 点 を曖 昧 にし，誤 解 を生 じることもある[85]．
プロジェクトを破 綻 から救 い出 すには，それぞれのプロジェクトの状 況 を的
確 に判 断 し，それに適 した手 法 を選 択 し[50]，問 題 を解 決 するための高 度
な技 術 と能 力 が要 求 技 術 者 に要 求 される．しかし，高 度 な技 術 を持 った要
求 技 術 者 を確 保 することは容 易 ではなく，一 方 ，要 求 はますます高 度 化 し
てゆく．要 求 技 術 者 の知 識 と技 術 力 の向 上 は，偏 に，技 術 者 の精 進 にか
かっているといってよい．
教育的問題
時 代 の進 展 とともに，コンピュータの利 用 環 境 はますます複 雑 化 し，情 報
システムが与 える影 響 は，単 にシステムユーザの域 に止 まらず，社 会 全 体 に
広 がってゆきつつある．要 求 者 が，ユーザからステークホルダに代 わった所
第1章
要求工学の現状と課題に関する調査
17
以 である．彼 らは多 様 な視 点 と興 味 を持 ち[41]，それに伴 い，ソフトウェアに
対 するニーズも拡 大 と変 化 を続 け[16]，それが要 求 の進 化 と多 様 性 の引 き
金 となっている[25]．一 方 ，MDSOC[140] やオントロ ジー，エージェントとい
った，進 化 と多 様 性 の問 題 に対 応 するための新 たなソフトウェア技 術 の研 究
も進 んでおり，利 用 者 と開 発 者 をつなぐ要 求 工 学 の役 割 がますます重 大 に
なっている．
進 化 と多 様 化 に対 応 するには，問 題 の特 性 に合 わせた柔 軟 な手 法 の選
択 と，それに伴 うモデルの変 更 という問 題 を解 決 しなければならない．しかし，
複 雑 化 する問 題 を解 決 するには，いきおい技 術 そのものも進 化 せざるを得
ず，現 場 の技 術 者 に対 する教 育 の重 要 性 が増 している．本 論 文 の，要 求
工 学 知 識 に関 するフレームワークの提 案 は，要 求 の進 化 と多 様 性 という新
たな問 題 の解 決 に如 何 に貢 献 できるかを具 体 的 に問 うものである．
1. 2. 要 求 工 学 技 術 の 概 要
要 求 工 学 プロセスの中 でプロジェクトが遭 遇 する問 題 を解 決 するために，様 々
な技 術 が開 発 され，要 求 工 学 として集 大 成 されてきた．ここでは，要 求 工 学 技 術
を，その性 質 によって要 求 獲 得 技 法 と要 求 定 義 技 法 に分 けて整 理 し，最 後 に，
要 求 の多 様 性 と進 化 という新 たな問 題 に対 応 するための技 術 をまとめて議 論 す
る．
1.2.1. 要 求 獲 得 技 法
要 求 獲 得 (requirements elicitation)は，要 求 の所 有 者 であるステークホルダを
通 して，これから作 成 しようとしているソフトウェアに対 する具 体 的 な要 求 や，問 題
領 域 に関 する知 識 や情 報 を収 集 するための作 業 であり，情 報 収 集 （information
gathering）などとも呼 ばれる．
B.Nuseibeh らは，要 求 獲 得 技 法 を，次 のような６つのタイプに分 類 している
[105].すなわち，インタビューに代 表 される伝 統 的 技 法 ，複 数 のステークホルダに
よるグループ技 法 ，仮 製 品 を評 価 するプロトタイピング，モデルを使 って情 報 を分
18
第1章
要求工学の現状と課題に関する調査
析 するモデル駆 動 型 技 法 ，特 定 の個 人 の振 る舞 いに注 目 する認 知 技 法 ，観 察
された現 象 の普 遍 的 なモデルを作 ろうとする文 脈 的 技 法 である．これは，要 求 獲
得 作 業 で使 用 する方 法 や道 具 に注 目 した分 類 で，技 術 の全 体 像 を捉 えるのに
は便 利 な分 類 法 であるが体 系 的 ではない．この分 類 法 を参 考 にして，要 求 獲 得
のための代 表 的 な技 法 を，モデル駆 動 型 技 法 と非 モデル駆 動 型 技 法 ，および関
連 技 法 とに分 けて議 論 する．
複 雑 で困 難 な要 求 獲 得 作 業 を支 援 するために様 々な技 法 （Techniques）や手
法 （Methods）が提 案 されてきた．現 場 の要 求 分 析 者 にとっての課 題 は，そうした
多 様 な技 術 の選 択 と適 用 である．分 析 者 の視 点 による要 求 獲 得 技 法 の分 類 は，
第 3章 で取 り扱 う．ここで取 り上 げるドメインモデル，ゴール指 向 モデル，ユースケ
ースモデルはそれぞれ，第 3章 で定 義 する領 域 分 割 型 ，ゴール指 向 型 ，シナリオ
ベース型 の技 法 を代 表 するモデルであり，非 モデル駆 動 型 技 法 の多 くはブレーン
ストーミング型 技 法 に属 している．
(a) モ デ ル 駆 動 型 要 求 獲 得 技 法
モデルは問 題 領 域 を抽 象 化 したもので，モデルを使 うことによって，要 求 に対 す
るプロジェクトメンバー相 互 の理 解 を深 めることができる．モデルとして抽 象 化 され
た問 題 領 域 は，システム化 の目 標 の妥 当 性 や，個 々の要 求 の完 全 性 を検 証 す
ることを容 易 にし，ステークホルダと要 求 分 析 者 のコミュニケーションの基 盤 を提 供
する．
モデルという言 葉 は，模 型 や模 範 ，あるいは理 論 に対 する実 現 というように，
様 々な意 味 で使 われるが，ソフトウェアの世 界 では，構 造 を持 った対 象 の抽 象 的
な記 述 をモデルと呼 んできた[138]．モデル駆 動 型 技 法 は，獲 得 された問 題 領 域
の知 識 や要 求 を，モデルによって表 現 し，分 析 するタイプの技 法 の総 称 である．
現 在 使 用 されている主 要 な要 求 獲 得 技 法 の多 くは，問 題 解 決 のためのアプロー
チが異 なっていても，このカテゴリーに分 類 される．しかし，直 感 的 理 解 には優 れ
ていても，図 式 には十 分 な説 明 能 力 があるとはいえず，図 式 によるモデルに論 理
的 な厳 密 性 を与 えるために形 式 化 が用 いられることがある．形 式 仕 様 がモデルに
分 類 される理 由 である．
第1章
要求工学の現状と課題に関する調査
19
ドメインモデル
ドメインモデルは，問 題 領 域 を構 成 する実 体 と，それらの関 係 を抽 象 化 し
たものである．ドメインモデルは具 体 的 で明 快 なモデルであり，問 題 の本 質 を
明 らかにし，問 題 領 域 に関 する知 識 の曖 昧 さや矛 盾 を解 消 したり，異 なっ
た考 え方 を持 ったメンバー間 の理 解 と意 見 の統 一 を図 ったりするのに有 効
である[83]．
実 装 言 語 の進 化 とともに，ドメインモデルの構 成 要 素 も変 化 してきた．問
題 領 域 をモデル化 することの重 要 性 をいち早 く唱 えたのは，M.Jacksonであ
る．Jackson は，当 時 の中 心 的 なプログラミング言 語 である手 続 き型 言 語 を
前 提 に，実 体 とその行 動 ならなる実 体 構 造 図 を提 案 した[70]．しかし，その
両 者 を同 時 にモデル化 することは容 易 ではなく，その後 登 場 したオブジェク
ト指 向 言 語 を前 提 とした多 くの手 法 では，実 体 の静 的 側 面 と動 的 側 面 を
別 々にモデル化 しようとしている．そこでは，実 体 の概 念 はクラス図 によって，
その振 る舞 いはシーケンス図 などの補 助 的 図 式 を使 って表 現 される[119]．
問 題 領 域 の複 雑 化 と，ソフトウェアの実 装 技 術 の進 化 に伴 い，よりフレキシ
ブルなモデル化 が求 められるようになり，実 体 より，より本 質 的 な構 成 要 素 で
ある役 割 （rｏｌｅ）をベースとしたモデル化 が注 目 されるようになった．役 割 によ
る モ デ ル は ， エ ー ジ ェ ン ト 指 向 設 計 [147] や ， 動 的 な オ ブ ジ ェ ク ト 指 向 設 計
[139]などを通 して，多 様 な実 装 環 境 への柔 軟 な適 用 が可 能 である．
A.Davis は，問 題 領 域 をモデル化 することのメリットとして，ステークホルダ
間 のコミュニケーション，システム境 界 の設 定 ，問 題 領 域 の分 割 と抽 象 化 ，
問 題 レベルでの分 析 ，情 報 の衝 突 箇 所 の特 定 ，分 析 のための知 識 構 造 の
容 易 な変 更 を 挙 げている[35]．しかし， 問 題 領 域 のモデル化 に は，対 象 領
域 を抽 象 化 する能 力 が求 められるので，困 難 な作 業 であることが多 い．
ゴール指向モデル
ステークホルダの意 図 を基 に，要 求 を達 成 すべきゴールとして構 造 化 した
のが，ゴール指 向 モデルである．ゴール指 向 モデルでは，組 織 や個 人 の目
標 を表 現 することによって，より本 質 的 な要 求 を明 らかにすることができる．ゴ
ール指 向 モデルの一 種 であるエンタープライズモデルでは，企 業 内 の組 織
や担 当 者 は，与 えられたゴール（目 標 ）を実 現 するために行 動 するという前
20
第1章
要求工学の現状と課題に関する調査
提 に立 っている[90]．そういう意 味 で，ゴール指 向 モデルは，組 織 の意 図 を
反 映 したモデルであり，実 装 環 境 に影 響 されないという特 徴 がある．ドメイン
モデルが機 械 論 的 世 界 観 （the mechanistic view of the world）にもとづい
た モ デ ル で あ る の に 対 し ， ゴ ー ル 指 向 モ デ ル は 目 的 論 的 世 界 観 （ the
teleological view of the world）にもとづいたモデルであるといえる．
ユースケースモデル
多 くのモデルは問 題 領 域 そのものを抽 象 化 しようとしているが，システムに
対 する要 求 を，より直 接 的 に表 現 しようとしたのがユースケースモデルである
[74] ． I.Jacobson の 方 法 論 Objectry の 中 で 使 用 さ れ て い た モ デ ル が ，
UML（Unified Modeling Language）の中 に取 り込 まれ，広 く使 用 されるよう
になった．
ユースケースは，ステークホルダの視 点 から捉 えたシステムへの機 能 要 求
であり，その詳 細 はシナリオによって定 義 される．ユースケースモデルが表 現
で き る の は 機 能 モ デ ル だ け であ る と い う 批 判 に 対 し， Jacobson は， 非 機 能
要 求 は 機 能 要 求 の 属 性 で あ り ， 機 能 要 求 が 定 義 で き れ ば ， FURPS モ デ ル
[57]を使 って非 機 能 要 求 の導 出 は可 能 であるとしている[77]．また，ユース
ケースシナリオとともに，事 前 条 件 や事 後 条 件 などを明 確 にすることによって，
ユースケースモデルを詳 細 化 し，厳 密 性 を高 めるためのユースケース記 述 が
提 案 されている[28]．
問題モデル
問 題 領 域 を別 の時 空 間 に写 像 することによって，取 り扱 うべき問 題 を明 ら
か に す る こ と が で き る ． M.Jackson は ， 実 世 界 を 問 題 フ レ ー ム （ Problem
frames ） 空 間 に 写 像 す る こ と に よ っ て ， 未 知 の 問 題 を 既 知 の 問 題 に 収 束 さ
せ，解 決 法 を提 示 しようとしている[73]．問 題 フレーム空 間 は，問 題 を抱 えて
いる実 世 界 と，その問 題 を解 決 するための情 報 機 械 としてモデル化 され，問
題 はさらに小 さな基 本 問 題 に分 割 されている．Jackson は，問 題 フレームの
記 述 法 とともに，いくつかの基 本 問 題 に対 する解 も提 示 している．基 本 問 題
に対 する解 の集 合 が，元 の問 題 の解 となる．問 題 モデルもドメイン分 割 手 法
に属 するモデルということができる．
第1章
要求工学の現状と課題に関する調査
21
(b) 非 モ デ ル 駆 動 型 要 求 獲 得 技 法
非 モデル駆 動 型 の要 求 獲 得 法 は，具 体 的 な要 求 を個 別 に収 集 する方 法 で，
特 定 の対 象 に焦 点 を当 てることによって，対 象 を様 々な角 度 からより深 く検 討 す
ることができる．しかし，無 作 為 に収 集 された要 求 は構 造 化 されていないので，そ
の全 体 像 を把 握 することが困 難 である．収 集 が終 わった後 で，全 体 を整 理 しなお
す必 要 がある．
調査技法
構 造 化 されたインタビューは，情 報 収 集 のための最 も一 般 的 で強 力 な手
法 である[155]．一 見 簡 単 そうな技 法 であるが，正 しい要 求 を効 果 的 に収 集
するための適 当 な手 順 やツールをもたないため[153]，必 要 な情 報 が収 集 で
きなかったり，不 必 要 な情 報 を大 量 に収 集 してしまったりすることがある．要
求 を聞 き出 すために，ステークホルダが行 っているタスクに関 する情 報 を収
集 する．しかし，タスクには，現 在 行 われているタスクと将 来 の望 ましいタスク
が あ り[79] ， ど ちら の タ スク を 要 求 の ベ ー ス と す る か は ， シス テ ム 化 の 目 標 に
依 存 する．要 求 技 術 者 には，インタビュー技 術 とともに，収 集 した情 報 を整
理 したり，情 報 の真 偽 を判 定 するためのスキルが必 要 とされる．もちろん，イ
ンタビューを受 ける側 にもそれなりのスキルが要 求 される[10]．P.Ferdinandi
は，Webアプリケーションのための要 求 獲 得 作 業 で使 用 する，インタビューの
ための具 体 的 な質 問 を，目 標 ，使 用 形 態 ，獲 得 質 問 という形 で列 挙 してい
る[47]．
調 査 によって問 題 領 域 の知 識 や，個 別 の要 求 を収 集 する手 段 としては，
インタビューの他 にも，アンケートによる調 査 ，ドキュメントの調 査 ，作 業 現 場
の観 察 ，分 析 者 が実 際 に作 業 体 験 をする徒 弟 制 などといった方 法 もある．
何 れの方 法 も，収 集 された情 報 の整 理 が課 題 として残 る．
グループ技法
グループ技 法 は，チーム・アプローチなどとも呼 ばれ，複 数 のステークホル
ダや要 求 技 術 者 が一 堂 に会 して，情 報 や意 見 を交 換 し，知 識 の共 有 化 を
図 るための技 法 である．ステークホルダ自 身 が実 際 のグループ作 業 に参 加
22
第1章
要求工学の現状と課題に関する調査
することによって，知 識 や要 求 の違 いを，ステークホルダ同 士 の会 話 によって
解 消 する．グループ作 業 の効 率 や，統 合 化 された情 報 の品 質 などは，会 議
をリードするファシリテータの能 力 に依 存 するところが大 である．また，唯 でさ
え忙 しいステークホルダを，場 合 によっては，長 期 間 拘 束 せざるをえないとい
う問 題 が残 る．
グループ技 法 は，新 しいアイデアを創 出 するのに有 効 である．ブレーンスト
ーミングは，アイデア発 想 法 の1つで，グループメンバーの発 想 の違 いから，
さらに多 くのアイデアを生 み出 そうという手 法 である．KJ法 は，人 間 の直 観 を
用 いて問 題 の意 味 や構 造 を整 理 し，新 たな解 や発 想 を導 出 する[84]．
フォーカスグループは，マーケティングでよく使 われる技 法 で，特 定 のテー
マに関 し，無 作 為 に選 んだメンバーによる話 し合 いによって，様 々な意 見 を
収 集 する[134]．特 定 の個 人 を対 象 にしたインタビューに比 べ，多 様 な意 見
の収 集 が可 能 となる．
ステークホルダの声 を直 接 反 映 し，コンセンサスを得 るためにもグループ技
法 が用 いられることがある．Joint Application Development（JAD）は，１９７
０ 年 代 にIBMによ っ て提 唱 された 技 法 [151] で， ステークホ ルダ 自 身 が 問 題
を定 義 したり，解 を発 見 するのを分 析 者 が支 援 する．ＪＡＤチームは，ステー
クホルダと熟 練 したファシリテータによって構 成 され，ＪＡＤセッションを通 して，
要 求 を共 有 する．User Centered Design [101]や Participantory Design
[58]も，ＪＡＤに似 た手 法 である．
シナリオ
シ ナ リ オ は ， 現 実 世 界 の 物 語 で あ る [22] ． CREWS(Cooperative
Requirements Engineering With Scenarios)プロジェクトでは，現 状 の問 題
についてのシナリオを通 して，ゴールを検 証 したり，新 たなゴールが発 見 でき
ることを明 らかにした[94]．シナリオは，主 に，自 然 言 語 によるテキストを使 っ
て記 述 されるが，簡 単 なマルチメディアを使 う場 合 もある．自 然 言 語 は，人
間 の思 考 や感 情 を表 現 するために生 まれた言 語 であり，曖 昧 で冗 長 である
反 面 ，それだけ多 くの情 報 を含 み，シナリオ分 析 などを通 して，様 々な発 想
を誘 発 することができる．シナリオから自 然 言 語 の持 つ冗 長 性 を排 除 するた
めのモデル化 手 法 も試 みられている．大 西 は，格 文 法 [48]を使 ったシナリオ
の解 析 法 を提 案 している[106]．
第1章
要求工学の現状と課題に関する調査
23
プロトタイピング
プロトタイピングは，その品 質 を定 量 化 できない要 求 や，ステークホルダの
意 見 や反 応 を必 要 とする要 求 を確 定 するために用 いられる手 法 であり[36]，
感 覚 的 な判 断 が必 要 とされるユーザインタフェースへの要 求 を確 定 するとき
などに良 く用 いられている．プロトタイピングによって得 られた情 報 は，グルー
プ技 法 の議 論 のための情 報 として使 われたり，アンケートやプロトコル分 析 の
ための基 礎 データとしても利 用 される．
プロトタイピングは，曖 昧 な要 求 を確 定 するためだけではなく，複 雑 なアル
ゴリズムの検 証 や，開 発 の可 否 を判 定 するためのデモンストレーションとして
も用 いられることが多 い．このような作 業 を通 して得 られた情 報 も，要 求 の一
種 である．
認知技法
認 知 技 法 は，知 識 システム構 築 のために，専 門 家 の知 識 を獲 得 するため
の知 識 獲 得 法 の流 れを引 いている[129]．特 定 の個 人 の行 動 を解 析 し，そ
の背 景 にある認 知 プロセスを通 して，その知 識 構 造 を解 明 しようという技 法
である．
プロトコル分 析 では，その認 知 プロセスを観 察 者 に伝 えるために，指 名 さ
れたステークホルダは自 らの行 動 を声 に出 しながら作 業 する．ラダーリングは，
事 前 に用 意 された調 査 用 の定 型 的 な質 問 を順 次 行 い，その答 えから知 識
の構 造 を解 明 してゆく．カードソーティングでは，ステークホルダに，キーワー
ドの書 かれたカードを，問 題 領 域 別 に分 類 してもらう．レパートリ・グリッドは，
実 体 ごとに，その属 性 と値 をステークホルダに訊 ねることによって，属 性 マトリ
ックスを作 成 する．いずれも，特 定 のステークホルダの知 識 構 造 を調 べるた
めの手 法 である．
文脈的技法
文 脈 的 技 法 は，伝 統 的 な技 法 や認 知 技 法 の代 替 として１９９０年 代 に登
場 し た [56] ． 他 の 技 法 が 対 象 世 界 を 抽 象 化 し よ う と す る の に 対 し ， 文 脈 的
技 法 では組 織 的 ，社 会 的 な理 解 が重 要 であるという考 えのもとに，観 察 され
た現 象 の普 遍 的 モデルを作 ろうとする[113]．ここでは，対 象 の観 察 といった
民 俗 学 的 な手 法 が使 われ，会 話 分 析 では，会 話 のパターンを見 つけるため
24
第1章
要求工学の現状と課題に関する調査
に詳 細 な分 析 が行 われる[145]．
（ｃ）関連技法
獲 得 されたばかりの要 求 には，様 々な矛 盾 や曖 昧 な要 素 が含 まれている．工 学
的 な技 法 だけでそれらの問 題 を解 決 することは困 難 であり，そうした場 合 には，発
見 的 な知 識 の活 用 が有 効 なこともある．要 求 の品 質 を高 めるために，いくつかの
関 連 技 術 が提 案 されている．ここでは，技 法 として確 立 している，合 意 形 成 と優
先 順 位 付 けのための技 術 を取 り上 げる．問 題 解 決 に有 効 な発 見 的 知 識 の記 述
と体 系 化 については第 2章 で扱 う．また，優 先 順 位 付 けのための技 法 は，第 3章
で議 論 する．
合意形成
利 害 関 係 の異 なったステークホルダ同 士 が，異 なった要 求 を持 つことは避
けられないことであるし，問 題 領 域 に対 する共 通 の理 解 だけで，それが解 消
できるとも限 らない．異 なった意 見 を持 ったステークホルダ同 士 の合 意 を形
成 するために，個 々のステークホルダの貢 献 度 をモデル化 し[42]，妥 協 点 を
発 見 する必 要 がある[117]．これをネゴシエーションと呼 ぶ．
WinWin アプローチは，ステークホルダ間 での要 求 の違 いを解 消 するので
はなく，互 いの妥 協 点 を求 めるための手 法 として提 案 された[14]．意 見 の相
違 は ， condition ， issue ， agreement ， option と い う ４ つ の 基 本 ス キ ー マ と ，
それらの関 係 によって定 義 され，これをもとに，ステークホルダ同 士 のネゴシ
エーションを行 い，合 意 を形 成 しようとするものである[15]．このアプローチは，
中 東 戦 争 をモデルにしたネゴシエーションのための1つの方 法 であるが，国
際 紛 争 の調 停 作 業 が多 様 であるように，すべての異 なった要 求 がこのアプ
ローチによって解 決 するわけではない．
優先順位付け
期 間 とコストという制 約 下 にあるプロジェクトでは，ソフトウェア開 発 における
優 先 度 を決 めるために，個 々の要 求 に対 し，優 先 順 位 づけを行 う必 要 があ
る[69]．優 先 順 位 の決 定 は，解 決 すべき問 題 の重 要 度 や緊 急 性 ，ステーク
ホルダの好 みなどを考 慮 して決 定 されるため，相 反 する複 数 の意 見 に対 す
第1章
要求工学の現状と課題に関する調査
25
る意 思 決 定 機 構 が必 要 となる．優 先 順 位 付 けのための代 表 的 な技 法 に，
品 質 機 能 展 開 ，ソフトシステム方 法 論 ，階 層 化 意 思 決 定 法 などがある．
品 質 機 能 展 開 （ＱFD：Quality Function Deployment）は，顧 客 の声 を製
品 開 発 の各 ステージで適 切 な技 術 要 求 に変 換 する手 法 であり，関 係 マトリ
ックスを用 いて顧 客 の要 求 と製 品 の機 能 を関 連 付 けている[1，6]．この構 造
を要 求 獲 得 に応 用 し，関 係 マトリックスによって顧 客 要 求 の重 要 性 を，製 品
機 能 の順 位 付 けに反 映 することが可 能 である[25]．
ソフトシステム方 法 論 （SSM： Soft Systems Methodology）は，複 数 のメン
バー間 の異 なった考 えを，問 題 状 況 に即 して評 価 ・決 定 する方 法 である．
はじめに，問 題 状 況 の本 質 的 な目 標 を認 識 する．次 に，それを実 現 するた
めの可 能 な問 題 解 決 案 をメンバーから提 示 してもらい，モデル化 する．モデ
ル化 に当 たっては，顧 客 や変 換 プロセスといった６種 類 （CATWOＥ）の要 素
を使 ってその解 決 案 を定 義 し，それぞれの案 を，効 果 や効 率 といった視 点
から評 価 する[24]．
階 層 化 意 思 決 定 法 （AHP： Analytic Hierarchy Process）は，複 数 の代
替 案 に対 する意 志 決 定 を行 うための技 法 である．問 題 を階 層 構 造 あるいは
ネットワーク構 造 を使 って表 現 し，個 々の案 を一 対 比 較 によって評 価 し，そ
の構 造 内 での相 対 的 な関 係 をつくり上 げる[123]．AHPを使 うことによって，
物 理 的 な事 象 だけでなく，心 理 的 な事 象 を評 価 することも可 能 である．
1.2.2. 要 求 定 義 技 法
要 求 獲 得 技 法 を使 って収 集 された要 求 や問 題 領 域 に関 する知 識 は，その内
容 の厳 密 性 を高 めるためにモデルや仕 様 として定 義 され，要 求 仕 様 書 に記 述 さ
れる．この作 業 を要 求 定 義 と呼 ぶ．
要 求 定 義 では，問 題 領 域 に関 する知 識 や要 求 をモデルとして表 現 する場 合 と，
要 求 そのものを仕 様 として記 述 する場 合 があるが，要 求 を記 述 するために使 用 す
る言 語 は，要 求 獲 得 フェーズから引 き続 いて使 用 されることが多 い．要 求 仕 様 書
は，特 別 な教 育 を受 けていない設 計 者 にも伝 わるように，自 然 言 語 を使 ってより
分 かりやすく記 述 されることが多 いが，リアルタイムシステムのように厳 密 性 を要 す
るシステムの場 合 には，状 態 遷 移 図 や形 式 仕 様 記 述 言 語 がよく用 いられる．
26
第1章
要求工学の現状と課題に関する調査
IEEE-８３０は，要 求 仕 様 書 に記 述 されるべき項 目 についての提 案 を行 っている
[69]．
ここで取 り上 げるのは，要 求 モデルや要 求 仕 様 を作 成 したり，保 守 したりするた
めのモデル記 述 言 語 や要 求 仕 様 記 述 言 語 である．工 学 的 知 識 に属 する知 識 の
表 現 と体 系 化 については第 4章 で議 論 する．
（ａ）モデル記述技法
モデル記 述 言 語 は問 題 領 域 を抽 象 化 し，それを，図 式 などを使 って記 述 する
ための言 語 であり，ビジュアル言 語 などとも呼 ばれている．モデル化 手 法 では，要
求 は，モデルの中 から浮 かび上 がってくると考 えられる．言 い換 えれば，モデルは
要 求 のもう１つの表 現 である[138]．図 式 によって表 現 されたモデルは，テキストを
使 った表 現 に比 べ，直 感 的 な理 解 に優 れている反 面 ，論 理 的 な説 明 能 力 には
乏 しいという側 面 を持 っている．
モデルの記 述 能 力 は，モデル記 述 言 語 の記 述 能 力 に依 存 する．それぞれのモ
デル化 手 法 は，独 自 のモデル記 述 言 語 をもっており，IDEF[52]や UMLのように，
記 法 の標 準 化 が進 んでいるものもある．UMLは，様 々なオブジェクト指 向 方 法 論
のモデルの記 法 を統 一 するために標 準 化 団 体 のOMGによって制 定 されたもので，
複 数 の図 式 から構 成 されている．
要 求 をモデル化 する最 初 の試 みは，ステークホルダとシステムの動 的 な変 化 や
機 能 的 な振 る舞 いをモデル化 することであった．構 造 化 手 法 では，実 世 界 （問 題
領 域 ）の業 務 から情 報 （データ）の流 れを抽 出 し，データを処 理 するためのシステ
ムの機 能 を，データフロー図 を使 って表 現 した[38]．一 方 ，オブジェクト指 向 にお
ける実 体 の振 る舞 いは，シーケンス図 [119]や状 態 遷 移 図 [74]などを使 ってモデ
ル化 が図 られている．初 期 のモデル化 手 法 の多 くは，要 求 工 学 技 術 マップ（第 ３
章 ）では，シナリオ型 の手 法 に属 していることが分 かる．形 式 的 手 法 は，対 象 の状
態 変 化 を数 学 的 に記 述 するもので，習 得 が困 難 であるが，事 前 条 件 から事 後 条
件 への変 化 を計 算 できるため，分 析 の自 動 化 が期 待 できる[122]．
多 くのドメインモデル記 述 言 語 は，プロジェクトメンバー間 で共 通 の認 識 を得 や
すい実 世 界 の実 体 に焦 点 を当 て，その性 質 と振 る舞 いを記 述 しようとしている．
JSD法 の実 体 構 造 図 が実 体 とその行 動 を1つの図 式 で表 現 する[70]のに対 し，
第1章
要求工学の現状と課題に関する調査
27
現 在 のオブジェクト指 向 手 法 では，静 的 モデルと動 的 モデルのための記 述 言 語
は異 なっている[119]．ドメインモデルは，システムへの要 求 を直 接 的 に表 現 すると
いうより，問 題 領 域 の構 造 を正 しく理 解 し，実 世 界 とソフトウェアの構 造 的 な同 一
性 を実 現 するために用 いられることが多 いので[96]，複 数 のモデルを使 用 した場
合 [103]の中 心 的 なモデルとなる場 合 が多 い．
KAOS[87]や i* [149]といったゴール指 向 型 のモデル化 手 法 では，組 織 の構
造 や目 標 ，構 成 メンバーの役 割 や責 務 ，タスクなどに焦 点 を当 て，組 織 行 動 の
基 盤 となっている目 標 という抽 象 的 な概 念 を記 述 しようとしている．ゴール指 向 モ
デル記 述 言 語 では，特 定 の目 標 をゴール分 解 することによって，階 層 化 されたサ
ブゴール木 が展 開 され，要 求 はゴールの操 作 化 [87]や Means-end分 解 [148，
26]などを通 して導 出 される．また，複 数 の上 位 ゴールに対 する寄 与 度 を計 算 す
ることによって，採 用 すべきサブゴールを選 択 するような方 式 も提 案 されている
[82]．
ドメインモデルやエンタープライズモデルのように問 題 領 域 を抽 象 化 したモデル
では，要 求 はそれらのモデルの中 に暗 黙 的 に含 まれているという立 場 をとっている
が，より直 接 的 に要 求 を表 現 したいという要 求 に対 応 したのがユースケース図 であ
る[74]．ユースケース記 述 言 語 が描 くのは，アクターとそれに関 連 した機 能 要 求 と
してのユースケースだけである．ユースケース図 の厳 密 性 を高 めるために，シナリオ
を柱 とした，自 然 言 語 によるユースケース記 述 も使 用 されている．ユースケースモ
デルは，単 に要 求 を記 述 するだけでなく，ソフトウェア開 発 工 数 の見 積 もり[97]や，
プログラムのテスト[91]などにも使 用 されている．
（ｂ）仕様記述技法
モデル記 述 言 語 が要 求 や問 題 領 域 を簡 潔 に表 現 することを目 的 としているの
に対 し，仕 様 記 述 言 語 はステークホルダの要 求 を厳 密 に記 述 することを目 指 して
いる．機 能 要 求 や性 能 要 求 ，品 質 要 求 といった様 々な要 求 を表 現 するためには，
機 能 ，性 能 ，品 質 ，インタフェースなどを表 現 できる仕 様 記 述 言 語 が必 要 となる
[69]．仕 様 を記 述 するために，論 理 表 現 [8]から自 然 言 語 [5]に至 るまで，様 々な
形 式 的 ，準 形 式 的 ，非 形 式 的 な言 語 が提 案 されているが，どの言 語 を使 用 する
かは，仕 様 に何 を記 述 するかによって異 なってくる．そのことは，とりもなおさず，仕
28
第1章
要求工学の現状と課題に関する調査
様 とは何 かという問 題 に帰 着 する．仕 様 に関 する代 表 的 な考 え方 には，次 のよう
なものがある．
M.Jackson は，環 境 と機 械 （システム）によって仕 様 を説 明 している[71，72]．
彼 によれば，要 求 はシステムの外 にある環 境 について述 べたものであり，システム
は要 求 を実 現 する手 段 である．一 方 ，仕 様 とは，環 境 とシステムの境 界 上 で，シ
ステムの振 る舞 いを，現 象 として記 述 したものである．このとき，環 境 特 性 （E）と仕
様 （S）が満 たされることによって要 求 （R）が満 足 され（S，E ⊢ R），プログラム（P）と
それが動 く機 械 （C）の特 性 によって仕 様 （S）が満 足 される（C，P ⊢ S）という命 題
が証 明 されなければならない．一 方 ，D.Parnas は，利 用 環 境 とソフトウェアの間
の４変 数 モデルによって要 求 と仕 様 との関 係 を説 明 している[110]．環 境 とソフトウ
ェアの間 には，センサーなどの入 力 デバイスと，アクチュエータなどの出 力 デバイス
があると考 える．環 境 は，入 力 デバイスへの観 測 変 数 によって認 識 され，出 力 デ
バイスからの制 御 変 数 によって操 作 される．観 測 変 数 と制 御 変 数 の関 係 が要 求
であり，入 力 データと出 力 データの関 係 が仕 様 であるとしている．
要 求 獲 得 や分 析 の段 階 では図 式 表 現 であるモデルが用 いられることが多 いが，
仕 様 の記 述 では自 然 言 語 や形 式 仕 様 記 述 言 語 のようなテキスト表 現 がよく用 い
られる［138］．厳 密 なモデルを描 ためには，VDM [81]や Z [132]のような形 式 仕
様 記 述 言 語 が用 いられる．形 式 仕 様 記 述 言 語 は，数 学 や論 理 学 を使 って，問
題 領 域 の実 体 や事 象 の生 起 を，正 確 かつ厳 密 に記 述 することができ，モデルの
検 証 も可 能 であるが[27]，要 求 技 術 者 と設 計 技 術 者 の双 方 に，形 式 仕 様 に対
する知 識 が必 要 となる．
要 求 変 更 時 には，モデルの場 合 と同 様 ，仕 様 の一 貫 性 を保 証 することも重 要
な作 業 である．要 求 仕 様 記 述 言 語 を使 用 した場 合 は，もともと構 造 的 な記 述 とな
っているが，第 ４章 で議 論 するように，テキスト形 式 で記 述 された仕 様 も，構 造 化
することによって，図 式 へのマッピングが可 能 となる．
（ｃ）仕様検証技法
検 証 は，英 語 の Verification＆Validation の訳 である．両 者 の違 いを，
Boehm は，正 しく製 品 を作 っているか（verification）と，正 しい製 品 を作 っている
か（validation）の違 いであるとしている[12]．言 い換 えれば，Verificationはソフト
第1章
要求工学の現状と課題に関する調査
29
ウェアの開 発 工 程 の品 質 を検 査 することであり，Validation は製 品 そのものの品
質 を検 査 することであるといえる．しかし，日 本 語 では何 れの場 合 も定 訳 がない
[138]．本 論 文 では併 せて検 証 と呼 ぶことにする．
要 求 仕 様 検 証 の目 的 の1つは，記 述 された仕 様 が正 しいかどうかを判 定 するこ
とである．しかし，仕 様 の正 しさと一 言 で言 っても，様 々な正 しさがある．検 証 の目
的 にあわせて，種 々の検 証 技 法 の中 から適 切 な技 法 を選 択 する必 要 がある．
仕 様 が形 式 的 言 語 で記 述 されている場 合 は，自 動 推 論 [92]やモデル検 査 など
によって，その一 貫 性 と完 全 性 を自 動 的 にチェックすることが可 能 である[61]．
SCRツールは，形 式 的 に記 述 された仕 様 の形 式 論 的 な一 貫 性 と完 全 性 を自 動
的 に検 査 する[61]．モデル検 査 は，モデルがシステムに要 求 される性 質 を満 たす
かどうかを自 動 的 に検 査 する手 段 で，どのような経 路 を通 ってもデッドロックのよう
な望 ましくない事 象 が発 生 しないという安 全 性 （safety）と，望 ましいことはいつか
必 ず起 きるという活 性 （liveness）を検 査 する．ラベル付 きの遷 移 システムとして記
述 したモデルの性 質 を，時 相 論 理 によるモデル検 査 手 法 でチェックする手 法 が多
く提 案 されており[27]，SPIN のようなモデル検 査 系 も提 供 されている[64]．
手 動 による検 証 を支 援 するシステムも提 案 されている．手 動 で検 証 を行 う場 合
は，インスペクション[46]やウォークスルーなどの手 法 がよく用 いられる．アニメーシ
ョンは，システムの振 る舞 いを視 覚 的 に表 現 することが可 能 であるため，対 象 の動
的 な変 化 を時 間 の経 過 にしたがって確 認 することができるが，正 確 な順 序 制 御 や
矛 盾 のチェックを行 うには向 いていない[23]．また，プロトタイプは，本 来 ，数 量 化
できない品 質 要 求 を，擬 似 実 装 コードによって確 定 するための方 法 であり，デモ
ンストレーションによって，多 くのステークホルダの検 証 を受 けたり，実 行 環 境 の中
に組 み込 むことによって性 能 上 の検 証 を行 うこともできる．また，手 動 による検 証
には，要 求 を実 現 する上 でのリスクの評 価 も含 まれる．リスクには，人 的 リスク，コス
ト的 リスク，技 術 的 リスクなどがあり，いずれも，要 求 を実 現 する上 で欠 かせない条
件 である．環 境 の変 化 によってリスクも変 化 する [104]．
検 証 法 の選 択 について，本 論 文 では明 示 的 には議 論 していない．検 証 作 業 は，
要 求 工 学 プロセスの中 で繰 り返 し行 われるので，時 宜 に応 じた検 証 法 選 択 のた
めの知 識 が必 要 となる．
30
第1章
要求工学の現状と課題に関する調査
1.2.3. 要 求 の 進 化 と 多 様 化 の た め の 技 法
インターネットをはじめとする技 術 革 新 によって，ソフトウェアを取 り巻 く世 界 は，
変 化 と多 様 性 の度 合 いを急 速 に増 加 しつつあり，それは，ソフトウェアに対 する要
求 の不 安 定 性 となって現 われている[25]．要 求 が進 化 する原 因 は，ニーズの絶 え
間 ない変 化 であり[124]，多 様 化 の原 因 は，異 なったステークホルダの異 なった視
点 と興 味 である[41]．ここでは，要 求 の進 化 と多 様 化 という問 題 に対 応 するため
の新 たな技 術 をまとめて概 括 する．
(a) 初 期 要 求
これまでの要 求 工 学 プロセスに先 立 って，システムが組 織 的 要 求 に合 致 してい
るか，システムは何 故 必 要 かなどという基 本 的 問 題 を定 義 したものを初 期 要 求 と
呼 ぶ．
ビジネスの将 来 像 をモデル化 することによって，要 求 獲 得 作 業 の前 にビジネス
の変 化 を予 測 しようとしたのが，ビジネスモデリングである．I.Jacobson らは，ユー
スケースモデルを使 ってビジネスモデルを作 成 するための手 法 [75]と，ビジネスモ
デルからシステムモデルへの変 換 方 法 [76]について提 案 している．H.Eriksson ら
は，プロセスよりも詳 細 なビジネス活 動 に注 目 し[44]，C.Marshall らは，ビジネス
活 動 を構 成 している組 織 や実 体 に注 目 したモデリング法 を提 案 している[95]．こ
れらドメインモデル系 のビジネスモデルでは，将 来 モデルを描 くために，ビジネス変
革 の方 向 性 を定 義 しなければならないが，ビジネス戦 略 の立 案 には，企 業 経 営
やマーケティングといったソフトウェア工 学 とは異 なった分 野 の知 識 を必 要 とするた
め，要 求 技 術 者 には扱 いにくい手 法 であった．要 求 獲 得 の前 に本 質 的 問 題 を
明 確 にしようというビジネスモデリングは，初 期 フェーズ要 求 工 学 という考 え方 の先
駆 をなしている．
初 期 フェーズ要 求 工 学 という用 語 を確 立 したのは，i*法 である[149]．そこでは，
ビジネス上 の意 図 をゴールとして，モデルに明 示 的 に組 み込 み，アクターの活 動
の本 質 的 な問 題 に焦 点 を当 てようとしている．i*法 が扱 うビジネス上 のゴールは，
企 業 経 営 レベルのゴールではなく，アクター同 士 の依 存 関 係 という作 業 レベルの
ゴールであり，ソフトウェア技 術 者 にも扱 い易 いものとなっている．i*法 では，通 常
のハードゴールとともに，その実 現 の評 価 が難 しいソフトゴールも明 示 的 にモデル
第1章
要求工学の現状と課題に関する調査
31
化 され，ゴール分 解 によって必 要 なタスクが導 出 されるようになっている．しかし，ソ
フトゴールのような感 覚 的 なゴールには，個 人 の主 観 的 な判 断 が色 濃 く反 映 され
る．異 なった価 値 観 を取 り扱 うための手 法 としてソフトシステム方 法 論 ［24］などが
有 効 である．
(b)
多視点モデル
世 界 の複 雑 化 に伴 い，様 々な立 場 のステークホルダが現 れ，システムに対 する
視 点 も多 様 化 してきた．多 様 な視 点 を敢 えて統 一 することなく，それぞれの観 点
（perspective）からモデル化 したものを多 視 点 モデルと呼 ぶことにする．ステークホ
ルダの視 点 の違 いは，所 属 する組 織 ，組 織 内 での責 務 ，個 人 的 な世 界 観 や知
識 などの違 いによって生 じ，要 求 の矛 盾 や曖 昧 性 を生 み出 す原 因 となる．しかし，
一 方 で，異 なった視 点 によって作 成 されたモデルを比 較 し，統 合 することによって，
要 求 の正 当 性 を確 保 することが可 能 となる．視 点 の違 いに着 目 したモデル化 や
要 求 獲 得 法 が提 案 されている．これらの手 法 は，対 象 範 囲 や分 類 基 準 は違 うも
のの，本 論 文 の議 論 と目 指 す方 向 は同 じである．
Zachman らは，同 一 の製 品 であっても，計 画 者 や設 計 者 といったシステム開 発
における観 点 の違 いによって，異 なった目 的 や手 法 による記 述 が必 要 であること
を指 摘 し，Information System Architecture として体 系 化 した[150，131]．
A.Finkelstein らは，システム開 発 チームのメンバーのスキルや知 識 や経 験 など
のバックグラウンドと，開 発 チームの中 で果 たすべき役 割 を観 点 として捉 え，異 な
ったスタイルでそれを表 現 するための Viewpoints というフレームワークを提 案 し
ている[49]．
CORE（COntrolled Requirements Expression and analyst）は，要 求 工 学 の
基 本 的 な枠 組 みの中 に多 視 点 を取 り扱 うための手 法 を組 み入 れている．はじめ
に，分 析 されるべき問 題 が定 義 され，次 に，その問 題 に関 連 する視 点 が明 らかに
され，それぞれの視 点 で，情 報 の収 集 が行 われる．収 集 された情 報 は，それぞれ
の視 点 で図 式 表 現 され，制 約 分 析 を通 して非 機 能 要 求 が識 別 され，文 書 化 さ
れる[136]．
M.Deutsch は，リアルタイムシステムを作 成 するための手 法 のなかで，顧 客 の
視 点 による要 求 モデル，使 用 者 の視 点 による操 作 モデル，実 装 者 の視 点 による
32
第1章
要求工学の現状と課題に関する調査
実 装 モデルといった３種 類 のモデル提 案 している[39]．多 くの多 視 点 モデルの中
でも，彼 のアプローチは洗 練 されており，メタモデルを介 したモデルの自 動 変 換 と
いう新 たな研 究 課 題 が視 界 に入 ってくる[140]．
(c) メ ソ ッ ド 工 学
進 化 し多 様 化 する要 求 に対 応 するためのもう１つの技 術 は，既 成 の手 法 や方
法 論 をそのまま適 用 するのではなく，それぞれのプロジェクトの状 況 に合 わせて個
別 の手 法 を選 択 的 に適 用 しようというものである．こうした技 術 は，方 法 論 の開 発 ，
評 価 ，利 用 などの技 術 を工 学 的 に研 究 するメソッド工 学 として研 究 されている．
手 法 の選 択 と連 携 は，ここでの大 きな課 題 である．偶 発 的 な問 題 への対 応 という
考 え方 は，本 論 文 のプロセスパターンによる発 見 的 知 識 の記 述 に通 じるものがあ
る．
個 々の要 求 工 学 技 術 が，どのような問 題 に適 しているかを知 ることによって，プ
ロジェクトの特 徴 や，抱 えている問 題 に合 わせて，適 切 な手 法 を選 択 することが可
能 となる．システムやプロジェクトの特 徴 から要 求 プロセスの不 確 定 性 を判 定 し，
それをもとに要 求 の確 実 性 を高 めるための戦 略 を設 定 したり，手 法 を選 択 するた
めの方 法 が提 案 されている[99，34]．
MEMAモデルでは，オブジェクト（組 織 の視 点 ），情 報 （コンポーネントの視 点 ），
データ(処 理 の視 点 )，実 装 (運 用 と保 守 の視 点 )といった４つのモデルと，ゴール
や機 能 やプロセスなどからなる８個 の問 題 領 域 特 性 によって問 題 領 域 の特 徴 を
決 定 し，それらをもとに，用 意 されている手 法 断 片 との適 合 性 の評 価 を行 ってい
る[114]．
G.Vlasblom らは，情 報 システムや問 題 領 域 の型 によるプロジェクトの特 徴 と，
ビジネス環 境 や既 存 の情 報 システムなどの環 境 要 素 という２つの側 面 からなるプ
ロジェクト状 況 プロファイルをもとに，最 適 のモデル状 況 プロファイルを探 し，開 発
モデルをプロジェクトのシナリオに合 わせて変 形 するというアプローチを提 案 してい
る[146]．
メソッド工 学 のもう１つの課 題 は手 法 の連 携 である．異 なった手 法 ，あるいは手
法 の断 片 を連 携 させる場 合 ，これらの手 法 の間 で意 味 上 の一 貫 性 を確 保 する必
要 があり[60，18]，基 本 的 には，それぞれの手 法 で作 成 されたソフトウェア成 果 物 ，
第1章
要求工学の現状と課題に関する調査
33
すなわちモデル同 士 の間 での意 味 論 的 整 合 を保 つという形 で行 われることになる．
多 くのメソッド工 学 手 法 では，今 のところ，形 式 的 に表 現 できる範 囲 内 での意 味
論 を扱 うに留 まっている．これらの研 究 は，本 論 文 の要 求 モデル変 更 時 の一 貫
性 の保 証 と表 裏 の関 係 にある．
多 視 点 でも取 り上 げた Viewpoint アプローチは，ステークホルダの観 点 ごとに
異 なった表 現 形 式 で記 述 された部 分 要 求 を，視 点 統 合 規 則 によって連 携 させ，
表 現 形 式 の意 味 論 的 一 貫 性 を保 証 するためのフレームワークを提 案 している
[102]．視 点 統 合 規 則 は，それぞれの視 点 ごとに準 備 された Viewpointテンプレ
ートの中 に，実 行 されるべきアクションとして記 述 されている．
Viewpoint アプローチが異 なったモデル同 士 の変 換 を規 則 によって統 合 しよう
としているのに対 し，H.Delugach は，異 なった図 式 で記 述 されたモデルを，汎 用
的 な中 間 モデルに変 換 し，同 一 形 式 の概 念 図 の上 で各 モデルの一 貫 性 をチェ
ックする手 法 を提 案 している[37]．彼 の研 究 では，ERD，DFD，STD などの図 式
で記 述 されたそれぞれのモデルを，中 間 モデルである概 念 図 に変 換 し，モデル同
士 の一 貫 性 をチェックしている．
一 方 ，Situational Methods Engineering では，既 存 の手 法 から断 片 を切 り出
し，それらを組 み立 てて，プロジェクト固 有 の手 法 を構 築 しようとする．
S.Brinkkemper らは，ソフトウェア成 果 物 である製 品 断 片 とともに，その操 作 も工
程 断 片 として分 割 し，それぞれの断 片 を組 み合 わせて新 たな手 法 を構 築 するた
めに，メタモデルのレベルでの統 合 ガイドラインを示 している[19]．
(d) 要 求 変 更
要 求 変 更 の発 生 には，要 求 獲 得 作 業 の失 敗 と，外 部 環 境 の変 化 という２つの
原 因 がある．前 者 は修 正 作 業 に無 駄 な追 加 コストがかかるので好 ましくない変 更 ，
後 者 は製 品 の使 用 期 間 の長 期 化 や販 売 数 量 の増 加 につながる好 ましい変 更 で
あると言 われている［116］．いずれにしろ，要 求 の変 更 は避 けられない現 象 であ
る．
ステークホルダの多 様 な視 点 や，プロジェクトの特 性 に合 わせて選 択 された複 数
の異 なる手 法 を使 って作 成 されたモデルや仕 様 は，最 初 から意 味 論 と形 式 論 の
一 貫 性 を考 慮 して作 成 された手 法 や方 法 論 に比 べ，要 求 変 更 に対 する脆 弱 性
34
第1章
要求工学の現状と課題に関する調査
を抱 えている．
要 求 変 更 が発 生 したときには，その変 更 に如 何 に容 易 に対 応 できるかというこ
とが問 題 となる．ソフトウェア変 更 管 理 技 術 ［55］は，実 際 の変 更 箇 所 を特 定 する
ための技 術 であり[17]，構 成 管 理 [45]や要 求 追 跡 ［78］などの技 術 と密 接 な関 係
を持 っている．
要 求 仕 様 書 への主 たる変 更 作 業 は，要 求 の追 加 ，削 除 ，修 正 である．追 加 は，
ステークホルダによる要 求 の変 更 や，分 析 ミスなどによって生 じる．削 除 は，開 発
コストや開 発 期 間 の超 過 によって発 生 し，実 装 段 階 に入 ってから，定 義 済 みの要
求 が取 り消 されるようなこともある[13]．さらに，要 求 変 更 は，要 求 モデル同 士 の
矛 盾 や，要 求 仕 様 の非 一 貫 性 という問 題 を引 き起 こすこともある．モデル間 の矛
盾 が発 見 されたら[66]，必 要 な修 正 を施 さなければならない．モデルの変 更 は，さ
らに，同 じモデルの他 の部 分 に，論 理 的 な矛 盾 や衝 突 を引 き起 こすことがある．
変 更 による影 響 を分 析 し，必 要 なら，修 正 を実 施 する．追 跡 リンクだけでは影 響
は十 分 に分 析 できないが，異 なった複 数 の視 点 を用 いることによって影 響 の拡 大
を自 動 的 に検 出 できる場 合 もある[43]．
第 ２ 章
要求工学プロセス知識の記述
実 世 界 とソフトウェアシステムの狭 間 にあって，曖 昧 な要 望 と厳 密 な仕 様 の双
方 を，その処 理 対 象 としている要 求 工 学 プロセスでは，プロジェクトの発 足 時 には
想 定 得 なかった障 害 ，いわゆる偶 発 的 な問 題 がしばしば発 生 している．要 求 工
学 プロセス，なかでも，要 求 獲 得 の作 業 中 に偶 発 的 な問 題 が多 発 する理 由 は，
プロジェクトと，そこで扱 う問 題 の特 殊 性 にあると考 えられる[25]．
要 求 獲 得 は，システムへの要 求 提 示 者 であるステークホルダと，システムの開 発
者 である要 求 分 析 者 の共 同 作 業 で成 り立 っている．しかし，プロジェクトの構 成 要
員 でもある両 者 の間 には，持 っている専 門 知 識 の違 いをはじめとして，異 なった価
値 観 や相 対 立 する利 害 関 係 など，互 いの理 解 や意 思 の疎 通 を妨 げる様 々な障
壁 が横 たわっている．そのうえ，ソフトウェアの意 味 を決 定 するはずの要 求 は，曖
昧 で，変 化 しやすく，時 には矛 盾 さえ含 んでいる．
要 求 獲 得 のための工 学 的 な技 法 や手 法 では解 決 が難 しい偶 発 的 な問 題 に対
する解 決 策 の１つが，熟 練 技 術 者 の経 験 則 やノウハウ，すなわち発 見 的 知 識 で
ある．たしかに，発 見 的 知 識 だけでこれらの問 題 がすべて解 決 するわけではない．
しかし，いくつかの研 究 はプロジェクトで発 生 する偶 発 的 問 題 解 決 への発 見 的 知
識 の有 効 性 について言 及 している[114,146]．
多 くの発 見 的 知 識 は，特 定 の技 術 者 に固 有 の知 識 で，一 般 に公 開 されること
もなければ，文 書 として明 文 化 されてもいない．本 章 では，多 くの要 求 技 術 者 たち
にとって，困 難 な問 題 を解 決 するための有 効 な方 法 である発 見 的 知 識 を記 述 す
るための知 識 フレームワークについて議 論 する．
36
第2章
要求工学プロセス知識の記述
2. 1. 発 見 的 知 識 の 記 述 方 法
発 見 的 知 識 を記 述 し，利 用 するための枠 組 みとして，知 識 工 学 が注 目 を浴 び
た時 代 があったが，問 題 解 決 のための知 識 がシステム内 に隠 蔽 されてしまってい
たり，個 別 の知 識 や一 般 常 識 の取 り扱 いなどに技 術 的 な困 難 さがあったため，特
別 な場 合 を除 いて用 いられることが少 なくなった．最 近 では，知 識 工 学 に代 って，
パターンという技 術 が用 いられることが多 い[53，54]．パターンに記 述 された知 識
は利 用 者 に公 開 されるので［29］，個 々の技 術 者 が持 っている能 力 や技 術 力 とと
もに，困 難 な問 題 の解 決 に寄 与 することが可 能 となる．
以 下 に，要 求 工 学 プロセスにおける発 見 的 知 識 を記 述 するためのプロセスパタ
ーンの基 本 的 な概 念 について述 べる．
プロセスパターン
パターンは，ソフトウェア開 発 に関 わる様 々な発 見 的 知 識 を記 録 し再 利 用
するための有 効 な方 式 の1つであり，数 多 くのパターンが作 成 されてきた[30]．
しかし，これまで提 案 されてきたパターンの多 くは，ソフトウェア設 計 のための
知 識 を記 述 するためのものであり，その対 象 はモデルであり，プログラムであ
った．設 計 知 識 を記 述 するためのパターン形 式 は，基 本 的 には，問 題 と解
の組 み合 わせから構 成 されている[3,29]．それに対 し，プロセス知 識 を記 述
するためのパターンが対 象 にするのは，時 間 と共 に変 化 する活 動 であり，体
制 であり，工 程 である．それゆえ，プロセスパターンには，問 題 と解 だけでなく，
解 を特 定 するために必 要 なプロジェクトの状 況 に関 する情 報 も必 要 となる．
課題
課 題 とは，解 決 すべき問 題 である．要 求 工 学 プロセスパターンでは，課 題
は，プロジェクトが遭 遇 する偶 発 的 な問 題 と，それを解 決 するための発 見 的
知 識 である解 から構 成 される．様 々な原 因 が複 雑 に絡 み合 い変 化 するプロ
セスでは，同 じ問 題 に対 し，何 時 も同 じ解 が適 用 できるとは限 らないし，1つ
のプロジェクトで成 功 した解 が他 のプロジェクトでも成 功 するとは限 らない．
状況
状 況 とは，個 々のプロジェクトが置 かれた環 境 であり，そのプロジェクトを特
徴 付 ける性 質 である．要 求 工 学 プロセスパターンでは，これをプロセスに関
第2章
要求工学プロセス知識の記述
37
する外 部 状 況 と，プロジェクトに固 有 の内 部 状 況 として記 述 する．外 部 状 況
は所 与 の状 況 であり，内 部 状 況 は自 ら変 更 可 能 な状 況 である．同 じ問 題 で
あっても，プロジェクトの状 況 が異 なれば，適 用 すべき解 も異 なってくる．
状況遷移
新 たな問 題 が発 生 したり，その問 題 が解 決 するとプロジェクトの状 況 が変
化 する．プロジェクトに起 きる連 続 した状 況 の変 化 を状 況 遷 移 と呼 ぶ．状 況
遷 移 には，望 ましい遷 移 と望 ましくない遷 移 がある．望 ましくない状 況 遷 移 と
は，状 況 が悪 化 してゆく遷 移 である．状 況 遷 移 は，要 求 工 学 プロセスパター
ンの連 鎖 として表 現 できる．これを図 式 化 したものが状 況 遷 移 図 である．
本 章 では，要 求 工 学 プロセスにおける発 見 的 知 識 を記 述 するためのプロセスパ
ターンの形 式 と，その体 系 的 表 現 である状 況 遷 移 図 を提 案 する．
2. 2. 要 求 獲 得 プ ロ セ ス の 構 造
はじめに，実 際 の要 求 獲 得 事 例 の作 業 構 造 を解 析 し，それをもとに，プロセス
パターンの形 式 を定 義 する．ここで，構 造 解 析 の対 象 とする事 例 は，化 学 薬 品 メ
ーカーの営 業 支 援 システム開 発 における要 求 獲 得 作 業 である（図 -2.1）．この事
例 をもとに，多 くのプロジェクトに共 通 する要 求 獲 得 作 業 の構 造 を抽 出 する．解
析 にあたって，本 アプリケーションに固 有 の要 件 は極 力 排 除 してある．また，技 術
的 な知 識 に焦 点 を当 てており，予 算 や期 間 といったプロジェクト管 理 に関 する知
識 については触 れていない．図 -2.2に作 業 シナリオを示 す．このシナリオは，６つ
基 本 ステップから構 成 されている．
構 造 解 析 によって，このシナリオから明 らかになった構 造 は次 の2つである．
ステージ構造
１つ目 の解 析 は，共 通 目 標 による作 業 ステップの統 合 化 である．同 じ目 標
を共 有 するステップ同 士 によるグループをステージと呼 ぶことにする．プロジェ
クトには，正 常 なプロセスのためのステージと，問 題 解 決 のためのステージが
ある．この事 例 は，次 の４つのステージで構 成 されている．
38
第2章
ステージ１
要求工学プロセス知識の記述
要求獲得作業－講義
ステップ１： 講 義 形 式 による，領 域 専 門 家 からの情 報 収 集 作 業
ステップ２： 欠 如 した利 用 者 ニーズの発 見 と代 替 案 の提 示
ステージ２
要求獲得作業－インタビュー
ステップ３： インタビュー形 式 による，利 用 者 への情 報 収 集 作 業
ステップ４： 多 すぎる情 報 の整 理
ステージ３
要求分析作業－矛盾
ステップ５： 抽 出 された要 求 の矛 盾 の発 見 と解 消
ステージ４
要求分析作業－確認
ステップ６： ステークホルダとの最 終 的 な要 求 の確 認 と承 認
活動サイクル構造
2つ目 の解 析 は，ステップの分 解 による構 造 化 である（図 -2.3）．それぞれ
のステップ内 の活 動 の共 通 する構 造 を活 動 サイクル構 造 と呼 ぶことにする．
本 事 例 で検 出 された活 動 サイクルは，以 下 の通 りである．
状 況 判 断： プ ロ ジ ェ ク ト は ， 達 成 す べ き 目 標 ， あ る い は ， 解 決 す べ き 問 題 を
持 っている．これをプロジェクトの課 題 とする．課 題 を克 服 するために，プロジェ
クトは，自 身 の能 力 や制 約 条 件 を把 握 する．
目 標 設 定： プロジェクトは，課 題 や問 題 を解 決 するために，具 体 的 な目 標
を設 定 し，その目 標 を実 現 するための戦 略 を立 案 する．
手 法 選 択 : 次 に，プロジェクトは，戦 略 に沿 って，自 身 の状 況 に適 した手
法 を選 択 する．選 択 された手 法 は，問 題 に対 する解 である．
作 業 実 行 ： プロジェクトは，選 択 された手 法 を使 って課 題 克 服 のための作
業 を実 行 する．しかし，その作 業 が必 ずしも成 功 裏 に完 結 するとは限 らない．
作 業 実 行 中 に，新 たな問 題 が発 生 したときには，そちらの問 題 の解 決 を先 行
させなければならないことがある．
結 果 評 価： 作 業 が終 了 したら，目 標 が達 成 されたかどうかを判 断 し，達 成
していれば作 業 が完 了 したものとして，次 のステージに進 み，達 成 されていない
ときには，何 らかの問 題 が発 生 していると考 えられる．
第2章
要求工学プロセス知識の記述
図 -2.1 プロジェクトの概 要
図 -2.2 構 造 化 シナリオ
39
40
第2章
要求工学プロセス知識の記述
図 -2.3 活 動 サイクルの構 造
2. 3. プ ロ セ ス パ タ ー ン の 形 式
プロジェクトに問 題 が発 生 すると，プロジェクトの状 況 が変 化 する．これは，問 題
を抱 えた状 況 である．プロジェクトは，この状 況 から抜 け出 すために，さまざまなプ
ロセス知 識 を使 って問 題 を解 決 するための活 動 を行 う．この問 題 解 決 活 動 の構
造 をもとに，要 求 工 学 プロセスパターンの記 述 形 式 を定 義 する．
要 求 工 学 プロセスでは，たとえ同 じ問 題 であっても，プロジェクトの状 況 によっ
て，その解 決 方 法 が異 なる場 合 がある．すなわち，状 況 と課 題 は独 立 した事 象
として扱 われなければならない．例 を示 す．ここで，：の前 が状 況 ，後 ろが課 題 を
第2章
要求工学プロセス知識の記述
41
示 している．
（イ）要 求 を決 定 のできないワークショップ：領 域 専 門 家 の不 在
（ロ）要 求 を決 定 のできないワークショップ：ステークホルダの不 在
（ハ）情 報 が収 集 できないワークショップ：ニーズを知 らない要 求 者
（ニ）訂 正 が頻 発 するワークショップ：ニーズを知 らない要 求 者
（イ）と（ロ）は，同 一 状 況 における異 なった問 題 であり，（ハ）と（ニ）は，異 なった
状 況 における同 一 問 題 の例 である．
この例 で分 かるように，同 一 の状 況 ，同 一 の問 題 であっても，課 題 が異 なれば，
異 なった解 が必 要 となり，同 じ課 題 であっても，状 況 が異 なれば，異 なった解 が必
要 となる．このように，問 題 解 決 のためのプロセス知 識 には，プロジェクトのおかれ
た状 況 を認 識 するための知 識 と，プロジェクト内 部 における問 題 を解 決 するため
の知 識 がある．この２種 類 の知 識 を記 述 するために，プロセスパターンを，２つのセ
クションに分 ける．
状 況 セクション： プロジェクトの状 況 を記 述 するためのセクション
課 題 セクション： 課 題 を克 服 するための知 識 を記 述 するためのセクション
状 況 セクションには要 求 獲 得 プロセスにおけるプロジェクトの位 置 やプロジェクト
自 身 の特 徴 を記 述 し，課 題 セクションにはプロジェクトが抱 える問 題 とその問 題 を
解 決 するための方 策 を記 述 する．
2.3.1. 状 況 セクションの形 式
プロジェクトの状 況 を記 述 するための状 況 セクションの形 式 を定 義 する．以 下 は，
状 況 セクションに記 述 されるべきプロジェクトの特 徴 である．
・ 設 定 された課 題 を克 服 してゆくために，プロジェクトが遂 行 する作 業 の単 位 を
ステージとする．各 ステージには，固 有 のステージ名 と達 成 すべき目 標 が設
定 される．目 標 が達 成 されると，プロジェクトは次 のステージに移 行 する．
・ ステージの中 で問 題 が発 生 すると，プロジェクトの状 況 が変 化 する．1つの問
題 が解 決 されても，新 たな問 題 が発 生 したり，問 題 解 決 活 動 中 に新 たな問
題 が発 生 することによって，更 なる状 況 変 化 が発 生 する．連 続 する状 況 の
42
第2章
要求工学プロセス知識の記述
変 化 を譲 許 遷 移 と呼 ぶ．状 況 遷 移 のなかで，それぞれの状 況 は固 有 の名
前 を持 つ．
・ プロジェクトが置 かれている環 境 下 での制 約 や，プロジェクトそのものが持 って
いる特 性 によって，プロジェクトの状 況 は異 なる．前 者 を外 部 状 況 ，後 者 を
内 部 状 況 とする．
・ 問 題 を抱 えたプロジェクトは，問 題 解 決 のための活 動 を行 う．問 題 が解 決 さ
れた状 況 を目 標 状 況 とする．
・ プロジェクトが，ある状 況 に変 化 したと判 断 するための条 件 を事 前 条 件 ，その
状 況 から抜 け出 したと判 断 するための条 件 を事 後 条 件 とする．
・ 状 況 変 化 には問 題 が解 決 に向 かう良 い変 化 と，更 に悪 化 する悪 い変 化 が
ある．悪 い変 化 が続 くと，プロジェクトは破 綻 するかもしれない．そこで，プロジ
ェクトは，問 題 解 決 のために，新 たな目 標 を設 定 し，新 たなステージに移 行
する．問 題 が解 決 すると，もとのステージに戻 る．
状 況 に関 するこれらの特 徴 をもとに，要 求 獲 得 プロセスを記 述 するための状 況
セクションの構 造 を定 義 する（図 -2.4）．状 況 セクションは，状 況 および状 況 タイプ
と条 件 タイプから構 成 される．状 況 タイプは，プロジェクトの状 況 の説 明 であり，外
部 状 況 と内 部 状 況 および目 標 状 況 がある．条 件 タイプは，その状 況 が成 立 する
ための条 件 で，事 前 条 件 と事 後 条 件 を含 む．図 -2.5に状 況 セクションの具 体 的
な記 述 形 式 を示 す．
図 -2.4 状 況 セクションの概 念 構 造
第2章
要求工学プロセス知識の記述
43
図 -2.5 状 況 セクションの記 述 形 式
2.3.2. 課 題 セ ク シ ョ ン の 形 式
プロジェクトが抱 えた問 題 とその解 を記 述 するための課 題 セクションの形 式 を定
義 する．課 題 セクションに記 述 されるべきプロジェクトの特 徴 を以 下 に示 す．
要 求 工 学 プロセスにおけるプロジェクトの問 題 解 決 活 動 は，状 況 判 断 －目
標 設 定 －手 法 選 択 －作 業 実 行 －結 果 評 価 という５つの活 動 から構 成 されて
いるものとする．この構 造 を，課 題 セクションの基 本 構 造 とする．
プロジェクトの活 動 は，達 成 すべき目 標 や解 決 すべき問 題 で始 まる．それを
課 題 名 とする．
目 標 や問 題 には，それが発 生 する，何 らかの理 由 が存 在 する．この理 由 が，
課 題 の背 景 である．背 景 は通 常 のパターン形 式 ［29］における“文 脈 ”に相 当
する．しかし，同 じ背 景 から生 じた現 象 が，どのプロジェクトにとっても同 じ課 題
となるわけではない．それぞれのプロジェクトには，現 象 から特 定 の課 題 が生 じ
るための独 自 の原 因 がある．
プロジェクトは，その特 性 や内 外 で発 生 する事 象 の変 化 から，プロジェクトが
抱 える問 題 を特 定 し，それを解 決 するための目 標 を設 定 しなければならない．
44
第2章
要求工学プロセス知識の記述
しかし，問 題 を解 決 するための目 標 は，1つとは限 らない．1つの問 題 に対 する
複 数 の目 標 同 士 は，代 替 関 係 にある．
プロジェクトは，目 標 を達 成 するために，戦 略 を策 定 し，その戦 略 を実 行 する
ための方 法 を選 択 する．選 択 された方 法 は，問 題 に対 する解 である．
1つの目 標 に複 数 の解 が存 在 することもあれば，1つの解 が複 数 の異 なった
目 標 を達 成 することもある．あるいは，1つの目 標 を達 成 するための解 のセットが
存 在 するかもしれない．目 標 達 成 のために選 択 された解 には，選 択 されるがゆ
えの理 由 が存 在 する．解 の選 択 幅 を制 約 する目 標 は，通 常 のパターン形 式 に
おける“フォース”に相 当 する．
解 には，工 学 的 手 法 によって実 現 される技 術 的 な解 と，プロジェクト管 理 手
法 によって実 現 される管 理 的 な解 がある．
事 前 に設 定 した目 標 と解 の実 行 結 果 とを比 較 し，問 題 が解 決 されたかどう
か，あるいは状 況 が良 くなったかどうかを判 断 し，その結 果 を結 果 評 価 とする．
選 択 された解 を実 行 したからといって，何 時 も期 待 する結 果 が得 られるとは
限 らない．プロジェクトの他 の要 因 が，活 動 の結 果 に予 期 せぬ影 響 を与 える場
合 がある．目 標 は期 待 される状 態 であるが，結 果 は目 標 に対 して取 り得 る可 能
なすべての状 態 の中 の1つである．
目 標 は，問 題 が解 決 した状 態 であり，解 は目 標 を達 成 するための手 法 であ
る．この階 層 構 造 は，問 題 から目 標 ，目 標 から解 ，解 から結 果 というゴール分
解 の木 構 造 を形 成 している．問 題 が定 義 できたら，木 構 造 の下 位 の項 目 を順
に選 択 してゆくことによって，問 題 解 決 の方 法 と，期 待 される結 果 を定 義 でき
る．
問 題 解 決 におけるこの特 徴 をもとに，要 求 工 学 のプロセスを記 述 するための課
題 セクションの構 造 を定 義 する．図 -2.6に課 題 セクションの概 念 構 造 を，図 -2.7
に課 題 セクションの記 述 形 式 を示 す．
第2章
要求工学プロセス知識の記述
図 -2.6 課 題 セクションの概 念 構 造
図 -2.7 課 題 セクションの記 述 形 式
45
46
第2章
要求工学プロセス知識の記述
2. 4. 状 況 遷 移 図 の 形 式
プロジェクトは問 題 の発 生 と解 決 を繰 り返 しながら推 移 してゆく．これを状 況 遷
移 と呼 ぶ．要 求 技 術 者 の役 割 は，遭 遇 した問 題 を解 決 するために，自 身 のプロ
ジェクトが，遷 移 する状 況 の中 のどの位 置 にいるのかを判 断 し，プロセスパターン
を使 って適 切 な解 決 策 を選 択 し，実 行 することである．しかし，大 量 のプロセスパ
ターンの中 から，適 切 なパターンを選 び出 すことは困 難 である．この作 業 を支 援 す
るのが状 況 遷 移 図 である．
状 況 遷 移 図 は，プロジェクトの状 況 遷 移 を，有 効 グラフによって表 現 したもので
ある．状 況 遷 移 図 には，要 求 工 学 プロセスにおける作 業 ステージと，それぞれのス
テージのなかで発 生 する可 能 性 のあるすべての状 況 変 化 が描 かれている．要 求
技 術 者 は，状 況 遷 移 図 を使 うことによって，自 身 のプロジェクトの置 かれた状 況 を
プロセスの流 れのなかで捉 えることができ，より適 切 なプロセスパターンの選 択 が可
能 になる．
プロセスパターンを適 用 すると，プロジェクトの状 況 はさらに変 化 してゆく．この変
化 には，状 況 の好 転 や悪 化 という相 対 的 な価 値 判 断 が伴 う．状 況 が好 転 し，問
題 が解 決 すれば，プロジェクトはもとのステージに戻 ることができるが，問 題 が解 決
しなかったり，新 たな問 題 が発 生 したりして状 況 が悪 化 すると，そのステージの中
でプロジェクトそのものが破 綻 終 了 してしまうかもしれない．複 合 的 な問 題 の場 合
は，1つの問 題 が解 決 すると，それまで隠 れていた別 の問 題 が表 面 化 する場 合 も
ある．
状 況 遷 移 図 の構 成 要 素 と，その表 記 法 は以 下 の通 りである．
ステージ：
ステージは状 況 遷 移 図 の中 の大 きな四 角 形 で表 し，ステージ間 の移
動 は矢 印 付 き線 分 で表 す．ステージはステージ名 で識 別 される．
状況：
状 況 はステージの中 の四 角 形 で表 す．また，状 況 の変 化 は，２つの
状 況 の間 の矢 印 付 き線 分 で表 す．状 況 は，次 の３つの領 域 から構
成 される．
- 名前：
状 況 の名 前 ．すなわち，状 況 セクションの状 況 名 ．
- 状況：
プロジェクトの状 況 ．すなわち，状 況 セクションの内 容 ．
- 課題：
解 決 すべき課 題 とその解 ．すなわち，課 題 セクションの内 容 ．このセ
第2章
要求工学プロセス知識の記述
47
クションで，目 標 と解 は，その組 み合 わせを表 すために，状 況 の中 の
小 さな四 角 形 で表 す．１つの目 標 に複 数 の解 が存 在 する場 合 ，OR
関 係 は並 列 構 造 で，AND 関 係 は直 列 構 造 で解 を示 す．
結 果 評 価 ： 結 果 評 価 は，状 況 変 化 に対 する，要 求 技 術 者 による価 値 判 断 であ
る．状 況 変 化 の価 値 は，状 況 同 士 の相 対 価 値 によって定 義 され，
良 い変 化 は線 上 の（＋），悪 い変 化 は（－）記 号 で表 現 する．
開 始 ／終 了 ： ステージの移 行 や状 況 遷 移 の開 始 と終 了 を表 す．
図 -2.8に状 況 遷 移 図 の概 念 構 造 をクラス図 で示 す．
図 -2.8 状 況 遷 移 図 の概 念 構 造
問 題 の種 類 によって，必 要 とされる情 報 が異 なる場 合 がある．状 況 遷 移 図 には，
表 示 する情 報 の違 いによって，次 の３種 類 の表 現 形 式 を用 意 する．
完 全 型 ： プロセスパターンの状 況 セクションと課 題 セクションの内 容 を，すべて
記 述 する．
部 分 型 ： 状 況 名 と課 題 名 だけからなる中 間 的 な状 況 遷 移 図 である．
簡 易 型 ： 状 況 名 だけからなる状 況 遷 移 図 であり，状 況 遷 移 の全 体 像 を描 くの
に使 用 される．
48
第2章
要求工学プロセス知識の記述
状 況 遷 移 図 のそれぞれの表 現 形 式 の違 いを，図 -2.9に示 す．
図 -2.9 状 況 遷 移 図
2. 5. 要 求 工 学 プ ロ セ ス パ タ ー ン の 記 述 例
本 節 では，上 記 構 造 解 析 で使 用 した営 業 支 援 システムの事 例 を使 って，具 体
的 な要 求 工 学 プロセスパターンと状 況 遷 移 図 の記 述 例 を示 す．
2.5.1. 状 況 セクションと簡 易 型 状 況 遷 移 図
各 状 況 セクションの各 項 目 を簡 単 に記 述 した例 を，図 -2.10に示 す．これは，
「情 報 が収 集 できないワークショップ」という状 況 から始 まる一 連 の状 況 変 化 の例
である．ここでは，状 況 セクションは4つのステージから構 成 されている．ステージの
1から３では状 況 に変 化 が起 きているが，ステージ４では状 況 変 化 は発 生 していな
第2章
要求工学プロセス知識の記述
49
い．
また，これらの状 況 セクションを，簡 易 型 の状 況 遷 移 図 によって表 したものを図
-2.11に示 す．なお，この状 況 遷 移 図 の中 で，破 線 で描 かれた状 況 と状 況 遷 移
は，本 構 造 解 析 のシナリオにはなかったパスである．本 来 は実 線 で表 されるべきも
のであるが，ここでは，便 宜 的 に破 線 で表 してある．
実 際 のプロジェクトの状 況 は，いくつかの異 なった状 況 が組 み合 わされた複 合
型 の状 況 であることが多 い．したがって，状 況 遷 移 も，複 数 の状 況 遷 移 の複 合 型
となる．こうした複 合 型 問 題 への対 応 の仕 方 には，2つのアプローチがある．1つは，
複 合 状 況 を分 解 し，単 独 状 況 の集 合 として扱 う方 法 である．プロジェクトは，それ
ぞれの単 独 状 況 の遷 移 に順 番 に対 応 してゆけばよい．しかし，複 合 型 の状 況 が
相 乗 効 果 を発 揮 し，新 たな問 題 を生 じる場 合 がある．複 合 型 状 況 は，それ自 身
を1つの状 況 とみなして対 応 することが必 要 である．これは，人 間 の病 気 と治 療 の
関 係 に似 ている．西 洋 医 学 では，病 気 の原 因 を個 別 に治 療 してゆくが，東 洋 医
学 では，複 合 症 状 そのものに対 応 しようとする．問 題 の特 性 に合 わせて対 応 法 を
変 えてゆくというアプローチは，ソフトシステム・アプローチ［２４］とも呼 ばれ，プロジ
ェクトの問 題 解 決 にも役 立 つであろう．どちらの方 法 を採 用 するかに関 する知 識 も
また発 見 的 知 識 である．
50
第2章
要求工学プロセス知識の記述
図 -2.10 状 況 セクションの例
第2章
要求工学プロセス知識の記述
51
図 -2.11 簡 易 型 状 況 遷 移 図 の例
2.5.2. 課 題 セ ク シ ョ ン と 完 全 型 状 況 遷 移 図
図 -2.12に示 した例 は，課 題 セクション「情 報 が収 集 できないワークショップ」とい
う状 況 における「ユーザニーズを知 らない要 求 者 」という課 題 である．ここでは，「ユ
ーザニーズを知 らない要 求 者 」という課 題 に対 し，「新 たな情 報 源 を求 める」と「既
存 の情 報 を利 用 する」という２つの目 標 と，それらの目 標 に対 する３つの解 のみを
示 しているが，当 然 ，それ以 外 の目 標 も存 在 するし，それぞれの目 標 に対 しても，
ここに挙 げた以 外 の解 が存 在 する．
52
第2章
要求工学プロセス知識の記述
図 -2.12 課 題 セクションの例
第2章
要求工学プロセス知識の記述
53
図 -2.13には，その前 後 の状 況 を含 めた完 全 型 の状 況 遷 移 図 を示 す．
図 -2.13 完 全 型 状 況 遷 移 図 の例
2. 6. 事 例 研 究 ： 航 空 運 輸 シ ス テ ム
要 求 工 学 プロセスパターンを適 用 したプロジェクトの事 例 について述 べる．ただ
し，当 該 プロジェクトの活 動 は極 めて多 岐 に渡 っており，ここで述 べる事 例 は，そ
の中 の要 求 獲 得 作 業 における情 報 の整 理 という問 題 だけに焦 点 を当 てている．
（ａ）プロジェクトの概要
航 空 運 輸 業 界 は，スカイフリーに代 表 される規 制 緩 和 ，中 国 を中 心 とした物 流
の変 化 ，各 国 通 関 業 務 の電 子 化 ，アライアンスを締 結 したグループ企 業 による顧
54
第2章
要求工学プロセス知識の記述
客 の囲 い込 み，動 的 な価 格 設 定 による利 益 の管 理 ，顧 客 への新 規 サービスの
提 供 など，大 きな変 化 が始 まりつつある．こうした時 代 の潮 流 に乗 り遅 れないため
には，航 空 運 輸 会 社 は基 幹 システムを改 造 する必 要 に迫 られており，数 年 計 画
でシステムの大 規 模 改 修 を実 施 することになった．
システム改 修 プロジェクトの構 成 と役 割 は次 のように決 められた．
社 内 の承 認 オペレーション： 航 空 会 社 の情 報 企 画 部 門 のメンバー ３名
システム改 修 項 目 の提 案 ： コンピュータメーカーの航 空 運 輸 担 当 ＳＥ ３名
（ｂ）要求工学プロセス
ステップ１：
プロジェクトの開始
プロジェクトの開 始 に当 たって，情 報 企 画 部 門 からコンピュータメーカーに，次 の
2つの条 件 が提 示 された．
改 修 項 目 に抜 けが無 いように，業 務 全 般 にわたって調 査 すること
社 内 の承 認 を得 るために，新 たな魅 力 的 機 能 を提 案 すること
ステップ２：
情報収集と整理
コンピュータメーカーの航 空 運 輸 担 当 ＳＥらは，情 報 の見 落 としを防 ぐために，
できるだけ多 くの情 報 源 を探 し，以 下 のような情 報 の収 集 に当 たった．
現 行 システムの機 能 の調 査
過 去 3年 に渡 る業 界 紙 による業 界 動 向 の調 査
運 輸 コンサルタントを使 ったロジスティックス・サービスの調 査
空 港 現 場 での，作 業 担 当 者 へのヒアリング調 査
こうした調 査 の結 果 ，約 ２０００件 に上 る情 報 や要 求 が収 集 された．この情 報 を
もとに，コンピュータメーカーから航 空 会 社 の情 報 企 画 部 に，改 修 項 目 の提 示 と
新 たな機 能 の提 案 を行 なうことになった．メーカーの担 当 ＳＥたちは，収 集 された
膨 大 な情 報 の整 理 を始 めたが，その量 のあまりの多 さに，整 理 作 業 が進 まず，時
間 だけが徒 に過 ぎていった．メンバーたちは，その原 因 を，絶 えず増 え続 ける情 報
と，クライアントの矛 盾 した意 見 のせいにした．
第2章
要求工学プロセス知識の記述
ステップ３：
55
プロセスパターンの適用：情報の整理
プロジェクトは，大 量 情 報 の整 理 という問 題 を解 決 するために要 求 工 学 プロセス
パターンの適 用 を図 ることにした．
パターンの選 択 にあたって，はじめに，情 報 整 理 作 業 を行 っているメーカーの担
当 SE３名 による状 況 の判 断 を行 った．状 況 遷 移 図 を使 って，自 分 たちの置 かれ
ている状 況 を選 択 することにし，「情 報 を整 理 できない分 析 者 」という状 況 が同 定
された．次 に，その状 況 の中 から「大 量 情 報 の整 理 」というパターンが選 択 された．
「増 加 し続 ける情 報 」や「矛 盾 した情 報 」というパターンも選 択 されたが，情 報 量 と
の比 較 によってそれらの重 要 性 は低 いとみなされた．
選 択 されたパターンには，解 として次 の４つの分 類 法 が提 示 されていた．
業 務 の種 類 の違 いによって情 報 を分 類 する
関 係 者 のタイプの違 いによって情 報 を分 類 する
目 的 の違 いによって情 報 を分 類 する
時 間 の経 過 にしたがって情 報 を分 類 する
これを参 考 に，現 行 の組 織 体 制 をもとにした業 務 と，個 々の要 求 の上 位 目 的 と
いう２つの軸 を使 って情 報 を分 類 することにし，それぞれ同 じグループ内 で，類 似
した情 報 を統 合 した．次 に，選 択 された２つの軸 によって分 類 した項 目 をさらに統
合 し，最 終 的 に，３０個 の要 求 項 目 に整 理 することができた．その殆 どは，航 空 運
輸 制 度 の変 更 に対 する対 応 策 であった．この分 類 統 合 作 業 は１人 のＳＥによって
行 われ，作 業 に要 した期 間 は２週 間 であった．
ステップ４：
新機能の創出
航 空 会 社 からのもう１つの要 請 である新 機 能 の創 出 については，発 想 支 援 法 を
用 いていくつかのアイデア創 出 を行 った．しかし，それは要 求 プロセスパターンとは，
異 なった作 業 である．
（ｃ）考察
56
第2章
要求工学プロセス知識の記述
「大 量 情 報 の整 理 」という問 題 は，要 求 工 学 プロセスにおいてしばしば遭 遇 する
典 型 的 な問 題 の1つである．この問 題 を解 決 するための基 本 的 な戦 略 は，情 報
分 類 のために可 能 な分 類 軸 を設 定 し，それを順 次 試 して行 くという方 法 である．
しかし，その戦 略 を実 行 するには膨 大 な時 間 が必 要 となる．問 題 は，情 報 の分 類
統 合 のための手 法 と，有 効 な分 類 軸 を如 何 に早 く発 見 できるかということにある．
本 事 例 では，プロセスパターンを使 って情 報 の分 類 軸 の候 補 を提 供 することに
よって，３人 のＳＥが１ヶ月 かかっても整 理 できなかった情 報 の整 理 を，１人 のＳＥが
２週 間 でできるという結 果 を得 ることができた．もちろん，問 題 領 域 についてのある
程 度 の知 識 をもった担 当 ＳＥにとって，提 示 された分 類 軸 の中 から，有 効 な軸 を
発 見 することは比 較 的 容 易 であり，一 旦 ，分 類 軸 が決 まれば，それに沿 って情 報
を整 理 することは，さして難 しい作 業 ではなかった．この事 例 から分 かったことは，
抽 象 化 作 業 に慣 れていない一 般 のＳＥにとって難 しいのは，情 報 の理 解 ではなく，
それを整 理 するための分 類 軸 の発 見 であるということであった．もしプロジェクトの
状 況 を無 視 して，問 題 だけを特 定 しようとしていたら，「増 加 し続 ける情 報 」や「矛
盾 した情 報 」という異 なった問 題 が選 択 され，分 類 軸 の提 示 という結 論 には至 ら
なかったかもれない．状 況 セクションを独 立 させ，状 況 認 識 を優 先 させたプロセス
パターンの有 効 性 が示 された例 である．しかし，状 況 の特 定 は困 難 な作 業 である．
プロジェクトメンバーによってしばしばその認 識 が異 なる場 合 がある．特 に，地 位 の
高 い技 術 者 は，自 分 にとって都 合 の悪 い状 況 は認 めたがらない傾 向 がある．客
観 的 な状 況 判 断 にもとづいたメンバー同 士 の合 意 の形 成 と問 題 の事 前 検 討 が
問 題 解 決 の重 要 な鍵 となる．この例 では，状 況 遷 移 図 の使 用 によって，「情 報 の
分 類 が出 来 ない分 析 者 」という状 況 を特 定 することができ，情 報 の分 類 に有 効 な
分 類 軸 を提 示 が可 能 となった．
（ｄ）その他の知見
本 事 例 で学 んだことの１つは，ちょっとしたアイデアが問 題 解 決 に大 いに有 効 な
場 合 があるということである．発 見 的 知 識 とは，そういうものであるかもしれない．も
ちろん，そうしたアイデアを受 け入 れるためには，受 け入 れる側 に，思 考 の柔 軟 性
が必 要 であることは言 うまでも無 い．
第2章
要求工学プロセス知識の記述
57
ステップ４における問 題 は，いわゆる営 業 時 のオーバーコミットから生 まれたもの
で，本 来 の要 求 工 学 の対 象 範 囲 外 である．こうした人 間 の創 造 性 に関 わる問 題
に対 しては，要 求 工 学 技 術 以 外 の技 術 が必 要 となり，要 求 工 学 プロセスパター
ンとは異 なった発 想 支 援 パターンのようなものが必 要 となるだろう．
2. 7. 関 連 研 究
ソフトウェア開 発 における個 別 の問 題 を解 決 するための発 見 的 知 識 をカタログ
化 するための有 効 な記 述 方 法 であるパターンが提 案 されて以 来 ，ソフトウェア工
学 の様 々な局 面 で，種 々のパターンが提 案 されてきた．方 法 論 がシステム開 発 プ
ロジェクトの成 功 シナリオを提 供 するのに対 し，経 験 に基 づいた知 識 を記 述 したパ
ターンは，方 法 論 では提 供 されない，偶 発 的 な問 題 に対 する解 を提 供 することを
目 的 としている．しかし，ＳＣＲＵＭのように，方 法 論 そのものをパターンで記 述 して
いる例 もある[126]．
パターンの基 本 的 なアイデアは，建 築 家 であるC.Alexander によって提 案 され
たものである[2]．Alexander は，問 題 と文 脈 と解 というパターンの主 要 な構 成 要
素 を提 示 することによって，その後 のパターン発 展 の礎 を築 いた[3]． Alexander
は建 築 家 だったので，彼 が提 示 したパターンも建 築 設 計 に関 するものである．そ
の後 のパターン研 究 の主 流 が設 計 型 パターンであった遠 因 が，ここにあるのかも
知 れない．
ソフトウェアパターンにおける最 初 の大 きな仕 事 は，GoF によるデザインパター
ンである[54]．このデザインパターンは，著 者 らの発 見 的 知 識 が集 大 成 されたもの
で，オブジェクト指 向 プログラム設 計 上 の有 益 な2３個 のパターンから構 成 されてい
る．その基 本 的 なアイデアは，継 承 よりも合 成 や委 譲 を優 先 させて再 利 用 可 能 な
プログラム構 造 を作 ろうとするもので，そのアイデアを，14種 類 の構 成 要 素 によっ
て記 述 している．GoF 本 の成 功 に刺 激 され，その後 ，アナリシスパターン[53]やア
ーキテクチャパターン[21]など，様 々なソフトウェア設 計 に関 するパターン集 が提
案 された．それらの記 述 項 目 には，いくつかの共 通 要 素 が見 られる．なかでも，特
に，問 題 と文 脈 と解 は，対 象 問 題 に拘 わらない本 質 的 な要 素 である． Coplien
は，これらの形 式 を発 展 させ，ソフトウェアパターンを記 述 するための一 般 的 なパタ
ーン形 式 を提 案 した[29]．この Coplien 形 式 と呼 ばれる形 式 は，パターン名 ，問
58
第2章
要求工学プロセス知識の記述
題 ，文 脈 ，フォース，解 ，根 拠 ，結 果 という７つのパターンセクションから構 成 され
ており，本 研 究 でも，この形 式 を念 頭 においている．Fowler のアナリシスパターン
は，異 なった問 題 領 域 に共 通 する実 体 構 造 を，抽 象 度 の高 い概 念 モデルとして
表 現 したものである．問 題 領 域 の基 本 構 造 である概 念 モデルをパターン化 し，そ
こから共 通 の要 求 を導 出 しようというものであり，その意 味 で，対 象 領 域 を理 解 す
るための発 見 的 知 識 の1種 と位 置 づけることができる．Jackson の問 題 フレーム
[73]も，対 象 を解 決 すべき問 題 と捉 えるという違 いを除 けば，同 様 の文 脈 で捉 え
ることができる．パターンが建 築 業 界 よりも情 報 システム業 界 で受 け入 れられたの
は，建 築 パターンが意 匠 設 計 への適 用 だったのに対 し，情 報 システムパターンが
ソフトウェアの構 造 設 計 への適 用 であったからかもしれない．感 性 が大 きな比 重 を
占 める意 匠 設 計 では，他 人 のパターンを受 け入 れることは難 しい．
パターンは，その後 ，個 別 の問 題 解 決 のための知 識 を記 述 するための代 表 的
な方 式 として定 着 し，優 れたソフトウェアを作 るためのソフトウェアパターンとともに，
開 発 プロセスを支 援 するためのプロセスパターンも提 案 されるようになった．要 求
工 学 プロセスのためのパターン形 式 に関 しては，Hagge らが，目 標 ，文 脈 ，問 題 ，
解 ，アプリケーション領 域 ，フォース，構 造 ，結 果 ，事 例 と経 験 という９つの要 素 を
提 案 しており[59]，本 研 究 との類 似 性 が高 い．いわゆる設 計 パターンなどにはな
い目 標 や結 果 という概 念 をプロセスパターンに導 入 しているところに彼 らの独 自 性
があり，本 論 文 でもその重 要 性 が再 認 識 されている．しかし，パターン化 の対 象 が
小 規 模 プロジェクトに限 定 されているため，状 況 変 化 という概 念 が欠 如 している．
例 えば，“Provide Specification Guideline by Reverse Envisioning” というパタ
ーンでは，プロジェクトの状 況 を特 定 するための文 脈 の記 述 は，「分 散 プロジェクト
が発 足 した後 の要 求 獲 得 作 業 」というように，手 順 を示 しているだけで，プロジェク
トの状 況 の説 明 にはなっていない．そのため，「異 なった視 点 を統 合 しなければな
らない」という問 題 が，プロジェクトのどのような問 題 に寄 与 するのかの具 体 的 なイ
メージがつかめない．また，内 部 状 況 についての記 述 もないので，「ガイドラインの
作 成 」という解 が，どの程 度 のメンバー構 成 のプロジェクトなら有 効 であるかなどを
判 断 することが困 難 である．プロジェクトが大 きくなればなるほど，そのプロジェクト
が遭 遇 する状 況 は複 雑 化 してゆく．そのため，問 題 とは独 立 した状 況 の定 義 をし
なければ，解 の選 択 は困 難 となる．しかし，彼 らの目 的 は，プロセスパターンの形
式 を研 究 することではなく，要 求 パターンを収 集 することにあり，本 研 究 とは目 的
第2章
要求工学プロセス知識の記述
59
が異 なっている．
パターンの有 効 性 が示 されて以 来 ，PLoP[30]をはじめとする多 くのパターン集
が出 版 された．しかし，大 量 のパターンの中 から目 的 とするパターンを選 択 するこ
とは至 難 の業 である．その上 ，それぞれのパターンは他 のパターンと密 接 に結 び
つくことによって，パターンの構 造 的 な複 雑 さが増 加 する．多 くのパターンが提 案
されたにもかかわらず，参 照 されるパターンがGoFの設 計 パターンに集 中 している
ことの理 由 がそこにある．Alexander は，複 数 のパターンをまとめて記 述 するパタ
ーンランゲージ[2]を提 案 しているが，パターンランゲージは，１つの建 築 対 象 に適
用 すべき連 続 したパターンの集 合 であり，そこから特 定 のパターンを発 見 すること
を目 的 とはしていない．一 方 ，R.Johnson らは，複 雑 なパターン構 造 を記 述 する
ための方 法 として有 効 グラフの使 用 を提 言 している［80］．彼 らは描 画 エディタの
使 用 法 を１０ステップのフレームワークとし記 述 し，それらの関 係 を有 効 グラフによ
って示 しており，それは本 論 文 の状 況 遷 移 図 と同 じアプローチである．ただし，描
画 エディタの使 用 法 は，彼 らも言 っているように完 結 したパターンランゲージの一
種 であり，偶 発 的 問 題 を対 象 としている本 研 究 とはそこが異 なっている．
2. 8. 考 察
本 章 では，要 求 工 学 プロセスにおける問 題 解 決 のための発 見 的 知 識 の記 述
方 式 について議 論 し，状 況 と問 題 の分 離 がプロセス知 識 の記 述 にとって有 効 で
あることを具 体 的 な事 例 を通 して示 した．
熟 練 技 術 者 が持 つ個 別 の発 見 的 知 識 は，それを普 遍 化 することによって再 利
用 が可 能 となる．パターンは，そのような普 遍 的 な知 識 を記 述 するのに向 いている．
本 論 文 で提 案 したプロセスパターンにおける状 況 セクションと課 題 セクションの分
離 は，たとえ同 一 の問 題 であっても，状 況 が異 なれば，異 なった解 が必 要 となるよ
うな工 学 プロセス特 有 の問 題 構 造 ，すなわち，状 況 と課 題 の非 同 期 構 造 を素 直
に表 現 するのに適 している．ステージ，状 況 ，問 題 という階 層 構 造 は，問 題 の段
階 的 な絞 り込 みを可 能 にすることによって，選 択 の容 易 性 や記 述 の明 快 さという
問 題 に寄 与 している．さらに，結 果 の提 示 は，適 切 と思 われる手 法 を選 んだからと
いって，必 ずしも良 い結 果 が得 られるとは限 らない工 学 プロセスでの，解 の選 択 に
60
第2章
要求工学プロセス知識の記述
対 するリスクを軽 減 するのにも役 立 つ．
しかし，普 遍 化 されただけで未 整 理 のままの知 識 は，抽 象 化 された知 識 に比 べ，
その量 が膨 大 となることが避 けられない．大 量 で複 雑 な情 報 を整 理 する方 法 とし
て，分 割 ，抽 象 化 ，構 造 化 などがある[13]．本 論 文 で提 案 している状 況 遷 移 図
は，構 造 化 による発 見 的 知 識 の整 理 であり，状 況 の変 化 に焦 点 を当 てることによ
って大 量 のパターンを体 系 化 するための図 式 である．状 況 遷 移 図 を使 って，状 況
別 ，問 題 別 にパターンを整 理 し，解 析 することによって大 量 のパターンの中 から適
切 なパターンを探 すことが容 易 になる．さらに，有 向 グラフが示 す状 況 変 化 の前
後 関 係 は，問 題 の予 測 ，回 避 の事 前 処 置 ，コストの見 積 もりなどに関 する基 礎 情
報 を提 供 してくれ，予 期 せぬ問 題 を検 討 することにも役 に立 つ．また，図 式 は，異
なった立 場 の人 間 同 士 の合 意 形 成 に役 立 つので[138]，多 くの経 験 者 との合 意
によって発 見 的 知 識 の有 効 性 を判 断 するのにも効 果 がある．
ソフトウェア工 学 の様 々な分 野 で，大 量 のパターンが提 案 されてきたが［30］，一
般 によく使 用 されているのは，そのうちの僅 かなものに過 ぎない．利 用 者 にとって
価 値 のあるパターンとは，同 様 の問 題 がよく発 生 し，その解 が普 遍 的 な価 値 を持
つものである．デザインパターンやアナリシスパターンが多 くの技 術 者 に受 け入 れ
られた理 由 の１つは，パターンの普 遍 化 が図 られており，少 ない知 識 で高 い再 利
用 の可 能 性 を秘 めているからである．選 択 の容 易 性 ，記 述 の明 快 さ，解 の普 遍
性 などが再 利 用 を促 進 する要 因 であり，パターンの記 述 にはある程 度 の熟 練 性
を要 することになる．
状 況 遷 移 図 で見 たように，構 造 化 は多 様 で曖 昧 な問 題 領 域 を理 解 する有 効
な方 法 の１つである[13]．そうした視 点 から，構 造 主 義 [88]などとの関 連 について
検 討 を行 うことは今 後 の課 題 である．
第 ３ 章
要求工学技法の選択
要 求 工 学 プロセスの中 で，要 求 技 術 者 はいくつかの意 思 決 定 を行 わなければ
ならない．その中 でも，最 も困 難 な作 業 の1つは，プロジェクトに適 した要 求 工 学
技 法 を選 択 することである．プロジェクトが遭 遇 する問 題 の多 様 性 に合 わせて
様 々な技 法 が提 唱 されてきたが，これは，プロジェクトに適 した要 求 工 学 技 法 を選
択 するにはどうすれば良 いかという新 たな問 題 を提 起 した．
プロジェクトは，対 象 問 題 領 域 や，システムのタイプ，大 きさ，組 織 の文 化 といっ
た様 々な要 因 によって特 徴 付 けられる．プロジェクトの特 性 に合 わない要 求 工 学
技 法 が選 択 されると，そのプロジェクトは障 害 に陥 ってしまうかもしれない［144］．
確 かに，要 求 選 択 の問 題 に関 して，いくつかの研 究 がある[93, 62]．しかし，論 文
や教 科 書 ，チュートリアル，ツールのマニュアルといった要 求 工 学 関 係 の文 献 の
多 くは，特 定 の技 法 の優 位 性 について強 調 はするが，その適 用 領 域 や限 界 につ
いて十 分 に言 及 することがない．プロジェクトに適 した手 法 を選 択 する上 で重 要 な
のは，要 求 手 法 とプロジェクトの特 徴 を関 係 付 ける汎 用 的 なフレームワークであ
る．
要 求 工 学 技 法 の適 用 上 でのもう一 つの課 題 は，プロジェクトの状 況 変 化 にどの
ように寄 与 できるかということである．要 求 工 学 作 業 中 であろうと，要 求 仕 様 が完
成 した後 であろうと，ビジネス環 境 やステークホルダあるいは適 用 技 術 などの変 化
によって，プロジェクトは重 要 かつ実 質 的 な変 化 を経 験 することになる．プロジェク
トは変 化 していないのに，プロジェクトの性 質 に対 する要 求 技 術 者 の理 解 が変 化
することもある．要 求 工 学 プロセスが障 害 に遭 遇 してしまってから，プロジェクトの
特 性 に対 する最 初 の判 断 が間 違 っていたということに気 付 くこともある．このような
62
第3章
要求獲得技法の選択
状 況 に陥 ったプロジェクトは，直 面 している障 害 を回 避 するために，新 たな要 求
工 学 技 法 を選 択 し，適 用 しなければならない．
優 れた技 術 者 は，良 い選 択 をし，選 ばれた技 法 を上 手 に適 用 する能 力 を持 っ
ている．しかし，限 られた教 育 や乏 しい経 験 しか持 たない未 熟 な技 術 者 は，手 法
選 択 の幅 が限 定 されている．一 度 ，プロジェクトに適 さない手 法 が選 択 されると，
そのプロジェクトは破 綻 に帰 することになってしまうかもしれない．本 章 では，代 表
的 な要 求 工 学 技 法 の特 徴 を整 理 し，プロジェクトの開 始 時 や，プロジェクトの特
性 が変 化 したり，障 害 に遭 遇 したときなどに，適 切 な技 法 を選 択 できるようにする
ためのフレームワークを提 案 する．
3. 1. 要 求 獲 得 技 法 の 分 類
初 期 要 求 工 学 プロセスである要 求 獲 得 技 法 に焦 点 を当 てる．
要 求 工 学 技 法 の特 徴 を検 討 するために，ドメイン分 割 ，ゴール指 向 ，シナリオ
ベース，ブレーンストーミングという，広 く使 われている４つの代 表 的 なアプローチを
取 り上 げる．オブジェクト指 向 モデリングや状 態 モデリングといったモデリング技 術
とその記 法 は重 要 であり，いくつかの要 求 分 析 技 法 はそのようなモデリング技 術 に
強 く結 びついているが，ここでは，純 粋 な要 求 獲 得 技 法 にのみ注 目 することにす
る．この４つの技 法 は，単 に重 要 というだけではなく，互 いに明 確 に異 なった特 性
を有 している．以 下 に，４つのアプローチを概 観 する．
ドメイン分割
ドメイン分 割 によって対 象 ドメインは，順 次 ，サブドメインに分 割 されてゆく．
扱 うサブドメインが，十 分 に小 さいく管 理 が可 能 なときは，要 求 を漏 れなくリ
ストアップすることが容 易 である．この技 法 を使 って，小 さなサブドメインや要
求 を，より大 きなものにまとめ上 げてゆくというボトムアップ式 の処 理 も可 能 で
ある．このようなドメイン分 析 手 法 の研 究 は，長 い歴 史 を持 っている．代 表 的
な 例 は ， R.Rieto-Diaz に よ る 仕 事 で [115] ， J.Neighbor に よ っ て Draco
プロジェクトに引 き継 がれた[100]．このアプローチは，分 類 手 法 として一 般
化 することがきる．ビジネスプロセスやステークホルダのグループ化 など，ドメイ
第3章
63
要求獲得技法の選択
ン以 外 の要 求 に関 わる様 々な実 体 を分 類 するためのアプローチも，これに
含 まれる．
ゴール指向
多 くのゴール指 向 アプローチが提 案 されてきた[7，33，87，98]．そうした研
究 の 中 で ， KAOS が 形 式 的 な ア プ ロ ー チ を 採 用 し て い る の に 対 し ， GBRAM
は非 形 式 的 なアプローチをとっている．
シナリオベース
シナリオベースのアプローチも一 般 的 である[63，112]．ユースケースは，シ
ナリオの統 合 セットと考 えられる．それゆえ，ユースケースアプローチ[32，74]
は，基 本 的 に，このカテゴリーに属 するが，より後 期 の要 求 工 学 フェーズで
使 用 するのに向 いている．
ブレーンストーミング
ブレーンストーミングは，システム開 発 経 験 が乏 しかったり，新 たなソフトウ
ェアの開 発 が期 待 されているような領 域 での要 求 獲 得 に，特 に効 果 がある．
KJ法 は，４０年 以 上 前 に作 られた手 法 であるが，洗 練 されたブレーンストーミ
ング法 の1つで，実 業 界 では広 く使 用 されている[84]．KJ法 のソフトウェア要
求 工 学 への適 用 は，N.Takeda らによって報 告 されている[137]．
要 求 工 学 技 法 の違 いを，その適 用 という観 点 から特 徴 付 けるために，２つの次
元 について考 える．１つは，獲 得 操 作 のタイプに関 するもので，もう１つは，対 象 物
のタイプに関 するものである．それぞれの次 元 を，さらに，分 類 する．すなわち，操
作 タイプを，静 的 （static）と動 的 （dynamic）という２つのカテゴリーに分 け，対 象 タ
イプを閉 鎖 的 （closed）と開 放 的 （open）という２つのタイプに分 ける．表 -3.1に，２
つの次 元 からなる空 間 上 に配 置 された４つの技 法 を示 す．
要 求 工 学 技 法 を分 類 するに当 たって，この２つの次 元 を使 用 する．
最 初 の次 元 は，要 求 獲 得 プロセスのなかで，静 的 （static）な構 造 と動 的
（dynamic)な振 る舞 いの，いずれに焦 点 を当 てて活 動 しているかということである．
表 -3.1 技 法 と次 元 空 間
64
第3章
操作
静 的 （Static)
要求獲得技法の選択
動 的 （Dynamic）
対象
閉 鎖 的 （Closed)
領域分割
シナリオベース
開 放 的 （Open)
ゴール指 向
ブレーンストーミング
静的
要 求 は，静 的 な構 造 として捉 えた問 題 領 域 から，構 造 的 あるいは体 系 的
な方 法 で収 集 され，整 理 される[18]．一 般 に，このタイプの技 法 は，静 的 な
構 造 を持 った問 題 領 域 を扱 うのに適 している．(サブ)ドメインやゴールあるい
は要 求 それ自 身 といった，対 象 に関 する要 求 を分 解 ／合 成 ，あるいは，分
類 ／集 約 するための規 則 やガイドラインがある．
動的
要 求 は，動 的 な文 脈 に焦 点 を当 てた問 題 領 域 から，創 造 的 かつ非 手 法
的 な方 法 で収 集 される．このタイプの技 法 は，問 題 領 域 を動 的 な文 脈 で扱
うの に 適 している[22]． 多 くの ステークホ ル ダにと っ て， 手 続 き的 な振 る舞 い
や時 間 的 な状 況 変 化 について考 えることは，比 較 的 容 易 な場 合 が多 い．
要 求 は，ステークホルダや分 析 者 の想 像 力 によって列 挙 されたり生 成 された
りする．しかし，このような手 法 の使 用 は，動 的 なドメインに限 定 されるわけで
はない．実 際 ，このタイプの代 表 的 な手 法 であるブレーンストーミングは，静
的 な性 質 を持 った要 求 を獲 得 するのにも使 われている．
第 ２の次 元 は，分 析 されるべき対 象 空 間 が閉 鎖 的 （closed)か，開 放 的 （open)
か，という特 性 に関 係 している．
閉鎖的
対 象 空 間 は，比 較 的 安 定 しており，良 く知 られていて，閉 じている．そうし
た空 間 は，基 本 的 に構 造 化 が可 能 であり，形 式 論 的 に多 様 な型 に整 理 す
ることができる．それゆえ，主 として，対 象 の形 式 や構 文 に注 目 することによ
って理 解 することが可 能 である．
第3章
要求獲得技法の選択
65
開放的
対 象 空 間 は，安 定 しておらず，あまり知 られていず，開 いている．そうした
空 間 を探 索 するには，対 象 の意 味 を詳 細 に検 討 しなければならない．
他 の様 々な要 求 工 学 技 法 も，この２つの次 元 によって展 開 される平 面 上 に写
像 することが可 能 である．この平 面 を要 求 工 学 技 術 マップと呼 ぶ．図 -3.1は，代
表 的 な技 法 を配 置 した要 求 工 学 技 術 マップである．技 法 の配 置 は基 本 的 に，筆
者 の経 験 をもとに行 われ，筆 者 もその一 員 として活 動 している実 務 家 たちによる
要 求 工 学 研 究 グループ Mahoroba のメンバーによって確 認 された．
このマップ上 に，いくつかの注 目 に値 する類 型 が見 られる．
１． 右 半 分 の上 部 から下 部 にかけて，MSC，ユースケース，シナリオ，物 語 法 ，
ロールプレイといった一 連 のシナリオベースの技 法 が見 られる．これらの技 法
は，動 的 なイベントの進 行 におけるユーザや専 門 家 の経 験 と直 感 をベース
にしているという，要 求 獲 得 上 の共 通 した性 質 をもっているが，決 して硬 直
的 ではない．上 方 部 の技 法 群 は，形 式 あるいは構 文 を意 識 しながら，閉 鎖
的 な空 間 を調 べるのに比 較 的 適 している．それに対 し，下 方 部 の技 法 群 は，
開 放 的 な空 間 を調 査 するのに適 しており，より人 間 性 を指 向 する傾 向 を持
っている．プロトタイピングアプローチも，同 様 の性 質 を持 っており，その中 心
的 課 題 は，動 的 な会 話 をシミュレートすることである．
２． 左 上 から右 下 にかけての対 角 線 に沿 って，ドメイン分 割 ，構 造 化 インタビ
ュー，カードソーティング，抽 象 化 ，KJ 法 ，ブレーンストーミング，民 俗 学 的
技 法 といった，一 連 の知 識 獲 得 分 類 型 のアプローチが見 られる．この対 角
線 は，左 上 に向 かっては収 束 的 ，右 下 に向 かっては発 散 的 という方 向 性 を
持 った軸 とみなすことができる．
３． ゴール指 向 アプローチの中 で，形 式 的 な KAOS は上 方 に位 置 づけられ，
非 形 式 的 な GBRAM は下 方 に位 置 づけられる．i*フレームワーク［149］は，
ゴール指 向 アプローチにオーバーラップしているが，右 方 向 に拡 張 している．
ゴール指 向 アプローチとシナリオベースアプローチを連 結 させた多 くの提 案
が あ り ［ 11 8 ］ ， そ れ ら は ， 要 求 工 学 技 術 マ ッ プ 上 に は 示 さ れ て い な い が ， 左
下 と右 上 の象 限 の架 け橋 である．
66
第3章
要求獲得技法の選択
４． 前 に述 べたように，実 体 を分 割 するトップダウンと，合 成 するボトムアップの
両 方 のアプローチが左 上 象 限 に含 まれている．KJ 法 は，ブレーンストーミン
グによって作 られたカードを分 類 するプロセスを持 っており，より閉 鎖 的 な左
上 方 へ位 置 づけられる．Problem frames アプローチ［73］は，トップダウン
階 層 型 技 法 によっても並 列 並 行 型 技 法 によっても構 造 化 されない分 割 で
あるが，他 のドメイン分 割 と関 連 付 けることができる．
５．様 々なアイデア生 成 タイプの技 法 が右 下 象 限 に含 まれている．例 えば，ア
ブダクションベースのアプローチ［120］もここに配 置 される．
いくつかの手 法 は，異 なった象 限 の中 に分 類 された技 法 を合 成 している．例 え
ば，静 的 －閉 鎖 的 象 限 に位 置 づけることのできる Multi Viewpoints アプローチ
は，複 数 の視 点 の分 類 をもとに要 求 獲 得 を行 うが，多 くの視 点 からの要 求 を処 理
するためにシナリオやゴールやその他 の技 法 を合 体 させる．
第3章
67
要求獲得技法の選択
図 -3.1
要 求 工 学 技 術 マップ
68
第3章
要求獲得技法の選択
3. 2. プ ロ ジ ェ ク ト 特 性 へ の 要 求 工 学 技 法 の 適 合 性
要 求 工 学 技 法 は，要 求 技 術 者 の直 感 や経 験 をもとに選 択 され，それぞれのプ
ロジェクトに適 用 される［4，62］．優 れた技 術 者 は優 れた選 択 をし，選 ばれた技 法
を適 切 に適 用 する能 力 を持 っている．しかし，訓 練 と経 験 に乏 しい未 熟 な技 術 者
は，選 択 肢 の幅 が限 定 されている．ひとたび，プロジェクトに適 さない技 法 が選 択
されると，プロジェクトは奈 落 の底 に落 ちてゆくことになるだろう．
前 節 で述 べた要 求 工 学 技 法 の特 性 は，プロジェクトの特 性 との適 合 性 が判 定
され，手 法 選 択 のプロセスをガイドしてゆくために使 われるべきである．
本 節 では，アプリケーションドメイン，要 求 技 術 者 のタイプ，情 報 資 源 ，ユーザの
参 画 ，要 求 特 性 という５つの要 因 によってプロジェクトを特 徴 付 ける．この５つの特
性 は，筆 者 の経 験 をもとに，要 求 工 学 技 術 マップへの適 応 性 を考 慮 して選 んだ
ものである．J.Naumann らは，プロジェクトの偶 発 性 の要 因 を，プロジェクトのサイ
ズ，構 造 化 の程 度 ，ユーザタスクの理 解 度 ，開 発 者 タスクの理 解 度 という４つのカ
テゴリーに分 類 しており［99］，筆 者 の選 択 が妥 当 であることが分 かる．
ここで取 り上 げる要 求 工 学 技 法 は，どのような大 きさのプロジェクトにも適 用 可 能
であると考 えられる．「構 造 化 の程 度 」は本 研 究 におけるアプリケーションドメインの
安 定 性 に対 応 し，「ユーザタスクの理 解 度 」は情 報 資 源 とユーザの参 画 に対 応 し，
「開 発 者 タスクの理 解 度 」は情 報 資 源 と技 術 者 のタイプに対 応 している．さらに，
要 求 品 質 と非 機 能 要 求 という２つの要 因 を取 り入 れることにする．これによって，
選 択 のための意 思 決 定 要 因 はさらに豊 かになるだろう．
手 法 の適 合 方 向 を示 すために，プロジェクト要 因 を要 求 工 学 技 術 マップ上 に
写 像 することにする．図 -3.2に示 したような，四 角 形 の中 の双 頭 の矢 印 によって，
それぞれの要 因 を象 徴 的 に示 す．四 角 形 の位 相 は図 -3.1の要 求 工 学 技 術 マッ
プ平 面 に対 応 している．
3.2.1. アプリケーションドメイン
図 -3.2で示 した方 向 は，アプリケーション領 域 の安 定 性 に対 応 している．上 方
向 は，比 較 的 安 定 的 なアプリケーションのタイプである．対 象 ドメインに類 似 したシ
ステムの開 発 経 験 の知 識 がよく蓄 積 されており，問 題 領 域 は閉 じた空 間 として捉
第3章
69
要求獲得技法の選択
えられ，機 械 的 ，形 式 論 的 な方 法 で調 査 できる．
下 方 向 は，比 較 的 新 しく，あまり知 られていない非 安 定 的 なアプリケーションで
ある．このようなアプリケーションの要 求 を探 すためには，深 層 レベルでの意 味 解
析 が必 要 となる．問 題 領 域 は開 いた空 間 と見 做 される．
両 ケースとも，静 的 －動 的 に関 する次 元 とは比 較 的 無 関 係 である．例 えば，あ
まり知 られていないアプリケーション領 域 の要 求 獲 得 は，ゴール指 向 タイプのアプ
ローチでもブレーンストーミングタイプのアプローチでもよく，選 択 は他 の要 因 を考
慮 して行 うべきである．
図 -3.2 ドメインの安 定 性
3.2.2. 要 求 技 術 者 タ イ プ
図 -3.3の方 向 は，要 求 技 術 者 の性 質 に対 応 している．左 方 向 の技 術 者 は，論
理 的 かつシステマティックな思 考 法 を好 む傾 向 にある．右 方 向 の技 術 者 は，むし
ろ想 像 性 や直 感 的 思 考 法 を好 む傾 向 にある．別 の見 方 をすれば，左 側 の人 た
ちは比 較 的 理 論 志 向 で，右 側 の人 は経 験 志 向 であるともいえる．要 求 工 学 技 術
マップ上 で左 右 に分 類 された技 法 群 と，このグループの分 類 は対 応 している．
要 求 分 析 チームは異 なった背 景 を持 つ多 くの人 たちによって構 成 されているが，
多 くの場 合 ，要 求 工 学 プロセス全 体 をコントロールしているリーダーがいる．例 え
ば，J.Carroll と P.Swatman は次 のように述 べている［22］．「・・・ひとたび，チー
ムがフィールドに入 り，情 報 収 集 を始 めたら，チーム活 動 の多 くは，A１の仕 事 を
70
第3章
要求獲得技法の選択
支 援 するために組 織 化 される．A1はプロジェクトの要 求 技 術 者 で，問 題 領 域 と，
その空 間 内 の主 要 実 体 やシステムや情 報 要 求 を分 析 する．」 ここで，A1は，技
術 者 ，社 会 学 者 ，電 子 コマースの専 門 コンサルタント，研 究 者 という７人 のメンバ
ーで構 成 される要 求 工 学 チームの２人 のリーダーのうちの一 人 である．
単 一 の優 位 なリーダーを発 見 するのが困 難 な場 合 もある．マップはそのような場
合 でも有 効 である．すべての代 表 的 技 術 者 のタイプをマッピングすることによって，
全 体 としてチームの性 質 を示 すことができる．
図 -3.3 技 術 者 の気 質
3.2.3. 情 報 資 源
文 書 や知 識 ，あるいは既 存 のシステムの調 査 を通 して入 手 できる利 用 可 能 な
情 報 が大 量 にある場 合 は，探 索 すべき空 間 は限 定 され，閉 鎖 側 の技 法 が適 する．
情 報 は整 理 され，主 として，構 文 ベースの方 法 によって整 頓 されるだろう．一 方 ，
使 用 可 能 な情 報 が少 ないとか隠 されているといった場 合 には，要 求 は，開 放 側 の
技 法 を使 って，開 いた空 間 の中 を探 される．
第3章
71
要求獲得技法の選択
図 -3.4 情 報 資 源
3.2.4. ユ ー ザ の 参 加
ユーザの参 加 は，情 報 資 源 の要 因 と関 係 がある．もし，情 報 が形 式 的 な知 識 と
して利 用 可 能 なら，要 求 収 集 のためのユーザの参 加 は不 要 である．しかし，ゴー
ル探 索 やブレーンストーミングのような手 法 を実 行 するには，ユーザの参 加 は不 可
欠 である．
図 -3.5 ユーザの参 加
72
第3章
要求獲得技法の選択
3.2.5. 要 求 品 質
要 求 の品 質 は，多 くの尺 度 によって評 価 される．IEEE標 準 830-1998 には，正
当 性 ，非 あいまい性 ，完 全 性 ，一 貫 性 ，ランク付 け，検 証 性 ，変 更 性 ，追 跡 性 が
あげられている[69]．これらの特 性 はすべて重 要 だが，それらの間 の優 先 順 位 は
プロジェクトの性 質 によって異 なってくるだろう．
静 的 －閉 鎖 的 象 限 の技 法 は，問 題 領 域 を組 織 的 にカバーするのに適 している．
それゆえ，対 象 領 域 を完 全 にカバーするという意 味 での完 全 性 が達 成 できる．動
的 －閉 鎖 的 象 限 の技 法 ，特 にシナリオベースの技 法 は，振 る舞 いの一 貫 性 を保
証 するのに適 している．特 に，ワークフローやデータフローの一 貫 性 は比 較 的 容
易 に検 出 することができる．同 様 に，要 求 を動 的 な文 脈 で入 手 し，実 装 システム
の振 る舞 いに一 致 させることができるので，追 跡 性 についても実 現 することは容 易
である．静 的 －開 放 的 象 限 の技 法 ，特 にゴール指 向 アプローチは，ゴール間 の
矛 盾 を発 見 するのに向 いている．いくつかの矛 盾 解 消 手 法 とともに，このタイプの
技 法 を使 って要 求 の論 理 的 一 貫 性 を保 証 することが期 待 される．動 的 －開 放 的
象 限 の技 法 は，期 待 される将 来 の要 求 も含 め，異 なった観 点 から多 様 な要 求 を
作 るのに向 いているので，それらは要 求 への適 合 性 を予 測 するのに役 立 つ．
図 -3.6 要 求 品 質
第3章
73
要求獲得技法の選択
3.2.6. 非 機 能 要 求
非 機 能 要 求 のいくつかは，特 定 の技 法 によって容 易 に獲 得 することが可 能 であ
る．ゴール指 向 アプローチの流 れは，ソフトゴールの概 念 を用 いた非 機 能 要 求 を
カバーすることでよく知 られている［98］．
セキュリティ関 係 は，シナリオベースのアプローチによって効 果 的 に扱 うことがで
きる．何 故 なら，攻 撃 者 がシステムに侵 略 するかもしれないすべての可 能 なシナリ
オを発 見 することが，システム攻 撃 を防 ぐための本 質 であるからである．可 能 性 の
あるシナリオを挙 げることは，発 生 するかも知 れないその他 のリスクを防 ぐ効 果 もあ
る．
使 い易 さは，会 話 とインタフェースに関 する感 覚 的 経 験 の機 会 をユーザに提 供
するプロトタイプ手 法 によって，特 によくカバーされる．
3. 3. 状 況 変 化 へ の 貢 献
プロジェクトは，前 節 の分 析 によって選 択 された適 切 な要 求 工 学 技 法 によって
スタートする．しかしながら，新 たな課 題 が発 生 し，それが解 決 されると，第 2章 で
述 べたように，プロジェクトの状 況 は変 化 する．要 求 分 析 フェーズ中 にプロジェクト
が障 害 に遭 遇 するかもしれないし，後 期 フェーズで要 求 仕 様 の不 備 が発 見 される
かも知 れない．我 々の経 験 と M.Christel らによるコンサルティング文 献 ［25］をも
とに，要 求 獲 得 活 動 で発 生 する問 題 を表 -3.2に示 した．
これらは，3.2.5節 で扱 った要 求 品 質 のネゴシエーションに関 わる問 題 でもある
が，ここではそのような問 題 が検 知 されるイベントについて考 える．そうしたイベント
が検 出 されたときは様 々な判 断 がなされる．使 用 している要 求 工 学 技 法 を変 更 す
ることは，考 え得 る最 も効 果 的 な戦 略 の1つである．要 求 の品 質 と獲 得 技 法 群 の
関 連 については既 に述 べたが，表 -3.2に挙 げたような要 求 問 題 が顕 わになったと
きにとるべき戦 略 は，それぞれの要 求 品 質 に対 応 している獲 得 技 法 グループ内
の技 法 を単 純 に適 用 することではない．注 意 すべき事 柄 を，以 下 に示 す．
表 -3.2 要 求 獲 得 の問 題
74
第3章
要求獲得技法の選択
不 完 全 な要 求
ニーズの不 完 全 な理 解
不 完 全 な領 域 知 識
ユーザの協 調 性 不 足
暗 黙 的 仮 説 の見 落 とし
間 違 った要 求
間 違 ったシステム境 界
システムの目 的 の間 違 った理 解
曖 昧 な要 求
類 義 語 や同 義 語
異 なったユーザの観 点 の違 い
確 定 しない要 求
変 動 する要 求
際 限 のない追 加 要 求 の受 け入 れ
多 すぎる要 求
組 織 化 されていない嵩 張 った情 報 源
多 すぎる要 求
営 業 によるオーバーコミット
不 要 な設 計 思 考
完全性
左 上 象 限 の技 法 は，不 完 全 性 を発 見 するのに効 果 があるが，不 十 分 な
要 求 を満 たすのには必 ずしも適 しているわけではない．ゴール指 向 やブレー
ンストーミングのような，要 求 工 学 技 術 マップの下 半 分 の技 法 は，見 失 った
要 求 を獲 得 するために使 うのがよい．そのような手 法 を通 して新 たな要 求 を
収 集 した後 ，完 全 性 をチェックするために，分 類 スキーマのもとでそれらをソ
ートし，配 置 するために，左 上 象 限 に戻 ることが好 ましい．
矛盾
第3章
要求獲得技法の選択
75
要 求 同 士 の間 に矛 盾 が発 見 されたら，それが振 る舞 い上 の矛 盾 の場 合
はシナリオベースのアプローチを，論 理 的 な矛 盾 の場 合 はゴール指 向 アプロ
ーチを適 用 することが効 果 的 である．
膨大な要求
左 上 象 限 のいくつかの技 法 はトップダウン分 割 のために使 われ，いくつか
はボトムアップ集 約 のために使 われる．問 題 が要 求 量 の多 さにある場 合 は，
集 約 型 技 法 が役 に立 つ．問 題 は，それらの間 にどのような優 先 度 をつける
か で あ る ． AHP の よ う な 評 価 機 構 を 組 み 合 わ せ た ゴ ー ル 指 向 ア プ ロ ー チ は
効 果 がある．
あいまい性
要 求 表 現 のあいまい性 は，基 本 的 には，要 求 獲 得 技 法 とは直 交 した問
題 であり，モデリングや表 記 用 言 語 に依 存 している．しかしながら，もし，問
題 が具 体 性 の欠 如 なら，要 求 工 学 技 術 マップの上 方 向 へ移 動 することによ
って，操 作 ゴールを入 手 するためのゴール指 向 アプローチを実 行 したり，シ
ナリオをメッセージシーケンスチャートとして形 式 化 することによって具 体 化 を
支 援 することができる．
3. 4. 事 例 研 究
ケーススタディとして，2つのプロジェクトを取 り上 げる．1つは研 究 発 表 会 支 援 シ
ステムで，もう1つは核 燃 料 棒 管 理 システムである．
3.4.1. 研 究 発 表 会 支 援 システム
(a) プ ロ ジ ェ ク ト の 概 要
このシステムは，企 業 内 のソフトウェア工 学 シンポジウムのためのものである．プロ
ジェクトの立 ち上 げ時 には，本 研 究 で報 告 した要 求 工 学 技 法 の分 類 と選 択 のた
めのガイドラインは完 成 していなかった．プロジェクトは，基 本 的 に要 求 分 析 者 の
76
第3章
要求獲得技法の選択
経 験 とスキルをもとに進 行 したが，プロジェクトの観 察 を通 して本 研 究 のアイデアを
洗 練 させることができた．
このシンポジウムは毎 年 行 われており，スタッフメンバーから社 員 への論 文 投 稿
が呼 びかけられている．シンポジウムは事 務 局 によって組 織 化 されるが，実 際 には，
過 去 10年 間 は事 務 局 のただ一 人 の事 務 局 員 によってシンポジウムが運 営 されて
きた．この事 務 局 員 の定 年 が近 づいたので，彼 が持 っている知 識 を残 す必 要 が
生 じた．システム開 発 のもう１つの目 的 は，シンポジウムの管 理 作 業 をより効 率 的
に行 うことである．
プロジェクトを始 めることが決 定 されたが，当 該 事 務 局 員 は忙 しすぎてプロジェク
トに参 加 できないことが判 明 した．代 わりに，過 去 10年 間 の未 整 理 の文 書 が要 求
分 析 者 に渡 された．そこには，会 議 議 事 録 やレターや事 務 局 員 の個 人 的 なメモ
などが乱 雑 に含 まれていた．
(b) プ ロ ジ ェ ク ト の 特 徴
プロジェクトの基 本 的 な特 徴 は，以 下 の通 りであった．
・ 対 象 領 域 は比 較 的 限 定 されていて，小 さい．
・ 他 方 ，開 発 組 織 は似 たようなシステムの開 発 経 験 が無 く，問 題 領 域 は彼 ら
にとって新 しい．
・ ステークホルダの参 加 は望 めない．
・ 使 用 可 能 な情 報 ソースは大 きいが，知 識 は組 織 化 されていない．
(c) 要 求 工 学 プ ロ セ ス
実 際 の要 求 分 析 プロセスは，次 の4つのステップで行 われた．
ステップ１：
ドメイン知識を入手するための情報の整理
最 初 のステップは，シンポジウムを組 織 化 するプロセスと，事 務 局 員 の行 う
べきタスクを理 解 することだった．事 務 局 員 から情 報 を入 手 することができな
いので，情 報 資 源 は組 織 化 されていない資 料 だけであった．この状 況 に，
第3章
要求獲得技法の選択
77
静 的 －閉 鎖 的 象 限 の分 類 技 法 がよく適 していた．問 題 領 域 が比 較 的 小 さ
く閉 鎖 的 であったという事 実 は，その適 合 性 を高 めた．シンポジウムを開 催
するための仕 事 は，計 画 立 案 ，論 文 募 集 ，論 文 選 択 ，シンポジウム開 催 ，
論 文 誌 の発 刊 という流 れに沿 って進 むので，情 報 を整 理 するために，活 動
プロセスによる分 割 が選 択 された．この判 断 は，資 料 を調 べた分 析 者 によっ
て発 見 され，論 文 を投 稿 した一 人 の著 者 が，一 般 的 な従 業 員 から論 文 投
稿 者 ，入 選 者 ，発 表 者 へと変 化 するという事 実 によって確 証 された．
中 核 プロセスは，さらにサブプロセスに分 割 された．例 えば，計 画 立 案 プロ
セスは，組 織 コミッティの立 ち上 げ，プログラムコミッティの立 ち上 げと査 読 者
の選 定 ，組 織 とプログラムのコミッティ会 議 の開 催 ，スケジュールの決 定 とい
う具 合 に分 割 された．
すべての文 書 は，このプロセスの分 割 構 造 をもとに整 理 され，冗 長 で重 要
性 の無 い情 報 は破 棄 された．
ステップ２：
シンポジウムを組織化するタスクの理解
文 書 は作 業 の進 行 順 序 に沿 って並 べられ，プロセスの構 造 を理 解 する助
けとなったが，それぞれの具 体 的 なタスクは未 だ良 く理 解 されていなかった．
こうしたタスクを明 らかにするために，動 的 －閉 鎖 的 象 限 のシナリオベースの
手 法 がよく適 合 した．過 去 のシンポジウムにコミッティメンバーとして参 加 した
人 たちへのインタビューによって得 られた情 報 と，並 び替 えられた文 書 をもと
に，分 析 者 は，自 分 自 身 でシナリオを記 述 しなければならなかった．シナリオ
の例 は，次 のようなものである．
論文募集
１. 特 別 セッションのテーマの設 定
２. 論 文 募 集 要 項 の作 成
３. PCメンバーへの論 文 募 集 要 項 の送 付 と必 要 な修 正
４. 組 織 コミッティへの論 文 募 集 要 項 の送 付 と承 認
５. 論 文 募 集 要 項 の印 刷 依 頼
６. 全 従 業 員 への論 文 募 集 要 項 の配 布
78
第3章
要求獲得技法の選択
出 来 上 がったシナリオは正 当 性 をチェックするために事 務 局 員 に送 られ，
若 干 のミスが指 摘 された．
ステップ３：
要求の識別
前 のステップは，分 析 者 が対 象 問 題 領 域 とプロセスを理 解 するためのもの
であり，構 築 するシステムのための要 求 とは，明 確 に識 別 されなければならな
かった．要 求 を識 別 するために，静 的 ―閉 鎖 的 象 限 の分 類 技 法 が再 び使
われ，要 求 空 間 を分 割 するために，２つの基 準 が用 いられた．1つは，機 能 ，
性 能 ，品 質 という要 求 タイプであり，他 方 はビジネス，操 作 員 ，システムという
要 求 元 である．このステージでは，事 務 局 員 はプロジェクトのために多 少 の
時 間 を取 れるようになっていたので，この作 業 を進 めるために，分 析 者 は事
務 局 員 との週 １回 の会 議 を持 つことになった．表 -3.3に，結 果 を単 純 化 して
示 す．
表 -3.3 要 求 マトリックスによる要 求 の整 理
機能要求
ビジネス
性能要求
品質要求
計画立案，
データ量 ：
執 筆 者 情 報 の保 護 ，
論文募集，
３００論 文
査 読 者 情 報 の保 護 ，
査 読 者 の選 択 ，
不 正 アクセスの防 止
論文審査，
論 文 執 筆 者 への告 知
操作者
システム
イントラネットによる処 理 ，
操作応答：
容 易 な操 作 性 ，
テンプレートの使 用
３０秒
ガイダンスとヘルプ
イントラネットの代 替 パス
MTBF：１日
論 文 ファイル互 換 性
ステップ４：
要求の洗練
要 求 は獲 得 できたが，十 分 に具 体 的 なレベルにはないということが明 らか
になった．要 求 を洗 練 するために，ゴール分 割 法 が使 われ，ゴールが操 作 レ
ベルに分 解 された．その作 業 を通 して，いくつかの新 たな要 求 が発 見 され，
表 -3.3の要 求 マトリックスに追 加 された．同 様 に，ゴールは「Why？」という疑
第3章
要求獲得技法の選択
79
問 詞 によって上 位 方 向 に拡 張 され，その結 果 は，プロジェクトの承 認 を得 る
ために管 理 者 に伝 えられた．
(d) 考 察
要 求 獲 得 作 業 への要 求 者 の非 協 力 的 な姿 勢 は，要 求 技 術 者 を悩 ましている
最 も大 きな問 題 の1つである[133]．本 事 例 では，要 求 工 学 技 術 マップと状 況 変
化 への技 法 選 択 戦 略 をもとに，４つの異 なった手 法 を順 次 適 用 することによって，
危 機 的 な状 況 を回 避 することができた．技 法 選 択 の指 針 が無 ければ，プロジェク
トは破 綻 に陥 るか，不 完 全 な要 求 仕 様 に基 づいて作 成 されたプログラムに対 する
係 争 問 題 に発 展 していたかもしれない．
システム化 対 象 領 域 は限 定 的 で，サイズも小 さいので，この事 例 プロジェクトで
使 われた要 求 獲 得 技 法 の殆 どは，要 求 工 学 技 術 マップの上 半 分 に属 するもの
であった．この事 実 は，3.2.1節 の所 見 に一 致 している．問 題 領 域 は小 さく，比 較
的 閉 鎖 的 であったけれど，アプリケーションのタイプは，ソフトウェア技 術 者 にとって
はむしろ新 しかったので，彼 らには問 題 領 域 は開 いていると見 做 された．それが，
最 終 ステップで，ゴール指 向 アプローチが使 われた理 由 の1つである．しかしなが
ら，ゴール分 割 を使 った主 な理 由 は，上 で述 べたように，要 求 を操 作 レベルに詳
細 化 するためだったので，実 際 に適 用 されたゴール指 向 技 術 の性 質 は，形 式 的
あるいは制 約 的 な方 向 を指 している．この手 法 を使 ったもう１つの目 的 は，管 理 者
にプロジェクトの正 しさを示 すことであった．
プロジェクトの大 きさに較 べ，この要 求 分 析 プロセスでは，４ステップという入 念 な
方 法 が採 用 された．この４ステップというプロセスは，プロジェクトが始 まる前 には計
画 されておらず，プロセス実 行 中 の意 思 決 定 の結 果 であった．それは，3.3節 で
議 論 した状 況 変 化 による，実 際 の要 求 獲 得 プロセス遷 移 の1つの例 である．
3.4.2. 原 子 燃 料 棒 管 理 シ ス テ ム
(a) プ ロ ジ ェ ク ト の 概 要
80
第3章
要求獲得技法の選択
システムのゴールは，電 力 会 社 における核 燃 料 集 合 体 とその取 り扱 いを管 理 す
ることである．全 体 プロセスは，燃 料 倉 庫 への新 たな核 燃 料 集 合 体 の搬 入 ，検 査
とプールへの保 管 ，炉 心 への移 動 ，使 用 済 み燃 料 の破 棄 ，再 処 理 のための搬
出 から構 成 されている．システムの重 要 な機 能 は，核 燃 料 集 合 体 を処 理 するため
の一 連 の作 業 指 示 書 を生 成 することである．システムが関 心 を持 っている主 な作
業 は，製 造 工 場 から新 たな倉 庫 へ，倉 庫 からプールへ，プールから炉 心 へ，炉 心
からプールへ，プールからプールへ，プールから再 処 理 施 設 への燃 料 集 合 体 の
移 動 である．システムは，また，個 々の燃 料 集 合 体 の状 態 と位 置 に関 する情 報 を
保 持 し，それらの履 歴 を記 録 する．
作 業 計 画 立 案 者 からの一 連 の作 業 指 示 を受 け取 り，指 示 書 を出 力 している
CUIベースの古 いシステムがあった．作 業 計 画 立 案 者 は紙 上 のシミュレーションを
通 して計 画 を立 て，結 果 をシステム端 末 に入 力 していた．この作 業 は長 い時 間 を
要 するため，計 画 立 案 者 にとって多 大 な作 業 負 担 となっていた．プロジェクトの目
的 は，燃 料 集 合 体 の状 態 と位 置 をグラフィカルに示 し，作 業 計 画 立 案 者 である
ユーザによって提 供 される作 業 指 示 に従 って，その動 きをシミュレートし，検 証 さ
れた一 連 の作 業 指 示 を印 刷 する機 能 を定 義 することであった．プロジェクトへの
参 加 者 は次 の通 りである．
クライアント： 電 力 会 社 本 体 の管 理 スタッフメンバーが２名
ソフトウェア技 術 者 ： 現 行 システムを開 発 したソフトハウスから５名
問 題 領 域 の法 律 や類 似 システムに関 する知 識 を持 ったコンサルタントが１名
要 求 技 術 者 １名 （筆 者 ）
(b) プ ロ ジ ェ ク ト の 特 徴
プロジェクトの特 徴 は以 下 の通 りであった．
・ 既 に現 行 システムが稼 動 しているので，ワークフローは明 確 であり，アプリケー
ションドメインは比 較 的 安 定 している．
・ 要 求 技 術 者 のタイプは，想 像 的 というより論 理 的 である．
・ 情 報 資 源 は十 分 にある．現 行 システムとそれに関 する文 書 は，良 い情 報 資
源 であり，そこには全 てのタスクの処 理 が文 書 化 されていた．
第3章
要求獲得技法の選択
81
・ ユーザは参 加 していたが，原 子 力 設 備 が遠 隔 地 にあったため，システムの最
終 利 用 者 である作 業 計 画 立 案 者 は参 加 できない．
・ 必 要 とされる要 求 品 質 の中 で，完 全 性 と構 造 的 一 貫 性 は極 めて重 要 と考 え
られたが，操 作 の一 貫 性 と変 更 可 能 性 に関 する優 先 度 は比 較 的 低 かった．
何 故 なら，システムの振 る舞 いには殆 ど複 雑 さが無 く，作 業 プロセスの変 更
は考 えられていなかった．
(c) 要 求 工 学 プ ロ セ ス
ステップ１：
プロジェクト特性による要求工学技法の最初の選択
上 で示 したすべてのプロジェクト特 性 は，最 初 の選 択 では，左 上 象 限 の
要 求 工 学 技 法 が適 していることを示 唆 しており，第 ２の選 択 肢 として左 下 象
限 の技 法 があった．こうして，要 求 を収 集 し分 類 するためにドメイン分 割 が選
ばれた．しかし，核 燃 料 集 合 体 の取 り扱 いは，動 的 な操 作 の特 徴 も持 って
いるので，要 求 分 析 の後 半 に，右 上 象 限 の技 法 ，特 にユースケース法 を適
用 するのが良 いだろうということが予 想 された．
ステップ２：
新らたな要求
しかしながら，予 期 せぬ新 らたな要 求 が現 れた．システムの中 心 的 な目 標
は核 燃 料 集 合 体 のデータを保 持 することであったが，政 府 が電 力 会 社 に核
物 質 の在 庫 を報 告 させるための法 律 を作 ろうとしていたため，核 物 質 の在
庫 管 理 という新 機 能 をシステムに加 えるべきであるという決 定 がなされた．こ
れはシステムに異 なった性 格 を持 ち込 むことになった．その機 能 は，メンバー
にとって，よく知 られていない新 たなものであり，法 律 に関 する情 報 も不 十 分
で不 確 定 であった．この要 求 は，プロジェクトに状 況 変 化 をもたらした．
さらに，はじめに仮 定 していた要 求 を再 検 討 した結 果 ，GUIを使 って作 業
手 順 のシミュレーションを行 うという機 能 を新 たに追 加 することになり，基 本
的 に現 行 システムの踏 襲 を前 提 としていた当 初 の機 能 に比 較 して，異 なっ
た性 格 をもつことになった．その結 果 ，次 の３つの機 能 局 面 が顕 になった．
燃料集合体操作局面
82
第3章
要求獲得技法の選択
シミュレーション局 面
核物質在庫管理局面
燃 料 集 合 体 操 作 局 面 は，元 々予 想 されたのと同 じプロジェクトの性 質 を
保 持 しているが，シミュレーション局 面 は，新 たな機 能 として導 入 されたので，
その位 置 を要 求 工 学 技 術 マップの下 方 向 に移 動 すると考 えられた．こうして，
これらの局 面 を分 析 するために，最 初 にブレーンストーミング，次 にプロトタイ
ピングを追 加 することが決 定 された．核 物 質 在 庫 管 理 は，導 入 される機 能
が全 体 的 に新 しいので下 方 向 への移 動 が考 えられたが，要 求 は論 理 的 で
静 的 であったため左 舷 域 に止 まったままであった．こうして，ブレーンストーミ
ングを使 ってこの局 面 の分 析 を始 め，ドメイン分 割 と論 理 的 分 析 を続 けるこ
とが決 定 された．
ステップ３：
操作指示語の新たな課題
この時 点 で，燃 料 集 合 体 の操 作 の中 核 局 面 に新 たなアイデアが導 入 さ
れた．コンサルタントによって提 案 されたそのアイデアは，操 作 指 示 語 セット
の変 更 であった．古 い指 示 語 セットは，基 本 的 な操 作 指 示 語 から構 成 され，
単 一 の燃 料 集 合 体 に対 する単 一 の操 作 指 示 であった．提 案 された新 しい
指 示 語 セットは，複 数 の基 本 的 指 示 語 を組 み合 わせた複 合 指 示 語 から構
成 され，操 作 計 画 立 案 タスクの効 率 を高 めることが期 待 された．同 様 の指
示 語 を使 用 している他 の電 力 会 社 の類 似 システムでの成 功 例 も説 明 され
た．
しかし，この提 案 はクライアントに受 け入 られなかった．ユーザは不 慣 れな
指 示 語 を使 うことを嫌 うかもしれないという懸 念 が生 じ，さらに，基 本 指 示 語
は，設 計 された操 作 指 示 列 の微 調 整 に必 須 であるということが判 明 した．ま
た，クライアントは同 業 他 社 の仕 様 を受 け入 れることを嫌 い，独 自 の指 示 語
セットを欲 した．
これは，一 種 のステークホルダ間 の要 求 の矛 盾 という状 況 である．矛 盾 を
解 消 するために，3.2.5節 のガイドラインに沿 ってゴール指 向 アプローチが使
われた．その結 果 ，提 案 された複 合 指 示 語 セットが採 用 されたが，クライアン
トの懸 念 を和 らげるために古 い基 本 指 示 語 も残 すことにした．この時 点 で要
第3章
要求獲得技法の選択
83
求 工 学 プロセスにおけるユーザの不 在 が重 大 な問 題 として顕 在 化 した．ゴ
ール指 向 分 析 を実 施 している間 ，要 求 チームは遠 隔 地 の核 設 備 にいる最
終 利 用 者 の意 見 を聞 かなければならず，その回 答 は通 常 一 週 間 遅 れで報
告 された．あらゆる要 求 工 学 プロセスが遅 れ出 した．
ステップ４：
ユースケース分析
ステップ３の結 論 が最 終 ユーザによって承 認 された後 ，燃 料 集 合 体 の操
作 局 面 に関 する要 求 工 学 プロセスには，ステップ１で予 想 されたように，ユー
スケースアプローチが実 施 された．チームの内 の3人 のメンバーがユースケー
スを記 述 したが，２００個 ほどの大 量 のユースケースが作 られ，作 業 はスケジ
ュールされた期 間 内 には終 わらないと思 われた．さらに，記 述 されたユースケ
ースのスタイルと粒 度 が，記 述 者 によって相 当 に異 なっていた．この問 題 を
解 決 するために，いくつかのユースケースに共 通 のパターンを抽 出 し，具 体
的 なユースケースを記 述 するときのテンプレートとしてそれらを利 用 することに
した．[移 動 －検 査 －移 動 ]といった指 示 語 の典 型 的 な組 み合 わせがパター
ンとして抽 出 され，位 置 と場 所 といった指 示 の対 象 をパラメータ化 した．この
解 決 法 は，大 量 の情 報 を，ドメイン分 割 によって分 類 するという規 則 の適 用
と考 えることもできる．
(d) 考 察
本 事 例 の特 徴 はプロジェクトの状 況 が時 々刻 々変 化 していることで，プロジェク
トが使 用 する技 法 や戦 略 は，時 宜 に応 じて変 化 させなければならない．それぞれ
の状 況 とそこで発 生 した問 題 ごとに，要 求 工 学 技 法 マップと技 法 選 択 戦 略 知 識
が使 用 されることになる．プロジェクトの発 足 時 に，適 用 可 能 な技 法 の候 補 を選
択 することができたので，その後 の具 体 的 な要 求 分 析 戦 略 を立 案 することが可 能
であった．また，クライアント間 の要 求 の矛 盾 やスケジュールの遅 延 といった状 況
の変 化 が認 識 されたときには，マップとそれに関 連 付 けられたガイドラインを使 用
することは特 に役 に立 った．さらに，要 求 獲 得 作 業 だけでなく，複 合 局 面 の出 現
時 に局 面 を分 析 するための手 法 を選 択 するのにも有 効 であった．
通 常 ，１つの手 法 には複 数 の機 能 が含 まれており，個 々の機 能 に着 目 すれば，
84
第3章
要求獲得技法の選択
手 法 の適 用 範 囲 は格 段 に拡 大 することになる．しかし，それぞれの手 法 には，そ
れぞれ独 自 の目 標 があり，適 切 な条 件 下 での使 用 によって最 も有 効 な効 果 を発
揮 する．手 法 の単 純 な機 能 比 較 [93]からは，適 切 な適 用 条 件 を想 定 することは
難 しい．プロジェクトの戦 略 に手 法 を対 応 付 けようとする方 法 もあるが[99]，手 法
の全 体 像 を見 渡 すことができず，また，集 約 された戦 略 によって手 法 選 択 の幅 が
限 られてしまう．要 求 工 学 技 術 マップは，適 用 対 象 の特 徴 と処 理 の特 徴 という２
つの視 点 から手 法 の全 体 像 を示 すとともに，手 法 同 士 の相 対 的 関 係 を視 覚 的
に示 している．このプロジェクトの要 求 分 析 プロセスを通 して，要 求 工 学 技 術 マッ
プが適 切 な要 求 工 学 技 法 の選 択 をガイドするのに効 果 のあることが検 証 された．
（ｄ）その他の知見
この事 例 研 究 で学 んだ重 要 なことの1つは，システムは複 数 の局 面 を持 ってい
て，システムを局 面 によって特 徴 付 けるか，個 々の局 面 に対 する特 別 の性 質 を考
えることが役 に立 つということである．また，技 法 の選 択 は，機 械 的 にはゆかない．
システムの特 徴 とその環 境 は一 意 ではないし，プロジェクトの特 徴 から要 求 工 学
技 術 への対 応 付 けは，代 替 選 択 のための余 地 を残 しておかなければならない．ま
とめれば，フレームワークはこのプロジェクトの要 求 技 術 者 に，チームをガイドし，他
の参 加 者 を納 得 させる上 での多 くの自 信 を与 えることができたといえる．
3. 5. 関 連 研 究
この研 究 と似 た目 標 を持 った研 究 はそう多 くはないが，その中 で，A.Hickey &
A.Davis と N.Maiden & G.Rugg の研 究 は，関 連 が強 い．Hickey & Davis は，
９人 の高 名 な専 門 家 へのインタビューを行 い，彼 らがどのように要 求 獲 得 を行 った
かを訊 ねている[62]．インタビューのスタイルは制 約 が無 く，インタビューごとに大 き
く異 なっている．彼 らが問 題 にどのように取 り組 んでいるかということに対 する回 答
を提 供 するために，短 文 で記 述 された比 較 的 曖 昧 で，意 図 的 な４つの状 況 が，イ
ンタビューアーに提 示 された．結 果 は，１）技 法 を使 う時 期 ，２）４つの状 況 への一
般 的 な回 答 ，３）その他 の情 報 ，としてまとめられた．調 査 は興 味 深 く，役 に立 つ
情 報 を提 供 しているが，要 求 技 術 とプロジェクト状 況 の関 係 は明 らかにされず，バ
第3章
要求獲得技法の選択
85
ラバラに議 論 されている．Maiden & Rugg の研 究 は，より体 系 的 である[93]．１２
種 類 の要 求 獲 得 技 法 が選 ばれ，要 求 の目 的 ，知 識 のタイプ，知 識 の内 部 フィル
タリング，観 察 可 能 な現 象 ，獲 得 文 脈 ，手 法 の相 互 依 存 性 という６つの側 面 から
比 較 されている．結 果 は，相 互 依 存 性 を除 く５つの側 面 に関 する５つの表 によっ
て表 わされ，表 のそれぞれのエントリーはチェックまたは表 象 的 重 みを表 している．
提 案 されたフレームワークは，要 求 獲 得 技 法 を選 択 するときに使 われるこれらの
表 を含 んでいる．これらは，選 択 時 のチェックリストとして役 に立 つが，事 例 の報 告
が無 い．
いくつかの論 文 は，似 たようなトピックスを扱 っているが，その目 標 あるいはアプロ
ーチは本 研 究 のものとは相 当 に異 なっている．S.Yadav らは，要 求 分 析 技 法 の
ための比 較 フレームワークを提 案 しているが，彼 らが比 較 したのは，要 求 分 析 の
後 半 に使 われると思 われる DFD と IDEF０ であった[148]．
似 たような目 標 を持 った，偶 発 的 アプローチを扱 ったいくつかの研 究 もある．例
えば，J.Naumann らは，偶 発 的 アプローチに基 づいてプロジェクト状 況 を要 求 確
定 戦 略 に結 び付 けている[99]．そこには我 々の意 図 との類 似 性 がある．しかし，
我 々のアプローチが獲 得 フェーズに焦 点 を当 てているのに対 し，その対 象 プロセ
スは要 求 定 義 である．C.Sullivan も偶 発 的 アプローチを取 り上 げており，情 報 シ
ステム計 画 戦 略 全 体 を対 象 としている[135]．
他 の強 力 なアプローチは，メソッド工 学 をもとにしている．G.Vlasblom らは，プロ
ジェクトの状 況 プロファイルによって開 発 手 法 を決 定 している［146]．T.Punter &
K.Lemmen も，手 法 を問 題 特 性 に一 致 させている[114]．V.Savolainen は，組
織 的 情 報 システムの開 発 のための参 照 フレームワークを提 案 している[125]．我 々
のアプローチが要 求 フェーズに焦 点 を当 てているのに対 し，これらのアプローチに
共 通 した目 標 は，開 発 手 法 の選 択 である．彼 らは，設 計 ，実 装 ，検 証 プロセスを
含 む開 発 プロセス全 体 をカバーしようとしている．
E.Hudlicka は，知 識 工 学 と認 知 科 学 の視 点 から要 求 獲 得 技 法 を比 較 してい
る[65]．そこでは，レパートリーグリッド分 析 ，多 次 元 スケーリング，階 層 化 クラスタリ
ングという3つの知 識 獲 得 技 法 が選 ばれ比 較 されている．これらの技 法 は，要 求
獲 得 に直 接 的 な関 係 はないが，情 報 の創 作 や分 類 技 術 を扱 っているので，要
求 工 学 技 術 マップの右 下 から左 上 への対 角 線 上 に配 置 することができる．これら
の３つの技 法 は，航 空 機 の安 全 性 検 査 という文 脈 の中 での比 較 によって知 見 を
86
第3章
要求獲得技法の選択
得 ているが，それらがシステム要 求 を獲 得 するのにどのように使 われたかということ
は明 確 に議 論 されていない．
J.Coughlan & R.Macredie は要 求 獲 得 プロセスのコミュニケーションを強 調 して
いる[31]．その結 果 ，彼 らはMUST，Joint Application Design(JAD)，User-Led
Requirements Construction(ULRC)，Soft Systems Methodology (SSM) といっ
たユーザ参 加 型 方 法 論 を比 較 している．本 研 究 とこれらのアプローチの違 いは，
手 法 タイプの選 択 だけでなく，彼 らの焦 点 が技 法 ではなく方 法 論 であるという点 に
もある．ブレーンストーミング，シナリオ，などのレベルの技 法 は，それぞれの方 法
論 に採 用 されているが，共 有 されているものもあれば，共 有 されていないものもあ
る．
M.Bergman & G.Mark は，高 レベルで要 求 を扱 っているために，プロジェクトが
要 求 を決 定 するという通 常 の事 例 とは異 なり，要 求 がプロジェクトを選 定 している
[9]．NASAのプログラムが分 析 されている．そこでは，多 くのプロジェクトが提 案 さ
れ，問 題 はNASAの高 レベルの要 求 を満 足 する適 切 なプロジェクトのセットを発 見
することであった．確 かに，そのような高 レベルの要 求 も分 析 され決 定 されなけれ
ばならず，それは論 文 の興 味 ある部 分 ではあるが，本 論 文 の目 標 とは異 なる．
A.Padula は， Hewlett-Packard での要 求 工 学 プロセスを選 択 する実 例 を報
告 している．獲 得 技 術 の視 点 ではなく，要 求 工 学 プロセスのために，２つのプロジ
ェクトが比 較 されている[108]．
3. 6. 考 察
要 求 獲 得 技 法 の全 体 像 を，2つの特 徴 軸 による座 標 空 間 によって表 現 し，同
一 の位 相 空 間 上 のプロジェクト特 性 を写 像 するという方 法 は，上 に示 した事 例 に
よって一 定 の効 果 があることが検 証 された．
しかし，我 々の意 図 は，すべての要 求 技 術 者 がマップ上 のすべての手 法 を知 る
べきであるといっているわけではない．要 求 技 術 者 が要 求 工 学 技 術 マップから得
ることのできる最 初 の効 果 は，彼 らが知 っている手 法 の位 置 を知 ることである．そ
れぞれの技 術 者 は，それぞれの象 限 内 の少 なくとも１つの手 法 については，よく知
っていることが望 まれる．たとえそうでは無 い場 合 にも，知 らない技 法 はチームの他
第3章
要求獲得技法の選択
87
のメンバーによってカバーされるだろう．さらに，よく知 らない技 法 の特 徴 も，既 知
の技 法 との相 対 的 な位 置 関 係 から，簡 単 に捕 まえることができ，学 習 を助 けるだ
ろう．
この研 究 の結 果 は，要 求 選 択 のフレームワークをシステマティックに使 うための
チェックリストあるいは規 則 のセットとして使 用 されるのが望 ましい．実 際 のプロジェ
クトにフレームワークを適 用 する中 で，チェックリストを使 って経 験 を積 むということ
は良 いことである．
88
第3章
要求獲得技法の選択
第 ４ 章
要求モデルの連携
プ ロ ジ ェ ク ト の 状 況 の 変 化 や [ 1 9 ] ， ステ ー ク ホル ダ 間 の 観 点 （ pe r s p e c t i v e） の 相
違 [ 4 9 ] に 対 応 す る た め に ， 要 求 分 析 者 は ， 異 なっ た 手 法 を 選 択 し ， 異 な っ た 要 求
モ デル を 作 成 す る こ と に な る ． し か し ， 要 求 変 更 が 発 生 す る と ， プ ロ ジ ェク ト は ， 作 成
済 みの関 連 する要 求 モデル同 士 の間 で矛 盾 がないように調 整 しなければならない．
こ れ をモ デ ル の 一 貫 性 の 保 証 と 呼 ぶ ．
モ デル の 一 貫 性 を 保 障 す る には ， モ デル 同 士 の 連 携 が 必 要 に な る ． 複 数 の モ デ
ル の 一 貫 性 を 保 と う と す る 研 究 は ， 主 に ， 要 求 追 跡 の 領 域 で 議 論 さ れ て きた [ 78 ] ．
し か し ， 要 求 追 跡 は ， 要 求 モ デ ル か ら 設 計 モ デル と い う よ う に , 形 式 論 的 な 変 換 に
よ っ て 作 成 さ れ たモ デ ル 同 士 を 順 次 追 跡 し て ゆ く も ので ， 同 一 対 象 に 対 す る 視 点
の 違 い を 問 題 と し て い る 要 求 モ デ ル 同 士 の 連 携 と は ， そ の 意 味 が 異 なる ．
メ ソッ ド 工 学 では ， 新 た なモ デ ルを 作 成 す る と き の 要 求 モ デル 同 士 の 一 貫 性 の 保
証 に 焦 点 を 当 て て お り ， 要 求 変 更 時 の モ デ ル の 変 更 に つ い ては ， あ ま り 議 論 さ れ
て いな い [1 9 , 102 ] ． し か し ， 既 存 モ デル の 変 更 では ， 異 な った モ デル 同 士 の 一 貫
性 の 保 障 に 加 え ， 変 更 に よ る 同 一 モ デル 内 の 影 響 箇 所 を 探 し 出 し ， 修 正 し な け れ
ばならず，新 たなモデルの作 成 よりも，遥 かに困 難 な作 業 であることが多 い．
異 な っ たモ デル 同 士 の 一 貫 性 の 保 証 と い う 作 業 を ， ソ フ ト ウェ ア 構 成 管 理 ツ ー ル
など を 使 っ て 支 援 し よ う と い う 試 み も 行 わ れ て きた [ 4 5 ] ． 確 かに ， 多 く の 構 成 管 理 ツ
ール は ， ソフ ト ウ ェ ア の 版 管 理 と い う 問 題 で は 効 果 を 挙 げ て いる [ 5 5 ] ． し かし ， モ デ
ル 自 身 の 変 更 の 支 援 に ま で 踏 み 込 ん で いる 例 は 少 な い ． 本 論 文 で は ， 要 求 変 更
時 に ， 関 連 す る 要 求 モ デル 同 士 の 間 で 変 更 箇 所 を 特 定 し ， 同 一 モ デル 内 で の 2
次 的 な 影 響 の 予 測 を 支 援 す る た め の フレ ー ム ワ ーク を 提 案 す る ．
90
第4章
要求モデルの連携
4.1. 要 求 モ デ ル 連 携 の 枠 組 み
メ ソッ ド 工 学 は ， 異 な っ たモ デ ル の 間 の 一 貫 性 を 保 証 す るた め の いく つ か の 機 構
を 提 案 し て いる が [ 19 ， 51 ] ， そ れ ら の 多 く は ， モ デル 記 述 言 語 上 の 制 約 条 件 に も と
づ いた ， モ デル 構 成 要 素 同 士 の 存 在 制 約 に 関 す る 形 式 論 的 な 一 貫 性 を 保 証 し
よ う と い うも の で ある ． し か し ， 要 求 変 更 に 伴 っ て 変 更 を 受 けた 要 求 モ デル では ， モ
デル の 構 造 や 属 性 が 変 更 さ れ る だ け でな く ， モ デル が 表 現 し よ う と し て いた 対 象 領
域 そ の も の の 意 味 ま で が 変 更 さ れ て し ま う こ と が あっ た ． 要 求 モ デ ル の 変 更 時 に 保
証 し な け れ ば な らな い のは ， 異 な った 要 求 モ デル 同 士 の 形 式 論 的 一 貫 性 と 意 味
論 的 一 貫 性 で ある ．
形式論的一貫性
モデルとは，問 題 領 域 の抽 象 であり，多 くのモデル化 技 法 は抽 象 化 された対
象 を表 現 するのに図 式 を使 っている．図 式 で使 用 する図 形 の表 記 上 の意 味 は，
それぞれのモデル記 述 言 語 によって定 義 されている．したがって，特 定 のモデル
記 述 言 語 の規 約 に則 って記 述 されたモデルは，形 式 論 的 に唯 一 の解 釈 が可
能 で ある ． 一 方 ， 異 な っ た モ デル 記 述 言 語 を 使 用 し て 作 成 し た モ デ ル 同 士 の 間
では，問 題 領 域 内 の同 一 の対 象 が，異 なった図 式 によって表 現 されることにな
る．しかし，同 一 問 題 領 域 内 の同 一 対 象 は，表 記 法 が異 なっても，意 味 的 に同
一 の も の で あ る ． 複 数 の モ デ ル 記 述 言 語 か ら 構 成 さ れ て い る U ML で は ， モ デ ル
の表 記 法 上 の相 違 を，メタモデルによって形 式 論 的 に統 一 し，それらの一 貫 性
を 保 証 し よ う と し てい る ．
意味論的一貫性
モデル記 述 言 語 は，モデルの記 法 上 の制 約 を規 定 してはいるが，記 述 対 象
の意 味 までは規 定 していない．モデルによって表 現 された対 象 世 界 の意 味 ，す
なわち，モデルの意 味 論 は，モデル作 成 者 によって定 義 される．同 一 の問 題 領
域 に対 する異 なったモデル同 士 の間 では，形 式 論 的 な一 貫 性 とともに，意 味 論
的 な 一 貫 性 を 保 障 す る こ とも 重 要 で ある ．
第4章
要求モデルの連携
91
要 求 モ デ ル を 変 更 す る 場 合 に 保 証 し な け れ ば な らな い 一 貫 性 に は ， モ デル 同 士
の 一 貫 性 と ， モ デル 自 身 の 一 貫 性 が ある ． モ デル の 一 貫 性 を 保 証 す る には ， モ デ
ル 同 士 の 連 携 が 必 要 と なる ． モ デ ル 連 携 は ， 外 部 連 携 と 内 部 連 携 に 分 け ら れ る ．
外 部 連 携 は ， 異 な っ た 要 求 モ デ ル 同 士 の 連 携 で あり ， 内 部 連 携 は ， 同 一 モ デル
内 の モ デ ル 構 成 要 素 同 士 の 連 携 で ある ．
外部連携
モデルの外 部 連 携 には，２つのレベルの連 携 がある．1つはモデルの変 更 に
際 し，変 更 を同 期 させる必 要 のある他 のモデルを特 定 するための連 携 で，もう１
つは特 定 されたモデル同 士 の間 で，変 更 対 象 となるモデル構 成 要 素 同 士 を特
定 するための連 携 である．作 業 の進 捗 によって複 数 の版 が存 在 しているモデル
もあれば，1つのモデルが複 数 に分 割 して描 かれている場 合 もある．まず，変 更
が行 われたモデルから，連 携 するモデルを探 し，次 に，変 更 対 象 となるモデル構
成 要 素 を特 定 する．外 部 連 携 には，モデル記 述 言 語 の規 約 に基 づく形 式 論
的 な 連 携 と ， 対 象 問 題 領 域 に 依 存 し た 意 味 論 的 な 連 携 が ある ．
内部連携
モデルは複 数 のモデル構 成 要 素 によって構 成 されており，１つのモデルの中
で，モデル構 成 要 素 同 士 は，複 雑 に関 連 しあっている．あるモデル構 成 要 素 を
変 更 すると，その影 響 が他 のモデル構 成 要 素 に伝 播 し，モデル全 体 に広 がっ
てゆく．２次 的 な変 更 箇 所 を特 定 するために，同 一 モデル内 での影 響 追 跡 を行
う．影 響 追 跡 のための内 部 連 携 は，モデル構 成 要 素 同 士 の連 携 である．内 部
連 携 に も ， 形 式 論 的 な 連 携 と 意 味 論 的 な 連 携 が ある ．
複 数 の 異 な った 要 求 モ デル を 採 用 し てい る プ ロ ジ ェク ト で の ， モ デル 連 携 を 使 用
した 基 本 的 な 要 求 変 更 作 業 は ， 次 の 通 り で あ る ．
1. 要 求 変 更 が 発 生 し た ら ， 要 求 分 析 者 は ， 要 求 モ デ ル を 使 用 し て 変 更 箇 所
を確 認 する．どの要 求 モデルを使 用 するかは，変 更 が手 続 き的 なものに対 す
るものか，構 造 的 なものに対 するものかによって判 断 し，変 更 箇 所 が確 認 で
きたら， 該 当 の 要 求 モデルに 必 要 な 変 更 を 施 す．
92
第4章
要求モデルの連携
2. モ デ ル の 外 部 連 携 に よ り ， 変 更 が 必 要 な 他 の 要 求 モ デ ル の 変 更 箇 所 を 特
定 する．特 定 された要 求 モデルの変 更 方 法 を検 討 し，形 式 論 的 一 貫 性 と意
味 論 的 一 貫 性 を 保 証 す るため に， 必 要 な 変 更 を 施 す．
3. モ デ ル の 内 部 連 携 に よ り ， 変 更 が 施 さ れ た そ れ ぞ れ の 要 求 モ デ ル 内 で ， ２
次 的 な影 響 を受 ける可 能 性 のある箇 所 を特 定 する．変 更 の必 要 性 と変 更
方 法 を検 討 し，形 式 論 的 一 貫 性 と意 味 論 的 一 貫 性 を保 証 するために，必
要 な 修 正 を 施 す．
4.2. モ デ ル 連 携 の 構 造
モ デル の 変 更 や 修 正 に は ，モ デ ル 記 述 言 語 や 問 題 領 域 に 対 す る 知 識 が 必 要 と
さ れ るた め ， モ デル の 変 更 作 業 は ， こ れ ま で ， そ の モ デル を 作 成 し た 技 術 者 に 任 さ
れ る こ と が 多 か っ た [ 1 3 3 ] ． し か し ， た と え 十 分 な 知 識 を もっ て いた と し ても ， 人 手 に
よ る 作 業 に はミス が つ き も ので あり ， ま た ， 該 当 モ デル の 作 成 者 が い つ ま でも 保 守
作 業 に 携 わ って い る とは 限 ら な い ． そ こ で 求 め ら れ る のは ， モ デル の 変 更 に 伴 っ て
発 生 す る モ デル 間 の 矛 盾 箇 所 を 指 摘 し て く れ る 機 能 で ある ．
本 節 で は ， 具 体 的 な モ デル の 変 更 実 験 の 結 果 を 通 し て ， 異 な っ た 要 求 モ デ ル の
変 更 に 必 要 な 知 識 と そ の 構 造 を 検 討 す る ． こ の 実 験 に 使 用 し た ア プ リ ケー シ ョ ン は ，
3 .4 . 1 節 の 事 例 研 究 で 用 い た 社 内 研 究 発 表 会 支 援 シ ステ ム で ある ． 企 業 内 研 究
発 表 会 の 事 務 局 を 支 援 す る た め の シス テ ム を ， 国 際 会 議 の プ ロ グ ラ ム 委 員 長 の 業
務 を 支 援 す るシ ス テ ム に 変 更 し ， 要 求 モ デ ル の 変 更 箇 所 を 洗 い 出 し ， そ れ を 解 析
した ． 主 な 要 求 変 更 は ， 以 下 の 通 り で あ る ．
・ 社 内 組 織 上 の ス テ ー ク ホル ダ の 削 除
・ 学 会 事 務 作 業 部 門 の追 加
・ 承 認 に関 する社 内 手 続 きの削 除
・ 入 選 論 文 の審 査 方 法 の変 更
・ 論 文 審 査 に 併 設 さ れ て いる プ ロ グラ ム コ ン テ ス ト の 削 除
・ 上 記 変 更 に伴 う事 務 作 業 の追 加 ・削 除 ・変 更
第4章
要求モデルの連携
93
実 験 に使 用 したモデルは以 下 の５つのモデルである．ゴール指 向 モデル以 外 は，
モ デル を 記 述 す る た め に U ML の 図 式 を 使 用 し た ．シ ナ リ オ を 除 く モ デ ル の 実 験 結
果 を ， 図 - 4 . 1 か ら 図 -4 . 4に 示 す ． 変 更 箇 所 を 示 す た め に ， 変 更 前 と 変 更 後 の モ デ
ルを オ ーバ ー ラッ プ さ せ て いる ． そ れ ぞ れ の 図 中 で ， × 印 は 削 除 さ れ た モ デル 構 成
要 素 ， ○ 印 は 変 更 さ れ たモ デ ル 構 成 要 素 ， △ 印 は 追 加 さ れ たモ デ ル 構 成 要 素 を
示 す ． な お ， こ の モ デ ルで は ，モ デル 連 携 に よ る 変 更 箇 所 と ， 影 響 追 跡 に よ る 変 更
箇 所 を同 時 に示 してある．
ゴール指向モデル
（ 図 - 4. 1 ）
ゴール指 向 分 解 によってシステムに必 要 な機 能 を導 出 する．ここではシステム
化 の目 的 をゴールに設 定 している．図 式 は，KAOS[87]の記 法 に従 っている．こ
の技 法 は，要 求 工 学 技 術 マップの左 下 象 限 のゴール指 向 技 法 に属 する．
オ ブ ジ ェ ク ト モ デ ル （ 図 - 4. 2 ）
問 題 領 域 の静 的 な構 造 を表 現 するためのモデルで，UMLのクラス図 によって
記 述 する．この技 法 は，要 求 工 学 技 術 マップ（第 3章 ）の左 上 象 限 のドメイン分
割 技 法 に属 する．
ユ ー ス ケ ー ス モ デ ル （ 図 - 4. 3 ）
機 能 要 求 を直 接 モデル化 したモデルで，オブジェクトモデルとは独 立 に作 成
さ れ る ． 使 用 し た 図 式 はU M L の ユ ー ス ケー ス 図 で ある ． ユ ース ケー ス 法 は 要 求 工
学 技 術 マ ッ プ の 右 上 象 限 の シ ナ リ オ ベー ス 技 法 に 属 す る ．
シナリオ
ユースケースモデルのそれぞれのユースケースごとに，テキスト形 式 のシナリオ
が記 述 されている．シナリオはモデルではないが，本 論 文 では，シナリオを構 造
化 し，モデルと同 様 に扱 えるようにしている．シナリオは，右 上 象 限 のシナリオベ
ース 技 法 に 属 す る ．
メ ッ セ ー ジ シ ー ケ ン ス モ デ ル （ 図 - 4. 4 ）
問 題 領 域 の動 的 な振 る舞 いを表 現 するためのモデルで，オブジェクトモデル
と シ ナ リ オ を も と に 作 成 さ れ て い る ． 図 式 は ， U ML の シ ー ケ ン ス 図 を 使 っ て 記 述 し
てある．この手 法 も，要 求 工 学 技 術 マップの右 上 象 限 のシナリオベース技 法 に
属 する．
94
第4章
要求モデルの連携
本 実 験 に よ って 判 明 し たこ と は 次 の 通 り で あ る ．
・ 通 常 の要 求 追 跡 では，要 求 仕 様 書 から設 計 仕 様 書 といった異 なった文 書 間
での追 跡 関 係 が必 要 となる．しかし，要 求 モデル同 士 の連 携 では，要 求 モデ
ルは要 求 仕 様 書 に記 述 されているので，文 書 間 の連 携 は必 要 ではない．た
だし，要 求 仕 様 書 が複 数 に分 冊 されている場 合 は，文 書 間 連 携 も必 要 となる
場 合 が ある ． し か し ， 文 書 間 連 携 に つ いて は ， 本 論 文 で は 扱 わ ない ．
・ 形 式 論 的 一 貫 性 を 保 証 す る た め の 外 部 連 携 は ， U ML の よ う に ， 異 な っ た モ デ
ル記 述 言 語 同 士 の間 にメタモデルが定 義 されている場 合 は，規 則 の形 式 で
比 較 的 容 易 に定 義 することができる．しかし，ゴール指 向 モデルとUMLのモデ
ルのように，独 立 したモデル記 述 言 語 同 士 の場 合 は，連 携 が必 要 なモデル
同 士 を特 定 し，外 部 連 携 規 則 を作 成 するためのメタモデルないし変 換 ルール
を定 義 する必 要 がある．しかし，いずれの場 合 も，連 携 規 則 によって支 援 でき
る のは ， 形 式 論 的 一 貫 性 だ け で ある ．
・ 意 味 論 的 一 貫 性 を保 証 するための外 部 連 携 は，モデル作 成 者 の意 図 を理
解 しなければならないため，モデル記 述 言 語 にもとづいた外 部 連 携 規 則 によ
って記 述 することは困 難 である．モデル作 成 者 の意 図 を汲 むのに有 効 なのは，
実 際 の モ デ ル 上 で ， 依 存 関 係 を 使 っ て 連 携 を 記 述 す る 方 法 で ある ． こ の 依 存
関 係 は ， U ML で 定 義 さ れ て いる も の で ある が ， U ML 以 外 に も 適 用 可 能 で ある ．
・ 形 式 論 的 一 貫 性 を保 証 するための内 部 連 携 は，モデル記 述 言 語 の規 約 を
規 則 化 することによって容 易 に記 述 できる．影 響 分 析 はこの規 則 を使 って，
修 正 箇 所 を予 測 する．しかし，意 味 論 的 一 貫 性 を保 証 するために，モデル構
成 要 素 ご と に あら ゆ る 影 響 の 可 能 性 を 洗 い 出 す こ と は 不 可 能 に 近 い ．
・ テキスト形 式 であるシナリオの場 合 は，1つのシナリオをモデルと考 えて，その
中 の１つ１つの文 をモデル構 成 要 素 とすることによって，モデルと同 等 に扱 うこ
と が でき る ．
こ れ ら の 知 見 を も と に ， 一 貫 性 保 証 の た め の モ デル 連 携 の 記 述 方 式 を 提 案 す る
する．
第4章
95
要求モデルの連携
図 - 4 . 1 ゴ ール 指 向 モデル
図 - 4 . 2 オ ブ ジ ェク ト モ デ ル
96
第4章
図 -4.3 ユースケースモデル
図 -4.4 メッセージシーケンスモデル
要求モデルの連携
第4章
要求モデルの連携
97
4.3. モ デ ル 連 携 の 記 述 方 式
モ デル 連 携 は ， 互 い に 一 貫 性 を 保 証 し 合 う 必 要 の あ る 要 求 モ デ ル 同 士 の 関 係
で ， 外 部 連 携 と 内 部 連 携 と が ある ． 記 法 の 制 約 条 件 に も と づ く 形 式 論 的 一 貫 性
保 証 の た め の 連 携 は ， 厳 密 な 記 述 が 可 能 な 連 携 規 則 に よ って 記 述 す る ． 一 方 ，
作 成 者 の意 図 を含 む意 味 論 的 一 貫 性 を保 証 するための外 部 連 携 の記 述 には，
モ デル そ の も のを ベ ー スと し た 連 携 依 存 関 係 を 使 用 す る ． し か し ， 内 部 連 携 の 記
述 は ， 作 業 負 荷 の 割 り に 効 果 が 少 な い ので 実 施 し な い ．
4.3.1. 形 式 論 的 一 貫 性 の 保 証
モ デル 連 携 規 則 で は ， 変 更 の 対 象 と な る モ デル 構 成 要 素 と と も に ， そ れ ぞ れ の
モ デル 記 述 言 語 上 の 制 約 条 件 を もと に ， 削 除 ・ 修 正 ・ 追 加 と い う 変 更 操 作 の タ イ
プと ， 必 須 ・ 可 能 ・ 不 要 と い う 変 更 の 必 要 性 の レベ ルも 表 現 す る こ と でき る ．
こ こ に 示 し た 規 則 は ， 個 別 の モ デ ル のた め の テ ン プレ ー ト で あ る ． 末 端 ク ラ ス 以 外
に も 具 象 ク ラス の 存 在 を 認 め た り ， 属 性 を 公 開 し て ， 他 の ク ラス から の 直 接 の ア ク セ
スを 許 可 し た り ， 具 象 ユ ース ケー スを 共 有 ユ ース ケ ー ス と し て 使 用 し た り ， あ るい は
境 界 オ ブ ジ ェク ト や 制 御 オ ブ ジ ェ ク ト とい った ア プ リ ケ ー シ ョ ン ・ ア ー キ テ ク チ ャ に 依
存 し た ク ラス を 採 用 す る など と い った ， モ デリ ン グ 言 語 上 で は 規 定 さ れ て い ない モ デ
ル作 成 上 の作 法 の違 いによって，異 なった規 則 が生 成 される場 合 があるが，ここで
は 考 慮 し て い ない ． そ う した モ デ ル 化 作 法 の 違 い は ， こ の テ ン プレ ー ト の 規 則 の 追
加 や 変 更 に よ っ て 対 処 す るこ と が 可 能 で あ る ．
(ａ ) 外 部 連 携 規 則
実 験 で 使 用 し た ５ つ の モ デル 間 の 連 携 関 係 の 基 本 構 造 は ， 以 下 の 通 り で あ る ．
・ オブジェクトモデルのステークホルダ･クラスと，それに該 当 するユースケースモ
デル の ア ク タ ー の 生 滅 は 連 動 す る ．
・ オブジェクトモデルのクラスと，それに該 当 するメッセージシーケンスモデルのオ
ブジェクトの生 滅 は連 動 する．
98
第4章
要求モデルの連携
・ ユースケースモデルのアクターと，それに該 当 するメッセージシーケンスモデル
のアクターの生 滅 は連 動 する．
・ ユ ース ケ ー ス の 生 滅 に した が っ て ， そ れ に 対 応 す る シ ナ リ オ も 生 滅 す る ．
・ ユ ース ケ ー ス モ デ ル に お ける ア ク タ ー の 生 滅 は ， シ ナ リ オ に 変 更 を 与 え る ．
・ シ ナリ オ の 変 更 と ， メ ッ セ ージ シ ー メ ン ス モ デ ル の 変 更 は 連 動 す る ．
・ ゴール指 向 モデルに対 する形 式 論 的 一 貫 性 を保 証 するための外 部 連 携 規
則 は存 在 しない．
オ ブ ジ ェク ト モ デル と ユ ース ケ ー ス モ デル に お け る 外 部 連 携 規 則 の 例 を 示 す ．
図 - 4 .5 オ ブジェク トモ デルの 外 部 連 携 規 則
図 - 4 .6 ユ ースケ ース モデルの 外 部 連 携 規 則
第4章
要求モデルの連携
99
（ｂ）内部連携規則
形 式 論 的 一 貫 性 を 保 証 す る た め の 内 部 連 携 規 則 は ， そ れ ぞ れ の モ デル 記 述 言
語 の 規 約 に もと づ い て いる ． 以 下 に 示 す の は ， オ ブジ ェク ト モ デル と ユ ース ケ ー ス モ
デル の 内 部 連 携 規 則 で あり ， そ れ ぞ れ U M L の 規 約 を 使 用 し てい る ．
オブジェクトモデル内部連携規則（クラス図）
ク ラ ス 図 に よ って 記 述 さ れ る オ ブジ ェク ト モ デル の 内 部 連 携 の 基 本 構 造 は 以 下 の
通 り で ある ．
図 - 4 .7 は ， 基 本 構 造 の 概 念 図 で ある ． 四 角 形 は ク ラス を 示 し ， ク ラ ス 間 の 関 係 は
ＵＭＬの記 法 を用 いて描 いてある．影 響 の伝 播 は太 い矢 印 で表 してある．黒 い矢
印 は 影 響 が 必 ず 伝 播 す る こと を ， 白 抜 き の 矢 印 は 影 響 伝 播 の 可 能 性 が ある こ と を
示 している．
図 - 4 .７ ク ラス 図 にお ける 内 部 依 存 関 係
100
第4章
要求モデルの連携
あるクラスの変 更 によって影 響 を受 ける可 能 性 のあるクラスは，そのクラスと汎
化 ，関 連 ，集 約 ，合 成 関 係 で直 接 的 に関 連 付 けられているクラス，および属 性
や 操 作 に 対 す るア クセ ス 関 係 を 持 っ て いる ク ラス で あ る ．
あるクラスのすべての子 クラスの削 除 は，それらの親 クラスの削 除 を誘 導 する
場 合 が ある ．
合 成 関 係 にあるクラスの親 クラスの削 除 は，それに関 連 している全 ての子 クラ
スの削 除 を誘 導 する．
図 - 4 .8 に ， オ ブ ジ ェク ト モ デル の 内 部 連 携 規 則 の 例 を 示 す ．
図 - 4 .8 オ ブジェク トモ デルの 内 部 連 携 規 則
第4章
要求モデルの連携
101
ユースケースモデル内部連携規則（ユースケース図）
ユ ース ケー ス 図 に よ っ て 記 述 さ れ るユ ー ス ケース モ デル の 内 部 連 携 の 基 本 構 造
は 以 下 の 通 り で ある ．
図 - 4 .9 は ， 基 本 構 造 の 概 念 図 で ある ． ユ ース ケー ス 図 に お ける 影 響 追 跡 の 対 象
は ，ア ク タ ー と ユ ー ス ケ ー ス の 関 係 お よ び ， i n c l u d e と e x t e n d の 関 係 で あ る ．
i n c l ud e 関 係 は 複 数 の ユ ース ケー ス か ら 共 有 さ れ る 共 有 ユ ース ケー スの 存 在 を 示
し ， e xt e nd 関 係 は ， 他 の ユ ー ス ケー スを 拡 張 す る 拡 張 ユ ース ケー スの 存 在 を 示
している．
図 - 4 .9 ユ ースケ ース 図 にお ける 内 部 依 存 関 係
あるユースケースの変 更 によって影 響 を受 ける可 能 性 のあるユースケースは，
そ の ユ ー ス ケ ー ス と i n c l u d e 関 係 ， あ る い は e xt en d 関 係 で 直 接 的 に 関 連 付 け ら
れ て いる ユ ース ケ ー ス ， お よ び アク タ ー で あ る ．
ユ ー ス ケー ス は ， 関 連 す る 全 て の ア ク タ ー が 削 除 さ れ る と ， ユ ー ス ケ ー ス 自 体 も
削 除 される．
一 部 のアクターが削 除 されても，ユースケースそのものは削 除 されず，対 応 す
るシナリオに変 更 が生 ずる．
102
第4章
要求モデルの連携
共 有 関 係 にある子 ユースケースの削 除 は，それらの親 ユースケースに対 し，
何 ら かの 変 更 を 誘 導 す る ．
ユ ース ケー スの 変 更 は ， ユ ース ケ ース ・ シ ナリ オ の 変 更 を 伴 う ．
図 - 4 .1 0 に ， ユ ース ケー スモ デ ル の 内 部 連 携 規 則 の 例 を 示 す ．
図 - 4 .10 に， ユースケ ースモデ ル の内 部 連 携 規 則
4.3.2. 意 味 論 的 一 貫 性 の 保 証
異 な っ た 要 求 モ デ ル 間 の 意 味 論 的 一 貫 性 を 保 証 す る の に ， モ デル 連 携 依 存 関
係 を使 用 する．
モ デル 記 述 言 語 は モ デ ル 構 成 要 素 を 形 式 的 に 規 定 し て はい る が ， そ れ ぞ れ の
要 素 に ど の よ う な 意 味 を 与 え る か はモ デル の 作 成 者 に 任 さ れ て い る ． 個 々 の モ デ
ル構 成 要 素 の意 味 論 的 な制 約 条 件 を連 携 規 則 で記 述 することは可 能 であるが，
モ デル の 作 成 者 が 図 形 に よ っ て 表 現 し よ う と した 意 図 を ， 規 則 で 表 現 す る こ と は 極
め て 困 難 で ある ． そ れ が モ デル 同 士 の 連 携 依 存 関 係 を 使 用 す る 理 由 で ある ．
モ デル の 外 部 連 携 に お け る ，モ デ ルお よ び モ デル 構 成 要 素 と い う ２ 種 類 の 連 携
依 存 関 係 の 違 い は ， 依 存 関 係 のス テ レオ タ イ プ に よ っ て 区 別 す る ． モ デル 同 士 の
連 携 依 存 関 係 に は ス テレ オ タ イ プ 《m od e l -t r a c e》 を ， モ デ ル 構 成 要 素 同 士 の 連
携 依 存 関 係 に は ス テ レオ タ イ プ 《 e l e me n t - t r a c e 》 を 使 用 す る （ 図 - 4 .1 1 ） ．
第4章
要求モデルの連携
103
図 - 4 .11 モデル 連 携 を 表 す２ つの依 存 関 係
モ デル 同 士 の 意 味 論 的 連 携 に も ， 制 約 条 件 が ある ． 実 験 で 使 用 し た５ つ の モ デ
ル 間 の 連 携 依 存 関 係 に お ける 意 味 論 的 な 制 約 条 件 は ， 以 下 の 通 り で ある ．
・ ユースケースモデルのユースケースは，ゴール指 向 モデルのゴールを含 んでい
る．ユースケースに写 像 されていないゴールは，採 用 されなかったゴールであ
る．
・ メッセージシーケンスモデルのドメインオブジェクトは，オブジェクトモデルのクラ
スで定 義 されている．
・ メッセージシーケンスモデルのアクターは，ユースケースモデルのアクターであ
る．
・ ユースケースモデルのアクターは，オブジェクトモデルのクラスで定 義 されている．
しかし，ソフトウェアによって管 理 する必 要 のないアクターは，定 義 されていな
い．
・ メ ッ セ ー ジ シ ー ケ ン ス モ デル の メ ッ セ ージ パ ッ シ ン グ は ， シ ナ リ オ に 依 存 す る ．
・ シ ナリ オ は ， ユ ース ケ ー ス モ デ ル の ユ ース ケ ー ス に 対 応 し て いる ．
・ オ ブ ジ ェ ク ト モ デ ル の ク ラ ス に 対 応 す る オ ブジ ェ ク ト は ， シ ナ リ オ の 中 で 参 照 さ れ
て いる ．
図 - 4 .1 2 に ， 異 な っ たモ デル 同 士 の 意 味 論 的 関 係 を 示 し て ある ． そ れ ぞ れ の モ デ
ル の 連 携 依 存 関 係 は ， モ デル 設 計 者 に よ っ て 指 定 さ れ る ．
104
第4章
要求モデルの連携
図 - 4 .12 モデル 連 携 依 存 関 係
4.4. 事 例 研 究 ：
対外系パッケージにおける要求変更管理
金 融 向 け パ ッ ケー ジソ フ ト ウ ェ ア のモ デル 連 携 に つ いて 述 べ る ．
（ａ）プロジェクトの概要
本 事 例 研 究 で取 り上 げる対 外 系 ソフトウェアとは，バンキング・システムにおいて，
Ｓ Ｗ Ｉ Ｆ Ｔ な ど の 公 的 シ ステ ム や ， 大 手 顧 客 の 固 有 の シ ステ ム な ど と の 接 続 を 支 援 す
るた め の ソフ ト ウ ェ ア・ パ ッ ケー ジで あ る ． シス テ ム が 提 供 す る 機 能 は ， 提 供 さ れ る 金
第4章
要求モデルの連携
105
融 新 商 品 や 新 た な 通 信 機 器 の 出 現 に あわ せ て ， 頻 繁 に ， 追 加 変 更 さ れ る が ， そ
の ため の ソ フ ト ウェ ア 保 守 コ ス ト が 大 き な 負 担 と なっ て いた ． そ れ ま で メ イ ンフ レ ー ム
で提 供 していた該 パッケージソフトウェアを，サーバシステムへ移 行 するに当 たって，
機 能 の 追 加 変 更 の 容 易 性 が 大 き な テ ー マ とな り ， ソ フ ト ウェ ア の 開 発 は ， 保 守 の 容
易 性 と い う 観 点 か ら ， そ れ ま で の C O B OL ベ ース か ら オ ブ ジ ェ ク ト 指 向 言 語 ベ ー スに
変 更 す る こ と に なっ た ．
ソフ ト ウ ェ ア の 開 発 プ ロ セス は ， 要 求 モ デ リ ン グ， 設 計 実 装 ， 保 守 の ３ つ のフ ェ ー
ズに分 けられ，作 業 期 間 はほぼ２ヶ月 を要 した．要 求 分 析 チームの構 成 は，仕 様
を 決 定 す る リー ダ ー が １ 名 ， 要 求 の 提 供 者 が ３ 名 ， モ デ ル 作 成 者 が ３ 名 お よ び ア ド
バ イ ザ ー が1 名 で あ っ た ．
パッ ケ ー ジ ソフ ト ウ ェ ア に 対 す る 要 求 は ， ク ラ イ ア ン ト か ら 直 接 聞 き だ す こ と がで き
な いた め ， 該 当 業 務 の 専 門 化 や 客 先 担 当 の S Eを 要 求 者 と し ， プ ロ ジ ェク ト の リ ー ダ
ー が 仕 様 の 最 終 決 定 に 当 た った ． 決 定 さ れ た 要 求 仕 様 は ， 製 品 主 管 部 の メ ン バ
ー に よ っ て モ デル 化 さ れ た ． こ う し て 定 義 さ れ た 仕 様 に も と づ くソ フ ト ウ ェ ア の 設 計 と
開 発 は ， メ イ ンフ レ ー ム 上 の シ ス テ ム を 開 発 し て い た ソ フ ト ハ ウス に 外 注 さ れ た が ，
開 発 後 の ソ フ ト ウェ ア に 対 す る 保 守 は ， プロ ダ ク ト 主 管 部 の 要 員 ３ 名 が 当 た る こ と に
なっ た ． 彼 ら の 主 た る 任 務 は ， 変 更 要 求 へ の 対 応 と 要 求 モ デル の 更 新 で あり ， 実
際 の プロ グ ラ ム 変 更 作 業 は ， 担 当 ソフ ト ハ ウ ス に 外 注 さ れ た ．
（ｂ）要求のモデル化プロセス
は じ め に ， 要 求 モ デ ル の 作 成 と モ デル 連 携 の 定 義 を 行 っ た ．
ステップ１：要求モデルの作成
要 求 モ デ リ ン グでは ， 次 の ４ 種 類 の 要 求 モ デ ル の 作 成 を 行 う こ と に し た ．
ユ ース ケ ー ス モ デ ル ： クラ イ ア ン ト に 提 供 さ れ る サ ー ビ ス 機 能 の 定 義
オ ブ ジ ェク ト モ デル： 問 題 領 域 の 構 成 要 素 と ソフ ト ウ ェ ア 内 部 の 情 報 の 関 係
シ ー ケン ス モ デル： そ れ ぞ れ の サ ー ビス 機 能 ご と の 情 報 交 信 手 順
シ ナリ オ ： 詳 細 な 機 能 と ， 関 連 す る 非 機 能 要 求 の 定 義
106
第4章
要求モデルの連携
要 求 獲 得 の 結 果 ， 相 手 先 起 動 集 信 や セ ン タ 起 動 集 信 と いっ たサ ー ビス 機 能 を
表 す 最 上 位 の ユ ー ス ケー ス の 総 数 は １0 個 ， ま た ， 加 入 者 や サ ー ビ ス 種 別 な ど ， 問
題 領 域 の 構 成 要 素 や 情 報 を 表 すク ラ ス の 総 数 は 約 ７ 0 個 で あった ． そ れ ぞ れ の サ
ー ビス 機 能 （ユ ース ケー ス） ご と に ， シ ー ケ ン ス 図 を 描 き ， 共 通 す る 情 報 交 信 の 単 位
（ サ ブ シ ナ リ オ） を 抽 出 し ， そ れ ら を 順 次 組 み 合 わ せ る こ と に よ っ て ， ５レ ベ ル の 階 層
か ら な るサ ー ビス 機 能 の 構 造 が 定 義 さ れ た ． こ の 階 層 構 造 は ， 共 有 サ ブ ユ ース ケ
ース の 階 層 構 造 を 表 し て いる ． 表 - 4 .1 に ， 相 手 先 起 動 集 信 の 一 部 を 示 す ．
表 - 4 .1 相 手 先 起 動 集 信 の サブ シナリ オ 階 層 構 造
サービス機 能
共 有 サブユースケース
ユースケース
相手先起動集
開局電文受付
電文入力
信
開局要求受付
電文検査
相手先判定
使用者通知
運用者通知
加入者確認
確 認 コード検 査
パスワード検 査
サービス時 間 検 査
通話年月日記録
通話記録
電文出力
開局回答創出
使用者通知
ファイル転 送
電文入力
開始
回線状況交信
運用者通知
開始要求受付
電文検査
使用者検査
運用者検査
対 象 ファイル
通話記録確認
回線状況確認
判定
種別加入者確認
加入者取得
レコードＩＤ検 査
：
第4章
107
要求モデルの連携
最 右 列 の サ ブユ ース ケ ース は ，ク ラ スの 間 で の 情 報 交 信 パ タ ー ン で あ り ， そ れ ぞ
れシーケンスモデルによってその交 信 パターンが定 義 されている．それらを順 次 組
み 合 わ せ て ゆ く こ と に よ って 最 上 位 の サ ー ビス 機 能 が 構 成 さ れ る ． こ う し て ， サー ビ
ス 機 能 を 定 義 し て い る １ ０ 個 の ユ ー ス ケ ース か ら ， 約 ８ ０ 個 の 共 有 サ ブ ユ ース ケ ー ス
を 抽 出 す る こ と がで き た ．
ステップ２：モデル連携の定義
プ ロ ジ ェ ク ト は ，ユ ー ス ケ ー ス モ デ ル ，オ ブ ジ ェク ト モ デル ， シ ー ケ ン ス モ デル と い う
複 数 の 要 求 モ デ ルを 使 用 し た の で ， 外 部 連 携 規 則 と 内 部 連 携 規 則 お よ び モ デル
連 携 依 存 関 係 に よ っ てモ デ ル の 連 携 を 定 義 す るこ と に な った ．
外 部 連 携 規 則 は ， U ML の 専 門 技 術 者 が 事 前 に 作 成 し た も の を 使 用 し ， こ の モ
デル 連 携 規 則 を も と に ， モ デル 連 携 依 存 関 係 を 設 定 す る こ と に した ． 本 プ ロ ジ ェ ク
ト では ， 連 携 関 係 に あ るモ デ ル 構 成 要 素 同 士 の 関 係 を ， 規 則 や 依 存 関 係 で は な
く ，モ デ ル 連 携 対 応 表 に よ っ て 記 述 し ， モ デル の 変 更 時 に 参 照 で きる よ う に し た ．
図 - 4 .2 に 対 応 表 の 例 を 示 す ． １ つ の モ デル 構 成 要 素 の 変 更 に 対 し ， 複 数 の モ デ
ル の 複 数 の モ デル 構 成 要 素 が 影 響 を 受 け る 場 合 が ある ．
図 - 4 .2 モ デル 連 携 対 応 表
連 携 元 モデル
連 携 先 モデル
ユースケースモデル
オブジェクトモデル
モデル
モデル構 成 要 素
モデル
関係属性
モデル構 成 要 素
可能性
関 係 タイプ
集 信 可 否
集信状況記録
集信
集信状況
必須
形式
検査
通話記録
回線
回線状況
可能
意味
：
：
：
：
：
：
対 応 関 係 には ， ２ つ の 属 性 を 指 定 でき る よ う に した ． １ つ は 修 正 の 可 能 性 に 関 す
るも の で ， も う １つ は 関 係 タ イ プ に 関 す る も の で ある ． 関 係 タ イ プ で は ， 形 式 論 的 関
係 か ， モ デ リ ン グ作 法 上 の 関 係 か ， 意 味 論 的 関 係 か を 区 別 で き る よ う に した ． 要 求
変 更 が行 われるたびに，この表 は更 新 されることになる．
108
第4章
要求モデルの連携
一 方 ， 影 響 分 析 の た め に ， 一 般 的 な 内 部 連 携 規 則 を チ ェ ックリ ス ト の 形 で ま と め
たも の を 作 成 し た が ， 具 体 的 な モ デル を ベ ー スに 影 響 関 係 を 定 義 す る こと は ， 要
求 モ デ ル の 構 造 そ の も の を 定 義 す る こと と 変 わ ら ず ， 負 荷 が 大 き 過 ぎ るた め 取 り や
めた ．
（ｃ）要求の変更プロセス
ソフ ト ウ ェ ア の 開 発 後 ， 製 品 主 管 部 は ， 保 守 フェ ー ズ に 入 り ， ソ フ ト ウ ェ ア のリ リ ー
スと 機 能 追 加 作 業 の た め の 要 員 を 残 し て ， 開 発 プ ロ ジ ェ ク トは 解 散 した ．
保 守 要 員 の 役 割 は ， 顧 客 へ の ソ フ ト ウェ ア の リリ ース ， 要 求 モ デ ル と 設 計 仕 様 書
の 保 守 お よ び ， 外 注 ソ フ ト ハ ウス へ の プロ グ ラ ム 修 正 の 発 注 で あ る ． 要 求 モ デ ル の
保 守 は，要 求 変 更 依 頼 が上 部 機 関 で承 認 されたのち，連 携 規 則 ，連 携 依 存 表 ，
影 響 追 跡 チェ ック リス ト を 使 っ て 行 わ れ た ． 初 年 度 ５ 名 いた 保 守 要 員 は ， 次 年 度 か
ら３ 名 と な り ， 現 在 ま で 若 手 要 員 へ の ロ ー テ ー ショ ン を 継 続 し な が ら 続 い て い る ．
（ｄ）考察
モ デル の 形 式 論 的 構 造 は メ タ モ デル な ど に よ っ て 定 義 す るこ と は 可 能 で ある が ，
そ の モ デル に 固 有 の 意 味 論 的 構 造 を 機 械 的 に 定 義 す る こ とは 困 難 で ある [1 1 ] ． し
かし，モデルの作 成 者 自 身 がモデルの意 味 論 的 一 貫 性 やプロジェクト独 自 のモデ
リ ン グ作 法 を 連 携 依 存 関 係 に 反 映 さ せ る こ と に よ り ， モ デ ル 変 更 作 業 に お け る 作
業 負 荷 の 軽 減 と 正 確 性 の 大 幅 な 向 上 が 可 能 と な っ た ． 本 事 例 で は ， チ ェッ クリ ス ト
による修 正 箇 所 の確 認 が可 能 となり，保 守 作 業 に開 発 要 員 が関 与 する必 要 が無
く なっ た ．コ ー ドを 直 接 作 成 す る こ と の でき な い 外 注 プ ロ グラ ム の 保 守 で は ， そ の 効
果 は 一 層 顕 著 で あっ た ． また ， 手 作 業 に よ る モ デル 変 更 作 業 で は ， 人 間 の ミ ス に よ
る 誤 り が 発 生 す る こ と が ある が ， モ デル 連 携 規 則 は そ う し た 誤 り を 発 見 す る の に も 役
に立 った．
モ デル 連 携 の もう １ つ の 効 果 は ， モ デル 連 携 規 則 の 適 用 を 通 し て ， ソ フ ト ウ ェ ア
保 守 チ ー ム の オ ブ ジ ェ ク ト 指 向 技 術 や 該 当 モ デル に 対 す る 理 解 が 深 ま り ， 要 員 の
ロ ー テ ー ショ ン がス ム ー ズ に 行 え る よ う に な った こ とで ある ． ２ 年 目 以 降 の 保 守 要 員
の 数 を 減 ら す こ と がで き た のも ， こ の 教 育 効 果 の 成 果 で あ る ．
第4章
要求モデルの連携
109
影 響 追 跡 では ， 内 部 連 携 規 則 の チ ェック リ ス トを 用 い た が ， 修 正 の 対 象 を 絞 り 込
む こ と には 十 分 役 に 立 っ た ． 具 体 的 な モ デ ル の 内 部 連 携 規 則 は 極 め て 多 様 かつ
複 雑 で あり ， し か も ， 要 求 変 更 発 生 時 に 実 際 に 使 わ れ る のは ， そ の 極 一 部 で ある ．
した が っ て ， そ れ ら の す べ てを モ デ ル 作 成 時 に 指 定 さ せ る こ とは 現 実 的 で は ない と
判 断 された．
（ｄ）その他の知見
本 事 例 で 学 ん だ こ と は ，モ デ ル 記 述 言 語 上 の 制 約 ， モ デリ ン グ作 法 上 の 制 約 ，
意 味 論 的 制 約 を そ れ ぞ れ 異 な っ た グル ー プ に ま と め て お くこ と に よ って ， モ デ ル 変
更 の 理 由 の 違 い ご と に ， 該 当 す る グ ル ー プの 規 則 だ け を 適 用 す れ ば よ く ， 作 業 の
効 率 向 上 に 役 立 っ た と い うこ と で ある ． ま た ， モ デル 連 携 依 存 関 係 は ，モ デ ル が 大
きくなるにつれて図 式 上 の依 存 関 係 より表 の方 が使 い易 いことが分 かった．しかし，
モ デル 上 に 直 接 依 存 関 係 を 指 定 でき る 支 援 ツ ー ル が あれ ば 作 業 負 荷 は ， さ ら に
削 減 されるだろう．
本 事 例 研 究 は ， す で に メ タ モ デ ル 上 で の 制 約 関 係 が 定 義 さ れ て いる U M Lモ デル
同 士 の 連 携 に 関 す る 作 業 で あっ たた め ， 連 携 規 則 を 作 成 す る こ と は 比 較 的 容 易
で あった ． し かし ， こ れ が 全 く 異 な っ たモ デ ル 同 士 の 連 携 で あ れ ば ， 規 則 を 作 る こ と
の難 しさが増 加 するが，それだけ，効 果 も大 きいと考 えられる．モデル連 携 を機 械
化 す る 方 法 と し て ， プ ロ グラ ム の 構 造 解 析 と 同 様 ， 入 れ 子 構 造 の 解 析 や 共 有 情 報
を 介 し た モ デル 構 成 要 素 間 の 関 係 を 評 価 す る 方 法 な ど が 考 え ら れ る が [1 54 ] ， 本
研 究 で は ， そ の 検 証 に ま では 至 っ て いな い ．
4.5. 関 連 研 究
モ デル の 連 携 に 関 す る 知 識 は ， メ ソッ ド 工 学 の 一 貫 性 保 証 の た め の 知 識 に 似 て
いる ． メ ソ ッ ド 工 学 に は ， 複 数 の 異 なっ た 手 法 に よ っ て 作 成 さ れ た モ デル 間 の 形 式
上 の 違 い を ， 変 換 規 則 など を 使 っ て 変 換 し て ゆ く 方 式 ［ 1 0 2 ］ と ， 個 々 の 対 象 の 形
式 に 左 右 さ れ な い メ タ モ デル を 介 し て 変 換 を 図 ろ う と す る 方 式 ［ 1 9 ］ が あ る ． し か し ，
メ ソッ ド 工 学 は ，ス テ ーク ホル ダ の 観 点 の 違 い や プロ ジ ェ ク ト の 状 況 の 変 化 に 応 じ て
110
第4章
要求モデルの連携
適 宜 選 択 さ れ る 手 法 に よ り 作 成 さ れ た 異 種 モ デル 間 の 一 貫 性 を 保 証 す るた め の
技 術 で あ り ， 要 求 変 更 が 発 生 し た 時 の 一 貫 性 の 保 証 に つ いて ま で は 言 及 し て い
な い ． 既 成 の モ デル を 変 更 す る と き の 一 貫 性 の 保 証 は ， よ り 困 難 な 問 題 で ある ．
Multi Viewpoint アプローチは，前 者 に属 する代 表 的 な手 法 である[51，102，
103 ] ． ソ フ ト ウ ェ ア 開 発 に 従 事 す る ス テ ー ク ホ ル ダは 異 な った 立 場 と 観 点 を 持 っ て
おり，異 なったモデルを作 成 する．それを Viewpoints と呼 び，それぞれの
V i e w p o i n t s を 記 述 す るた め のフ レー ム ワ ー ク を 提 案 し て いる ． 個 々 のフ レ ー ム ワ ー
ク は ， そ こ で 使 用 さ れ る モ デル の 形 式 な ど を 記 述 す る た め のス タ イ ル ス ロ ッ ト や ， 異
なっ た モ デ ル 間 で の 一 貫 性 を チ ェ ック する た め の 規 則 を 記 述 す る た め の 作 業 計 画
ス ロッ ト ， 開 発 中 の シ ス テ ム に 関 す る V i e w po i nt の 関 心 事 領 域 を 指 定 す る た め の
ド メ イ ンス ロ ッ ト ， 問 題 領 域 の 記 述 で ある 仕 様 ス ロ ッ ト ， 開 発 状 況 の 履 歴 を 格 納 し て
お くた め の 作 業 記 録 ス ロ ッ ト ， と い った ５ つ のス ロ ッ ト から 構 成 さ れ て い る ． こ のフ レ ー
ム ワ ーク に は ， 一 般 的 な 知 識 や 規 則 を 格 納 し て おく た め の テ ン プ レ ー ト と ， そ の テ ン
プレートから生 成 した個 別 のプロジェクトのためのインスタンスがある．彼 らの考 え方
は ， 本 研 究 と の 類 似 性 が 高 く ， 特 に ， モ デル 間 の 連 携 に 関 す る 規 則 は ， 彼 ら の
i n t e r- V i e w P o in t c h e c k ア ク ショ ン に 似 て い る ． テ ン プ レ ー ト と イ ンス タ ンス と い う 考
え 方 も ， 本 論 文 の 研 究 と 似 て い る ． し かし ， V i e w P o i n t は ，モ デ ル 作 成 時 の 一 貫 性
の 保 証 に 焦 点 を 当 て て お り ， そ れ ゆ え ， モ デル の 形 式 論 的 な 問 題 し か 対 象 と し て
い ない ． 一 方 ， 本 研 究 では ， 作 成 さ れ たモ デ ル に 対 す る 要 求 変 更 時 の 一 貫 性 の
保 証 を 対 象 と し て お り ， プ ロ ジ ェ ク ト の モ デリ ン グ作 法 や ア プ リ ケー シ ョ ン の 意 味 論 も
扱 っ て い る ． 影 響 分 析 機 能 も ， 要 求 変 更 独 自 の 問 題 で あり ， V i e w P o in t の 研 究 対
象 範 囲 外 の テ ーマ で ある ．
S i tu a t i on a l M et ho d s E ng i ne e r i n g [1 9 ]は ， メ タ モ デル を 使 って 概 念 間 の 連 携 を
図 ろ う と し て いる ． す な わ ち ， 既 存 の 手 法 から 手 法 の 断 片 を 切 り 出 し ， そ れ ら の 断
片 を 組 み 立 て 直 し て ， プロ ジ ェ ク ト に 固 有 の 手 法 を 構 築 す る ． 個 々 の 手 法 断 片 は ，
メ タ モ デ ル に よ っ て 形 式 論 的 な 統 合 が 図 ら れ る ． こ の 方 法 は ， 成 果 物 で ある 製 品
断 片 だ け で な く ， プ ロ セ ス そ のも の で ある 工 程 断 片 の 連 携 も 可 能 と し てい る ． モ デル
間 の 一 貫 性 に つ い て は ， 概 念 レ ベル で の 一 貫 性 保 証 規 則 が 提 案 さ れ て い る ． こ の
手 法 は ， 形 式 論 的 な モ デル 同 士 の 一 貫 性 を 保 証 す る た め の 洗 練 さ れ た 手 法 で あ
る ． し か し ， メ タ モ デ ル を 使 っ た 方 式 で は ， ア プ リ ケー シ ョ ン の 意 味 論 的 な 一 貫 性 ま
でを 保 証 す る こと は 難 し い ． また ， 個 々 の モデ ル の 言 語 仕 様 が 定 義 さ れ て いる こ と
第4章
要求モデルの連携
111
が 条 件 と な り ， 不 特 定 の モ デル を 扱 う の に は 向 い て い な い ．
要 求 変 更 に伴 うモデル間 の変 更 の追 跡 は，むしろ，要 求 追 跡 の領 域 で研 究 さ
れ て きた [ 78 ] ． 要 求 追 跡 で は ， 要 求 モ デ ル の 変 更 箇 所 を 設 計 モ デ ル ， 実 装 モ デ ル
と い う よ う に ， モ デル の 作 成 順 序 に 従 っ て 追 跡 し て ゆ く が ， 要 求 モ デル と い う 同 一 レ
ベル の モ デ ル 同 士 で は ， 基 本 的 に モ デル 間 の 生 成 関 係 は 存 在 し な い ． し か し ， 本
論 文 に お け る 連 携 の 基 本 的 な 機 能 に つ いて は ， 要 求 追 跡 機 能 が ベ ー スと な っ て
いる ［1 41］ ． 要 求 追 跡 では ， 追 跡 作 業 を 支 援 す るい く つ か の ツ ー ル が 提 案 さ れ て
いる が ， そ の 多 く は ， ハ イ パ ーカ ー ド 機 能 な ど を 使 っ て モ デ ル 連 携 作 業 を 支 援 す る
も の で あ り ［ 40 ,1 11 ] ， 参 照 先 の モ デ ル 構 成 要 素 ま で 特 定 す る こ と は で き な い ． ま た ，
要 求 追 跡 に関 する研 究 においても，影 響 追 跡 についての議 論 は少 ない．
4.6. 考 察
こ れ ま で ， モ デル の 修 正 作 業 は ， モ デル 作 成 者 自 身 が 行 う こ と が 多 か った ． し か
し ， モ デル 作 成 者 が ， い つ まで も 同 一 シ ス テ ム に 携 わ っ て いら れ る と は 限 ら な い ． 担
当 者 の変 更 と共 に要 求 変 更 時 の作 業 負 荷 が激 増 し，要 求 変 更 作 業 が不 可 能 と
な る と と も に ， ソ フ ト ウェ ア そ の も の が 陳 腐 化 し て ゆ く こ と に な る ． 本 研 究 で は ， 外 部
連 携 依 存 関 係 や 内 部 連 携 依 存 規 則 に よ って ， モ デ ル 作 成 者 が い なく て も ， 異 な
った モ デル 同 士 の 一 貫 性 保 証 や 同 一 モ デ ル 内 の 影 響 箇 所 の 特 定 と い う 作 業 の
困 難 さ を 軽 減 で き る こ と を ， 具 体 的 な 事 例 を 通 し て 証 明 し た ．こ の こ と は ，モ デ ル 連
携 依 存 関 係 さ え 記 述 でき て い れ ば ， 状 況 に 応 じ て 異 な った モ デリ ン グ技 法 を 選 択
でき る と い う ， 多 様 性 の 克 服 と い う 問 題 に も 寄 与 で き る こ と を 意 味 し て いる ． ま た ， 内
部 連 携 規 則 による影 響 追 跡 は，単 一 の要 求 モデルの場 合 にも必 要 な機 能 であり，
外 部 連 携 が 問 題 の 多 様 さ の 解 消 に 貢 献 す る の に 対 し ， モ デル 内 部 の 矛 盾 の 解 消
へ の 寄 与 度 が 高 い ． オ ブ ジ ェク ト 指 向 技 術 の 登 場 な ど に よ っ て ， 要 求 変 更 に よ る ソ
フ ト ウェ ア 構 造 の 劣 化 問 題 が 一 段 落 し た 現 在 ， モ デ ル 変 更 に 伴 う ２ 次 的 な 影 響 箇
所 の 追 跡 は ， ソ フ ト ウェ ア 進 化 の た め の 鍵 の １ つ で あ る と 考 え ら れ る ．
要 求 モ デ ル 連 携 の た め の 知 識 と ， メ ソッ ド 工 学 に お ける モ デル の 一 貫 性 保 証 の
ため の 知 識 は ， 意 味 的 に 同 じ も の で あ る が ， そ の 使 用 目 的 の 違 い に よ っ て 表 現 形
式 が 異 な っ て いる だ け で ある ． 同 一 の 知 識 を 別 々 に 持 つ こ とは ， 冗 長 で あ る ． 共 通
112
第4章
要求モデルの連携
す る 知 識 の フ レ ー ム ワ ーク に つ い ては 今 後 の 検 討 課 題 で あ る ．
モデル同 士 の意 味 の連 携 に関 しては，今 のところ，分 析 者 の努 力 に頼 る以 外 に，
良 い方 法 が見 つかっていない.要 求 モデルそのものから，その意 味 を抽 出 するには，
要 求 モ デ ル の 設 計 時 に ， ア ナ リス パ タ ー ン [ 53 ] の よ う な 集 約 的 な 知 識 の 適 用 を 検
討 す る 必 要 が ある が ， こ れ も 今 後 の 課 題 で あ る ．
連 携 規 則 を 作 成 で き る の が ， 該 当 モ デル 記 述 言 語 に 精 通 し て い る 専 門 技 術 者
で ある こ とな ど か ら ， 要 求 モ デ ル の 連 携 は ， プ ロ セス 知 識 の 記 述 や 要 求 工 学 手 法
の 選 択 に 較 べ て ， そ の コ ス トは 高 価 に つ く ． し か し ， 次 の 3 つ の 観 点 か ら ， そ の 効 果
は コ ス ト に 十 分 見 合 っ て いる と 考 え ら れ る ． 第 １ に ， テ ン プレ ー ト と な る 連 携 規 則 は ，
１ 度 作 っ て し ま え ば ， 新 た な 負 担 無 し に ， 再 利 用 可 能 で あり ， 再 利 用 の 回 数 が 増
え れ ば 増 え る ほど ， 効 果 に 対 す る コス ト の 割 合 は 低 下 し て ゆ く ． 第 ２ に ， モ デル の 一
貫 性 の 保 証 は ， 異 な った モ デル を 作 成 す る 場 合 に は 必 須 の 作 業 で あ り ， テ ン プ レ
ー ト に も とづ い て ， そ れ を 明 示 化 す るた め の 作 業 は 付 加 的 な も の で ある ． こ れ は メ ソ
ッ ド 工 学 に もい え る こ と で あ る ． 第 ３ に ， ソ フ ト ウ ェ ア ラ イ フ サ イ ク ル に お け る 保 守 コ ス ト
の削 減 は，ソフトウェア工 学 の重 要 な課 題 である[19,74,119]．さらに，実 際 のプロ
ジ ェク ト では ， 高 度 な 技 術 を 持 っ た モ デル 作 成 者 を ， い つ ま でも 保 守 作 業 に 携 わ ら
せ て おく こ と が でき な い こ とを 考 え れ ば ， 新 た な 保 守 担 当 者 が 仕 様 を 理 解 す る 上 で
も ，モ デ ル 依 存 関 係 は コ ス ト の 削 減 に 寄 与 す る とい え る ．
第 ５ 章
まとめと関連する課題
最 後 に，本 研 究 全 体 を総 括 し，関 連 する課 題 として，これまでに述 べた知 識 を
利 用 するための支 援 ツールの実 現 方 法 について言 及 する．
5. 1. 研 究 の ま と め
要 求 工 学 プロセスは，ソフトウェアのライフサイクルを通 して，ソフトウェアそのもの
の意 味 を定 義 するための唯 一 のプロセスである．このことは，要 求 工 学 が，現 実
世 界 とコンピュータという仮 想 空 間 をつなぐための学 際 的 な技 術 であるということを
意 味 している．実 際 のプロジェクトでは，要 求 分 析 者 と呼 ばれるソフトウェア技 術
者 と，ステークホルダと呼 ばれる非 ソフトウェア技 術 者 とによる，共 同 作 業 が行 われ
ており，そこでは，工 学 的 な技 術 だけでは解 決 できない数 多 くの問 題 が発 生 して
いる．熟 練 技 術 者 の知 識 と技 術 が，それらの問 題 を解 決 するのに，おおいに役
立 っている．
本 論 文 では，要 求 工 学 作 業 で直 面 する３つの典 型 的 な問 題 を題 材 に，発 見
的 知 識 と工 学 的 知 識 の体 系 化 と，それを表 現 するための方 式 について議 論 した．
発 見 的 知 識 には個 別 の普 遍 的 知 識 とそれらを集 約 した抽 象 的 知 識 があり，工
学 的 知 識 にも個 別 の制 約 規 則 と，それらを定 義 するための構 造 的 知 識 が必 要 と
なる．さらに，それぞれの知 識 には，それを適 切 に表 現 するための様 々な表 現 法
がある．それぞれの章 では，問 題 ごとに，これらの知 識 の体 系 化 と表 現 方 式 につ
いて議 論 した．
114
第5章
まとめと今後の課題
「はじめに」では，本 研 究 の動 機 と目 標 について述 べた．熟 練 技 術 者 の経 験 に
もとづく発 見 的 知 識 は，定 形 的 な形 式 を持 たないため，それらを利 用 するには，
それぞれの知 識 を体 系 化 し，明 示 化 するためのフレームワークが必 要 であるという
問 題 を提 起 し，それを本 研 究 の目 標 として提 示 した．
第 1章 では，要 求 工 学 の現 状 を技 術 的 な側 面 から概 括 し，本 研 究 のテーマで
ある発 見 的 知 識 の表 現 と体 系 化 との関 連 について言 及 した．
第 ２章 では，要 求 工 学 プロセスにおける偶 発 的 な問 題 を解 決 するための発 見
的 知 識 の記 述 方 法 について議 論 した．要 求 工 学 プロセス知 識 を記 述 するために，
ソフトウェア設 計 用 のパターンの形 式 を拡 張 し，状 況 セクションと課 題 セクションと
いう２つの構 造 を提 案 した．さらに，プロジェクトの状 態 遷 移 の全 体 像 を表 示 する
ための状 態 遷 移 図 を提 案 した．
第 ３章 では，プロジェクトにおける要 求 獲 得 問 題 を解 決 するのに必 要 とされる要
求 工 学 手 法 の選 択 という知 識 のフレームワークについて議 論 した．代 表 的 な要
求 工 学 手 法 を，適 用 領 域 の特 徴 と処 理 操 作 の特 性 という２つの次 元 によって分
類 し，要 求 工 学 技 術 マップという座 標 空 間 上 に配 置 した．また，プロジェクトの特
徴 を分 類 し，要 求 工 学 技 術 マップ上 の具 体 的 な手 法 を選 択 するための戦 略 的
方 法 を提 案 した．
第 ４章 では，要 求 変 更 の発 生 時 に，モデルの一 貫 性 を保 証 するための知 識 と
その記 述 方 法 について議 論 した．要 求 変 更 の発 生 時 に，複 数 の異 なった要 求
モデル同 士 の一 貫 性 を保 つには，モデル同 士 の連 携 が必 要 であり，それを外 部
連 携 と内 部 連 携 という観 点 から整 理 し，それらを記 述 するための連 携 規 則 と連 携
依 存 関 係 を提 案 した．
３つの章 の関 係 を図 -5.1に示 す．現 実 世 界 には，様 々な知 識 が存 在 している．
再 利 用 可 能 な知 識 を収 集 するために，発 見 的 知 識 には普 遍 化 を，工 学 的 知 識
には規 則 化 を用 いた．収 集 された雑 多 な知 識 を整 理 するための主 要 な方 法 とし
て，分 割 と抽 象 化 と組 織 化 がある[18]．要 求 プロセスパターンのように個 別 に表
現 されている知 識 は，その中 から同 一 の範 疇 に属 する知 識 を選 び出 し，それらを
組 織 化 することによって，知 識 の全 体 構 造 を明 らかにすることができる．一 方 ，適
切 な技 法 の選 択 といった発 見 的 知 識 の体 系 化 には，抽 象 化 を用 いている．抽 象
化 によって特 殊 な知 識 は捨 象 され，知 識 の全 体 構 造 が明 らかになる．また，モデ
ルを記 述 するための制 約 条 件 のような工 学 的 知 識 は，知 識 全 体 を構 造 化 するこ
第5章
まとめと今後の課題
115
とによって体 系 化 を図 ることができる．工 学 的 知 識 が捨 象 されることは無 い．
図 -5.1 知 識 の抽 出 と体 系 化
知 識 は，それぞれ独 自 の表 現 形 式 を使 って表 現 されることになる．本 研 究 で使
用 した，それぞれの知 識 の表 現 形 式 をまとめると，以 下 のようになる．（）内 は，そ
れぞれの知 識 表 現 が用 いられた章 である．ただし，知 識 とその記 述 法 の関 係 は
固 定 的 なものではなく，他 の方 法 を使 用 することも可 能 である．
テキスト
： プロセスパターン記 述 （2章 ），手 法 適 合 原 則 （3章 ）
表
： プロジェクト問 題 （3章 ）
ルール
： モデル連 携 規 則 （4章 ），影 響 追 跡 規 則 （4章 ）
座標空間
： 要 求 工 学 技 術 マップ（3章 ），プロジェクト特 性 （3章 ）
図式
： 状 況 遷 移 図 （2章 ），モデル連 携 依 存 関 係 （4章 ）
図 式 や座 標 軸 を使 って表 現 される知 識 は，大 局 的 な構 造 が重 要 な知 識 であり，
利 用 者 の感 性 を通 して理 解 が可 能 な知 識 である．表 やルールによって表 現 され
る知 識 は，個 々の知 識 が明 確 に判 別 できるもので，その表 現 法 は利 用 者 に明 快
116
第5章
まとめと今後の課題
な解 を与 えることができるが，説 明 能 力 に乏 しい．自 然 言 語 による表 現 は，複 合
的 な条 件 を持 っている問 題 に有 効 であり，解 の説 明 能 力 が高 いが，冗 長 である
ため，その記 述 はパターンのように抽 象 化 する必 要 がある．
5. 2. 研 究 の 評 価
本 研 究 の，要 求 工 学 への効 果 について評 価 する．個 別 の研 究 評 価 は各 章 の
考 察 で述 べているので，本 章 では，共 通 の評 価 基 準 をもとに，定 性 的 評 価 と定
量 的 評 価 を行 う．
（ａ）定性的評価
要 求 工 学 プロセスでは，クライアントとの機 密 保 護 契 約 や，プロジェクトごとに異
なる課 題 や，再 現 できない作 業 環 境 などから，同 一 条 件 下 での観 測 データを組
織 的 に採 取 することが難 しい．ここでは，本 研 究 の成 果 を，筆 者 の主 観 を交 えて，
定 性 的 に評 価 する．評 価 は，それぞれのプロジェクトでリーダー的 役 割 を担 ってい
た技 術 者 から入 手 した感 想 を，筆 者 の経 験 もとに整 理 し直 したもので，本 研 究 で
提 案 した方 法 が，それを使 用 しなかった場 合 に較 べどれほどの効 果 があったかを，
４段 階 で定 性 的 に判 定 している．評 価 項 目 は以 下 の通 りである．
・
有効性：
本 来 な ら 解 決 で き な か っ た 問 題 を ，本 研 究 の 提 案 方 法
を 利 用 す る こ と に よ っ て ，ど れ だ け 解 決 で き た か を 評 価 す る ．評
価は，現場の技術者たちへの聞き取り調査に基づいている．
・
効率性：
単 位 作 業 に 対 す る 投 資 量 で ，時 間 的 効 率 性 や コ ス ト 的
効 率 性 が あ る が ，こ こ で は 人 的 コ ス ト に 注 目 し た 効 率 性 に つ い て
評 価 し て い る ．評 価 は 計 画 値 と 実 績 値 の 比 較 で 行 っ た ．時 間 的 効
率性については，次の定量的評価の項で議論する．
・
完 全 性：
作業が正確かつ漏れなく行われたかどうかという作業
品 質 を 評 価 す る も の で ，こ こ で は ，要 求 仕 様 書 の 完 成 度 に よ っ て
評 価 す る こ と に し た ． 要 求 仕 様 書 の 完 成 度 は ， IEEE830 の 仕 様
第5章
117
まとめと今後の課題
書 評 価 項 目 の 中 か ら 正 当 性 ，非 あ い ま い 性 ，完 全 性 ，一 貫 性 を 使
って，全要求数に対する総違反数の比率を定性的に求めた．
・
独 創 性：
発見的知識でも対応できない予期せぬ問題が発生した
と き に ，プ ロ ジ ェ ク ト メ ン バ ー が そ の 問 題 に 対 応 で き た か ど う か
を 評 価 す る ．評 価 は ，ど れ だ け 適 切 な 代 替 案 を 提 示 で き る か と い
う 要 求 技 術 者 の イ マ ジ ネ ー シ ョ ン 能 力 向 上 の 評 価 で も あ る ．評 価
は，筆者の独断的評価に顧客満足度を加味して行っている．
・
教育性：
本 研 究 が 提 案 す る 方 法 を 使 用 す る こ と に よ っ て ，要 求
技 術 者 の 技 術 力 が 向 上 し た か ど う か を 判 定 す る ．担 当 技 術 者 へ の
聞き取り調査を通して知識量の向上を評価した．
評 価 結 果 は，以 下 の通 りである．ここで，◎は非 常 に効 果 があった，○はそれな
りに効 果 があった，□は変 化 が無 かった，△は負 の効 果 があったことを示 してい
る．
表 -5.1 知 識 フレームワークの定 性 的 評 価
有効
性
2
効率
性
完全
性
創造
性
教 育
性
プロセスパターン
○
○
○
□
◎
状況遷移図
◎
◎
□
○
□
要 求 工 学 技 術 マッ
◎
◎
○
□
◎
プロジェクト特 性
○
○
□
○
□
外部連携関連図
◎
◎
○
□
◎
外部連携規則
○
△
◎
□
◎
内部連携規則
○
△
◎
△
□
章
3
プ
章
4
章
この定 性 的 評 価 の結 果 から読 み取 れることは次 の通 りである．すなわち，全 体
118
第5章
まとめと今後の課題
像 を示 す図 表 を伴 った方 法 は有 効 性 ，効 率 性 とも評 価 が高 いが，作 業 の完 全
性 にはあまり寄 与 していない．完 全 性 は，全 体 像 の把 握 より作 業 の綿 密 性 により
多 く依 存 していると考 えられる．事 実 ，パターンや連 携 規 則 といった詳 細 な情 報 を
提 供 する方 法 は，定 常 状 態 ではそれを利 用 するための付 加 作 業 が伴 うために作
業 効 率 が低 下 する反 面 ，作 業 の完 全 性 は向 上 している．さらに，詳 細 な情 報 に
は，ＯＪＴ的 な使 用 を通 しての教 育 的 効 果 も認 められた．連 携 規 則 の効 率 性 に関
する負 の評 価 は，規 則 作 成 者 の付 加 作 業 によるものであり，内 部 連 携 規 則 に対
する担 当 技 術 者 の創 造 性 の負 の評 価 は技 術 的 に未 熟 な技 術 者 が規 則 に依 存
してしまうためと考 えられる．創 造 性 については，予 期 せぬ問 題 への遭 遇 頻 度 が
少 なかったため，適 切 な評 価 ができていない．
（ｂ）定量的評価
本 研 究 の定 量 的 評 価 には，障 害 プロジェクトに対 する有 効 性 の評 価 を全 障 害
数 に対 する回 復 障 害 数 で測 定 するという方 法 や，成 果 物 の品 質 向 上 性 を製 品
の比 較 によって評 価 するといった方 法 もあるが，ここでは，筆 者 の経 験 をもとにした
要 求 工 学 作 業 の時 間 的 効 率 向 上 性 について評 価 する．
作 業 の効 率 性 は，定 常 状 態 での効 率 向 上 率 と，障 害 状 況 での効 率 向 上 率 と
いう２つの視 点 でとらえることができるが，ここでは，具 体 的 な事 例 をもとに，後 者 の
評 価 を行 う．ここで取 り上 げる３つの事 例 は，“多 すぎる要 求 ”という問 題 であり，
安 易 なヒアリング調 査 を行 ったプロジェクトがしばしば遭 遇 する問 題 である．それぞ
れの問 題 解 決 に当 たっては，第 2章 の要 求 工 学 プロセスパターンを使 用 した問 題
解 決 戦 略 の設 定 か，第 3章 の要 求 工 学 技 術 マップを使 った適 切 な手 法 の選 択
かの，いずれかの方 法 を採 用 している．以 下 に，定 量 的 な観 点 からの問 題 解 決
プロセスについて簡 単 に記 し，若 干 の考 察 を述 べる．
事例１：航空運輸における要求項目の整理
ヒアリングや業 界 誌 ，管 理 者 インタビューなどを通 して，約 ２０００件 の要 望 や
関 連 情 報 が収 集 され，その整 理 を３人 で１か月 ほど行 ったが，整 理 できず，タ
イムオーバーランとなってしまった．適 用 した研 究 成 果 は，要 求 工 学 プロセスパ
ターンである．業 務 をよく知 っている担 当 者 １名 を指 名 し，領 域 分 割 法 を適 用
第5章
まとめと今後の課題
119
した結 果 ，約 半 月 で整 理 が行 えた．（2.6(c)参 照 ）
ここで収 集 された情 報 には，要 求 だけでなく業 界 や市 場 の動 向 も含 まれて
おり，要 求 プロセスでも最 も初 期 段 階 での情 報 収 集 と位 置 づけられる．しかし，
技 術 者 は問 題 領 域 に関 する十 分 な知 識 を持 っており，それが領 域 分 割 法 を
選 択 した主 要 な理 由 である．彼 らは，業 界 や市 場 動 向 の中 から，暗 黙 の要 求
を抽 出 し，情 報 を洗 練 することができた．
事例２：介護支援における要求項目の整理
現 行 の介 護 支 援 管 理 システムの改 築 のために，現 場 担 当 者 へのヒアリング
調 査 の結 果 ，約 ４００件 の要 求 が収 集 され，その整 理 を５人 で１０日 ほど行 った
が，検 討 メンバーは業 務 に疎 く，要 望 の解 釈 がメンバーによって異 なり，タイム
オーバーランとなってしまった．適 用 した研 究 成 果 は，手 法 の選 択 である．業
務 に精 通 したメンバーがいなかったため，ゴール分 割 法 を適 用 し，メンバー1名
を指 名 し，クライアントの支 援 を受 けながら，１０日 ほどで整 理 ができた．
収 集 された情 報 はクライアントからの具 体 的 な要 求 であり，洗 練 された情 報 と
位 置 づけることができる．しかし，技 術 者 たちは，この新 たなビジネスに対 する知
識 は持 っておらず，それがゴール分 解 を選 択 した理 由 である．
事例３：電力自由化対応における要求の整理
電 力 自 由 化 対 応 のための機 能 は，電 力 会 社 も未 経 験 のため，SIベンダーと
共 同 で要 求 の取 りまとめをすることになった．提 案 された項 目 は，現 行 システム
の改 良 も含 めて，１５０件 ほどになった．これらを整 理 し，アプリケーションの構 造
を設 計 することになった．３名 の担 当 者 が１か月 ほどかけて整 理 を行 ったが，要
求 内 容 とソフトウェア構 造 の対 応 が確 定 せず，コストオーバーランとなってしまっ
た．適 用 した研 究 成 果 は，手 法 の選 択 である．電 力 自 由 化 の実 体 が不 透 明
であったため，業 務 担 当 者 やソフトウェア設 計 者 など異 なった観 点 からなるメン
バー５人 を指 名 し，KJ法 を使 って要 求 のグループ化 を行 った．整 理 は２日 ほど
で終 わった．
ここでは，クライアントとの間 で実 現 すべき要 求 の合 意 ができており，それらの
要 求 をもとに，クライアントにアプリケーションの構 造 を提 示 するための作 業 であ
り，要 求 プロセスの最 終 段 階 である．単 なる要 求 の分 類 ではなく，最 終 的 なソ
フトウェアの構 造 や実 現 の可 能 性 といった複 数 の分 類 基 準 を考 慮 しなければ
ならず，それがKJ法 を選 択 した理 由 である．
120
第5章
まとめと今後の課題
この3つの事 例 から作 業 量 を定 量 的 に定 義 すると，次 のようになる．
・
プロジェクトは，作 業 が3人 月 を超 えるとコストオーバーランかタイムオーバー
ランとなる．
・
プロセス知 識 パターンと手 法 の選 択 のいずれを採 用 しても，０．５～１．０人
月 で問 題 が解 決 している．
大 量 の情 報 の整 理 という問 題 に関 して言 えば，プロジェクトが障 害 に陥 った時 ，
なんらの手 も打 たなければ作 業 量 は３人 月 を超 え，そのプロジェクトは，遂 には，タ
イムオーバーランかコストオーバーランに陥 ることになる．しかし，ここで取 り上 げた
事 例 によれば，作 業 量 が２人 月 を超 えない状 態 で，異 常 な状 況 を検 知 し，発 見
的 知 識 の適 用 か適 切 な手 法 の選 択 を行 えば，障 害 は回 避 できることになる．もっ
と多 くの事 例 を収 集 すれば，より精 度 の高 い有 効 基 準 値 が得 られるだろう．そうし
た基 準 値 は，“多 すぎる要 求 ” 以 外 の問 題 にも存 在 していると考 えられる．これら
の研 究 成 果 は，他 の問 題 に対 する障 害 克 服 のための作 業 効 率 の向 上 という形
で寄 与 するであろう．
しかし，手 法 が適 切 に選 択 できればそれで問 題 が解 決 するわけではない．手 法
の適 用 の仕 方 を間 違 えば満 足 できる結 果 が得 られない場 合 もあるし，手 法 に対
する熟 練 度 によって作 業 速 度 が異 なることも事 実 である．しかし，個 別 の手 法 の
使 用 法 に関 する発 見 的 知 識 は，本 研 究 の対 象 外 である．この定 量 的 評 価 で用
いた事 例 では，それぞれの手 法 を適 用 した技 術 者 の技 量 は，筆 者 が想 定 してい
る平 均 的 技 術 者 のレベルである．
5. 3. 関 連 す る 今 後 の 課 題
本 研 究 では，知 識 の表 記 法 と体 系 化 について論 じた．個 々の課 題 は，それぞ
れの章 で述 べたので，ここでは，収 集 された知 識 の利 用 を支 援 するための機 械 化
について述 べる．本 研 究 の成 果 である体 系 化 された知 識 を使 って要 求 工 学 作 業
を支 援 するための環 境 を提 供 することは，プロジェクトの破 綻 の最 も多 くの原 因 と
第5章
まとめと今後の課題
121
なっている要 求 工 学 上 の問 題 [133]の解 決 に大 きく寄 与 するだろう．
はじめに，それぞれの知 識 がどのように使 われるかを検 討 する．知 識 の利 用 形
態 を図 -5.2に示 す．
知 識 の論 理 的 な構 造 を条 件 部 と結 論 部 に分 ける．条 件 部 は入 力 情 報 から問
題 を分 析 し，結 論 部 はそれに適 した解 を選 択 していると想 定 することができる．こ
こで，状 況 遷 移 図 は，プロジェクトの問 題 とその背 景 情 報 をもとに，該 当 プロジェ
クトの状 況 遷 移 図 上 での位 置 を特 定 し，プロセスパターンは，状 況 遷 移 図 上 の
位 置 情 報 をもとに実 際 のプロセスパターンを選 択 し，問 題 解 決 のための手 法 を提
示 することになる．
図 -5.2 知 識 の利 用 形 態
上 記 検 討 結 果 をもとに，図 -5.3に要 求 工 学 支 援 ツールの論 理 構 造 を示 す．要
求 技 術 者 は，図 -5.2に示 した知 識 の利 用 手 順 に従 って，問 題 を特 定 し，必 要 な
解 を得 るものとする．支 援 ツールは，「プロセス知 識 」，「要 求 工 学 手 法 の選 択 」，
「要 求 モデルの連 携 」などの知 識 ベースから成 り，利 用 者 の問 題 を特 定 し，適 切
な解 を導 き出 す．それぞれの知 識 に固 有 の図 や座 標 ，あるいはテキストを使 った
122
第5章
まとめと今後の課題
表 現 は，知 識 表 現 ベースとして参 照 可 能 となっている．
制 御 部 は，ユーザインタフェース部 を介 してツールの利 用 者 と会 話 し，利 用 者
の抱 えている問 題 を解 決 するのに必 要 な知 識 ベースを選 択 する．選 択 された知
識 ベースの条 件 部 は，利 用 者 から必 要 な情 報 を入 手 し，その利 用 者 独 自 のプロ
ジェクトモデルを作 成 する．結 論 部 は，このモデルをもとに問 題 の解 を求 め，利 用
者 にそれを提 示 する．
マルティメディア型 の知 識 とルールベースの知 識 の連 動 や，新 たな知 識 の追 加
機 構 など，解 決 すべき多 くの課 題 が残 っているが，教 育 的 効 果 も視 野 に入 れた
支 援 ツールの実 現 については，今 後 の研 究 課 題 の１つである．
図 -5.3 要 求 工 学 支 援 ツールの機 能 構 造
5. 4. 結 び
本 論 文 では，要 求 工 学 における，問 題 解 決 ，手 法 選 択 ，モデル連 携 という代
表 的 な３つの問 題 における発 見 的 知 識 と工 学 的 知 識 を利 用 するためのフレーム
ワークについて提 案 した．議 論 の対 象 となったこれらの知 識 は，要 求 工 学 プロセ
スの設 計 ，実 行 ，保 守 における代 表 的 な知 識 である．こうした知 識 の活 用 につい
ては，本 文 中 にも述 べたように，偶 発 的 アプローチとして多 くの研 究 報 告 があるが，
知 識 の体 系 化 にまで言 及 した研 究 は少 ない．発 見 的 知 識 は，工 学 的 な知 識 と
第5章
まとめと今後の課題
123
合 体 させることによって，要 求 技 術 者 の抱 える問 題 に適 切 に応 えることが可 能 と
なる．本 論 文 における知 識 フレームワークも，そうした総 合 的 な知 識 の体 系 化 を
目 指 したものであり，知 識 の表 現 法 にまで言 及 することによって，支 援 システムの
可 能 性 についても述 べることができた．
要 求 工 学 は，その対 象 や作 業 形 態 から，学 際 的 な色 彩 を持 たざるを得 ない領
域 であり，熟 練 した要 求 技 術 者 の経 験 的 知 識 が大 きな比 重 を占 め続 けるだろう．
発 見 的 知 識 と工 学 的 知 識 の融 合 と体 系 化 およびその表 現 に関 する本 研 究 の意
義 がそこにあると考 える．本 研 究 で取 り扱 うことのできなかったその他 の領 域 にお
ける知 識 の体 系 化 は，支 援 システムの実 現 と共 に，今 後 の研 究 課 題 とする．
124
第5章
まとめと今後の課題
参考文献
[1] Akao, Y. Quality Function Deployment: Integrating Customer Requirements
into Product Design. Productivity Press, 1990.
[2] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I.
and Angel, S. A Pattern Language. Oxford University Press, 1977.
[3] Alexander, C. The Timeless Way of Building. Oxford University Press, 1979.
[4] Alexander, I, Robertson, S. and Maiden, N. What influences the
requirements process in industry? Proc. of 13th International Requirements
Engineering Conference, 2005, pp. 411-415.
[5] Ambriola, V. and Gervasi, V. Processing natural language requirements.
Proc. of 12th International Conference on Automated Software Engineering,
1997, pp. 36-45.
[6] American Supplier Institute. Quality Function Deployment: A Collection of
Presentations and QFD Case Studies. American Supplier Institute, 1986.
[7] Anton A. I. Goal-based requirements analysis. Proc. of 2nd International
Conference on Requirements Engineering, 1996, pp. 136-144.
[8] Antoniou, G. The role of nonmonotonic representations in requirements
engineering. International Journal of Software Engineering and Knowledge
Engineering 8(3): 385-399, 1998.
[9] Bergman, M. and Mark, G. In situ requirements analysis: A deeper
examination of the relationship between requirements determination and
project selection. Proc. of 11th International Requirements Engineering
Conference, 2003, pp. 11-22.
[10] Berlin, L.M. User-centered application definition: A methodology and case
study. Hewlett-Packard Journal 40(5): 90-97, 1989.
126
参考文献
[11] Boehm, B. Software Engineering Economics. Prentice Hall, 1981.
[12] Boehm, B. A spiral model of software development and enhancement. IEEE
Computer 21(5): 61-72, 1988.
[13] Boehm, B. Software risk management: Principles and practices. IEEE
Software 8(1): 32-41, 1991.
[14] Boehm, B., Bose, P., Horowitz, E. and Lee, M. Software requirements as
negotiated win conditions. Proc. of 1st International Conference on
Requirements Engineering, 1994.
[15] Boehm, B. and In, H. Identifying quality-requirement conflicts. IEEE
Software 13(2): 25-35, 1996.
[16] Boehm, B. Requirements that handle IKWISI, COTS and rapid changer.
IEEE Computer 33(7): 99-102, 2000.
[17] Bohner, S. and Arnold, R. Software Change Impact Analysis. IEEE
Computer Society Press, 1996.
[18] Booch, G. Object-Oriented Analysis and Design with Application, Addison
Wesley, 1994.
[19] Brinkkemper, S. and Joosten, S. Editorial: Method engineering and
meta-modeling. Information and Software Technology 38(4): 259, 1996.
[20] Brooks, F.P. No silver bullet: Essence and accidents of software engineering.
IEEE Computer, 20: 10-19, 1987.
[21] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M.
Pattern-Oriented Software Architecture - A System of Patterns. John Wiley &
Sons, 1996.
[22] Carroll, J.M. and Swatman, P.A. Managing the RE process: Lessons from
commercial practice. Proc. of 5th International Workshop on Requirements
Engineering: Foundations of Software Quality REFSQ'99, 1999, pp. 3-17.
[23] Cameron, J.R. Prototyping core functionality using JSD. IEE Colloquium on
参考文献
127
Requirements Capture and Specification for Critical Systems (138): 2/1-2.
1989.
[24] Checkland, P. and Scholes, J. Soft Systems Methodology in Action. John
Wiley & Sons, 1990.
[25] Christel, M.G. and Kang, K.C. Issues in requirements elicitation. Technical
Report CMU/SEI-92-TR-12, 1992.
[26] Chung, L., Nixon, B., Yu, E. and Mylopoulos, J. Non-Functional
Requirements in Software Engineering. Kluwer Academic Publishers, 2000.
[27] Clarke, J., Cross, O. and Peled, A. Model Checking. MIT press, 1999.
[28] Cockburn, A. Writing Effective Use Case. Addison Wesley, 2001.
[29] Coplien, J.O. Software Patterns. SIGS Books & Multimedia, 1996.
[30] Coplien, J.O. and Schmidt, D.C. Pattern Languages of Program Design.
Addison Wesley, 1998.
[31] Coughlan, J. and Macredie, R. D. Effective communication in requirements
elicitation: A comparison of methodologies. Requirements Engineering
Journal 7(2): 47-60, 2002.
[32] Dano, B., Briand, H. and Barbier, F. An approach based on the concept of
use case to produce dynamic object-oriented specifications. Proc. of 3rd
International Symposium on Requirements Engineering, 1997, pp. 54-64.
[33] Dardenne, A., Lamsweerde, A.V. and Fickas, S. Goal directed requirements
acquisition. Science of Computer Programming 20 (1-2): 3-50, 1993.
[34] Davis, G.B. Strategies for information requirements determination. IBM
Systems Journal 21(1): 4-30, 1982.
[35] Davis, A.M. Software Requirements: Analysis and Specification. Prentice
Hall, 1990.
[36] Davis, A.M. Operational prototyping: A new development approach. IEEE
Software 9(5): 70-78, 1992.
128
参考文献
[37] Delugach, H.S. A multiple viewed approach to software requirements. Ph.D.
thesis, University of Virginia, 1991.
[38] DeMarco, T. Structured Analysis and System Specification. Prentice Hall,
1979.
[39] Deutsch, M.S. Focusing real-time systems analysis on user operations. IEEE
Software 5(5):39-50, 1988.
[40] Domges, R. and Pohhl, K. Adapting traceability environments to project Specific needs. Communications of ACM 41(12): 54-62, 1998.
[41] Dubois, E., Hagelstein, J. and Rifaut, A. Formal requirements engineering
with ERAE. Philips Journal of Research 43(3/4): 393-414, 1988.
[42] Easterbrook, S. Resolving conflicts between domain descriptions with
computer-supported negotiation. Knowledge Acquisition: An International
Journal 3: 255-289, 1991.
[43] Easterbrook, S. and Nuseibeh, B. Managing inconsistencies in an evolving
specification. Proc. of 2nd International Symposium on Requirements
Engineering, 1995, pp. 48-55.
[44] Eriksson, H. and Penker, M. Business Modeling with UML. John Wiley &
Sons, 2000.
[45] Estublier, J. Software configuration management: A roadmap. Proc. of 22nd
International Conference on Software Engineering - Future of Software
Engineering, 2000, pp. 279-289.
[46] Fagan, E. Design and code inspection to reduce errors in program
development. IBM systems journal 15(3):182-211, 1976.
[47] Ferdinandi, P.L. Requirements Pattern. Addison Wesley, 2002.
[48] Fillmore, C.J. The Case for Case. in Bach and Harms (Eds.). Universals in
Linguistic Theory, 1968.
[49] Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L. and Goedicke, M.
参考文献
129
Viewpoints: A framework for integrating multiple perspectives in system
development. International Journal of Software Engineering and Knowledge
Engineering 2(1):31-58, 1992.
[50] Finkelstein, A. Requirements engineering: An overview. Proc. of 2nd
Asia-Pacific Software Engineering Conference, 1993, pp. 152-164.
[51] Finkelstein, A., Gabbay, D., Hunter, A., Kramer, J. and Nuseibeh, B.
Inconsistency handling in multi-perspective specifications. IEEE
Transactions on Software Engineering, 20: 569-578, 1994.
[52] FIPS183, Federal Information Processing Standards Publication 183:
Integration definition for Function Modeling (IDEF0). 1993.
[53] Fowler, M. Analysis Patterns: Reusable Object Models. Addison Wesley,
1997.
[54] Gamma, E., Helm, R., Johnson, R. and Vlissides, J. Design Patterns:
Elements of Reusable Object- Oriented Software. Addison Wesley, 1995.
[55] Ghezzi, C. and Nuseibeh, B. Guest Editorial - Managing Inconsistency in
Software Development. IEEE Transactions on Software Engineering 24(11):
906-907, 1998.
[56] Goguen, J. and Linde, C. Techniques for requirements elicitation. Proc. of
1st International Symposium on Requirements Engineering, 1993, pp.
152-164.
[57] Grady, R. Practical Software Metrics for Project Management and Process
Improvement. Prentice Hall, 1992.
[58] Grudin, J. and Pruitt, J. Personas, participatory design and product
development: An infrastructure engagement. Proc. of Participatory Design
Conference, 2002, pp. 144-161.
[59] Hagge, L. and Lappe, K. Pattern for RE process. Proc. of 12th Requirements
Engineering Conference, 2004, pp. 90-99.
[60] Harmsen, F., Brinkkemper, S. and Oei, H. Situational method engineering
for information system project approaches. In Methods and Associated Tools
130
参考文献
for the Information Systems Life Cycle, pp. 169 - 194. Elsevier Science B.V.,
1994.
[61] Heitmeyer, C.L., Jeffords, R.D. and Labaw, B.G. Automated consistency
checking of requirements specifications. ACM Transactions on Software
Engineering and Methodology 5(3): 231-261, 1996.
[62] Hickey, A.M. and Davis, A.M. Elicitation technique selection: How do
experts do it? Proc. of 11th International Requirements Engineering
Conference, 2003, pp. 169-178.
[63] Holbrook, C.H. A scenario-based methodology for conducting requirements
elicitation. ACM SIGSOFT Software Engineering Notes 15 (1): 95-104, 1990.
[64] Holzmann, G. The model checker Spin. IEEE Transactions on Software
Engineering 23(5): 279-295, 1997.
[65] Hudlicka, E. Requirements elicitation with indirect knowledge elicitation
technique: Comparison of three methods. Proc. of 2nd International
Conference on Requirements Engineering, 1996, pp. 4-11.
[66] Hunter, A. and Nuseibeh, B. Managing inconsistent specifications:
Reasoning, analysis and action. ACM Transactions on Software Engineering
and Methodology 7(4): 335-367, 1998.
[67] Hutinsky, Z., Vrcek, N. and Bubas, G. Communication Problems in Complex
Information System Development Project. University of Zagreb, 2001.
[68] IEEE, Standard Glossary of Software Engineering Terminology. Std
610.12-1990 (revision and redesignation of IEEE Std. 729-1983), 1983.
[69] IEEE, Recommended Practice for Software Requirements Specifications. Std
830-1998, 1998.
[70] Jackson, M. System Development. Prentice Hall, 1983.
[71] Jackson, M. Software Requirements and Specifications: A Lexicon of
Practice, Principles and Prejudices. Addison Wesley, 1995.
[72] Jackson, M. and Zave, P. Deriving specifications from requirements: An
131
参考文献
example. Proc of 17th International Conference on Software Engineering,
1996, pp. 15-24.
[73] Jackson, M. Problem Frames: Analyzing and Structuring Software
Development Problems. Addison Wesley, 2001.
[74] Jacobson, I., Christerson, M., Jonsson, P. and Overgaard,
Object-Oriented Software Engineering. Addison Wesley, 1992.
G.
[75] Jacobson, I., Christerson, M., Jonsson, P. and Overgaard, G. The Object
Advantage. Addison Wesley, 1995.
[76] Jacobson, I., Griss, M. and Jonsson, P. Software Reuse. Addison Wesley,
1997.
[77] Jacobson, I. Usecase and aspect - Working seamlessly together. Journal of
object technology 2(4):7-28, 2003.
[78] Jarke, M. Requirements tracing. Communications of ACM 40(12): 32-36,
1998.
[79] Johnson, P. Human-Computer Interaction: Psychology, Task Analysis and
Software Engineering. McGraw Hill, 1992.
[80] Johnson, R.E. Documenting
OOPSLA’92, 1992, pp. 63-76.
frameworks
using
patterns.
Proc.
of
[81] Jones, C.B. Systematic Software Development using VDM, 2nd Edition.
Prentice Hall, 1990.
[82] Kaiya, H., Horai, H. and Saeki, M. AGORA: Attributed goal-oriented
requirements analysis method. Proc. of 10tn Requirements Engineering
Conference, 2002, pp. 13-22.
[83] Kang, C., Cohen, G., Hess, A., Novak, E. and Peterson, A. Feature-oriented
domain
analysis
(FODA)
feasibility
study.
Technical
Report
CMU/SEI-90-TR-21, ADA235785, Software Engineering Institute, 1990.
[84] Kawakita, J. The Original KJ Method. Kawakita Research Institute, 1991.
132
参考文献
[85] Kramer, J., Ng, K., Potts, C. and Whitehead, K. Tool support for
requirements analysis. Software Engineering Journal 3(3):86-96, 1988.
[86] Kruchten, P. The Rational Unified Process. Addison Wesley, 1998.
[87] Lamsweerde, A.V. Goal-oriented requirements engineering: A guided tour.
Proc. of 9th International Symposium on Requirements Engineering, 2001,
pp. 249-263.
[88] Lévi-Strauss, C. Tristes Tropiques. Plon, 1955.
[89] Loucopoulos, P. and Champion, M. Knowledge-based support for
requirements
engineering.
Information
and
Software
Technology
31(3):123-135, 1989.
[90] Loucopoulos, P. and Kavakli, E. Enterprise modelling and the teleological
approach to requirements engineering. International Journal of Intelligent
and Cooperative Information Systems 4(1): 45-79, 1995.
[91] Mader, M. Designing Tool Support for Use-Case-Driven Test Case
Generation. Di-plomarbeit, FHTW Berlin, 2004.
[92] Maiden, N. and Sutcliffe, A. Exploiting reusable specifications through
analogy. Communications of the ACM 34(5): 55-64, 1992.
[93] Maiden, N. and Rugg, G. ACRE: Selecting methods for requirements
acquisition. Software Engineering Journal 11(3): 183-192, 1996.
[94] Maiden, N. CREWS-SAVRE: Scenarios for acquiring and validating
requirements. Automated Software Engineering 5(4): 419-446, 1998.
[95] Marshall, C. Enterprise Modeling with UML. Addison Wesley, 2000.
[96] Meyer, B. Object-Oriented Software Construction. Prentice Hall, 1988.
[97] Mohagheghi, P., Anda, B. and Conradi, R. Effort estimation of use cases for
incremental large-scale software development. Proc. of 27th International
Conference on Software Engineering, 2005, pp. 303-311.
[98] Mylopoulos, J., Chung, L. and Nixon, B. Representing and using
133
参考文献
nonfunctional
requirements:
A process-oriented
approach.
Transactions on Software Engineering 18 (6): 483-497, 1992.
IEEE
[99] Naumann, J., Davice, G. and Mckeen, J. Determining information
requirements: A contingency method for selection of a requirements
assurance strategy. The Journal of Systems and Software 1: 273-281, 1980.
[100] Neighbors, J. The Draco approach to constructing software from reusable
components. IEEE Transactions on Software Engineering 10(5): 564-573,
1984.
[101] Norman, D. A. and Draper, S. W. User-Centered System Design: New
Perspectives on Human-Computer Interaction. Lawrence Earlbaum
Associates, 1986.
[102] Nuseibeh, B., Kramer, J. and Finkelstein, A. A framework for expressing the
relationships between multiple views in requirements specifications. IEEE
Transactions on Software Engineering 20(10): 760-773, 1994.
[103] Nuseibeh, B., Finkelstein, A. and Kramer, J. Method engineering for
multi-perspective software development. Information and Software
Technology Journal 38(4): 267-274, 1996.
[104] Nuseibeh, B. Ariane 5: Who Dunnit? IEEE Software 14(3): 15-16, 1997.
[105] Nuseibeh, B. and Easterbrook, S. Requirements engineering: A roadmap.
Proc. of 22nd International Conference on Software Engineering - Future of
Software Engineering, 2000, pp. 35-46.
[106] Ohnishi, A. Software requirements specification database based on
requirements frame model. Proc. of 2nd International Conference on
Requirements Engineering, 1996, pp. 221-228.
[107] 大 西 淳 要 求 工 学 ワーキンググループ活 動 報 告 . 情 報 処 理 学 会 研 究 報 告 ,
ソフトウェア工 学 研 究 会 -No.130: 127-134, 2001.
[108] Padula, A. Requirements engineering process selection at Hewlett - Packard.
Proc. of 12th International Requirements Engineering Conference, 2004, pp.
296-300.
134
参考文献
[109] Parnas, D.L. A technique for software module specification with examples.
Communications of the ACM 15(5):330-336, 1972.
[110] Parnas, D.L. and Madey, J. Functional documentation for computer systems.
Science of Computer Programming 25(1): 41-61, 1995.
[111] Pinherio, F. and Goguen, J. An object oriented
requirements. IEEE Software 13(2): 52-4, 1996.
tool
for
tracing
[112] Potts, C., Takahashi, K. and Anton, A. Inquiry-based requirements analysis.
IEEE Software 11(2): 21-32, 1994.
[113] Potts, C. Requirements models in context. Proc. of 3rd International
Symposium on Requirements Engineering, 1997, pp. 102-104.
[114] Punter, T. and Lemmen, K. The MEMA-model: towards a new approach for
method engineering. Information and Software Technology 38: 295-305,
1996.
[115] Rieto-Di´az, R. Domain analysis: An introduction. ACM SIGSOFT Software
Engineering Notes 15 (2): 47-54, 1990.
[116] Robertson, S. and Robertson, J. Mastering the Requirements Process.
Addison Wesley, 1999.
[117] Robinson, W.N. and Volkov, S. Supporting the negotiation life-cycle.
Communications of the ACM 41(5): 95-102, 1998.
[118] Rolland, C., Souveyet, C. and Achour, C. B. Guiding goal modeling using
scenarios. IEEE Transaction on Software Engineering 24 (12): 1055-1071,
1998.
[119] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W.
Object-Oriented Modeling and Design. Prentice Hall, 1991.
[120] Russo, A., Miller, R., Nuseibeh, B. and Kramer, J. An abductive approach
for analysing event-based requirements specifications. Proc. of 18th
International Conference on Logic Programming, 2002, pp. 22-33.
[121] Rzepka, W.E. A Requirements engineering testbed: Concept, status, and first
参考文献
135
results. In Bruce D. Shriver (editor), Proc. of 22nd Annual Hawaii
International Conference on System Sciences, 1989, pp.339-347.
[122] Saaltink, M. The Z/EVES System. Proc. of 19th International Conference
on the Z Formal Method, 1997, pp. 72-88.
[123] Saaty, T.L. The Analytic Hierarchy Process. McGraw Hill, 1980.
[124] Sage, A.P. and Palmer, J.D. Software Systems Engineering. John Wiley &
Sons, 1990.
[125] Savolainen, V. A dynamic framework of reference of information systems
development. Dynamic modelling of information systems II (eds. Sol H G,
Grosslin R L). Elsevier Science Publishers: 285-307, 1992.
[126] Schwaber, K. and Beedle, M. Agile Software Development with SCRUM.
Prentice Hall, 2001.
[127] Sharp, H., Finkelstein, A. and Galal, G. Stakeholder identification in the
requirements engineering process. Proc. of Workshop on Requirements
Engineering Processes - DEXA, 1999, pp. 387-391.
[128] Shaw, M. Prospects for an engineering discipline of software. IEEE
Software 7(6): 15-24, 1990.
[129] Shaw, M. and Gaines, B. Requirements acquisition. Software Engineering
Journal 11(3): 149-165, 1996.
[130] Southwell, K., James, K., Clarke, B., Andrews, B., Ashworth, C., Norris, M.
and Patel, V. Requirements Definition and Design. The STARTS Guide, 2nd
Edition. National Computing Centre, 1987.
[131] Sowa, J.F. and Zachman, J.A. Extending and formalizing the framework for
information systems architecture. IBM System-J 31(3): 590- 616, 1992.
[132] Spivey, J.M. The Z Notation--A Reference Manual 2nd Edition. Prentice
Hall, 1992.
[133] Standish Group Chaos. Standish Group Inc, 1994.
136
参考文献
[134] Stewart, D.W. and Shamdasani, P.N. Focus Groups: Theory and Practice.
Sage, 1990.
[135] Sullivan, C.H. Systems planning in the information age. Sloan Business
Review 26(2): 3-11, 1985.
[136] Systems Designers Scientific. CORE: The Method. Systems Designers
Scientific, 1985.
[137] Takeda, N., Shiom, A., Kawai, K. and Ohiwa, H. Requirements analysis by
KJ editor. Proc. of 1st International Symposium on Requirements
Engineering, 1993, pp. 98–101.
[138] 玉 井 哲 雄 ソフトウェア工 学 の基 礎 , 岩 波 書 店 , 2004.
[139] Tamai, T., Ubayashi, N. and Ichiyama, R. An adaptive object model with
dynamic role binding. Proc. of 27th International Conference on Software
Engineering, 2005, pp.166-175.
[140] Tarr, P., Ossher, H., Harrison, W. and Sutton, S. N degrees of separation:
Multi-dimensional separation of concerns. Proc of 21st International
Conference on Software Engineering, 1999.
[141] Tsumaki, T. and Morisawa, Y. A framework of requirements tracing using
UML. Proc. of 7th Asia-Pacific Software Engineering Conference, 2000, pp.
206-213.
[142] Tsumaki, T. Requirements engineering pattern structure. Proc. of 11th
Asia-Pacific Software Engineering Conference, 2004, pp. 502-509.
[143] Tsumaki, T. and Tamai, T. A framework for matching requirements
engineering techniques to project characteristics. Software Process:
Improvement and Practice 11(5): 505-519, 2006.
[144] Verner, J., Cox, K., Blerstein, S. and Cerpa, N. Requirements engineering
and software project success: An industrial survey in Australia and the U.S.
Proc. of 9th Australian Workshop on Requirements Engineering, 2004, pp.
225-238.
[145] Viller, S. and Sommerville, I. Social analysis in the requirements
参考文献
137
engineering process: From ethnography to method. Proc. of 4th International
Symposium on Requirements Engineering, 1999, pp. 6-13.
[146] Vlasblom, G., Rijsenbrij, D. and Gastra, M. Flexibilization of the
methodology of system development. Information and Software Technology:
Elsevier-Science B.V. 37 (11): 595-607, 1995.
[147] Wooldridge, M., Jennings, N. and Kenny, D. The Gaia methodology for
agent-oriented analysis and design. Autonomous Agent and Multi-Agent
Systems 3: 285-312, 2000.
[148] Yadav, S.B., Bravoco, R.R., Chatfield, A.T. and Rajikumar, T.M.
Comparison of analysis techniques for information requirement
determination. Communication of ACM 31 (9): 1090-1097, 1988.
[149] Yu, E. Towards modelling and reasoning support for early-phase
requirements engineering. Proc. of 3rd International Symposium on
Requirements Engineering, 1997, pp. 226-235.
[150] Zachman, J.A. A framework for information systems architecture. IBM
System-J 26(3): 276-292, 1987.
[151] Zahniser, R.A. How to speed development with group sessions. IEEE
Software 7(3): 109-110, May 1990.
[152] Zave, P. An operational approach to requirements specification for
embedded systems. IEEE Transactions on Software Engineering 8(3):
250-269, 1982.
[153] Zeroual, K. An approach for automating the specification - acquisition
process. Proc. of 2nd International Workshop on Software Engineering and
its Applications, 1989, pp. 349-355.
[154] Zhao, J. Slicing aspect-oriented software. Proc. of 10th International
Workshop on Program Comprehension, 2002, pp. 251-260.
[155] Zucconi, L. Techniques and experiences capturing requirements for several
real-time applications. ACM SIGSOFT Software Engineering Notes 14(6):
51-55, 1989.
138
参考文献