本日の構成 • 第1部：連続チュートリアル1回目「要求工 学」（大西 淳） • 第2部：要求工学国際会議紹介（東京工業 大学 佐伯元司教授） 連続チュートリアル：要求工学 ２００４．１．１５ 立命館大学理工学部情報学科 大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 1 講師紹介 今後の予定 • 大西 淳（ 1957年兵庫県西宮に生まれる） • 京都大学工学部情報工学科卒業、同大学院工 学研究科修士課程情報工学専攻修了、同博士 課程中退 • 京都大学助手、助教授を経て1994年より立命館 大学教授(理工学部情報学科） • 情報処理学会ソフトウェア工学研究会要求工学 ワーキンググループ主査 • 要求工学国際会議（RE’04)Local Chair, PC member • 第2回連続チュートリアル 日時：2月17日(火)18:00∼20:00 場所：情報処理学会会議室(田町） 講師：Sjaak Brinkkemper博士（オランダ） • 第3回連続チュートリアル 日時：3月4日（木）18:00∼20:00 場所：明治大学（御茶ノ水） 講師：郷 健太郎先生(山梨大学） 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 3 第一部の内容 1. 2. 3. 4. 5. 4 参考書 ソフトウェア要求とは 要求工学とソフトウェア工学 要求定義 要求獲得技術 要求仕様 • 大西 淳・郷健太郎「要求工学」 共立出版 ソフトウェアテクノロジーシリーズ９ １．はじめに ６．要求仕様化技法 ２．要求獲得 ７．形式的仕様 ３．シナリオ ８．要求仕様とソフト ウェア開発管理 ４．要求仕様 ５．要求言語 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 2 5 １０．要求定義 と支援技術 １１．おわりに ９．ラピッドプロト タイピング 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 6 1 ソフトウェア要求 ソフトウェア製品と要求 • ソフトウェア要求はユーザや顧客がソフト ウェアに当然備わっていると望む特性 • ユーザは「計算機システムのサービスを利 用する人々」、特に「計算機システムを直 接操作したり、直接やり取りする人々」 • 顧客＝発注者であり、顧客とユーザは同じ 場合もあるが、異なる場合もある。 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 7 ２つのタイプのソフトウェア製品がある 1. 開発者側がユーザのニーズを予測してそれを 満足するソフトウェア製品を開発し、広く大量に 販売する。 2. ユーザ側がニーズを開発者側に出して発注し、 開発者側はニーズを分析して、それを満足す るソフトウェア製品を開発する。単品での開発・ 販売となる場合が多い。 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 8 一般の工業製品とソフトウェア 一般の工業製品とソフトウェア (2) • 一般の工業製品は前者（開発者側がユー ザのニーズを予測してそれを満足するソフ トウェア製品を開発する）がほとんど • 一般の工業製品は、機能の追加や変更は 簡単にはできない。あらかじめオプションと して用意された範囲でできる程度。 • 一方、ソフトウェアの場合、利用者側のニー ズに応じて独自の機能を持ったソフトウェ アが作られる。また既存のソフトウェアへ の機能の追加や変更が、場合によっては 簡単に実現してしまう。 • ソフトウェアでは後者（ユーザ側がニーズ を提供し、特別仕様のソフトウェア製品を 開発者側に開発してもらう）が一般に行わ れている 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 9 システム(機器）の規模 システム(機器） ミシン･自転車 テレビ 自動車 ジェット機 最大構成要素数 １０２ １０３ １０４ １０５ 宇宙ロケット 宇宙ステーション 都市システム 超大規模ソフトウェア １０６ １０７ １０８ １０９ 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 10 多様なニーズとソフトウェア • このため利用者側は多様なニーズを持ち、 それをソフトウェアで解決することを望む。 • 利用する組織や人が異なると同じような業 務であっても、業務が異なるので、それを ソフトウェア化した場合、ソフトウェアに求 める解は異なる。 11 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 12 2 ソフトウェア要求の重要性 ソフトウェア要求（例題） • 開発者側は、ユーザが解決したい問題や どういったことをしたいかといったニーズを 的確に把握し、ソフトウェアが備えるべき機 能や性能等をソフトウェア要求としてまとめ なければならない。 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 13 ソフトウェア要求の解 「三角形の3辺の値を入力して、その面積を 求めるプログラムを作れ」 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 14 プログラム 「三角形の3辺の値を入力して、その面積を 求めるプログラムを作れ」 ⇒ 3辺の値をa,b,cとし、s=1/2(a+b+c)と 置くと、面積Ｓ＝√s(s-a)(s-b)(s-c) となる。（ヘロンの公式） read(a, b,c ); s=1/2(a+b+c); S=√s(s-a)(s- b)(s-c); print(S); ％３辺の値を入力 ％ヘロンの公式 ％出力 例えば、３，４，５を３辺の値とする直角三角形では s＝６、面積Ｓ＝√６×３×２×１＝６ と正しい値が求まる。 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 15 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 16 Ｑ：例題プログラムにユーザは満足するか？ Ａ：例題プログラムは要求を満たさない 1. 三角形を構成しない場合（-6, 4, 4)でも s=1, S=√7×(-3)×(-3)=3√7と正の答が求ま る 2. 三角形を構成しない場合のソフトウェアの振舞 いが未定義 3. 面積の精度が未定義(3辺が1,2,√5で面積は1 となるか？) 4. 3辺の入力値に対する規定（全角数字、漢数字 は？小数、無理数は？一括でファイルから入 力する、対話式に入力？単位？)が不明確 • 元の要求には誤り（ 抜け、不完全）がある が、ユーザにとって当り前のことはわざわ ざ要求として明示しない ⇒ ユーザにとって満足 できないプログラムに なってしまう 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 17 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 18 3 ソフトウェア要求 要求はユーザによって異なる • ユーザがソフトウェアに当然備わっている と望む特性 • 特性は機能に関する要求（機能要求）と非 機能要求に分かれる • ユーザにとって当たり前の特性は開発者 に逐一伝えない場合が多い 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 19 • 使う人の立場によってソフトウェアに求め る特性（要求） は異なる 例えばワープロソフトに 対して 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 20 ワープロソフトに対する要求（１） ワープロソフトに対する要求（２） • Ａさんは英語の論文をまとめたい • Ｂさんは年賀状を作りたい •スペルチェック、文法チェック •干支のイラスト •複雑な数式の記述 •デジカメ画像の貼り付け •学会指定の段組 •フルカラー印刷 •学会指定のフォント •はがき印刷 •住所管理 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 21 ワープロソフトに対する要求（3） • Ｃさんは会議資料を作成し、高速に印刷したい 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 22 ワープロソフトに対する要求（4） • Ｄさんは初めてなので、一度ワープロを 使ってみたい •どんな機能があるかも分か •簡単に資料が作れる らないけれど、使ってみたい •高速に印刷 •大量に印刷する •仕分け機能 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 23 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 24 4 要求が誤っていることがある 要求は立場によって異なる • ユーザと顧客の立場によってソフトウェア に求める特性（要求）は異なる（矛盾する） ユーザは使い勝手の良さを 顧客は投資効果の大きいものを 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 • 要求は不完全であったり（抜け） • 互いに矛盾していたり • あいまいであったり（解釈が何通りもできる） • ユーザのニーズと整合していない （ユーザが解決したい問題を解決できない） 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 25 要求は変わることがある 「ソフトウェア要求」のまとめ • 利用者が正確に伝えなかった要求を開発者側が 誤解すると、誤解された要求は修正されなけれ ばならない • 新技術の開発や環境の変化に伴って利用者の ニーズ自体が変わることがある。時間が経つと 上記の変化は起こりやすい。当初正確にニーズ を開発者側が引き出していても、ニーズが変わ ることによって要求が変わる 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 • 要求は利用者側がソフトウェアに備わるべきと思 う特性 • 利用者側は様々なニーズを持つ • 開発者はニーズを的確に捉える、それを実現す べくソフトウェアを開発する • でも、要求は立場によって異なる • でも、利用者側は当たり前のことは言わない • でも、要求は誤っていることがある • でも、要求は変わることがある 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 27 本日の内容 1. 2. 3. 4. 5. 28 要求工学 ソフトウェア要求とは 要求工学とソフトウェア工学 要求定義 要求獲得技術 要求仕様 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 26 • • 要求工学は「ソフトウェア要求を正しくまと める（定義する）ための技術や技法の集大 成」 ソフトウェア要求を正しくまとめられないと、 1. 開発コストの増加や開発スケジュールの遅延 2. 開発のやり直し、 3. 開発プロジェクトの失敗 29 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 30 5 ソフトウェア工学と要求工学 システム工学が母体となってスタート • 要求工学はソフトウェア工学の1分野 • ソフトウェア工学は「高機能高品質なソフトウェア を効率よく作成したり、利用するための方法論の 集大成」 • 発端は1968年ＮＡＴＯ主催の会議でソフトウェア 危機の提案・認識とその打開から • 当時は巨大システムの開発が相次いだが、軍用 システムの多くはソフトウェアトラブルが続出 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 31 • それまでの職人芸的なソフトウェア開発を改め、 工場で高品質な自動車が高い生産性で製造さ れるのと同じようにソフトウェアを開発したい • ６０年代はアポロ計画を始めとして、システム工 学が成果をあげていた • システム化の対象をソフトウェアに特化すること でシステム工学をカスタマイズすることからソフト ウェア工学は始まった 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 32 ソフトウェア工学の初期の成果 ソフトウェアライフサイクル • ソフトウェアライフサイクルモデル ⇒開発の分業化と各工程での成果物によ る工程管理 • 構造化プログラミング • データ中心設計 • …. • ソフトウェアの開発や運用・保守がどのよう に進んでいくかをモデル化したもの 要求定義 → 設計 → 実装 → テスト → 導入と設置 → 運用と保守 → 廃棄 ウォータフォール型ライフサイクルモデル 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 33 ウォータフォール型ライフ サイクルモデルの特徴 34 ウォータフォール型モデルの問題点 • 各工程でドキュメントが作成され、それが 次の工程の入力となる。（例えば要求定義 工程ではプロダクトとして要求仕様が作成 され、それが設計工程の入力となる） • 各工程でのプロダクトを検査すればその工 程が正しく実施されたかどうかを判断可 • 各工程ごとに専門家チームを用意できる 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 35 • ソフトウェア開発はスムーズに進むとは限 らず、後戻りが生じることがある。 • 特に要求定義を誤ると、最終製品をユー ザが使うまで、誤りが検出できない • この結果、開発コストの超過やスケジュー ルの遅延が生じる 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 36 6 改善されたライフサイクルモデル • プロトタイピング型ライフサイクルモデル 開発の初期段階でプロトタイプを作成し、利用者 に妥当性を確認してもらう • スパイラル型ライフサイクルモデル ソフトウェア開発を「目的や代替案、制約の決定」、 「代替案の評価やリスク分析」、「次レベルの製 品の開発と検証」、「次フェーズの計画」の４段階 を繰り返しと捉え、繰り返しを経るに従い、プロト タイプが成長して、最終製品に至る 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 37 スパイラル型 ライフサイクル モデル プロトタイピング型 ライフサイクルモデル 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 38 「要求工学とソフトウェア工学」のまとめ • 要求工学はソフトウェア工学の1分野 • システム工学の開発対象をシステムに特 化することでソフトウェア工学が始まった • 初期のソフトウェア工学の成果の一つに ウォータフォール型ライフサイクルモデル • 改良されたライフサイクルモデルがいくつ か提案されている 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 39 本日の内容 1. 2. 3. 4. 5. 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 40 要求定義は必要か？ ソフトウェア要求とは 要求工学とソフトウェア工学 要求定義 要求獲得技術 要求仕様 • ユーザ要求は時間が経つと変化する • 従って、要求を正確に定義することは不可 能 変化する要求と変化しない要求がある。 それらを切り分けて、変化しないコアとなる 要求を正確に定義することは必要。 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 41 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 42 7 要求定義のプロセス 要求定義プロセスサイクル 要求管理 1. 要求の獲得（開発者がユーザから獲得） 2. 要求の仕様化（獲得した要求の文書化） 3. 要求仕様の検証（要求仕様の品質チェッ ク） 4. 要求の管理（版管理、再利用） 変更追跡 ネゴシエーション 要求記述 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 44 要求定義の目標 何が問題であるかを認識してニーズを引 き出す必要がある。 • 要求定義の目標は 1. 問題の本質を明らかにして 2. 問題の解決策を策定し 3. 解決案を実現するためのソフトウェアの 特性を定める • 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 45 本日の内容 46 要求獲得 ソフトウェア要求とは 要求工学とソフトウェア工学 要求定義 要求獲得技術 要求仕様 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 記述 要求検証 43 • 一般に解決すべき問題あるいはニーズが存在し、 問題を解決するため、またはニーズを実現する ためにソフトウェアが作られる • 問題(ニーズ)は複雑であったり、不完全であった り、あいまいであったり、矛盾している場合が多 い • 特に前例がないような新規システムの開発の場 合は問題(ニーズ）を理解することすら難しい 1. 2. 3. 4. 5. モデル化 記述の解析 要求定義の前提 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 要求抽出 テスト・実行 これらの４フェーズを繰り返すことによって、要 求が成長する 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 Stakeholderの識別 要求獲得 • • 1. 2. 3. 4. 47 問題の本質を明らかにする段階 要求獲得では 現状のニーズや問題点を収集し、 収集した結果を分析・整理し、 解決すべき真の問題を明らかにする この結果、ニーズが明らかになる 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 48 8 要求獲得のための技法 問題分析法 • 問題分析法 • 開発者とユーザ間のインタラクション分析 法 • 合意形成と意思決定法 • ソフトウェア開発のために特化された要求 獲得技法 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 • • • • 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 49 ＫＪ法 50 ＫＪ法の手順（１） 川喜多二郎氏考案 特別な道具や知識は不要 １人でも４∼５人のグループでも可能 要求獲得だけでなく一般の問題解決に有 効 • 参考文献：川喜多二郎「発想法」中央公論 社 • • • • 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 創造工学 ブレーンストーミング 水平思考 ＫＪ法 1. 参加者に目的意識を徹底 2. 情報を広く収集 3. 情報を一つごとに１枚のカードに記入し、 見出しを付ける 4. カードを壁に貼ったり机に広げて全体が 見渡せるようにし、親近性のあるカード群 をまとめて小グループとする 5. 小グループに名前を付ける 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 51 ＫＪ法の手順（２） 52 インタラクション ６．４と５を繰り返す。これにより中グループ、 大グループができる ７．グループ間の類似・対立・従属・ 因果等を 表せるようカードを再配置する ８．以上の結果をまとめる • • 開発者とユーザや顧客とのやりとり（イン タラクション）を支援すれば要求獲得は円 滑に進む インタラクションには 1. アンケート 2. インタビュー 3. 会議 などがある 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 53 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 54 9 インタラクション分析 ビューポイント（視点） • インタラクションを記録し、その記録を分析 することをインタラクション分析という • インタラクションに現れた要求と要求に関 連した情報を抽出 • インタラクションの改良や支援 • ビューポイントとは「要求を捉える際の立場 や見方」 • 複数のユーザ、顧客、開発者が要求定義 に関わる。（関わる人々を総称して Stakeholder) • ビューポイントが異なると、お互いに矛盾 する要求が得られることが多い 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 55 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 56 合意形成 デルファイ法 異なる人々から出された要求が互いに矛 盾する場合、合意形成によって矛盾を解 消する必要がある 1. デルファイ法 2. ＡＨＰ法 • あるグループの人々に対して、同じ質問を 繰り返し、その結果をフィードバックさせな がら収束させ、最終的に１つの意見にまと める方法 • 単なるアンケートと異なり、同じ質問に対す る全体の回答傾向と少数意見には根拠を 付けてフィードバックすることにより、再評 価した結果が収斂していく 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 • 57 デルファイ法の手順（１） デルファイ法の手順（２） 1. 幅広い分野から回答者を選定する 2. アンケートやインタビューにより数値で答 えられる質問をし、結果を集める。 3. 結果をソートし、第一四分位数、中央値、 第三四分位数を求める 4. 上記の３つの数値を回答者に返し、再度 同じ質問をする。中央値から極端にはず れる結果を返す場合は理由を明記させる 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 58 59 ５．新しい結果について３と４のステップを繰り返す。 理由がある場合は３つの数値と共に理由も全員 に返す ６．ある程度、繰り返すと、結果が収束するので適 当なところで中央値を結果として採用する 回答に自身の無い人は多数意見（中央値）に近 づく。一方、少数意見でも回答に自信があれば それを根拠として示し、全体がその根拠に納得 すれば結果が修正される。 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 60 10 デルファイ法の例 デルファイ法の例（２） • 質問：「東京とニューヨークの所要時間は2030年 には何時間になるか？」 • 回答をソート • 再質問：「東京とニューヨークの所要時間は2030 年には何時間になるか？」 • 回答結果は自信の無い人は中央値に近づく 第一四分位数 第三四分位数 • 回答傾向を付けて再質問し、少数意見には根拠 も返してもらう 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 1. 2. 3. 4. 要素aiとaj を比較すると 一対比較のaij の値 オーストラリア １ やや重要 ３ 重要 ５ かなり重要 ７ 圧倒的に重要 ９ 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 問題 64 評価基準の一対比較行列 会議テーマ 代替案 ドイツ 開催地と期間 同程度に重要 63 評価基準 費用 62 一対比較の数量化 代替案が複数ある場合に、代替案を評価する ことによって、最適な案を選択する。 意思決定を行う問題を最上位に、代替案を最 下位に、案を選ぶ評価基準を中間に置いた階 層を定義する 各層の要素間を一対比較し、結果を数値で表 す 一対比較行列を正規化し、各層の重みを算出 各層の重みを合成し、代替案の重みを求める 国際会議の投稿先決定 中央値 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 61 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 14 • 再質問を繰り返し、ある程度収束した時点の中 央値を合意結果として返す ＡＨＰ法（階層化意思決定法） • 7 時間 14 中央値 時間 ３時間 時間 時間 ３時間 7 第一四分位数 第三四分位数 カナダ 開催地と期間 会議テーマ 費用 開催地と期間 １ １ ７ 会議テーマ １ １ ７ 費用 １/７ １/７ １ この行列の固有ベクトル ωを求める。 Ａｉｊ×ω＝λＭＡＸ×ω（λＭＡＸは最大固有値） 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 65 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 66 11 評価基準の重みベクトル 「開催地と期間」による代替案の評価 ω＝７/１５ ７/１５ １/１５ これは評価基準として「開催地と期間」、「会 議テーマ」は同程度に重要であり、「費用」 はそれほど重要でないことを示している。 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 ドイツ オーストラリア カナダ ドイツ １ ３ ３ オーストラリア １/３ １ ２ カナダ １/３ １/２ １ 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 67 「開催地と期間」による代替案の重み 68 「会議テーマ」による代替案の重み ω＝０．５９３６１ ０．１５７０６ ０．２４９３０ ω＝０．７４１８３ ０．１８２９５ ０．０７５２００ 「開催地と期間」ではドイツ、カナダ、オースト ラリアの順に好ましい 「会議テーマ」ではドイツがかなり好ましい 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 70 ３つの重みベクトルを合わせると 「費用」による代替案の重み ω＝０．０８７６１５ ０．６１９９４ ０．２９２４４ 「費用」 ではオーストラリア、ドイツ、カナダの 順に好ましい 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 69 71 開催地と期間 会議テーマ 費用 ドイツ ０．５９３６１ ０．７４１８３ オーストラリア ０．１５７０６ ０．１８２９５ ０．０８７５６ １５ ０．６１９９４ カナダ ０．２４９３０ ０．０７５２０ ０．２９２４４ 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 72 12 ゴール指向分析 これに評価基準の重みベクトルを掛けると ドイツ ０．６２９０５ オーストラリア ０．２００００ カナダ ０．１７０９３ この結果、ドイツの国際会議が最も好ましいことが分かる 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 • 最初に達成したいゴールを明確にする • 次にゴールをサブゴールに分割して行く。分割に はＡＮＤ分割とＯＲ分割を用いる。ＯＲ分割による サブゴールは代替案となり、他のゴールやサブ ゴールも含めて代替案同士を評価する。 • 分割によって抽象的だったゴールが詳細化され、 システム化可能なサブゴールにまで詳細化され た時点でそのサブゴールを要求とする 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 73 優秀な学生 ○○大学入試政策 多くの受験生 ゴール 「優秀な学生を入学させる」 「受験生をたくさん集める」 「入試の採点業務は簡素化したい」 採点の簡素化 受験料を安くする 問題を易しく 複数の受験機会 難しい入試 • 1. 2. 3. 74 教育環境の充実 採点の機械化 実験設備の充実 優秀な教育者 問題を少なく 優秀者への奨学金 教育環境の充実によって、「優秀な学生」 を確保し、 受験料の引き下げによって「多くの受験生」を集め、 採点の一部機械化によって採点業務の簡素化を図る 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 75 Ｃ−ＮＡＰIIの全体構成 NA (Needs Analysis) Ｃ−ＮＡＰ法 • 1. 2. 3. 4. 現状 調査 富士通（株）が開発したソフトウェア要求 獲得のために特化された手法。 ＰＮカードによる情報収集 問題点ネットワークによる問題分析 目的展開による目的レベルの設定 目的を達成する手段の検討 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 76 問題点 分析 業務 改善案 ﾌﾟﾛｼﾞｪｸﾄ の承認 管理対象 分析 情報シス テム仕様 最終 利用者 の確認 概念ﾃﾞｰﾀﾓﾃﾞﾙ 設計 ｿﾌﾄｳｪｱ 要求仕様 ｼｽﾃﾑ 設計 目的 展開 手段 検討 SA (Systems Analysis) 業務フロー 分析 DA (Data Analysis) ｲﾍﾞﾝﾄｼｰｹﾝｽ 分析 77 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 78 13 ＮＡの手法と手順 目的展開 ＰＮｶｰﾄﾞ 目的 .影響／結果 目的／狙い 目的リスト 目的 目的 目的 目的 目的 目的 順位 目的 評価 効果 特定手段 解決ﾎﾟｲﾝﾄ 背景／原因 問題点分析 手段検討 手段方法リスト 影響 原因 原因 原因 順位 手段・方法 新問題 影響 ｷｰｶｰﾄﾞ 原因 目的レベル 影響 影響 影響 基本方策 手段 評 基本方策 手段 手段 受注時に 品切れ品薄 商品が多い 緊急補充 が発生する 時期 ニーズ 問題点 問題点ネットワークの例 営業所間の 流用が円滑 に行われて いない 入出庫記録 が繁忙時に 2∼3日遅れる 基準 営業所の 営業所の 在庫把握が 在庫把握が 担当者が勘 商品ごとに で発注量を 営業所が 必要以上に 不正確である 不正確である 決めている 過不足のない 適正な在庫 補充発注が 過剰在庫を 在庫スペース 量を保持 できていない 抱えている を占有する していない 入出庫記録 (棚札)が 解決ﾎﾟｲﾝﾄ 不正確である ｷｰｶｰﾄﾞ 倉庫管理費 販売実績が 販売実績が 販売傾向が が増大する タ イ ム リ に タ イ ム リ に わからない 商品のサイフ 動きの鈍い 把握できない 把握できない サイクルが 商品の在庫 与件 短すぎる 管理が不十分 需要予測 需要予測方 需要予測方 のスキルを 式が確立さ 式が確立さ 解決ﾎﾟｲﾝﾄ 持った人 れていない れていない がいない 手段 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 79 80 目的展開の例 販売計画を達成する 手段体系図の例 目的ﾚﾍﾞﾙ 在庫品で販売計 画を達成する 売上を拡大する 小さい事務コスト で営業する 廃棄費用を抑える 在庫回転率を上げ る 手持ち在庫は完 売する 注文は必ず売上 に結び付ける 効率的な受注事 務を行う 在庫を売動向にあ わせてﾊﾞﾗﾝｽをとる 品切れを発生させ ることなく受注する 手戻りなく受注処 理を行う 倉庫間の在庫ｱﾝ ﾊﾞﾗﾝｽ状態を把握 適正な営業所在 庫を保持する 即時に注文に回 答する 停滞傾向にある 商品を把握する 早めに生産計画 の変更を行う 適正な補充発注 量を決定する 事前に代替品推 奨の体制をとる 本社で営業所在 庫を把握する 品薄傾向にある 商品を把握する 補充のための在 庫数を知る 品切れを判断する 品薄傾向を把握 死在庫をなくす 解決ﾎﾟｲﾝﾄ 在庫の把握がタ 在庫の把握がタ イムリでない イムリでない 社有倉庫 で統合 する 自動ピッキ ング棚を購 入する 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 △ 販売予測 を自動化 する 在庫状況 を一元的 に把握する ○ 商品の販売 動向に合った 予測方式を 決める 販売予測に 基づく補充 発注量を算 出する ◎ 営業所別 商品別 在庫数量 注文の 引当を自 動化する ○ 商品別 在庫数量 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 81 「要求獲得技術」のまとめ ◎ 在庫更新 を自動化 する ○ 商品別 入庫数量 商品別 出庫数量 必要情報 82 本日の内容 要求獲得には以下のものがある • 問題そのものを分析する • 開発者と利用者側のインタラクションを支 援する • 立場の違いから生じる矛盾を解消する • これらを含み、かつソフトウェア開発に特 化した手法 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 ○ 流用指示 を自動化 する ◎ 代替品の 引当を自 動化する 手段の重要度 自倉庫にない 時、他倉庫の 在庫品を引 き当てる 品切品薄の 判別と代替 品の明示を 自動化する 在庫の補充 発注を自動 化する ◎ 用地， 建物を 確保 する 倉庫・荷 役設備を 確保する 解決ﾎﾟｲﾝﾄ の肯定表現 外部依託 倉庫で 統合する ◎：大 ○：中 △：小 品切品薄を 受注時に判 別して代替 品を推販する 注文に即応 できる在庫 を保有する 倉庫を統合 する 受注時点の商品 の在庫を知る ﾀｲﾑﾘかつ正確な 在庫を把握する 注文は必ず 売上に結び 付ける 目的レベル 小さい在庫ｺｽﾄで 営業を行う 1. 2. 3. 4. 5. 83 ソフトウェア要求とは 要求工学とソフトウェア工学 要求定義 要求獲得技術 要求仕様 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 84 14 要求仕様 • • 1. 2. 3. 4. 5. 要求仕様は誰が書くか？ 要求仕様は要求定義段階の最終成果物 目的は 顧客や利用者による仕様の確認 開発者による仕様の検査 設計に必要な情報の提供 開発スケジュールやコストの見積もり ソフトウェア開発の契約書の一部 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 85 要求言語 • これらの組み合わせによって仕様化 87 要求仕様の品質特性(Std.830-1998) • • • • • • • • 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 88 仕様の妥当性 • 要求仕様中の全ての要求は、開発されて いるソフトウェアが満たすべき要求である こと • ある要求が開発するソフトウェアに必須か 否かは利用者や顧客でないと判断できな い場合が多いため、一般に妥当性の確認 は利用者や顧客が行う。 → プロトタイピングが有効 妥当性（正当性） 非あいまい性 完全性 無矛盾性 重要度のランク付け 検証可能性 変更可能性 追跡可能性 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 86 • 利用者や顧客の要求が正しく開発者側に伝わっ ていないと、場合によってはソフトウェア製品の 納入時に利用者や顧客の考えていたソフトウェ アとは異なることが判明し、再開発を余儀なくさ せられる • 開発の早い段階で利用者や顧客に妥当性を確 認する手間は、納入後に修正する手間やコスト に比べはるかに少ない → 妥当性確認にはプロトタイピングが有効 自然言語（日本語、英語など） 形式言語 制限言語（文法や語彙を制限した日本語） 図式言語（データフロー図、ＵＭＬなど） 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 要求仕様の妥当性確認 要求を記述するための言語 1. 2. 3. 4. • 開発者側の人間ではユーザ側の問題やニー ズを明確に理解できない • ユーザ側の人間に設計知識が無い場合は、 設計段階で設計者に十分な情報を伝えら れない ⇒ ユーザ側と開発者側の双方によって書かれ るのが望ましい 89 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 90 15 仕様の非あいまい性 仕様の完全性 • 仕様中の全ての要求が一意に解釈できる とき、仕様はあいまいでない • 要求があいまいだと、開発者は誤って解釈 する恐れがあり、結果として誤ったソフトウェ アが開発されることになる。 • あいまいさの原因としては、自然言語のも つあいまいさ（文法上、指示代名詞、語句 の省略）や多義語、定性的な表現がある 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 91 • 機能、性能、設計制約、属性、外部インタ フェースに関する要求が記述されており • あらゆる状態での入力に対する振舞い、 特に正当な入力と不当な入力に対する振 舞いの定義と • 仕様中の図や表に対するラベル付けと参 照、語句の定義、単位の定義 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 92 冗長な要求 仕様の無矛盾性 • 完全性の逆で、同じ要求が２箇所以上に 現れており、一部を削除しても正しく、抜け とならない場合は「冗長」な要求という。 • 冗長な要求は誤りではないが、修正時に 片方だけを修正し、残りを修正しないと矛 盾となるので、できるだけ冗長な要求は避 ける • 他の仕様書との矛盾ではなく、１つの要求 仕様書の中で一貫していることを意味する • 一貫しているとは個々の要求が互いに矛 盾しないことを意味する 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 93 94 重要度のランク付け 仕様の検証可能性 要求はすべて同じ優先順位が付けられ るとは限らない。個々の要求は以下のよ うな相違を区別できないといけない。 1. 必須な要求 2. あった方が望ましい要求 3. あってもなくてもよい要求 • ソフトウェア製品がその要求を満たしてい ることを計算機や人手によってチェックでき るプロセスが存在することを指す • 定性的な表現の要求は検証不能 ⇒ 定量的・具体的な表現にする 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 • 95 96 16 仕様の変更可能性 仕様の追跡可能性 • 仕様の構造を保持したまま、容易に、完全 に、矛盾無くしようを変更できる場合、変更 可能という。このためには、 • クロスリファレンスや索引・目次があって、 仕様が分かりやすい構成になっていること • 冗長な要求が無いこと • 個々の要求を別々に表現すること が必要 • 後方追跡可能性：各要求から、要求仕様 に先立って作成された文書中の各要求の 起源について参照できること • 前方追跡可能性：要求仕様を元にして作 成された全ての文書（例えば設計仕様書 やソースコード）から各要求を参照できるこ と 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 97 98 後方追跡可能性 前方追跡可能性 • 各要求の出された背景や理由を知りたい 場合に有用。特に新規システムの要求仕 様を既存システムの要求仕様から導く場 合に要求の背景や理由が分かるので、新 規システムに取り込むかどうかを判断しや すくなる • 運用段階や保守時に、ソースコードや設計 文書を変更する場合に、その変更によって 影響を受ける要求を同定したい場合に有 用 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 99 要求仕様の章構成(Std.830-1998) 1. 2. 3. 4. 5. はじめに 要求仕様の全体説明 詳細な要求仕様 付録 索引 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 要求仕様の「はじめに」 • • • • • 101 100 要求仕様の目的と対象とする読者 ソフトウェアの名称、何をするか、対象 用語の定義と略語の説明 参考文献リストと入手できる場所 要求仕様の概要と構成 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 102 17 要求仕様の「全体説明」 要求仕様の「詳細な要求」 ソフトウェアの全体像（関連製品も含む） ソフトウェアの主要な機能 利用者の一般的な特性 制約事項（法的、ハード上、セキュリティ上、 他のアプリとのインタフェース上等） • 要求に影響を与える仮定と依存事項 • 設計やテストに十分なまで詳細化された要 求 • 要求仕様の品質特性を満たすこと • 関連する文書と相互参照可 • 要求は個々に識別可能 • 読みやすく構成 • • • • 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 103 「詳細な要求」の構成 • • • • • • • • 「詳細な要求」の構成法 外部とのインタフェース 機能要求 性能要求 論理データベース要求 設計制約 ソフトウェアシステムの属性 要求仕様の構成 コメント • • • • • • • 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 105 IEEE Std 830-1998による要求仕様第３章の構成例 (オブ ジェクトを中心） 3. 詳細な要求仕様 3.1 外部インタフェース要求 3.1.1 ユーザインタフェース 3.1.2 ハードウェアインタフェース 3.1.3 ソフトウェアインタフェース 3.1.4 通信インタフェース 3.2 クラス/オブジェクト 3.2.1 クラス/オブジェクト１ 3.2.1.1 属性（直接または継承） 3.2.1.1.1 属性１ . . 3.2.1.1.n 属性ｎ 3.2.1.2 機能(サービス、メソッド、直接 または継承) 3.2.1.2.1 機能要求1.1 . 3.2.1.2. m 機能要求1.m 3.2.2 クラス/オブジェクト２ . . 3.2.p クラス/オブジェクトｐ 3.3 性能要求 3.4 設計制約 3.5 ソフトウェアシステムの属性 3.6 その他の要求 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 104 107 システムのモードに基づいた構成 オブジェクトに基づいた構成 機能階層に基づいた構成 サービスに基づいた構成 利用者のクラスに基づいた構成 入力に基づいた構成 応答に基づいた構成 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 106 機能階層を中心にしたシステムの第３章の構成例 3. 詳細な要求仕様 3.1 外部インタフェース要求 3.2 機能要求 3.2.1 情報フロー 3.2.1.1 データフロー図１ 3.2.1.1.1 データ実体 3.2.1.1.2 関連するプロセス 3.2.1.1.3 トポロジー 3.2.1.2 データフロー図２ . 3.2.1.n データフロー図ｎ 3.2.2 プロセス記述 3.2.2.1 プロセス１ 3.2.2.1.1 入力データ実体 3.2.2.1.2 アルゴリズムまたは 処理の式 3.2.2.1.3 影響するデータ実体 3.2.2.2 プロセス２ . 3.2.2.m プロセスｍ 3.2.3 データ構成 3.2.3.1 構成１ 3.2.3.1.1 レコード型 3.2.3.1.2 構成フィールド 3.2.3.2 構成２ . 3.2.3. p 構成ｐ 3.2.4 データ辞書 3.2.4.1 データ要素１ 3.2.4.1.1 名前 3.2.4.1.2 表現 3.2.4.1.3 構成単位/形式 3.2.4.1.4 精度 3.2.4.1.5 範囲 3.2.4.2 データ要素２ . . 3.2.4. q データ要素ｑ 3.3 性能要求 … 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 108 18 良い要求仕様とは？ ソフトウェア要求（例題） 1. 8つの品質特性を満たしていること 2. 要求仕様の構成上の内容を全て含んで いること これら２つの観点から要求仕様を見れば 良い。 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 「三角形の3辺の値を入力して、その面積を 求めるプログラムを作れ」 という仕様を 再度考察する。 １．誤りに関する品質特性から ２．要求仕様の「詳細な要求」 の構成から 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 109 110 例題とした要求の品質上の問題 例題とした要求の構成上の問題 • 妥当性：利用者側のニーズが明らかでな いので判断できない • 非あいまい性：値は整数値なのか？ • 完全性： • 外部とのインタフェース要求： 抜けている • 機能要求：一部あるが、不正な入力のチェックや 三角形を構成しない入力値の場合の処理が抜 けている • 性能要求：抜けている • 論理データベース要求：ない • 設計制約：プログラム言語や動作環境といった 制約が抜けている • ソフトウェアシステムの属性：ない – 三角形をなさない際のふるまい – 入出力データの書式、単位、入出力方法 – プログラム言語・動作環境 • 無矛盾性：特に矛盾は無い 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 111 「要求仕様」のまとめ おわりに • 要求仕様は満たすべき特性がある • 要求仕様に書かれるべき項目と章構成の 規格がある • こららの特性や構成を満足するように仕様 をまとめる 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 112 113 1. 2. 3. 4. 5. ソフトウェア要求とは 要求工学とソフトウェア工学 要求定義 要求獲得技術 要求仕様 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 114 19 参考書 お疲れ様でした • 大西 淳・郷健太郎「要求工学」 共立出版 ソフトウェアテクノロジーシリーズ９ ISBN:4-320-02782-5 3,600円＋税 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 115 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 116 引き続き第2部 • 要求工学国際会議の紹介 • 論文投稿案内 情報処理学会連続チュートリアル 「要求定義」 （ｃ）大西 淳 117 20
© Copyright 2024 Paperzz
