2011年6月号
SOLE
SOLE
ソフトウェアへの要求を定義する要求工学の体系と技術を学ぶ
SOLE 日本支部フォーラムの報告
The International Society of Logistics
JUNE 2011 76
ＳＯＬＥ日本支部四月度のフォー
ラムでは、日本ユニシス上席研究員
兼国立情報學研究所教授の妻木俊彦
氏が﹁要求工学﹂について講演を行
った。
﹁要求工学﹂とは、システムに 求められる要求事項をとりまとめる エンジニアリング体系である。
特にソ フトウェア開発に必要なオブェクト志 向・要求獲得法、仕様書作成、変更 管理などの技術の概要説明と以下の 文章の寄稿もいただいた。
︵企画担当 ：ＳＯＬＥ日本支部会員 菊地徹︶ システム開発の最大の課題 米国の調査会社のレポートによれ ば、企業のＩＴ統括責任者の約半数 が、ソフトウェア開発プロジェクトが 失敗する主たる原因として要求関連 事項を挙げているという（図１）【１】。
そのトップスリーを見てみると、 「ユーザの参加不足」、「不完全な要求 および仕様」、「要求および仕様の頻 繁な変更」という原因が上がっており、 この傾向は、現在の日本のソフトウェ ア開発プロジェクトが抱えている大き な問題でもある。
何故、要求という問題がソフトウ ェア開発にそれほど大きな影響を与え るのであろうか。
それは、要求定義 プロセスがソフトウェア開発プロセス における、「意味」を取り扱う唯一の プロセスであるということに深く関係 しているように思われる。
意味とは現実世界で価値を生み出 すものであり、コンピュータが実現し なければならないことである。
そし て、それは要求定義の段階で決定さ れていなければならない。
設計から実装に至るプロセスでは、 定義された要求をコンピュータを使っ て実現する、言い換えれば、意味を 変えずに、形式を変換しているとい うことができる。
意味が明確に定義 されなければ、ソフトウェア開発その ものが失敗するのは自明の理である。
ソフトウェアに対する要求は、その 性質によって機能要求、非機能要求、 制約条件、の大きく三種類に分けら れる。
機能要求は、コンピュータによっ て実現してもらいたいことであり、ソ フトウェアを実行することによって、 特定の対象に変化をもたらす活動の ことである。
非機能要求は、機能要求を実現す る上で守ってほしいことであり、ソフ トウェアを実行する上で維持すべき属 性である。
非機能要求は、さらに品 質要求と性能要求に分けられる。
品 質要求とは、信頼性や安全性、操作 性、保守性といったシステム属性のこ とであり、性能要求とは実行時の量 的、時間的な処理能力のことである。
また、オープンなネットワーク環境 で動くコンピュータシステムには、セ キュリティの管理やプライバシーの保 護といった安全性に関する対策が強く 求められるようになっている。
この ため、ソフトウェア要求には「しては ならない」制約条件も含まれ、法律 や法令のように明文化されたものか ら、文化的・社会的な制約まで多岐 にわたる。
はじめに問題を理解する ソフトウェアの発注者や利用者が求 めるニーズや要求は、要求仕様とし て、次の工程の担当者である設計者 に正確に伝達されなければならない。
しかし、これらの作業の中で、要求 分析者は多くの問題に直面すること になる。
要求を漏れなく収集するに はどうすればよいか、要求を正確に 伝えるには何をどのように記述すれ ばよいか、要求変更が発生したらど のように対応すればよいか、相反す る要求が提示された時にはどのよう に調整すればよいか。
このように要 求定義の工程で発生するさまざまな 問題を解決しようとする技術の集合 が、「要求工学」である。
こうした問 題を解決するためには、システム工学 ソフトウェアへの要求を定義する 要求工学の体系と技術を学ぶ ?ユーザの参加不足 ?要求および仕様が不完全 ?要求および仕様がよく変更になる ?経営者側からの支援不足 ?技術的能力の不足 ?リソースの不足 ?現実的でない期待 ?不明確な目的 ?現実的でない納期 ?全く実績のない新規技術 図1 ソフトウェア開発プロジェクトが失敗する主な原因 （CAOSレポートより：Standish） その他 ? ? ? ? ? ? ? ? ? ? 77 JUNE 2011 解決すべき問題を理解し、解法を 発見する ●ステークホルダ分析：要求を持って いる人を選定する ●要求抽出：具体的な要望や要求を 収集する 問題分析のための手法は要求工学 の中でも新しい技術に属する。
ここ に位置づけられる手法の多くは、発 想法と呼ばれる技術系列に属するも のが多く、人が持っている創造的な 能力をためるための技術がその中核 を担っている。
また、要求工学独自 の手法というより、他の領域、例え ばビジネス分析や民族学などで開発さ れた手法を要求工学に取り入れてい るケースも多い。
こうした手法群は超上流要求工学 などとも呼ばれる。
特に、ＫＪ法【４】 やソフトシステムズ方法論【５】、ある いは、ロジカルシンキング【６】等の 手法は、要求工学にとって重要な視 点や考え方を提供してくれている。
一方、伝統的なソフトウェア工学 の手法を駆使した問題分析手法も提 案されている。
代表的な手法に、初 期フェーズ要求工学手法と呼ばれる i★ （アイスター）法がある【７】。
i ★ 法はカナダのトロント大学でE.Yuた ちによって提案された学術的手法であ るが、その有効性が注目を浴び、実 た技法群であり、左側は静的な側面 に焦点を当てた技法群である。
また、縦軸は対象領域の性質を表 している。
上側は対象領域が閉じて いる世界、すなわち、よく知られて おり、変化の少ない領域に適用され る技法群で、反対に、下方は、開い ている世界、すなわち、その内部が よく知られておらず、常に変化し続 けているような領域に適用される技 法群である。
これらの技術は、その使用目的に よって、大きく情報収集の ための手法群と要求分析の ための手法群に分けること ができる。
ここでの情報収 集とは、システム化の対象 領域を定義し、要求者を特 定し、要求を収集するため の作業であり、要求分析と は、本質的な要求を認識し たり、未発見の要求を探し たり、矛盾した要求同士の 調整を図ったりする作業で ある。
情報を収集する 情報収集作業を支えるた めの手法には、次のような ものがある。
●問題分析：対象領域の や人類学、さらには認知科学や言語 学の知識も必要となってくる。
これまで、ソフトウェア要求に関わ る作業は要求分析とか要求定義と呼 ばれ、要求分析者がソフトウェアの 開発を依頼したクライアントやその使 用者であるユーザから、彼らのニーズ や要求を聞き出し、それを要求仕様 書にまとめあげる作業であると考え られてきた。
しかし、ソフトウェアの与える影響 が広く社会全体に広がるようになる にしたがって、特定の個人の要望を 満足していればよいという時代は過 ぎ去ってしまったと言ってよい。
新た な要求工学とは、そうした背景の元、 対象領域が抱えている問題そのもの に深くアプローチしようとするもので ある。
要求工学が目指している新た な枠組みとは、次のようなものであ る【２】。
１．対象領域が抱えている問題を理 解する ２．問題を解決するための方法を発 見する ３．ソフトウェアによる実現方法を 定義する 以下に、要求工学の中から代表的 な手法を紹介する。
要求を獲得する 要求工学の中心的テーマは、如何 に正確な要求を入手するかということ であり、これに関わる手法を総称して 要求獲得（requirements elicitation） と呼ぶ。
要求獲得は極めて多様な技 術群から構成されている。
図２は、 要求獲得に関する主要な技術のマップ である【３】。
ここで、横軸は、分析者の視点の 特性を示している。
すなわち右側は 対象領域の動的な性質に焦点を当て ドメイン分割 プロブレム フレーム 構造化 インタビュー 図2 主要な要求獲得技術のマップ i★ 物語法 シナリオ ユースケース MSC プロトタイピング ロールプレイ エスノグラフィー GBRAM KAOS ゴール カード ソーティング 閉じている（Closed） 開いている（Open） 動的 知的 （Dynamic） （Static） KJ 法 アブダクション ブレーン ストーミング JUNE 2011 78 適切なシステムが実現しないことは言 うまでもない。
ステークホルダの選定 は、情報収集にとって極めて重要な 作業である。
ステークホルダには、次 のような役割の人が含まれる【８】。
●ビジネス関係者：ビジネス分析者、 市場、その製品を欲しない批判者、 その製品に独自のユーザグループ、 特定団体 ●システム関係：プロジェクトの管理 者や後援者、システム開発者、技 術専門家、隣接システム ●監視者：安全監視者、技術監査 役、弁護士や警察官といった法律 関係者、政府やその出先機関、身 障者や老人などの特定団体、宗教 や政治・民族・文化に関わる文化 関係者 ステークホルダが選定されたら、彼 らから漠然とした願望やその領域特 有の規則なども含め、さまざまな情 報を収集することになる。
そのため の方法で最も一般的なのがインタビュ ーである。
インタビューは簡単な割に情報収集 の効率がよいが、重要な情報を得る ために、事前に問題点を整理してお く必要がある。
その他の情報収集手 段としては、さまざまな関連文書を 探したり、作業者の実際の活動現場 業務の中でも試行をする例が増えつつ ある。
i ★ 法の特徴は、ドメインモデル、 シナリオ、ゴール指向というモデル化 の三つの視点を統合した複合モデルで あるということであり、i ★ 法が目指 すのは、問題領域の基本的な構造と、 そこで発生している問題を正確に認 識し、情報システムによる問題の解決 法を探ることにある。
この手法が初 期フェーズ要求工学と呼ばれる所以で ある。
i ★ では、現状モデルと将来モデルを 描く。
それぞれのモデルは外部構造 モデルとアクター（関係者）の内部構 造モデルがあるので、計四つのモデル を作成することになる。
図３は、会 議の設定に関する将来内部構造モデ ルである。
ここでは、会議招集者の 「簡単に」とか「素早く」といったニ ーズがミーティングスケジューラ・シ ステムとして実現されている様子が描 かれている。
現在、情報システムの利用が広範 に行き渡るようになっているため、シ ステムの直接的なユーザの意見だけで なく、システムの利害関係者すなわ ちステークホルダから、広く情報を収 集する必要がでてきている。
重要な情報を持っているステークホ ルダを見落としたり、瑣末なステーク ホルダの意見を重要視したりすれば、 D D − D D D D D D D D D D − − − − − − − ＋ ＋ ＋ − − − − − − ＋ ＋ ＋ ＋ −＋ − − − Meeting Participant Arrange Meeting Attend Meeting Quality (ProposedDate) Agreeable (Meeting,Date) Low Effort User Friendly Richer Medium FindAgreeable DateUsing Scheduler Meeting Scheduler Schedule Meeting Attends Meeting Meeting Initiator MeetingBe Scheduled AgreeTo Date Enter AvailDates Obtain AvailDates Obtain Agreement Merge AvailDates FindAgreeable DateByTalking ToInitiator Find Agreeable Slot Proposed Date Agreement Convenient (Meeting,Date) Participate InMeeting Low Effort MeetingBe Scheduled LetScheduler Schedule Meeting Schedule Meeting Organize Meeting Quick Enter DateRange Goal Task Resource Soft-Goal Task-Decomposition link Means-ends link Contribution to softgoals Actor Actor Boundary LEGEND 図3 会議の設定に関する将来内部構造モデル 79 JUNE 2011 マップの第一象限に属する技法である。
シナリオと言うと、一般に、テキスト によって書かれた物語風のものを想像 するが、最近では、対象の変化に関 する図式もシナリオと呼ばれるように なった。
シナリオ型モデルで有名なのがユー スケースモデルである【1 1】。
図５は金 融業務に関するユースケースモデルの 一部であり、四角の箱の中の楕円形 がユースケースである。
ユースケース は、業務プロセスをモデル化したもの である。
ユースケースモデルの特徴は、 シナリオの多くが変化の順序に焦点を 当てているのに対し、プロセスの構造 に焦点を当てていることである。
た だし、それぞれのユースケースは、ユ ースケースシナリオという物語風のシ ナリオによって詳細化される。
ゴールモデルは、特定のゴールをゴ ール分解によって展開する手法で、技 法マップの第三象限に属する。
代表 的な手法にＫＡＯＳ法がある【 12 】。
ゴールとは、目標となる状態のこと であり、その性質によって幾つかの種 類に分類される。
成立条件による分 類では、これから実現させる必要の ある達成ゴールと、現在既に実現し ており、その状態を続ける必要のあ る維持ゴールがある。
また、達成条 件による分類では、ゴールの達成が計 測可能なハードゴールと、達成された モデルには、ドメインモデル、シナリ オ、ゴールモデルという三つのモデル がある。
ドメインモデルは、対象領域の静 的な側面、すなわち、そこに存在す る実体や現象をモデル化したもので、 図２の第二象限に属する技法である。
代表的なモデルにオブジェクトモデル がある【 10 】。
図４は、金融業務に関 するオブジェクトモデルの部分図であ る。
シナリオは、対象領域の動的な側 面、すなわち、時系列名変化や因果 関係をモデル化したものであり、技法 情報を元に要求分析を行う。
要求分 析の目的は、雑多な要求の中から正 しい要求を抽出したり、収集しそこ なった要求を発見したり、ステークホ ルダによって異なる要求の調整を図っ たりすることである。
要求分析のための手法には、モ デル化手法と非モデル化手法がある。
モデル化手法は対象領域全体の抽象 モデルを描き、そのモデルを元に構造 的な分析作業を行う。
他方、非モデ ル化手法では個別の事象を元に、そ れらをより深く検討する。
モデル化分析手法でよく用いられる を観察すると言った方法もある。
要求獲得に失敗しないためには、 分析者自身も問題領域に関する最低 限必要な知識を持っている必要もあ る。
また、要求獲得作業に入る前に、 システム化の対象範囲を明確に設定し ておくことも重要である。
変化の激 しい現代社会では、要求は頻繁に変 更になる。
この要求変更に如何に対 応するかが、要求獲得におけるプロジ ェクトの新たな課題である【９】。
要求を分析する 情報収集が終わったら、それらの 上位ゴール ゴール 下位ゴール 代替案 Why分解 ＋＋ ＋ ＋ ＋ ＋＋ ＋ − How分解 図6 ゴール分解におけるＷｈｙ分解とＨｏｗ分解 AND 図4 金融業務に関するオブジェクトモデルの部分図 融資担当 顧客 入金 法人顧客 個人顧客 勤務会社 出金 貸し付け ローン 自動振込み 保証人 図5 金融業務に関するユースケースモデルの部分図 顧客 1 * * 1 名前 住所 預金 預金 口座番号 預金口座 残高 個人顧客 企業顧客 当座預金口座 普通預金口座 定期預金口座 ことが計測できないソフトゴールがあ る。
図６に示したように、ゴール分解 にはＷｈｙ分解とＨｏｗ分解がある。
Ｗｈｙ分解は、そのゴールが何故必 要なのかという視点で分解したもの で、より本質的な上位ゴールが導出 される。
一方、Ｈｏｗ分解は、その ゴールを実現するための条件という視 点で分解したもので、実現方法が解 ゴールとして導出される。
下位ゴール同士の関係には、ＡＮ Ｄ関係とＯＲ関係がある。
ＡＮＤ関 係は、そのすべての下位ゴールが実現 しなければ上位ゴールが実現しないこ とを表している。
図中の＋や−の記 号は、下位ゴールの上位ゴールへの貢 献度を表している。
＋の数が多いほ ど、上位ゴールの実現可能性が高い。
要求を記述する 獲得された要求は、システム設計 者に伝達され、コンピュータ上での 実現方法が検討される。
したがって、 要求を如何に正確に分析者から設計 者に伝えられるかが、ここでの大き な問題となる。
最大の問題は、設計者は、コンピ ュータの専門家ではあっても、問題 領域に関する知識は持ち合わせていな いということである。
そこで、分析 者は問題領域の中で定義された要求 を、設計者にも理解できる形に変形 しなければならない。
これを要求仕 様という。
要求仕様は、問題領域の中での意 味を保持したまま、コンピュータによ って処理可能な形で記述する必要があ る。
すなわち、仕様は、両者にとっ て認識可能である共有現象によって 記述されなければならない【 13 】。
例え ば、動物園への入場者数という問題 領域の現象を、仕様ではコンピュータ にも認識可能な入場扉の回転数とい う共有現象に置きかえる必要がある。
仕様を文書化したものが要求仕様 書である。
要求仕様書を作成する上 では注すべきことが幾つかある【 14 】。
●正当性：仕様書には正しい要求だ けを記述すること ●非曖昧性：複数の解釈が可能な用 語や文章は避けること ●完全性：必要な要求はすべて記述 すること ●一貫性：仕様書内で異なった定義 を行わないこと ●重要性のランク付け：実現のため の優先順位付けを行うこと ●検証可能性：実現されたことを証 明する方法を示すこと ●変更可能性：要求変更発生時に仕 様書の変更が容易であること ●追跡可能性：仕様書の変更箇所か 【10】 Jacobson, I., Christerson, M., Jonsson, P. and Overgaard. G. Object-Oriented Software Engineering, Addison Wesley, 1995. 【11】 Fowler, M. and Kendall, S. UML Distilled, Addison-Wesley, 1997. 【12】 Lamsweed, A. V. Requirements Engineering, Willey, 2009. 【13】 Jackson, M. and Zave, P. Deriving specifications from requirements: An example. Proc of 17th International Conference on Software Engineering, 1996, pp. 15-24. 【14】 I E E E G u i d e t o S o f t w a r e Requirements Specifications. ANSI/IEEE Standard 830-1998. JUNE 2011 80 次回フォーラムのお知らせ 6月度のフォーラムは、6月15日 （水）日本能率協会コンサルティング （JMAC）の中森清美氏による講演「業 務機能展開とWBS」を予定している。
このフォーラムは年間計画に基づいて 運用しているが、単月のみの参加も可 能。
1回の参加費は6,000円。
ご希望の 方は事務局（ s-sogabe@mbb.nifty. ne.jp）までお問い合わせ下さい。
※ Ｓ Ｏ Ｌ Ｅ（The International Society of Logistics：国際ロジスティクス学会）は一 九六〇年代に設立されたロジスティクス団体。
米国に本部を置き、会員は五一カ国・三〇 〇〇〜三五〇〇人に及ぶ。
日本支部では毎 月「フォーラム」を開催し、講演、研究発 表、現場見学などを通じてロジスティクス・ マネジメントに関する活発な意見交換、議論 を行っている。
ら設計書やプログラムの変更箇所 を特定できること 要求工学には、この他にも多様な技 術が含まれるが、紙面の関係上、これ らの技術については割愛する。
参考文献 【1】 Standish Group Chaos. Standish Group Inc, 1994. 【2】 要求工学概論、近代科学社、2009. 【3】T s u m a k i , T . a n d T a m a i , T . A Framework for Matching Requirements Engineering Techniques to Project Characteristics, Software Process: Improvement and Practice 11(5): 505- 519, 2006. 【4】 Kawakita, J. The Original KJ Method. Kawakita Research Institute, 1991. 【5】 Checkland, P. and Scholes, J. Soft Systems Methodology in Action. John Wiley, 1990. 【6】 Minto, B. The Minto Pyramid Principle. Minto International Inc., 1996. 【7】 Yu, E. Towards modelling and reasoning support for early-phase requirements engineering. Proc. of 3 r d I n t e r n a t i o n a l S y m p o s i u m o n Requirements Engineering, 1997, pp.226-235. 【8】 Robertson, S. and Robertson, J. Mastering the Requirements Process. Addison Wesley, 1999. 【9】 Christel, M.G. and Kang, K.C. Issues in requirements elicitation. Technical Report CMU/SEI-92-TR-12, 1992.
﹁要求工学﹂とは、システムに 求められる要求事項をとりまとめる エンジニアリング体系である。
特にソ フトウェア開発に必要なオブェクト志 向・要求獲得法、仕様書作成、変更 管理などの技術の概要説明と以下の 文章の寄稿もいただいた。
︵企画担当 ：ＳＯＬＥ日本支部会員 菊地徹︶ システム開発の最大の課題 米国の調査会社のレポートによれ ば、企業のＩＴ統括責任者の約半数 が、ソフトウェア開発プロジェクトが 失敗する主たる原因として要求関連 事項を挙げているという（図１）【１】。
そのトップスリーを見てみると、 「ユーザの参加不足」、「不完全な要求 および仕様」、「要求および仕様の頻 繁な変更」という原因が上がっており、 この傾向は、現在の日本のソフトウェ ア開発プロジェクトが抱えている大き な問題でもある。
何故、要求という問題がソフトウ ェア開発にそれほど大きな影響を与え るのであろうか。
それは、要求定義 プロセスがソフトウェア開発プロセス における、「意味」を取り扱う唯一の プロセスであるということに深く関係 しているように思われる。
意味とは現実世界で価値を生み出 すものであり、コンピュータが実現し なければならないことである。
そし て、それは要求定義の段階で決定さ れていなければならない。
設計から実装に至るプロセスでは、 定義された要求をコンピュータを使っ て実現する、言い換えれば、意味を 変えずに、形式を変換しているとい うことができる。
意味が明確に定義 されなければ、ソフトウェア開発その ものが失敗するのは自明の理である。
ソフトウェアに対する要求は、その 性質によって機能要求、非機能要求、 制約条件、の大きく三種類に分けら れる。
機能要求は、コンピュータによっ て実現してもらいたいことであり、ソ フトウェアを実行することによって、 特定の対象に変化をもたらす活動の ことである。
非機能要求は、機能要求を実現す る上で守ってほしいことであり、ソフ トウェアを実行する上で維持すべき属 性である。
非機能要求は、さらに品 質要求と性能要求に分けられる。
品 質要求とは、信頼性や安全性、操作 性、保守性といったシステム属性のこ とであり、性能要求とは実行時の量 的、時間的な処理能力のことである。
また、オープンなネットワーク環境 で動くコンピュータシステムには、セ キュリティの管理やプライバシーの保 護といった安全性に関する対策が強く 求められるようになっている。
この ため、ソフトウェア要求には「しては ならない」制約条件も含まれ、法律 や法令のように明文化されたものか ら、文化的・社会的な制約まで多岐 にわたる。
はじめに問題を理解する ソフトウェアの発注者や利用者が求 めるニーズや要求は、要求仕様とし て、次の工程の担当者である設計者 に正確に伝達されなければならない。
しかし、これらの作業の中で、要求 分析者は多くの問題に直面すること になる。
要求を漏れなく収集するに はどうすればよいか、要求を正確に 伝えるには何をどのように記述すれ ばよいか、要求変更が発生したらど のように対応すればよいか、相反す る要求が提示された時にはどのよう に調整すればよいか。
このように要 求定義の工程で発生するさまざまな 問題を解決しようとする技術の集合 が、「要求工学」である。
こうした問 題を解決するためには、システム工学 ソフトウェアへの要求を定義する 要求工学の体系と技術を学ぶ ?ユーザの参加不足 ?要求および仕様が不完全 ?要求および仕様がよく変更になる ?経営者側からの支援不足 ?技術的能力の不足 ?リソースの不足 ?現実的でない期待 ?不明確な目的 ?現実的でない納期 ?全く実績のない新規技術 図1 ソフトウェア開発プロジェクトが失敗する主な原因 （CAOSレポートより：Standish） その他 ? ? ? ? ? ? ? ? ? ? 77 JUNE 2011 解決すべき問題を理解し、解法を 発見する ●ステークホルダ分析：要求を持って いる人を選定する ●要求抽出：具体的な要望や要求を 収集する 問題分析のための手法は要求工学 の中でも新しい技術に属する。
ここ に位置づけられる手法の多くは、発 想法と呼ばれる技術系列に属するも のが多く、人が持っている創造的な 能力をためるための技術がその中核 を担っている。
また、要求工学独自 の手法というより、他の領域、例え ばビジネス分析や民族学などで開発さ れた手法を要求工学に取り入れてい るケースも多い。
こうした手法群は超上流要求工学 などとも呼ばれる。
特に、ＫＪ法【４】 やソフトシステムズ方法論【５】、ある いは、ロジカルシンキング【６】等の 手法は、要求工学にとって重要な視 点や考え方を提供してくれている。
一方、伝統的なソフトウェア工学 の手法を駆使した問題分析手法も提 案されている。
代表的な手法に、初 期フェーズ要求工学手法と呼ばれる i★ （アイスター）法がある【７】。
i ★ 法はカナダのトロント大学でE.Yuた ちによって提案された学術的手法であ るが、その有効性が注目を浴び、実 た技法群であり、左側は静的な側面 に焦点を当てた技法群である。
また、縦軸は対象領域の性質を表 している。
上側は対象領域が閉じて いる世界、すなわち、よく知られて おり、変化の少ない領域に適用され る技法群で、反対に、下方は、開い ている世界、すなわち、その内部が よく知られておらず、常に変化し続 けているような領域に適用される技 法群である。
これらの技術は、その使用目的に よって、大きく情報収集の ための手法群と要求分析の ための手法群に分けること ができる。
ここでの情報収 集とは、システム化の対象 領域を定義し、要求者を特 定し、要求を収集するため の作業であり、要求分析と は、本質的な要求を認識し たり、未発見の要求を探し たり、矛盾した要求同士の 調整を図ったりする作業で ある。
情報を収集する 情報収集作業を支えるた めの手法には、次のような ものがある。
●問題分析：対象領域の や人類学、さらには認知科学や言語 学の知識も必要となってくる。
これまで、ソフトウェア要求に関わ る作業は要求分析とか要求定義と呼 ばれ、要求分析者がソフトウェアの 開発を依頼したクライアントやその使 用者であるユーザから、彼らのニーズ や要求を聞き出し、それを要求仕様 書にまとめあげる作業であると考え られてきた。
しかし、ソフトウェアの与える影響 が広く社会全体に広がるようになる にしたがって、特定の個人の要望を 満足していればよいという時代は過 ぎ去ってしまったと言ってよい。
新た な要求工学とは、そうした背景の元、 対象領域が抱えている問題そのもの に深くアプローチしようとするもので ある。
要求工学が目指している新た な枠組みとは、次のようなものであ る【２】。
１．対象領域が抱えている問題を理 解する ２．問題を解決するための方法を発 見する ３．ソフトウェアによる実現方法を 定義する 以下に、要求工学の中から代表的 な手法を紹介する。
要求を獲得する 要求工学の中心的テーマは、如何 に正確な要求を入手するかということ であり、これに関わる手法を総称して 要求獲得（requirements elicitation） と呼ぶ。
要求獲得は極めて多様な技 術群から構成されている。
図２は、 要求獲得に関する主要な技術のマップ である【３】。
ここで、横軸は、分析者の視点の 特性を示している。
すなわち右側は 対象領域の動的な性質に焦点を当て ドメイン分割 プロブレム フレーム 構造化 インタビュー 図2 主要な要求獲得技術のマップ i★ 物語法 シナリオ ユースケース MSC プロトタイピング ロールプレイ エスノグラフィー GBRAM KAOS ゴール カード ソーティング 閉じている（Closed） 開いている（Open） 動的 知的 （Dynamic） （Static） KJ 法 アブダクション ブレーン ストーミング JUNE 2011 78 適切なシステムが実現しないことは言 うまでもない。
ステークホルダの選定 は、情報収集にとって極めて重要な 作業である。
ステークホルダには、次 のような役割の人が含まれる【８】。
●ビジネス関係者：ビジネス分析者、 市場、その製品を欲しない批判者、 その製品に独自のユーザグループ、 特定団体 ●システム関係：プロジェクトの管理 者や後援者、システム開発者、技 術専門家、隣接システム ●監視者：安全監視者、技術監査 役、弁護士や警察官といった法律 関係者、政府やその出先機関、身 障者や老人などの特定団体、宗教 や政治・民族・文化に関わる文化 関係者 ステークホルダが選定されたら、彼 らから漠然とした願望やその領域特 有の規則なども含め、さまざまな情 報を収集することになる。
そのため の方法で最も一般的なのがインタビュ ーである。
インタビューは簡単な割に情報収集 の効率がよいが、重要な情報を得る ために、事前に問題点を整理してお く必要がある。
その他の情報収集手 段としては、さまざまな関連文書を 探したり、作業者の実際の活動現場 業務の中でも試行をする例が増えつつ ある。
i ★ 法の特徴は、ドメインモデル、 シナリオ、ゴール指向というモデル化 の三つの視点を統合した複合モデルで あるということであり、i ★ 法が目指 すのは、問題領域の基本的な構造と、 そこで発生している問題を正確に認 識し、情報システムによる問題の解決 法を探ることにある。
この手法が初 期フェーズ要求工学と呼ばれる所以で ある。
i ★ では、現状モデルと将来モデルを 描く。
それぞれのモデルは外部構造 モデルとアクター（関係者）の内部構 造モデルがあるので、計四つのモデル を作成することになる。
図３は、会 議の設定に関する将来内部構造モデ ルである。
ここでは、会議招集者の 「簡単に」とか「素早く」といったニ ーズがミーティングスケジューラ・シ ステムとして実現されている様子が描 かれている。
現在、情報システムの利用が広範 に行き渡るようになっているため、シ ステムの直接的なユーザの意見だけで なく、システムの利害関係者すなわ ちステークホルダから、広く情報を収 集する必要がでてきている。
重要な情報を持っているステークホ ルダを見落としたり、瑣末なステーク ホルダの意見を重要視したりすれば、 D D − D D D D D D D D D D − − − − − − − ＋ ＋ ＋ − − − − − − ＋ ＋ ＋ ＋ −＋ − − − Meeting Participant Arrange Meeting Attend Meeting Quality (ProposedDate) Agreeable (Meeting,Date) Low Effort User Friendly Richer Medium FindAgreeable DateUsing Scheduler Meeting Scheduler Schedule Meeting Attends Meeting Meeting Initiator MeetingBe Scheduled AgreeTo Date Enter AvailDates Obtain AvailDates Obtain Agreement Merge AvailDates FindAgreeable DateByTalking ToInitiator Find Agreeable Slot Proposed Date Agreement Convenient (Meeting,Date) Participate InMeeting Low Effort MeetingBe Scheduled LetScheduler Schedule Meeting Schedule Meeting Organize Meeting Quick Enter DateRange Goal Task Resource Soft-Goal Task-Decomposition link Means-ends link Contribution to softgoals Actor Actor Boundary LEGEND 図3 会議の設定に関する将来内部構造モデル 79 JUNE 2011 マップの第一象限に属する技法である。
シナリオと言うと、一般に、テキスト によって書かれた物語風のものを想像 するが、最近では、対象の変化に関 する図式もシナリオと呼ばれるように なった。
シナリオ型モデルで有名なのがユー スケースモデルである【1 1】。
図５は金 融業務に関するユースケースモデルの 一部であり、四角の箱の中の楕円形 がユースケースである。
ユースケース は、業務プロセスをモデル化したもの である。
ユースケースモデルの特徴は、 シナリオの多くが変化の順序に焦点を 当てているのに対し、プロセスの構造 に焦点を当てていることである。
た だし、それぞれのユースケースは、ユ ースケースシナリオという物語風のシ ナリオによって詳細化される。
ゴールモデルは、特定のゴールをゴ ール分解によって展開する手法で、技 法マップの第三象限に属する。
代表 的な手法にＫＡＯＳ法がある【 12 】。
ゴールとは、目標となる状態のこと であり、その性質によって幾つかの種 類に分類される。
成立条件による分 類では、これから実現させる必要の ある達成ゴールと、現在既に実現し ており、その状態を続ける必要のあ る維持ゴールがある。
また、達成条 件による分類では、ゴールの達成が計 測可能なハードゴールと、達成された モデルには、ドメインモデル、シナリ オ、ゴールモデルという三つのモデル がある。
ドメインモデルは、対象領域の静 的な側面、すなわち、そこに存在す る実体や現象をモデル化したもので、 図２の第二象限に属する技法である。
代表的なモデルにオブジェクトモデル がある【 10 】。
図４は、金融業務に関 するオブジェクトモデルの部分図であ る。
シナリオは、対象領域の動的な側 面、すなわち、時系列名変化や因果 関係をモデル化したものであり、技法 情報を元に要求分析を行う。
要求分 析の目的は、雑多な要求の中から正 しい要求を抽出したり、収集しそこ なった要求を発見したり、ステークホ ルダによって異なる要求の調整を図っ たりすることである。
要求分析のための手法には、モ デル化手法と非モデル化手法がある。
モデル化手法は対象領域全体の抽象 モデルを描き、そのモデルを元に構造 的な分析作業を行う。
他方、非モデ ル化手法では個別の事象を元に、そ れらをより深く検討する。
モデル化分析手法でよく用いられる を観察すると言った方法もある。
要求獲得に失敗しないためには、 分析者自身も問題領域に関する最低 限必要な知識を持っている必要もあ る。
また、要求獲得作業に入る前に、 システム化の対象範囲を明確に設定し ておくことも重要である。
変化の激 しい現代社会では、要求は頻繁に変 更になる。
この要求変更に如何に対 応するかが、要求獲得におけるプロジ ェクトの新たな課題である【９】。
要求を分析する 情報収集が終わったら、それらの 上位ゴール ゴール 下位ゴール 代替案 Why分解 ＋＋ ＋ ＋ ＋ ＋＋ ＋ − How分解 図6 ゴール分解におけるＷｈｙ分解とＨｏｗ分解 AND 図4 金融業務に関するオブジェクトモデルの部分図 融資担当 顧客 入金 法人顧客 個人顧客 勤務会社 出金 貸し付け ローン 自動振込み 保証人 図5 金融業務に関するユースケースモデルの部分図 顧客 1 * * 1 名前 住所 預金 預金 口座番号 預金口座 残高 個人顧客 企業顧客 当座預金口座 普通預金口座 定期預金口座 ことが計測できないソフトゴールがあ る。
図６に示したように、ゴール分解 にはＷｈｙ分解とＨｏｗ分解がある。
Ｗｈｙ分解は、そのゴールが何故必 要なのかという視点で分解したもの で、より本質的な上位ゴールが導出 される。
一方、Ｈｏｗ分解は、その ゴールを実現するための条件という視 点で分解したもので、実現方法が解 ゴールとして導出される。
下位ゴール同士の関係には、ＡＮ Ｄ関係とＯＲ関係がある。
ＡＮＤ関 係は、そのすべての下位ゴールが実現 しなければ上位ゴールが実現しないこ とを表している。
図中の＋や−の記 号は、下位ゴールの上位ゴールへの貢 献度を表している。
＋の数が多いほ ど、上位ゴールの実現可能性が高い。
要求を記述する 獲得された要求は、システム設計 者に伝達され、コンピュータ上での 実現方法が検討される。
したがって、 要求を如何に正確に分析者から設計 者に伝えられるかが、ここでの大き な問題となる。
最大の問題は、設計者は、コンピ ュータの専門家ではあっても、問題 領域に関する知識は持ち合わせていな いということである。
そこで、分析 者は問題領域の中で定義された要求 を、設計者にも理解できる形に変形 しなければならない。
これを要求仕 様という。
要求仕様は、問題領域の中での意 味を保持したまま、コンピュータによ って処理可能な形で記述する必要があ る。
すなわち、仕様は、両者にとっ て認識可能である共有現象によって 記述されなければならない【 13 】。
例え ば、動物園への入場者数という問題 領域の現象を、仕様ではコンピュータ にも認識可能な入場扉の回転数とい う共有現象に置きかえる必要がある。
仕様を文書化したものが要求仕様 書である。
要求仕様書を作成する上 では注すべきことが幾つかある【 14 】。
●正当性：仕様書には正しい要求だ けを記述すること ●非曖昧性：複数の解釈が可能な用 語や文章は避けること ●完全性：必要な要求はすべて記述 すること ●一貫性：仕様書内で異なった定義 を行わないこと ●重要性のランク付け：実現のため の優先順位付けを行うこと ●検証可能性：実現されたことを証 明する方法を示すこと ●変更可能性：要求変更発生時に仕 様書の変更が容易であること ●追跡可能性：仕様書の変更箇所か 【10】 Jacobson, I., Christerson, M., Jonsson, P. and Overgaard. G. Object-Oriented Software Engineering, Addison Wesley, 1995. 【11】 Fowler, M. and Kendall, S. UML Distilled, Addison-Wesley, 1997. 【12】 Lamsweed, A. V. Requirements Engineering, Willey, 2009. 【13】 Jackson, M. and Zave, P. Deriving specifications from requirements: An example. Proc of 17th International Conference on Software Engineering, 1996, pp. 15-24. 【14】 I E E E G u i d e t o S o f t w a r e Requirements Specifications. ANSI/IEEE Standard 830-1998. JUNE 2011 80 次回フォーラムのお知らせ 6月度のフォーラムは、6月15日 （水）日本能率協会コンサルティング （JMAC）の中森清美氏による講演「業 務機能展開とWBS」を予定している。
このフォーラムは年間計画に基づいて 運用しているが、単月のみの参加も可 能。
1回の参加費は6,000円。
ご希望の 方は事務局（ s-sogabe@mbb.nifty. ne.jp）までお問い合わせ下さい。
※ Ｓ Ｏ Ｌ Ｅ（The International Society of Logistics：国際ロジスティクス学会）は一 九六〇年代に設立されたロジスティクス団体。
米国に本部を置き、会員は五一カ国・三〇 〇〇〜三五〇〇人に及ぶ。
日本支部では毎 月「フォーラム」を開催し、講演、研究発 表、現場見学などを通じてロジスティクス・ マネジメントに関する活発な意見交換、議論 を行っている。
ら設計書やプログラムの変更箇所 を特定できること 要求工学には、この他にも多様な技 術が含まれるが、紙面の関係上、これ らの技術については割愛する。
参考文献 【1】 Standish Group Chaos. Standish Group Inc, 1994. 【2】 要求工学概論、近代科学社、2009. 【3】T s u m a k i , T . a n d T a m a i , T . A Framework for Matching Requirements Engineering Techniques to Project Characteristics, Software Process: Improvement and Practice 11(5): 505- 519, 2006. 【4】 Kawakita, J. The Original KJ Method. Kawakita Research Institute, 1991. 【5】 Checkland, P. and Scholes, J. Soft Systems Methodology in Action. John Wiley, 1990. 【6】 Minto, B. The Minto Pyramid Principle. Minto International Inc., 1996. 【7】 Yu, E. Towards modelling and reasoning support for early-phase requirements engineering. Proc. of 3 r d I n t e r n a t i o n a l S y m p o s i u m o n Requirements Engineering, 1997, pp.226-235. 【8】 Robertson, S. and Robertson, J. Mastering the Requirements Process. Addison Wesley, 1999. 【9】 Christel, M.G. and Kang, K.C. Issues in requirements elicitation. Technical Report CMU/SEI-92-TR-12, 1992.