Comments
Description
Transcript
SEC - IPA 独立行政法人 情報処理推進機構
Software Engineering Center Information-technology Promotion Agency, Japan SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」第6回 受発注者間での要求/要件の 合意形成 2012年5月17日 独立行政法人 情報処理推進機構（IPA） 技術本部 ソフトウェア・エンジニアリング・センター（SEC） 研究員 柏木 雅之 Copyright © 2010 - 2012 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center SEC 目次 Software Engineering for Mo･No･Zu･Ku･Ri 1. 第1部 「非機能要求グレード」ご紹介 ～システム基盤に対する非機能要求の設計手法～ 2. 第2部 「機能要件の合意形成ガイド」概説 ～発注者と受注者の合意形成について～ Copyright© 2010 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center 1 Software Engineering Center Information-technology Promotion Agency, Japan SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」第6回 非機能要求グレードご紹介 ～システム基盤に対する非機能要求の設計手法～ 2012年5月17日 独立行政法人 情報処理推進機構（IPA） 技術本部 ソフトウェア・エンジニアリング・センター（SEC） 研究員 柏木 雅之 Copyright © 2010 - 2012 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center SEC 情報システムの障害件数の推移 （報道ベース） 2005 2006 2007 2008 2009 Software Engineering for Mo･No･Zu･Ku･Ri 2010 2011 1～2件/月 10 10 4.5件/月 8 7 月6 別 件 数4 7 6 6 5 4 4 4 4 3.1件/月 3 2 6 5 4 4 4 3 1.8件/月 1.3件/月 1.4件/月 3 3 2 2 2 2 2 3 2 2 2 2 2 3 2 2 2 2 2 SDM公開講座 2012.5.17 1 Copyright © 2010 – 2012 IPA, All Rights Reserved 1 2011.5 2011.3 0 2011.1 0 0 2010.11 2010.1 2009.11 2009.9 2009.7 2009.5 2009.3 2008.11 0 1 2010.9 1 2010.7 1 1 2010.5 1 0 2008.9 2008.7 2008.5 2008.3 2008.1 2007.11 2007.9 2007.7 2007.5 1 1 2010.3 1 0 2007.3 0 0 2006.11 0 0 0 0 0 0 0 1 2009.1 1 2007.1 1 2006.9 2006.1 0 0 2005.11 2005.9 0 2005.7 0 1 2006.7 1 2006.5 1 2006.3 1 1 年 月 Software Engineering Center 3 SEC システム障害の要因とは Software Engineering for Mo･No･Zu･Ku･Ri 要件定義など上流工程の改善が品質向上に効果的 5年間に要件定義の問題が改善されていない 41.7% テストが不十分 36.7% 要件定義が不十分 システム開発の質が悪い 31.7% エンドユーザへの教育が不十分 31.7% システムの設計が不正確 31.7% 21.7% 社内の開発体制に問題 18.3% 計画が現実の利用形態に沿わず 16.7% システムの企画が不十分 15.0% ベンダの選択に問題 2008年 2003年 11.7% その他 0% 10% 20% 30% 40% 「日経コンピューター 2008年12月1日号」の「第2回プロジェクト実態調査」を元に作成 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 4 SEC 要求と要件 Software Engineering for Mo･No･Zu･Ku･Ri 英語ではどちらも「Requirements」 ANSI/EIA-632の要求の定義 製品が「何を、どれほどよく、どういった状態 で」与えられた目的を達成するかを決めるもの合意、 計画、仕様のような標準となる文書 IEEE1220の要求の定義 曖昧さがなく、テストあるいは計測が可能で、製品や プロセスを顧客あるいは内部の品質管理部門が受領に 必要である、製品やプロセスの運用面、機能面、設計 特性、制約を規定した文書 一般には、 要求とは「～したい」という利用者の願望 要件とは、要求を実現するためにシステムが備えるべ きもの ここでは、要件＝要求と同じものとして扱う SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 5 SEC 要求の分類 Software Engineering for Mo･No･Zu･Ku･Ri 本日のターゲットはシステム基盤の「非機能要求」に関するコミュニ ケーション 要件定義成果物からみた要求の分類※ 品質要求 非機能 要求 技術要求 その他要求 非機能要求 グレードでの分類 可用性 運用・操作要求 移行要求 付帯作業 性能・拡張性 運用・保守性 その他 機能 要求 移行性 機能要求（プロセス） セキュリティ 機能要求（データ） システム環境・ エコロジー 機能要求（インタ－フェース） ※参考：SEC BOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～」 （オーム社刊） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 6 SEC 要件定義で解決すべき課題 Software Engineering for Mo･No･Zu･Ku･Ri 要求の中でも利用者側の把握が難しいシステム基盤の 「非機能要求」が「非機能要求グレード」のターゲット 機 能 要 求 営業情報を システム上で 共有し把握したい。 レスポンスは３秒 以内にして欲しい。 非 機 能 要 求 将来の処理量増 大に備え、2倍の 性能に拡張できる ようにして欲しい。 SDM公開講座 (2012.5.17) 受発注情報に 連動した在庫管理 を行いたい。 システムダウン時は３時間以 内に復旧して欲しい。 業務時間中は、システム に関する質問に答えてく れる担当者がいて欲しい。 Copyright © 2010 - 2012 IPA, All Rights Reserved 実現したい業務機能に ついて、利用者が自ら の言葉で語ることができ る システムの実現方法 に関係し、具体化が 進まないと語りにくい 業務に直結せず技術 的要素が強いため、 要求項目が漏れやす く、開発者との共通 認識を持つのが難し い Software Engineering Center 7 SEC 機能要求と非機能要求の例 Software Engineering for Mo･No･Zu･Ku･Ri 機能要求はｼｽﾃﾑ化したい「業務」だが非機能要求は様々で 曖昧 機 能 要 求 非 機 能 要 求 この業務を システム化したい 対象業務は全てor特定？ 「極力」で許容される時間は 販売 製造 １分、１０分、or１時間？ 障害が発生しても サービスは極力止め ないでほしい データの暗号化の範囲は？ 暗号化の鍵管理方法は？ 丌正アクセスの追跡範囲は？ 事務室内で 運用したい SDM公開講座 (2012.5.17) サービス時間帯は ２４Ｈ、９～２１時、 会計 物流 or ９～１７時？ 対象ユーザ数はどのくらい？ 分析 EUC セキュリティ認証の程度は？ いつでも、誰でも どこでも使える ようにしてほしい 情報漏洩、 ウィルス混入は 防止してほしい どこでもの範囲は？ 建屋内、 同一県内、 情報は確実に 国内 or 海外？ 保全してほしい Software Engineering Center 8 SEC 非機能要求の実現要素 Software Engineering for Mo･No･Zu･Ku･Ri 非機能要求の多くは「システム基盤」にて実現 機 能 要 求 EUC 製造 物流 会計 分析 販売 システム基盤 非 機 能 要 求 分かり易い操作、 容易な業務変更、 ｱﾌﾟﾘｹｰｼｮﾝ性能 システム運用・ 調達の仕組み、 体制による実現 (運用設計にて検討) SDM公開講座 (2012.5.17) 制御/運用アプリケーションによる実現 ＯＳ、ミドルウェアによる実現 ＨＷ／ＮＷ機器による実現 Software Engineering Center 9 車選びと情報システムの非機能要求の対比例 SEC Software Engineering for Mo･No･Zu･Ku･Ri 車選び 情報システム 車検やディーラのサービス 保守 故障の少なさ 可用性 定員 将来の拡張性（処理量） エンジンの排気量 性能 コーナーセンサー、 後方カメラ、 縦列駐車アシスト機能 運用の容易性、 安全性 燃費 消費電力、ＣＯ２排出量 SDM公開講座 (2012.5.17) Copyright © 2011 IPA, All Rights Reserved. Software Engineering Center 10 SEC 非機能の過不足の例（１） Software Engineering for Mo･No･Zu･Ku･Ri 1. 可用性の例 車の場合 情報システムの場合 過剰 東京に住みスキーもしないの に、スタッドレスタイヤを常 備しており、車庫が手狭に なっている 冗長化するたびにコストが2 倍・3倍になり、得られる収 益よりもコストが超過してし まう 過小 降雪地帯に住んでおり、ス タッドレスタイヤは装備して いるが、タイヤチェーンを 持っておらず、出先で立ち往 生した システムの復旧に時間がかか り社会的信用が低下する。ま た、ビジネスチャンスを逃し てしまう（機会損失） SDM公開講座 (2012.5.17) Copyright © 2011 IPA, All Rights Reserved. Software Engineering Center 11 SEC 非機能の過不足の例（２） Software Engineering for Mo･No･Zu･Ku･Ri 2. 性能・拡張性の例 車の場合 情報システムの場合 過剰 ミニバンを買ったが、普段 乗るのはせいぜい３名程度 である 消費電力量が大きいため専用 のデータセンターを借りたら 保守費が増大。CPUを複数搭 載し処理能力が高いサーバー を用意したのに、普段は1つ のCPUで充分な処理量だった 過小 家族が増えて全員乗り切れ ず、家族そろってのドライ ブのたびに、レンタカーを 借りた 通常の処理をしきれず買い替 え。キャンペーンで注文増な のに処理しきれずシステムダ ウン（ビジネス機会の損失） SDM公開講座 (2012.5.17) Copyright © 2011 IPA, All Rights Reserved. Software Engineering Center 12 非機能の過不足の例（３） SEC Software Engineering for Mo･No･Zu･Ku･Ri 3. 運用・保守性の例 車の場合 情報システムの場合 過剰 ネットワーク経由で運転に役 システムを監視する運用を自 立つ情報を画面に表示するオ 動化したところ構築コストが プション装備をつけた かさんだ ところ、毎月の利用費用が結 構かかった 過小 カーナビが無くて何度も停車 手作業が多く人件費が増大し、 して地図を確認したものの、 結果として繁忙時に人為ミス 結局道に迷って約束の時間に による事故を起こした 遅れた SDM公開講座 (2012.5.17) Copyright © 2011 IPA, All Rights Reserved. Software Engineering Center 13 非機能の過不足の例（４） SEC Software Engineering for Mo･No･Zu･Ku･Ri 4. 移行性の例 車の場合 情報システムの場合 過剰 右ハンドル車から左ハンドル 移行のリハーサルを何度も 車に変えるための教習所の費 行ったため社員の訓練に時間 用がかさんだ とコストを要し、業務が滞っ た 過小 左ハンドル車に変わっても大 事前調査が不十分で、移行作 丈夫だろうと思ったが、結局 業中に問題が発生し、新シス は何度もボディに傷をつけて テムの稼動開始が遅れた しまった SDM公開講座 (2012.5.17) Copyright © 2011 IPA, All Rights Reserved. Software Engineering Center 14 SEC 非機能の過不足の例（５） Software Engineering for Mo･No･Zu･Ku･Ri 5. セキュリティの例 車の場合 情報システムの場合 過剰 車の盗難対策として車庫の シャッターに複数の鍵を付 けたところ、工事の費用が かさんだ。 また、安全強化したことで 急ぎの時にも出発するのに も一苦労である 強固なセキュリティの仕組み を採用したところ、システム の費用がかさんだうえ、個人 認証の仕組みが複雑になり、 業務の円滑性が低下した 過小 車上荒らしに遭い、車内に 置いてあった現金や貴重品 を盗まれ システムがウイルスに感染し て、顧客情報が漏えいした SDM公開講座 (2012.5.17) Copyright © 2011 IPA, All Rights Reserved. Software Engineering Center 15 SEC 非機能の過不足の例（６） Software Engineering for Mo･No･Zu･Ku･Ri 6. システム環境・エコロジー 車の場合 情報システムの場合 過剰 燃費ばかりを気にして、乗 り心地や性能が希望とは違 うものになってしまった 電力量不足にならないよう電 力設備を増強したら、システ ム構築費用を上回るコストが かかった 過小 マフラーが適合外でうるさ いうえ、排気ガスが汚い（ 車検が通らなかった） 法令違反により課徴金の支払 いとシステムの改修が必要に なった SDM公開講座 (2012.5.17) Copyright © 2011 IPA, All Rights Reserved. Software Engineering Center 16 SEC 非機能要求項目の体系 Software Engineering for Mo･No･Zu･Ku･Ri システム基盤に対する非機能要求を６つの大項目に分類し、 さらに具体的に非機能要求として挙げるべき項目を細分化 非機能要求を体系的に整理 したときの最も広い分類 大項目 中項目 検討すべき単位で 小項目をまとめた分類 小項目 小項目 小項目 中項目 … SDM公開講座 (2012.5.17) 小項目を定量的に 表現するための指標 （システムの開発コストや 品質に影響を与える度合 いの大きいメトリクスを 重要項目とする。） メトリクス メトリクス メトリクス メトリクス ユーザと開発ベンダの間で合意される 非機能要求を示す項目の分類 Software Engineering Center 17 SEC 非機能要求の６つの大項目 Software Engineering for Mo･No･Zu･Ku･Ri システム基盤に関する非機能要求を６つの大項目 要求の 分類 説明 要求例 確認結果に基づき、 実施する対策例 ① 可用性 システムサービス を継続的に利用可 能とするための要 求 • 運用スケジュール （稼働時間・停止予定など） • 障害、災害時における稼動目標 • 機器の冗長化やバックアップセンタの 設置 • 復旧・回復方法及び体制の確立 性能・ ② 拡張性 システムの性能、 および将来のシス テム拡張に関する 要求 • 業務量及び今後の増加見積り • システム化対象業務の処理傾向 （ピーク時、通常時、縮退時など） • 性能目標値を意識したサイジング • 将来へ向けた機器・ネットワークなど のサイズと配置 ＝ キャパシティ・プ ランニング システムの運用と 保守のサービスに 関する要求 • 運用中に求められるシステム 稼動レベル • 問題発生時の対応レベル • 監視手段及びバックアップ方式の確立 • 問題発生時の役割分担、体制、訓練、 マニュアルの整備 ④ 移行性 現行システム資産 の移行に関する要 求 • 新システムへの移行期間及び 移行方法 • 移行対象資産の種類及び移行量 • 移行ｽｹｼﾞｭｰﾙ立案、移行ツール開発 • 移行体制の確立、移行ﾘﾊｰｻﾙの実施 セキュリ ⑤ ティ 情報システムの安 全性の確保に関す る要求 • 利用制限 • 不正アクセスの防止 • アクセス制限、データの秘匿 • 不正の追跡、監視、検知 • 運用員等への情報セキュリティ教育 ｼｽﾃﾑ環境・ ⑥ ｴｺﾛｼﾞｰ システムの設置環 境やエコロジーに 関する要求 • 耐震／免震、重量／空間、温度／湿度、• 規格や電気設備に合った機器の選別 騒音など、システム環境に関する事項 • 環境負荷を低減させる構成 • CO2排出量や消費ｴﾈﾙｷﾞｰに関する事項 運用・ ③ 保守性 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 18 SEC 非機能要求項目の体系 Software Engineering for Mo･No･Zu･Ku･Ri 大・中項目の全体像 非機能要求項目 可用性 性能・拡張性 運用保守性 移行性 継続性 業務処理量 通常運用 移行時期 耐障害性 性能目標値 保守運用 移行方式 災害対策 リソース拡張性 障害時運用 回復性 性能品質保証 運用環境 移行対象 （機器） セキュリティ システム環境・ｴｺﾛｼﾞｰ 前提条件・ 制約条件 システム制約／ 前提条件 セキュリティ リスク分析 システム特性 適合規格 セキュリティ診断 サポート体制 移行対象 （データ） その他 運用管理方針 移行計画 セキュリティ リスク管理 アクセス・ 利用制限 中項目 多 データの秘匿 中項目 丌正追跡・監視 中項目 メトリクスに 重要項目を 含む割合 中項目 少 SDM公開講座 (2012.5.17) 機材設置 環境条件 環境 マネジメント ネットワーク対策 小項目で合計236項目 Copyright © 2010 - 2012 IPA, All Rights Reserved マルウェア対策 Ｗｅｂ対策 Software Engineering Center 19 非機能要求グレードの基本コンセプト① SEC Software Engineering for Mo･No･Zu･Ku･Ri レベルによる要求項目の共通認識 メトリクス毎に実現上必要となるコストや実装上のアーキテ クチャの難易度が大きく変わるポイントで『レべル』を設定。 レベル０からレベル５までの最大６段階で設定。レベル値が 大きいほど実現難易度は高くなり、一般に開発コストは増加。 レベルで示す値はユーザ／ベンダ間で合意形成を図る出発点 とし、最終的に具体的な数値として合意することを想定。 ユーザ レベルの例 大項目 中項目 小項目 メトリクス 可用性 継続性 業務継続性 （可能性を保証 するにあたり、 要求される 業務の範囲と その条件） SDM公開講座 (2012.5.17) 非機能要求を提示しやすい レベル ０ １ ２ ３ ４ ５ 対象業務範囲 内部向け バッチ系 業務 内部向け オンライン 系業務 内部向け 全業務 外部向け バッチ系 業務 外部向け オンライン 系業務 全ての 業務 サービス 切替時間 ２４時間 以上 ２４時間 未満 ２時間 未満 ６０分 未満 １０分 未満 ６０秒 未満 業務継続の 要求度 障害時の 単一障害 二重障害 業務停止 時は業務停 時でもサー を許容 止を許容せ ビス切替時 する。 ずに処理を 間の規定 継続させる 内で業務 継続 Copyright © 2010 - 2012 IPA, All Rights Reserved ベンダ 非機能要求を確認しやすい Software Engineering Center 21 非機能要求グレードの基本コンセプト② SEC Software Engineering for Mo･No･Zu･Ku･Ri グレードによる要求項目の選定 利用目的、規模、障害時に社会に与える影響が異なることにより実現水準に有意 な差がある３つのモデルシステムを定義。 モデルシステム毎に重要項目の選択レベルと選択時の条件をグレードと定義。 グレードは、非機能要求項目を決定する目安として有効。 モデル 社会的影響が殆ど無い システム システム 名 ⇒部門のファイ ルサーバ等 社会的影響が限定される 社会的影響が極めて システム 大きいシステム ⇒府省全体で ⇒公開している 使うシステム等 システム等 システム 組織内の特定部門が比較 組織活動の基盤となるシステ 国民生活・社会経済活動の の概要 的限られた範囲で利用して ムで、その機能が低下又は利 基盤となるシステムで、その いるシステムで、機能が低下 または利用丌可な状態に なった場合、利用部門では 大きな影響があるが、その他 には影響しないもの。 ここでは、ごく小規模のイン ターネット公開システムを想 定している。 SDM公開講座 (2012.5.17) 用丌可能な状態に陥った場合、機能が低下又は利用丌可 当該組織活動に多大の影響 能な状態に陥った場合、国 を及ぼすと共に取引先や顧客 民生活・社会経済活動に多 等の外部利用者にも影響を及 大な影響を不えるもの。 ぼすもの。 ここでは、丌特定多数の人 ここでは、組織内のネットワー が利用するインフラシステム クに限定した基幹システムを を想定している。 想定している。 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 22 非機能要求グレードコンセプト③ SEC Software Engineering for Mo･No･Zu･Ku･Ri 段階的な詳細化 ユーザー視点から要求の実現レベルを見える化するため、段階的に詳 細化して「早期に」「誤解なく」「漏らさずに」確認する。 方向性の確認 コストに大きな影響がある 開発開始までに必要な 要求項目を決定 要求項目を決定 ①モデルシステム （３つのモデル） ②グレード表 ＋樹系図 ③項目一覧 ＋樹系図 システムの特徴 重要項目 詳細項目 16項目 SDM公開講座 (2012.5.17) +76 92項目 Copyright © 2010 - 2012 IPA, All Rights Reserved +144 236項目 Software Engineering Center 23 非機能要求グレード 公開URL http://sec.ipa.go.jp/reports/20100416.html SEC Software Engineering for Mo･No･Zu･Ku･Ri 次の２つのガイド(①②) と３つの図表(③④⑤)から構成。 さらに、自由にカスタマイズできるスプレッドシート(⑥) を用意。 ①利用ガイド （解説編） 非機能要求グレードを 作成した背景やツールの詳 細等を解説したもの ③グレード表 ３つのモデルシステムと重 要な非機能要求項目に対 する要求レベルとグレード を一覧表化したもの ⑤樹系図 グレード表、項目一覧の 閲覧性を向上させ、要求項目 の検討順を可視化した図。 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved ②利用ガイド （利用編） 非機能要求グレードの 具体的な利用方法につい て解説したもの ④項目一覧 システム基盤に関わる非機能 要求項目を利用者／開発者 間で漏れなく共通に認識でき るよう体系化した一覧表。 ⑥活用シート グレード表と項目一覧の内容 をまとめた一覧表。 スプレッドシート形式で使用条 件の範囲で改変が可能。 Software Engineering Center 24 SEC 手順① モデルシステムの選択 Software Engineering for Mo･No･Zu･Ku･Ri 信頼性の観点から定めた情報システムの３つのモデルシス テムから１つ選ぶことでイメージを固める。 ※IPA/SEC 重要インフラ情報システム信頼性研究会報告書のシステムプロファイルより定義 モデル システ ム名 モデル システ ムの 概要 社会的影響が ほとんどないシステム 社会的影響が 限定されるシステム 社会的影響が 極めて大きいシステム ごく小規模のインターネット に公開されたシステムを イメージ 府省内のネットワークに限定 した基幹システムをイメージ 組織内の特定部門が比較的限 られた範囲で利用しているシ ステムで、機能が低下または 利用不可な状態になった場合、 利用部門では大きな影響があ るが、その他には影響しない もの。 組織活動の基盤となるシステ ムで、その機能が低下又は利 用不可能な状態に陥った場合、 当該組織活動に多大の影響を 及ぼすと共に取引先や顧客等 の外部利用者にも影響を及ぼ すもの。 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved 社会インフラのシステムなど 不特定多数の人が利用するシ ステムをイメージ 国民生活・社会経済活動の基 盤となるシステムで、その機 能が低下又は利用不可能な状 態に陥った場合、国民生活・ 社会経済活動に多大な影響を 与えるもの。 Software Engineering Center 25 モデルシステムの選択は１６の特徴項目から SEC Software Engineering for Mo･No･Zu･Ku･Ri 要求レベル（グレード）の特徴を示す非機能要求（16項目）を用いて一 番合うモデルシステムを選び、システムに合わせてカスタマイズ モデルシステムの要求レベル 特徴 モデル システム 社会的影響が殆ど無い システム 稼動率 ９９．９９％ ９９％ （年間許容停止時間 数日） 可用 目標復 週次のバックアップからの復 性 旧水準 旧 大規模 災害 性能 性能 目標 ・ 拡張 拡張性 性 運用 運用時 間 ・ 保守 バック 性 アップ 社会的影響が限定される 社会的影響が極めて大きい システム システム （年間許容停止時間 ９９．９９９％ 約１時間） （年間許容停止時間 約数分） １営業日以内の復旧 数時間で障害発生時点に復旧 システム再構築による復旧 １週間以内の業務復旧 ＤＲサイトで業務継続 大まかな性能目標 （他の要求より重視しない） 性能面でのサービスレベルを 規定 性能面でのサービスレベルを 規定 拡張性は考慮しない 拡張計画が決められている 拡張計画が決められている 業務時間のみサービス提供 夜間バッチ終了後、業務開始 まで若干の停止時間あり 常時サービス提供が前提 手動で必要データのみ 日次に自動でシステム全体 運用サイトと同期したバック アップサイトを構成 機器の死活監視 業務機能を監視 障害の予兆監視 ： ： ： 運用監 視 ： SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved （２４Ｈ／３６５日稼動） Software Engineering Center 26 手順② グレード表による推奨値の確認 SEC （ｼｽﾃﾑ基盤の非機能要求に関するｸﾞﾚｰﾄﾞ表） Software Engineering for Mo･No･Zu･Ku･Ri コストや品質に影響が大きい重要項目（92項目）についてあらかじめ要 求レベルの値を例示することで判断を「早期に」できる。 「可用性」：運用時間の例 社会的影響が ほとんどないシステム レベル値 2 夜間のみ停 止 (9時～21 時） 選択時の条件 社会的影響が 限定されるシステム レベル値 夜間に実施する業務はな 4 若干の停止 く、システムを停止可能。 有り (9時～翌朝 [-] 運用時間をもっと 8時55分) 限って業務を稼働させる 場合 [+] 24時間無停止やリ ブート処理等の短時間の 停止のみを考える場合 選択時の条件 レベル値 選択時の条件 24時間無停止での運用は 5 24時間無停 システムを停止できる時 必要ないが、極力システ 間帯が存在しない。 止 ムの稼働は継続させる。 [-] 夜間のアクセスは認 めないなど、長時間運用 を停止する場合 [+] 24時間無停止で運用 する場合 モデルシステムごとに 事前に要求レベルの値を例示 SDM公開講座 (2012.5.17) 社会的影響が 極めて大きいシステム [-] 1日のスケジュール で定期的に運用を停止す る時間帯が存在する場合 要求レベルの値を調整する ための判断条件を記載 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 28 手順③ 重要項目以外のレベルの決定 （ｼｽﾃﾑ基盤の非機能要求項目に関する項目一覧） SEC Software Engineering for Mo･No･Zu･Ku･Ri 網羅的な項目と選択肢を提示することで、要求項目のレベルを 「漏れなく」「誤解なく」確認し、必要に応じて「レベルを調整」 項番 大項目 A.1.1.1 可用性 中項目 継続性 小項目 運用スケジュール 重 複 項 目 小項目説明 重 要 項 目 システムの稼働時間や停止運用に関する情報。 レベル メトリクス (指標) 0 1 運用時間（通常） 規定無し 2 3 定時内 夜間のみ停 1時間程度の （9時～17時） 止 停止有り （9時～21時） （9時～翌朝8 時） 4 5 運用 コスト への 影響 若干の停止 24時間無停 有り 止 （9時～翌朝8 時55分） 備考 【重複項目】 C.1.1.1。運用時間は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コストや運用 コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。 【メトリクス】 運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。 【レベル】 （）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。規定無しは、固定のサービス時間が存 在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するようなケースを想定し ている（例：障害発生に備えた予備システム、開発・検証用システム等）。定時内や夜間のみ停止は、一般的な業務形態を 想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要であ る。停止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時間帯を指 す。24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することが できないようなケースも含まれる。 ○ ○ A.1.1.2 開発契約までに確認が 必要な要求項目一覧 運用時間（特定 規定無し 日） 定時内 夜間のみ停 1時間程度の （9時～17時） 止 停止有り （9時～21時） （9時～翌朝8 時） コスト感に基づく要求レベル に応じた選択肢を提示 若干の停止 24時間無停 有り 止 （9時～翌朝8 時55分） 【重複項目】 C.1.1.2。運用時間は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コストや運用 コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。 【メトリクス】 特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義している日のことを指 す。特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必要がある（例：「月～金はレベル2だが、土日 はレベル0」、「通常はレベル5だが、毎月1日にリブートをするためその日はレベル3」など）。 また、ユーザの休日だけでなく、ベンダの休日についても特定日として認識し、運用保守体制等を整合すること。 ○ ○ A.1.1.3 ○ ○ 計画停止の有無 計画停止有 り（運用スケ ジュールの変 更可） 計画停止有 計画停止無 り（運用スケ し ジュールの変 更不可） 【重複項目】 C.2.1.1。計画停止の有無は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コスト や運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。 ○ 【運用コストへの影響】 計画停止が”有り”の場合、事前のバックアップや、システム構成に応じた手順準備など、運用時のコストがかさむ。 要求レベル 要求項目 項番 大項目 中項目 小項目 小項目説明 メトリク ス (指標) A.1. 1.1 可用性 継続性 運用スケ ジュール システムの稼働時間や停 止運用に関する情報。 運用時間 （通常） レベル 0 1 2 3 4 5 規定無 し 定時内 （9時～ 17時） 夜間の み停止 （9時～ 21時） 1時間程 度の停 止有り （9時～ 翌朝8 時） 若干の 停止有 り （9時～ 翌朝8時 55分） 24時間 無停止 低 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved 高 Software Engineering Center 29 【参考】大項目ごとの体系化：樹系図 SEC Software Engineering for Mo･No･Zu･Ku･Ri 非機能要求項目の大項目単位に中項目以下の検討順序 を可視化したもの 検討順序 前 重要な 非機能要求項目 後 後 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 30 【参考】非機能要求グレードのカスタマイズSEC Software Engineering for Mo･No･Zu･Ku･Ri 自由にご利用いただくために改変可能な使用条件で、 スプレッドシートの「活用シート」を提供。 項番 大項目 A.1.1.1 可用性 中項目 継続性 小項目 小項目説明 重 重 複 要 項 項 目 目 運用スケジュー システムの稼働時間や停止運用に関する情 ル 報。 レベル メトリクス (指標) 0 運用時間（通 規定無し 常） 1 2 3 4 5 運用コ ストへ の影 響 定時内 夜間のみ 1時間程度 若干の停 24時間無 （9時～17 停止 の停止有 止有り 停止 時） （9時～21 り （9時～翌 時） （9時～翌 朝8時55 朝8時） 分） 社会的影響が殆ど無いシステム 選択レベル 【メトリクス】 運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。 運用時間（特 規定無し 定日） 定時内 夜間のみ 1時間程度 若干の停 24時間無 （9時～17 停止 の停止有 止有り 停止 時） （9時～21 り （9時～翌 時） （9時～翌 朝8時55 朝8時） 分） 【重複項目】 C.1.1.2。運用時間は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関 する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の 両方に含まれている。 計画停止の 有無 ○ ○ A.1.2.1 業務継続性 可用性を保証するにあたり、要求される業務 の範囲とその条件。 対象業務範 囲 計画停止 計画停止 計画停止 有り（運用 有り（運用 無し スケジュー スケジュー ルの変更 ルの変更 可） 不可） 【重複項目】 C.2.1.1。計画停止の有無は、システムの可用性の実現レベルを表す項目であると共に、運用・保守 性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保 守性の両方に含まれている。 ○ 内部向け 内部向け 内部向け 外部向け 外部向け 全ての業 バッチ系 オンライン 全業務 バッチ系 オンライン 務 業務 系業務 業務 系業務 【運用コストへの影響】 計画停止が”有り”の場合、事前のバックアップや、システム構成に応じた手順準備など、運用時の コストがかさむ。 【メトリクス】 ここでの対象業務範囲とは、稼働率を算出する際の対象範囲を指す。 【レベル】 内部向けとは対象とするシステム内に閉じた処理（業務）、外部向けとは他システムとの連携が必 要な処理（業務）を表している。 ○ A.1.2.2 サービス切替 24時間以 24時間未 2時間未満 60分未満 10分未満 60秒未満 時間 上 満 ○ グレード表 ○ 目標復旧水準 業務停止を伴う障害が発生した際、何をどこま （業務停止時） で、どれ位で復旧させるかの目標。 スプレッド シート化 障害時の 単一障害 二重障害 業務停止 時は業務 時でも を許容す 停止を許 サービス る 容せず、 切替時間 処理を継 の規定内 続させる で継続す る RPO（目標復 復旧不要 5営業日前 1営業日前 障害発生 旧地点） の時点 の時点 時点 （週次バッ （日次バッ （日次バッ クアップか クアップか クアップ+ らの復旧） らの復旧） アーカイブ ○ からの復 旧） A.1.3.2 【メトリクス】 サービス切替時間とは、想定できる障害（例えばハードウェアの故障等により業務が一時的中断す るケースなど）に対して、対策を施すこと（例えばクラスタ構成でのサーバの切替えなど）により、業 務再開までに要する時間を指す。 選択時の条件 2 夜間のみ 週末はバックアップ運用のみのた 停止 め、夜間は停止する。 （9時～21 時） [-] 週末運用するバックアップや バッチ処理などが存在せず、土休 日は運用を停止する場合 [+] 休日出勤する社員の業務に必 要なため、土休日も運用する場合 5 24時間無 システムを停止できる時間帯が存 停止 在しない。 1 計画停止 有り（運用 スケ ジュール の変更不 可） 2 計画停止 システムを停止できる時間帯が存 無し 在しない。 [+] 休日にバックアップ運用を行う など、通常とは異なる運用時間とな る特定日が存在する場合 0 計画停止 事前の合意があれば、停止は可 有り（運用 能。 スケ ジュール [+] 運用時間外での停止だけで対 の変更 応可能な場合 可） [-] 1日のスケジュールで定期的に 運用を停止する時間帯が存在する 場合 1 24時間未 外部向けの業務はなく、1日程度の 満 中断であれば許容できる。 5 60秒未満 リアルタイム性が要求されるため、 システム停止時は瞬時の復旧が必 要となる。 3 60分未満 外部とのオンラインでの業務はある が、数十分の停止までは許容可 能。 [-] 障害時の対策を必要としない場 合 [+] サービス切替の影響がある場 合（影響度に応じて中断を許容でき る時間を検討する） 1 単一障害 時は業務 停止を許 容せず、 処理を継 続させる 障害時の業務停止の許容時間に 合わせる。 【メトリクス】 RLOで業務の復旧までを指定している場合、該当する業務のデータの復旧までが対象であり、業務 再開の整合性の確認は別途必要となる。 1 5営業日 前の時点 （週次バッ クアップ からの復 旧） データの損失はある程度許容で き、週次のバックアップからの復旧 とする。 [-] リスクを認識した上、障害発生 時の業務停止を許容できる場合 [+] コスト増を考慮した上で二重障 害による業務停止を防止する必要 がある場合 [-] データを持たず、復旧が不要な 場合 [+] 日次のバックアップからの復旧 でないと、データ損失の影響が大き い場合 【メトリクス】 サービス切替時間（A.1.2.2）での復旧時間と異なり、RTOでの復旧時間は、業務の継続対策を実施 していない（業務停止となる）ケースでの障害での復旧時間を指している。 RLOで業務の復旧までを指定している場合、該当する業務のデータの復旧までが対象であり、業務 再開の整合性の確認は別途必要となる。 1 1営業日 目標復旧地点を考慮し、システム 以内 の規模から判断する。 RLO（目標復 システム 旧レベル） の復旧 【メトリクス】 業務停止を伴う障害が発生した際、何を復旧の対象とするかのレベルを示す。 1 特定業務 主要な業務のみを対象とすること のみ ができる。 [-] 業務継続に、外部とのリアルタ イムでの処理が必要とならない場 合 [+] オンライン業務においてサービ ス切替の影響がある場合（影響度 に応じて中断を許容できる時間を 検討する） 2 二重障害 障害時の業務停止の許容時間に 時でも 合わせる。 サービス 切替時間 [-] リスクを認識した上、二重障害 の規定内 での業務停止を許容できる場合 で継続す る 3 障害発生 時点 （日次バッ クアップ+ アーカイ ブからの 復旧） [-] 業務の停止が1時間以内であれ ば許容できる場合 2 二重障害 二重障害でも業務継続が前提とな 時でも る。 サービス 切替時間 の規定内 で継続す る データの損失は許容できないため、 3 障害発生 データの損失は許容できないため、 障害発生時点までの復旧が原則。 時点 障害発生時点までの復旧が原則。 （日次バッ [-] データの損失がある程度許容 クアップ+ できる場合（復旧対象とするデータ アーカイ （日次、週次）によりレベルを選定） ブからの 復旧） 2 12時間以 目標復旧地点を考慮し、システム 内 の規模から判断する。 [-] 業務停止の影響が小さい場合 [+] 業務停止の影響が大きい場合 【レベル0】 システムの復旧は、ハードウェアの復旧だけでなくデータのリストアまでを対象とする。 ○ [-] 運用スケジュールとして停止可 能な時間帯が存在し、計画停止の 必要性がある場合 [-] 運用スケジュールとしては停止 可能な時間帯は存在しないが、事 前の調整で停止が可能な場合 [+] 24時間無停止が要求される場 合 4 外部向け 外部とのリアルタイムでの処理が オンライ 主要業務であり、外部向けオンライ ン系業務 ン業務が稼働していることがシステ ム稼働の条件となる。 RTO（目標復 1営業日以 1営業日以 12時間以 6時間以内 2時間以内 旧時間） 上 内 内 特定業務 全ての業 のみ 務 24時間無停止での運用は必要な い。停止可能な時間が存在し、計 画的な停止は可能。 [-] 定期的に運用を停止する日が 存在する場合 2 内部向け 内部向けの業務が主要業務であ 3 外部向け 外部とのバッチ的な処理で業務が 全業務 り、内部向け全業務が稼働している バッチ系 主要業務であり、内部向けの業務 ことがシステム稼働の条件となる。 業務 および外部とのバッチ的な業務が 稼働していることがシステム稼働の [+] 外部向け業務も実施しており、 条件となる。 必要な業務としている場合 [-] 外部との業務が必要ない場合 [+] 業務継続に、外部とのリアルタ イムでの処理が必要な場合 【メトリクス】 業務継続の要求度とは、発生する障害に対して、どこまで業務を継続させる必要があるかを示す考 え方の尺度を示している。 システムを構成する機器や部位には、単一障害点SPOF（Single Point Of Failure）が多数存在し、シ ステム停止となるリスクを多く含んでいる。これらのSPOFを許容するか、冗長化などの対策で継続 性をどこまで確保するかが要求の分かれ目となる。 【レベル3】 障害発生時点とは、障害が発生する直前のトランザクションなどの処理が完了している時点のこと を指し、障害発生時点まで復旧するためには、発生直前の完了した処理のジャーナルログが保証さ れていることが前提となる。またジャーナルログをアーカイブすることで、障害発生までの任意の時 点への復旧に対応することを想定している。 ○ A.1.3.3 社会的影響が極めて大きいシステム 選択レベル 0 規定無し 通常と異なる運用時間となる特定 日は存在しない。 ○ 業務継続の 要求度 A.1.3.1 選択時の条件 5 24時間無 システムを停止できる時間帯が存 停止 在しない。 【運用コストへの影響】 中断を許容する時間が長くなれば、復旧対策としてはシステムでの自動化から人員による手動での 対処に比重が移るため、運用コストへの影響が出てくる。 A.1.2.3 選択レベル 4 若干の停 24時間無停止での運用は必要ない 止有り が、極力システムの稼働は継続さ （9時～翌 せる。 朝8時55 分） [-] 夜間のアクセスは認めないな ど、長時間運用を停止する場合 [+] 24時間無停止で運用する場合 【メトリクス】 特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義 している日のことを指す。特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必 要がある（例：「月～金はレベル2だが、土日はレベル0」、「通常はレベル5だが、毎月1日にリブート をするためその日はレベル3」など）。 また、ユーザの休日だけでなく、ベンダの休日についても特定日として認識し、運用保守体制等を 整合すること。 ○ ○ A.1.1.3 選択時の条件 2 夜間のみ 夜間に実施する業務はなく、システ 停止 ムを停止可能。 （9時～21 時） [-] 運用時間をもっと限って業務を 稼働させる場合 [+] 24時間無停止やリブート処理等 の短時間の停止のみを考える場合 【レベル】 （）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。規定無しは、固 定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユー ザがシステムを起動するようなケースを想定している（例：障害発生に備えた予備システム、開発・ 検証用システム等）。定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動 する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。停 止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のあ る時間帯を指す。24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必 要があり、システムを停止することができないようなケースも含まれる。 ○ ○ A.1.1.2 社会的影響が限定されるシステム 備考 【重複項目】 C.1.1.1。運用時間は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関 する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の 両方に含まれている。 4 2時間以 なるべく早く復旧する。 内 [-] 業務停止の影響が小さい場合 [+] 業務停止の影響が大きい場合 2 全ての業 全ての業務が稼働していないと影 務 響がある。 [+] 業務毎に影響を切り離せない 場合 2 全ての業 全ての業務が稼働していないと影 務 響がある。 [-] 影響を切り離せる業務がある場 合 [-] 影響を切り離せる業務がある場 合 3 一週間以 大規模災害時は、保管するデータ 内に再開 からの復旧により業務を再開する。 4 3日以内 ライフラインの復旧を考慮し、シス に再開 テムとして最大限の回復に努める。 【レベル1】 特定業務とは、例えばA.1.2.1対象業務範囲で定義する継続性が要求される業務などを指す。 A.1.4.1 目標復旧水準 大規模災害が発生した際、どれ位で復旧させ （大規模災害 るかの目標。 時） 大規模災害とは、火災や地震などの異常な自 然現象、あるいは人為的な原因による大きな 事故、破壊行為により生ずる被害のことを指 し、システムに甚大な被害が発生するか、電 力などのライフラインの停止により、システム をそのまま現状に修復するのが困難な状態と なる災害をいう。 稼働率 明示された利用条件の下で、システムが要求 されたサービスを提供できる割合。 明示された利用条件とは、運用スケジュール や、目標復旧水準により定義された業務が稼 働している条件を指す。その稼働時間の中 で、サービス中断が発生した時間により稼働 率を求める。 A.1.5.1 システム再開 再開不要 数ヶ月以 一ヶ月以 一週間以 3日以内に 1日以内に 目標 内に再開 内に再開 内に再開 再開 再開 【メトリクス】 大規模災害としては、RPO、RTO、RLOなどの細かな要求までは確定せず、システム再開目標とし て大まかな復旧時間を設定する。目標復旧レベルについては、業務停止時の目標復旧水準を参考 とする。 1 数ヶ月以 データの損失はある程度許容で 内に再開 き、週次のバックアップからの復旧 とする。 稼働率 【レベル】 24時間365日の稼働の場合、1年間で業務が中断する時間の合計は、それぞれ以下の通りとなる。 95%・・・・・・・・・18.3日 99%・・・・・・・・・87.6時間 99.9%・・・・・・・ 8.76時間 99.99%・・・・・・ 52.6分 99.999%・・・・・ 5.26分 2 99% ○ [-] 代替機器の調達や、復旧体制 の準備に時間がかかる場合 [+] 業務停止の影響が大きく、DRサ イトによる早急な復旧が必要な場 合 [-] データを持たず、復旧が不要な 場合 [+] 業務停止の影響が大きい場合 95%以下 95% 99% 99.9% 99.99% 99.999% ○ 1年間で数時間程度の停止を許 容。 4 99.99% 1年間で1時間程度の停止を許容。 [+] 人命に影響を及ぼす、経済的な 損失が甚大など、安全性が求めら れる場合 5 99.999% 1年間で数分程度の停止までしか 許容できない。 備考に記載した稼働率での目安と なる稼働時間を参考にして決定す る。 また1日8時間で週5日稼働のシステムではサービス切替時間と稼働率の関係は以下の通りとなる。 週に1時間・・・・97.5% 月に1時間・・・・99.4% 年に1時間・・・・99.95% A.2.1.1 耐障害性 サーバ サーバで発生する障害に対して、要求された サービスを維持するための要求。 冗長化（機 器） 非冗長構 特定の 全ての 成 サーバで サーバで 冗長化 冗長化 【メトリクス】 冗長化における機器、コンポーネントは、冗長化の単位を表し、機器は筐体を複数用意することによ る冗長化、コンポーネントは筐体を構成する部品（ディスク、電源、FAN、ネットワークカード等）を複 数用意することによる冗長化を指す。 また、仮想化技術の適用により、同一ハードウェア上にサーバ機能を集約させることで、冗長化に 必要なハードウェア所要量を削減することも可能である。いずれにしても、ハードウェア上で実現さ れる業務継続性の要求を満たすよう機器の冗長化を検討する必要がある。 【レベル1】 特定のサーバで冗長化とは、システムを構成するサーバの種別（DBサーバやAPサーバ、監視サー バなど）で冗長化の対応を分けることを意味する。 また要求としてサーバの単位ではなく、業務や機能の単位で冗長化を指定する場合、それを実装す るサーバを想定してレベルを設定する。 A.2.1.2 項目一覧 SDM公開講座 (2012.5.17) 冗長化（コン 非冗長構 特定のコ 全てのコン ポーネント） 成 ンポーネン ポーネント トのみ冗 を冗長化 長化 活用シート 改変・再配布が可能 Copyright © 2010 - 2012 IPA, All Rights Reserved 【レベル1】 サーバを構成するコンポーネントとして、内蔵ディスクや、電源、FANなどを必要に応じて冗長化する ことを想定している（例えば内蔵ディスクのミラー化や、ネットワークIFカードの2重化など）。 Software Engineering Center 31 非機能要求グレードの利用時期の例 SEC Software Engineering for Mo･No･Zu･Ku･Ri ゴールは「開発」を開始するために十分な要求項目の確 参考： SECBOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～」（オーム社刊） 認・決定 グレード表・樹系図 モデルシステム 項目一覧・樹系図 詳細 化 モデル 決定 利用 利用 利用 経営層 業務部門 情報システム 部門 ベンダ レビュー （要件定義書 ・予算） 事業要件定義 業務要件定義 システム 要件定義 業務要件定義 作成支援 SDM公開講座 (2012.5.17) システム 要件定義 作成支援 Copyright © 2010 - 2012 IPA, All Rights Reserved R F P 作 成 実行 稟議 承認 承認 発注 検討 提案・見積 Software Engineering Center 32 SEC 業界全体への普及（期待） Software Engineering for Mo･No･Zu･Ku･Ri 完成した非機能要求グレードが業界の皆様によって様々な形で活用 されることを期待 ⇒ ex.クラウドに対する非機能要求の整理 ITベンダーだけでなく、ユーザ組織での利用を期待 社内標準への取り込み 業種・業界向けに カスタマイズ 教育コンテンツ化 RFPへの掲載 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 33 「非機能要求グレード」による効果 SEC Software Engineering for Mo･No･Zu･Ku･Ri 「非機能要求の見える化」を通じ、利用者・社会・開発者 の発展に貢献 利用者 業務への情報システムの影響を明確に把握 情報システムの安心・安全な利用や効率的利用 情報システム費用の説明根拠の明確化 その結果 社会・ＩＴ業界 より安心・安全で便利な社会 インフラの実現 健全な業界構造と業界発展 （受発注関係や責任の明確化） SDM公開講座 (2012.5.17) 開発者 システム開発における手戻り コストの圧縮・期間短縮 システム運用におけるトラブル の減少・削減 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 34 非機能要求グレードの基本的な活用シーンSEC Software Engineering for Mo･No･Zu･Ku･Ri 活用シートを適宜加工することでさまざまなワークシートと して活用できる。 （１）要件定義書やＲＦＰに添付 上記資料の非機能要求はまとめて書かれていない。 このため、付録などに非機能要求を添付して抜け・ もれチェックに使う。また、まとめることで矛盾や 優先順位の検討が容易になる。 （２）非機能要求ヒアリング用シート 要件定義を行う場合、業務担当者や運用担当者に 非機能要求を確認する際に使う （３）非機能要件チェックシート 第三者が非機能要求グレードを使わずに作成した 要件定義のチェックを行う時に使う （４）既存のシステム診断シート 既存のシステムの非機能要求が正しく設定されて いるかを診断し、ITリスクや過剰なシステムを把握 SDM公開講座 (2012.5.17) Copyright © 2010 – 2012 IPA, All Rights Reserved Software Engineering Center 35 社内システムの共通ランク作成による効率化 SEC Software Engineering for Mo･No･Zu･Ku･Ri グ ル ー プ ③ グ ル ー プ ② グ ル ー プ ① 社内に共通インフラ基盤や社内グレードが存在する場合には、非機能要求い くつかのグループに体系化することで、非機能要求グレードを効果的に活用 できる。 性能･拡張性（ユーザ数、同時アクセス数） 移行性（移行方式） システム環境・エコ（システム特性） 個別調整項目： 構築するシステムに応じてレベルが異なる項目 etc 社内ランクＡ 可用性=超高 セキュリティ=高 社会的に影響がある 社内グレード別に、 項目のレベルを 定義したセットを 作っておく 社内ランクＢ 可用性=高 セキュリティ=中 全社的業務に影響がある 毎回個別にレベル を検討・調整して 決める 社内ランクＣ 可用性=低 セキュリティ=低 社内ローカルシステム 社内グレード：各社独自のシステム分類定義によってレベルが分かれる項目 システム共通基盤・設備・社内規程 可用性 （ネットワーク機器、災害対策） 共通基盤： 運用性 （運用管理方針） 共通インフラ基盤・社内規則等あらかじめ セキュリティ （セキュリティ前提条件） レベルが決まっている項目 環境・エコ （データセンタの仕様） etc 項目一覧を用いて 設定値を決めておく ※経済産業省 「非機能要求グレード評価委員会報告書」を元に作成 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 36 SEC クラウドサービスと非機能要求グレード（1/2) Software Engineering for Mo･No･Zu･Ku･Ri クラウドサービスは、作るから選択への転換 オンプ レミス IaaS PaaS SaaS 機能要求 業務アプリ ケーション 非機能要求 グ レ非 実行基盤 ー機 ド能 ハード、OS、 の 要 ミドルウェア 対求 象 (業務フロー、データ項目等) （可用性、性能・拡張性、運用保守性、 移行性、セキュリティ、 システム環境・エコロジー、 ユーザビリティ等） ：利用者が決めることができない ：利用者が決めることができる（自分で作る） SDM公開講座 (2012.5.17) Copyright © 2010 – 2012 IPA, All Rights Reserved Software Engineering Center 37 SEC クラウドサービスと非機能要求グレード（2/2) Software Engineering for Mo･No･Zu･Ku･Ri 次のステップでクラウドサービスを検討： 1. 利用者の要求を明確にする（機能、非機能とも） 2. クラウドサービスの機能・SLA(=非機能要件)を評価する。 ⇒クラウドサービスの情報開示が必要 3. 双方の要件のすり合わせ⇒「割り切りも必要」 クラウドの利便性の裏にある、ITリスクの把握をする 要件を満たさない場合、ビジネス側でITリスクの担保や受容 Ex. クラウドサービスが何らかの理由で使えない場合に備え、人手の作業で業 務を代行するなどの対策を講じておく。 非機能要求 検証、リスクの担保・受容 ＳＬＡ クラウド サービス 利用者 SDM公開講座 (2012.5.17) クラウドサービス Copyright © 2010 – 2012 IPA, All Rights Reserved Software Engineering Center 38 17の事例を「活用事例集」として公開 事 例 開発標 準策定 1 予算 予算 作成 概算 見積 SI 提案 開発工程 要件 定義 設 計 運用 テス ト 障害 診断 既 存 事 例 ○ ユー ザ ベン ダ ○ ○ ○ 3 ○ ○ ○ 4 ○ ○ ○ ○ ○ 5 ○ 6 ○ ○ ○ 7 ○ ○ ○ 8 ○ ○ ○ 9 ○ ○ ○ ○ ○ 10 新 規 追 加 事 例 Software Engineering for Mo･No･Zu･Ku･Ri 利用者 システ ム 再評価 ○ 2 SEC ○ 11 ○ ○ ○ 12 ○ ○ ○ 13 ○ ○ 14 ○ 15 ○ ○ ○ ○ 16 ○ ○ 17 ○ ○ ○ ○ http://sec.ipa.go.jp/reports/20120424/20120424_2.ppt SDM公開講座 (2012.5.17) Copyright © 2011,2012 IPA, All Rights Reserved Software Engineering Center 39 【参考】 ダウンロードＵＲＬ SEC Software Engineering for Mo･No･Zu･Ku･Ri http://sec.ipa.go.jp/reports/20100416.html ・事例集や英語版もあります。 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 40 Software Engineering Center Information-technology Promotion Agency, Japan SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」第6回 「機能要件の合意形成ガイド」概説 ～発注者と受注者の合意形成について～ 2012年5月17日 独立行政法人 情報処理推進機構（IPA） 技術本部 ソフトウェア・エンジニアリング・センター（SEC） 研究員 柏木 雅之 Copyright © 2010 - 2012 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center SEC Software Engineering for Mo･No･Zu･Ku･Ri 1.はじめに ～「使えるシステム」を実現するために～ 2.「機能要件の合意形成ガイド」 3.コツの例 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 42 SEC Software Engineering for Mo･No･Zu･Ku･Ri 1.はじめに ～「使えるシステム」を実現するために～ SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 43 「使えないシステム」がなぜできるか？ SEC Software Engineering for Mo･No･Zu･Ku･Ri 発注者と開発者の認識の齟齬により、要求と実現されるソフトとの間に ギャップが生じる ①要件定義すべき内容が抜けてお その主な要因①②③ り、開発者に説明していない 要件定義 の契約 発注者(各府省) シ ス テ ム 化 計 画 業 務 部 門 の 要 求 内 容 受注者（開発者、ベンダ） ②発注者が開発者に説 明したが、何らかの 理由で漏れた A 要 件 定 義 内 容 B 設 計 内 容 C 実 現 ソさ フ トれ ウる ェ ア バグや障害 ⇒ 「使えない」 バグや障害 ⇒ 「使えない」 ④発注者が開発者に 説明し、共通理解 が得られた。 バグや障害 ⇒ 「使えない」 この絵は、発注者が要件定義 までを行い、それ以降の工程を 開発者が行う場合の例 SDM公開講座 (2012.5.17) ③開発者が何らかの理由により 誤認・拡大解釈し、実現範囲 に取り込んでしまった 参考文献：IPA/SEC 「機能要件の合意形成ガイド 概要編」(P.3)より Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 44 「使えるシステム」を実現するためには？ SEC Software Engineering for Mo･No･Zu･Ku･Ri 業務の専門家である発注者と、システムの専門家である開発者がそれぞ れ思い描く業務・システム像を刷り合わせ、共有することが重要。 × 業務 不一致 システム･ソ フトウェア 業務・システム像の一致・・・合意形成に向けての第一歩 発注者 発注者 要件定義書(発 私たちはこうい 注仕様書)を作 うことがしたい。 成したからその こういう制限事 とおりに作っ 項があるがより て・・・ よい方法は？ SDM公開講座 (2012.5.17) 妥当な 不十分な 要件定義 要件定義 開発者 開発者 私たちはこういう 要件定義書（発注仕 風に理解したが、 様書）に忠実にシス ここがわからない。 テムを作ろう・・・ こうしたほうがよ りよいと思う。 吹き出し部分は、会話の単純な例 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 45 SEC 何からはじめたらいいか？ 例 Software Engineering for Mo･No･Zu･Ku･Ri 「業務・システム像の一致」 をはかるためには、何から始めたらいいか？ 発注者が何をしたいか、開発者に伝える。 たとえ ば ①ここで原課が伺いに関して原議を起こし・・・ ②「・・・」（何のことかさっぱりわからない） 一方的に伝えるだけではダメ 発注者 SDM公開講座 (2012.5.17) 開発者 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 46 SEC 何からはじめたらいいか？ 例 Software Engineering for Mo･No･Zu･Ku･Ri 「業務・システム像の一致」 をはかるためには、何から始めたらいいか？ 発注者が何をしたいか、開発者にわかる言葉で伝える。 たとえ ば 【前提や定義】(たとえば、一般的な言葉で） ・原課：担当課・・・ ・伺い：事前申請・・・ ・原議：決済文書・・・ ①ここで原課が伺いに関して原議を起こし・・・ ②なるほど 合意形成に向けての第一歩 発注者 SDM公開講座 (2012.5.17) 開発者 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 47 「使えるシステム」を実現するためには？ （再） SEC Software Engineering for Mo･No･Zu･Ku･Ri どんな要件定義であっても、システムは出来上がるが、「使えるシステム」 が出来上がるとは限らない。 ⇒ システム･ソフトウェア要件定義のためのインプット「要件定義」が重要 システム化 の方向性 投資効果はあるか？ ②「システム要件」等 評価の定義に必要となる、 システム化計画 要件定義 要求は正しかったか？ 運用テスト 調達 システム 要件定義 ①本日題材にする 「機能要件の合意形 成ガイド」は、示された 要件定義をもとに、シ ステム要件等としてど う表現し、発注者と開 発者がレビューするか を中心にガイドしてい ます。 SDM公開講座 (2012.5.17) 仕様どおりか？システム適格 性確認テスト ソフトウェア 要件定義 ソフトウェア適 格性確認テスト プログラミング 業 シ 務 ソ ス フ テ ト ム ウ ェ ア Copyright © 2010 - 2012 IPA, All Rights Reserved 「要件定義」に求め られることや発注 者が開発者に伝え るべき事柄をたくさ ん掲載していますので、 それらを紹介します。 事 業 （ ビ ジ ネ ス ） Software Engineering Center 48 SEC Software Engineering for Mo･No･Zu･Ku･Ri 2. 機能要件の合意形成ガイド SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 49 SEC 「機能要件の合意形成ガイド」とは？ Software Engineering for Mo･No･Zu･Ku･Ri 2010年3月31日に「機能要件の合意形成ガイド」を公開 当初2年間は民間、その後はIPAで活動 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 50 SEC 「機能要件の合意形成ガイド」の構成は？ Software Engineering for Mo･No･Zu･Ku･Ri 6つの技術領域（「画面」「システム振舞い」「データモデル」「帳票」「バッ チ」「外部インタフェース」）について、システム設計（システム・ソフトウェア の要件定義・方式設計部分）について、発注者と開発者の合意形成をよ りよくするためのコツをガイドするもの。 【技術領域】 【対象とする工程】 画面編 システム化の方向性 データモデル編 システム振舞い編 システム化計画 要件定義 システム設計 概要編 システム開発 クレジット信用照会 システム 処理証跡管理システム ZZ9／ZZ9 納品書 ７８００００７ 信用照会問合せ情報 (ZZ9) 伝票番号 XXXXXXXXXX お届け先コード XXXXXXXXXX お届け先名 NNNNNNNNNNNNNN 御中 お届け先住所 NNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNN 出荷元コード 出荷部門 XXXXXXXXXX NNNNNNNNNNNNNN 売上区分 X 発注区分 X 支払期限 YYYY年MM月DD日 ７８００００６ 受注処理ログ情報 受注管理システム イ ン タ ー ネ ッ ト 納品明細 No テスト 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 単 価 品 番 商品名 XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ 9 数量 ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ 合 価 \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZZ,ZZ 消費税 額 \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ \Z,ZZZ,ZZ 9 備 考 ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ ＮＮＮＮＮＮＮＮＮＮＮＮ 帳票編 SDM公開講座 (2012.5.17) ７８００００８ 信用照会結果情報 YYYY/MM/DD 23:59 Copyright © 2010 - 2012 IPA, All Rights Reserved ６８００００９ 販売管理処理ログ情報 集配信システム 販売管理システム ７８００００１ 受注情報 ６８００００１ 出荷指示情報 ７８００００２ 商品出荷状況情報 ６８００００２ 配送結果情報 ７８００００３ 商品情報 【監視端末】 顧客管理システム ７８００００４ 新規顧客情報 ７８００００５ 顧客更新情報 【インターネット端末】 バッチ編 【社内システム端末】 外部インタ フェース編 Software Engineering Center 51 分冊１ SEC 概要編 Software Engineering for Mo･No･Zu･Ku･Ri 本ガイドのコツは以下の場面で使えます。 発注者と開発者間の業務要件・機能要件の定義とレビュー 発注者の業務設計担当者と業務システム設計担当者間のレビュー 開発者のシステム開発者とソフトウェア開発者間のレビュー 発 注 者 発注者に役に立つ コツを増強して 適用場面を拡大 開 発 者 「機能要件の 合意形成 ガイド」 「発注者ビュー ガイドライン」 「機能要件の合意形成ガイド（概要編）」より SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved. Software Engineering Center 52 分冊２ システム振舞い編 SEC Software Engineering for Mo･No･Zu･Ku･Ri 概要 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 53 分冊３ SEC 画面編 Software Engineering for Mo･No･Zu･Ku･Ri 概要 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 54 分冊４ データモデル編 SEC Software Engineering for Mo･No･Zu･Ku･Ri 概要 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 55 分冊５ 外部インタフェース編 SEC Software Engineering for Mo･No･Zu･Ku･Ri 概要 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 56 分冊６ SEC バッチ編 Software Engineering for Mo･No･Zu･Ku･Ri 概要 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 57 分冊７ SEC 帳票編 Software Engineering for Mo･No･Zu･Ku･Ri 概要 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 58 SEC 「ガイド」のどこが使えるか？ ① Software Engineering for Mo･No･Zu･Ku･Ri 典型的な作業4つに整理し、発注者・開発者の役割を明確に。 1.言い切る／聞き切る 発注者が、開発者に対して設計に必要な情報を伝える。 開発者は、必要な情報を引き出すために、積極的にインタビューすることも必 要となる。 2. 図表に書く 開発者が、聞き切った内容に基づいて、「工程成果物」として図表を書く。 個別の工程成果物を書く前に、共通ルールを作ることも必要となる。 3. もれ／矛盾をチェックする 開発者が、工程成果物のもれ/矛盾をチェックする。 工程成果物１つの記述のもれだけではなく、複数の工程成果物に跨る矛盾も チェックする必要がある。 4. 一緒にレビューする 発注者と開発者が、工程成果物をレビューする。 合意成熟のレベルに応じてレビューを繰り返す。そのため、レビューに先行す る一連の作業も繰り返す場合がある。 +1. 発注者が事前に意識（注意）することを整理 （外部インタフェース編、帳票編） ・・・開発者側に機能要求を伝える前に、発注者側で関係者と調整し決めておくべき点 (コツ）がある。 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 59 「ガイド」のどこが使えるか？ ② SEC Software Engineering for Mo･No･Zu･Ku･Ri 合意形成は発注者と開発者の協同作業であり、システム設計工程を通し て段階を踏んで徐々に成熟。設計書そのものは、そのある時点（特に最 終段階）でのスナップショットでしかない。つまり、合意形成をうまく進める ためには、設計書の書き方だけではなく、段階の踏み方が併せて重要と なる。 本ガイドではこの合意形成の段階のことを合意成熟度のレベルと呼び、 次の３段階を踏んでいると想定。 1. 仕掛レベル 発注者が「言い切った」、開発者が「聞き切った」と言えるレベル 要件定義が完了していなければ、このレベルで実施します。システム化の目 的と範囲が明確になっています。 2. 充実レベル 言い切った／聞き切った内容から「図表に書いてレビュー」を繰り返し、発注 者と開発者の合意内容が充実していくレベル 3. 完成レベル 合意内容が管理され、発注者と開発者の双方が「合意内容を確認できた」と 言えるレベル 外部設計工程の成果物の最終承認直前までのレベル SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 60 SEC 「ガイド」が目指していることは？ Software Engineering for Mo･No･Zu･Ku･Ri ４つの作業を繰り返し、発注者と開発者が開発するシステム像を共有し、 合意形成を図る。 ソフトウェア詳細設計等 次工程へ 合意成熟度のレベル 完成 一緒に レビューする もれ／矛盾を チェックする 図表に書く 言い切る／聞き切る 充実 もれ／矛盾を チェックする 図表に書く 言い切る／聞き切る 仕掛 発注者が示す要件定義 （主に機能要求） SDM公開講座 (2012.5.17) 一緒に レビューする 合意形成を図るための作業 システム・ソフトウェアの要 件定義・方式設計 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 61 SEC Software Engineering for Mo･No･Zu･Ku･Ri 3. コツの例 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 62 SEC Software Engineering for Mo･No･Zu･Ku･Ri 「機能要件の合意形成ガイド」の適用例 （開発者向け書き方／レビュー編） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 63 SEC 事例１：わかりにくい設計書 Software Engineering for Mo･No･Zu･Ku･Ri 事例：わかりにくい画面遷移ドキュメント ユーザの役割（一般ユーザ、サプライヤ、管理者）毎に、異なる遷移を表現しよう と、以下の様な遷移図を持っていくと、お客様に「意味がわからない」といわれた。 《開始点》 ログイン画面 遷移と分岐が ゴチャゴチャし てて分からん … [一般ユーザの場合] トップページ [サプライヤの場合] [管理者の場合] 管理者トップページ サプライヤトップページ メニュー画面 発注者側 （お客様） [一般ユーザの場合] 《終了点》 商品一覧画面（ユーザ） SDM公開講座 (2012.5.17) [サプライヤの場合] [管理者の場合] 《終了点》 商品一覧画面（管理者） Copyright © 2010 - 2012 IPA, All Rights Reserved 《終了点》 商品一覧画面（サプライヤ） Software Engineering Center 64 SEC 事例１：わかりにくい設計書 Software Engineering for Mo･No･Zu･Ku･Ri 何故、そのようなことになってしまったのか？ ユーザ役割毎に画面遷移順序が異なるにも拘わらず、１つの画面遷移 ドキュメントに収めてしまったから。 一般ユーザの遷移 《開始点》 ログイン画面 [一般ユーザの場合] トップページ サプライヤの遷移 望ましい書き方は ユーザ役割別に 画面遷移を作成す る [サプライヤの場合] [管理者の場合] 管理者トップページ 商品一覧(ユーザ編)画面遷移 サプライヤトップページ 《開始点》 《開始点》 ログイン画面（共通） ト ップ ページ 管理者ト ップ ページ サプ ライヤト ップ ページ [メニュー選択] メニュー画面（共通） [メニュー選択] メニュー画面（共通） [業務種類選択] 《終了点》 商品一覧画面（管理者） 《終了点》 商品一覧画面（サプライヤ） メニュー画面（共通） [業務種類選択] [業務種類選択] 《終了点》 商品一覧画面（ユーザ） 商品一覧画面（ユーザ） [ログイン] [サプライヤの場合] [管理者の場合] 《終了点》 ログイン画面（共通） [ログイン] [メニュー選択] [一般ユーザの場合] 《開始点》 ログイン画面（共通） [ログイン] メニュー画面 商品一覧(サプ ラ イ ヤ編)画面遷移 商品一覧(管理者編)画面遷移 《終了点》 商品一覧画面（管理者） 《終了点》 商品一覧画面（サプ ライヤ） 画面遷移の例 管理者の遷移 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 65 事例２：出来上がった画面遷移をレビューする SEC Software Engineering for Mo･No･Zu･Ku･Ri 事例：出来上がった画面遷移の過不足についてレビューしたい 出来上がった画面遷移が過不足なく記述されていることを確認したい。 どうすればいい？ 単に追いかけるだけ じゃ芸がないよな… 受付状況確認画面 ログイン画面 注文結果確認画面 ［受付状況確認］ ［注文］ ［ログイン］ ［注文入力］ ［書籍検索］ メニュー画面 「OK」 「閉じる」 注文入力画面 開発者側 ［書籍登録］ 書籍検索画面 ［確認］ 「OK」 「閉じる」 書籍登録画面 SDM公開講座 (2012.5.17) 書籍登録確認画面 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 66 事例２：出来上がった画面遷移をレビューする SEC Software Engineering for Mo･No･Zu･Ku･Ri 適用できるコツ（レビューのコツ） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 67 SEC 事例３：発注者と一緒にレビューする Software Engineering for Mo･No･Zu･Ku･Ri 事例：出来上がったデータモデルについてレビューしたい データモデルのレビューが表面的になりがち お客様に、データ構造の意味（出来ること／出来ないこと など）をしっ かり伝えるにはどうすればよい？ たぶん、良いん じゃないかな．．． 大丈夫かな… 買取引 対象ER図の例 顧客 発注者側 （お客様） SDM公開講座 (2012.5.17) 取引グループ 顧客ID グループID 顧客名 連絡先 顧客ID ( F K) 発生日 終了日 取引ID 商談ID ( F K) 楽器番号 ( F K) 希望価格 取引ステータス 取引発生日 商品 楽器番号 売取引 取引ID ステータス 開発者側 商談ID ( F K) 取引ステータス 希望価格 楽器番号 ( F K) 取引発生日 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 68 事例３：発注者と一緒にレビューする SEC Software Engineering for Mo･No･Zu･Ku･Ri 適用できるコツ（レビューのコツ） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 69 SEC Software Engineering for Mo･No･Zu･Ku･Ri 「機能要件の合意形成ガイド」の適用例 （発注者への要求確認編） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 70 事例１：例外業務システム処理の設計漏れ SEC Software Engineering for Mo･No･Zu･Ku･Ri 事例：会計システムの振込処理における誤振込時の組戻し処理の漏れ 会計システムの振込処理において、誤振込が発生した場合、財務部が金 融機関に連絡をした上で、振込データの戻しとこれに伴う会計処理（組み 戻し処理）を行うことになっているが、会計システムでは組み戻し処理が設 計されていなかった。 本番直前の運用テストの段階で財務部からの指摘で組み戻し処理が抜 けている事が判明。急遽追加することになった。 当社の支払処理は銀行振込の 場合、・・・・・・・・・ という手順となります。 ここはシステム化の対象です。 ヒアリング時 経理部門担当者 なるほど、 そういう処理の 流れになるん ですね？ SDM公開講座 (2012.5.17) システム化業務フ ロー 販売部門 経理部門担当者 業務フロー 万一、振込口座が 誤っていて誤振込 になった場合には、 銀行に連絡すると ともに組戻し処理 を行います。 財務部門担当者 レビュー時 出荷部門 （倉庫） 仕入先 <<システム支援>> 顧客の登録 システム化される 振込処理の流れ は次のようになり ます。 テナント 契約 販売部門 出荷部門 （倉庫） <<システム支援>> 仕入先 物件仮押 <<人の作業>> 意思の確認 <<システム>> 顧客登録 <<システム>> 進捗登録 <<システム支援>> 顧客の登録 テナント 契約 <<システム支援>> 物件仮押 <<人の作業>> 意思の確認 <<システム>> 顧客登録 <<システム>> 進捗登録 ふむふむ。 振込結果 はどうわ かるの？ 開発担当者 経理部門担当者 Copyright © 2010 - 2012 IPA, All Rights Reserved 開発担当者 Software Engineering Center 71 SEC 事例１：例外業務システム処理の設計漏れ Software Engineering for Mo･No･Zu･Ku･Ri 何故、そのようなことになってしまったのか？ レビュー時に業務フローとシステム化業務フローを比較・検証しなかっ たから。 システム化業務フローを見ていただけでは例外業務である組み戻し処 理が抜けていることに気付かなかった。 レビュー時 ヒアリング 時 経理部門担当者 業務フロー 出荷部門 （倉庫） 販売部門 システム化業務フ ロー 販売部門 経理部門担当者 出荷部門 （倉庫） 仕入先 <<システム支援>> 顧客の登録 仕入先 テナント 契約 <<システム支援>> 物件仮押 <<システム>> 顧客登録 <<システム支援>> 顧客の登録 テナント 契約 <<人の作業>> 意思の確認 <<システム支援>> 物件仮押 <<人の作業>> 意思の確認 進捗登録 <<システム>> 顧客登録 <<システム>> 進捗登録 財務部門担当者 ヒアリングでは、業務フローを使って、 業務の流れとその中からシステム化 対象の業務を確認していた。 SDM公開講座 (2012.5.17) <<システム>> 開発担当者 業務フローと システム化業務フロー の比較・検証を行い、 システム化対象業務の 漏れがないかを確認し ていなかった Copyright © 2010 - 2012 IPA, All Rights Reserved 経理部門担当者 開発担当者 レビューでは、システム化業務フロー を使って、システム化対象の業務の流 れとシステムとのやりとりに齟齬がな いかを中心に確認していたため、対象 業務に漏れがないかの確認ができて いなかった。 Software Engineering Center 72 事例１：例外業務システム処理の設計漏れ SEC Software Engineering for Mo･No･Zu･Ku･Ri 適用できるコツ（言い切る／聞き切るコツ） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 73 SEC 事例２：業務運用パターンの確認漏れ Software Engineering for Mo･No･Zu･Ku･Ri 事例：売上伝票入力の承認のやり方が不十分と開発途中で発覚 発注者は開発者にシステム化対象業務の説明する際に、開発者に業務の 流れを理解してもらおうと思い、最もシンプルなフローで「営業部で手 続き」等の曖昧な表現で流れを説明した。その際、伝票入力者と承認者 等の役割（ロール）の違いは後で確認されると思い、説明しなかった。 開発者は説明されたとおりに、入力処理と承認処理を同一画面で行うよ う設計した。またワークフローもシンプルな構成のものを想定した。 権限階層やワークフローの実態が明確になるにつれ、当初開発者が想定 していた規模よりも大きな規模の開発である事がわかり、予算の追加と 工期の延長が必要となってしまった。 システム化される発注処理は各部署 でデータ入力して、承認するという 流れとなっています。 ヒアリング 時 システム化業務フ ロー 販売部門 伝票承認者 承認代行者 出荷部門 （倉庫） 仕入先 なるほどそうですか。 <<システム支援>> 顧客の登録 テナント 契約 <<システム支援>> 内部統制上、伝票入力者と 伝票承認者は別々にし、承 認者も代行をおけるように なっているが、その辺は販 伝票入力者 売担当のSEなら常識でわ かってくれるよね？ SDM公開講座 (2012.5.17) 物件仮押 <<人の作業>> 営業部門担当者 意思の確認 Copyright © 2010 - 2012 IPA, All Rights Reserved <<システム>> 顧客登録 <<システム>> 進捗登録 開発担当者 Software Engineering Center 74 事例２：業務運用パターンの確認漏れ SEC Software Engineering for Mo･No･Zu･Ku･Ri 何故、そのようなことが起こってしまったのか？ 発注者が、各部署には入力権限、承認権限、代理承認権限のユーザーがい るにも拘らず、役割（ロール）を正確に伝えなかった、また実際のワーク フローもデータの内容により複雑な分岐となることを説明しなかったため 。 開発者は入力処理と承認処理が分かれていることを確認しているにも拘わ らず、入力処理と承認処理の利用者の相違、入力処理、承認処理それぞれ の流れについて確認を怠っていたため。 ヒアリング／レビュー時 また入力処理から承認処理までの 一連の処理の流れを確認させてい ただけませんか？ システム化業務フ ロー 販売部門 出荷部門 （倉庫） 仕入先 <<システム支援>> 顧客の登録 テナント 契約 <<システム支援>> 物件仮押 <<人の作業>> 営業部門担当者 意思の確認 <<システム>> 顧客登録 <<システム>> 進捗登録 開発担当者 SDM公開講座 (2012.5.17) 入力処理と承認処理に分かれてい ますが、それぞれの処理を担当す る役割は異なるのでしょうか？ 承認処理はどういう場合でも同一 ですか？弊社の場合、受注金額で 承認できる職位が異なるんです が？ Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 75 事例２：業務運用パターンの確認漏れ SEC Software Engineering for Mo･No･Zu･Ku･Ri 適用できるコツ（レビューのコツ） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 76 SEC 事例３：要求した画面イメージと異なる Software Engineering for Mo･No･Zu･Ku･Ri 事例：発注者からの注文入力画面に関する不十分な要求 注文入力画面は、同一画面上段に入力欄、下段に注文履歴欄を設け、注文 履歴を確認しながら注文入力を行うという要件であるが、発注者は開発者 に単に「注文履歴を確認しながら注文入力が行えるよう」という曖昧な要 件を伝えたのみで画面レイアウトの提示をしなかった。 開発者は要件に沿うよう注文入力画面と注文履歴画面を分けて設計した。 発注者はレビューの段階で注文入力画面がイメージと異なる事に気付き、 急遽仕様変更することになった。 １つの画面で 注文入力画面 発注者： 発注者： 商品名： 合計 注文 注文番 号 商品名： わかりまし た 注文番号： 注文 数： 注文入力画面 ２つの画面で 本日の受注一覧： 商品名 発注 者 注文番号： 注文 数： メニュー ｷｬﾝｾﾙ 注文数 営業部門担当者 開発担当者 注文入 力 注文履 歴 注文番 号 合計 注文 本日の受注一覧： 商品名 発注 者 ｷｬﾝｾﾙ 注文数 注文入力画面と注文履歴画面 があり、注文履歴を見ながら 注文入力できるようにしてほ しい SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 77 SEC 事例３：要求した画面イメージと異なる Software Engineering for Mo･No･Zu･Ku･Ri 何故、そのようなことが起こってしまったのか？ 発注者が具体的な画面レイアウトの提示をしなかった、また開発 者が発注者に確認しなかったから。 開発者と発注者の間で業務の流れに沿った注文入力画面と注文履 歴画面の流れ、利用シーンを確認しなかったから。 ???? 注文入力画面 注文入力終了 発注者： 商品名： 複数件数ある場合 注文番号： ログイン画面 注文入力画 面 営業部門担当 者 開発担当者 こんな画面の遷移と 画面のイメージで よかったでしょうか？ SDM公開講座 (2012.5.17) 注文 数： 合計 注文 ｷｬﾝｾﾙ 確認終了 メニュー画面 注文検索画 面 注文一覧画 面 注文番 号 本日の受注一覧： 商品名 発注 者 注文数 更新終了 注文更新画 面 Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 78 事例３：要求した画面イメージと異なる SEC Software Engineering for Mo･No･Zu･Ku･Ri 適用できるコツ（言い切る／聞き切るコツ） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 79 SEC 事例４：意図しない画面遷移 Software Engineering for Mo･No･Zu･Ku･Ri 事例：一括注文取消処理の画面遷移がおかしい 注文一括取消処理は「発注履歴画面にて取消対象を複数選択後、注文取消画面に 遷移し、選択した個々の注文内容を確認しながら取消処理を選択数分連続して行 う」という要件を開発者に提示した。 出来上がったシステムを確認したところ、 「発注履歴画面（2件選択）→注文取消画面（1件目）→注文取消画面（2件目） →発注履歴画面」と遷移して欲しいところが、 「発注履歴画面（2件選択）→注文取消画面（1件目） →発注履歴画面→注文取消画面（２件目）→発注履歴画面」というように 都度発注履歴画面に戻るようになっていた。 注文取消画面 （取消注文１） 注文履歴画面 注文取消画面 （取消注文１） 実行 注文履歴画面 取消注文１に対する 注文取消処理 取消の適否確認 削除したい注文 を選択（複数） 実行 発注者 実行 取消注文１に対する注文取消処理および 注文取消画面（取消注文２）の表示 注文取消画面 （取消注文２） 実行 開発者 SDM公開講座 (2012.5.17) 削除したい注文 を選択（複数） Copyright © 2010 - 2012 IPA, All Rights Reserved 取消注文２に対する 注文取消処理 Software Engineering Center 80 SEC 事例４：意図しない画面遷移 Software Engineering for Mo･No･Zu･Ku･Ri 何故、そのようなことが起こってしまったのか？ レビューでは発注履歴画面と注文取消画面の確認はしたが、画面遷移の 確認を怠ってしまったから。 レビュー時 ふむふむ。 その操作手順でＯＫです。 この画面の表示項目は・・・・・・で、操作手 順は・・・・・・・・・・・と なります。これでＯＫですか？ 注文履歴画面 画面レイアウト 発注者 注文取消画面 画面レイアウト 開発者 レビュー 対象外 注文取消画面 注文履歴画 面 注文取消画面 注文取消画面 画面遷移 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 81 事例４：意図しない画面遷移 SEC Software Engineering for Mo･No･Zu･Ku･Ri 適用できるコツ（レビューのコツ） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 82 SEC 事例５：無駄な類似した帳票の開発 Software Engineering for Mo･No･Zu･Ku･Ri 事例：異なる現場部門から類似した内容の帳票開発要求 大規模システム開発のため、発注者側は設計担当者を業務領域毎に分け、個々に帳 票レイアウト定義を実施。担当者毎に完成時期が異なり、工期も厳しかったため、 発注者側は帳票類の整理と合理化の手間を省き、帳票レイアウト完成の都度五月雨 式に開発者に提示。 出来上がった帳票を俯瞰すると同じような帳票を幾つも作成してしまい、その無駄 を開発担当者から指摘された。 この帳票は このレイアウ トでないと 使えません。 開発依頼 部門Ａ担当者 このレイアウ トで何年も業 務をしてきた ので今更変更 できません。 部門Ｂ担当者 この帳票は うちの部門の ノウハウの塊 です。変更は 無理です。 整 理 ・ 統 合 調 整 で き ず 出力項目もレイアウト もかなり類似している のに、それぞれ作る 必要があるのかな？ 確認してみよう。 開発依頼 開発者 発注者調整 役 開発依頼 部門Ｃ担当者 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 83 SEC 事例５：無駄な類似した帳票の開発 Software Engineering for Mo･No･Zu･Ku･Ri 何故、そのようなことが起こってしまったのか？ 業務担当毎に設計した帳票類を一旦発注者側内部で整理、合理化した上で開 発者に開発すべき帳票を提示すべきだったが、厳しい工期で各業務担当部門 との調整をつけられず、 業務担当毎に必要な帳票の開発依頼をかけたため。 帳票の利用目的、必要な理由の確認が不十分なまま開発依頼を行ったため。 このレイアウトで 何年も業務をして きたので今更変更 できません。 この帳票は このレイアウ トでないと 使えません。 この帳票は半年に１回 だけ利用します。 部門Ａ担当 者 この帳票の利用目的は ××なので、代替策があ るなら考えます。 この帳票は うちの部門の ノウハウの塊 です。変更は 無理です。 部門Ｂ担当 者 こうした調整を図り、帳票を最低限必要なものに絞りたかった Ａ部門の帳票１とＢ部門の帳票 ２とＣ部門の帳票３はほとんど 同じ内容ですが、どのような使 われ方をしていますか？ 発注者調整役 SDM公開講座 (2012.5.17) ３帳票で異なるのは この部分だけで、 使われ方も３部門とも 同じようなのですが、 統一すると問題になるのはど んなことですか？ Copyright © 2010 - 2012 IPA, All Rights Reserved 部門Ｃ担当 この項目と 者 この項目を演算 した結果あればよ く、多少の変更は できるかも。 Software Engineering Center 84 事例５：無駄な類似した帳票の開発 SEC Software Engineering for Mo･No･Zu･Ku･Ri 適用できるコツ（言い切る／聞き切るコツ） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 85 事例６：現場業務に精通しない担当者からの帳票要求SEC Software Engineering for Mo･No･Zu･Ku･Ri 事例：現場業務に精通していない業務設計担当者からの帳票開発要求 発注者側の業務設計担当者は現場の業務にあまり精通していなかったが、 開発者は業務設計担当者の提示する要件に基づいて帳票設計を実施した。 展開時のユーザー向け説明会で、現場の利用者から帳票に承認印欄が不足 しているとの不備を指摘され、急遽設計変更を行うことになった。 現場担当者に は未確認 折角作っていただいた のに、この帳票には 承認印欄がないので、 業務では使えません。 この帳票の仕様は、・・・・・のよ うになっています。 現場業務に 詳しくない 現場業務担当者 発注者側 業務設計担当者 はいわかりました。 そのように開発します。 開発者 開発 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 86 事例６：現場業務に精通しない発注者の帳票要求 SEC Software Engineering for Mo･No･Zu･Ku･Ri 何故、そのようなことが起こってしまったのか？ 現場の業務担当者に開発する帳票の仕様に関して意見を聴いていなかった から。 帳票レビュー迄に現場の担当者の意見も聞いておけばこのような事態にな らなかった。 このような帳票の仕様で現場業務で 適用していただけますか？ 何か問題はありませんか？ この帳票のままでは 承認印欄がないので、業 務では使えません。 追加するようにお願いし ます。 現場業務担当者 発注者側 業務設計担当者 開発者 帳票レビュー前に内部で確認しておくべきこと SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 87 事例６：現場業務に精通しない発注者の帳票要求 SEC Software Engineering for Mo･No･Zu･Ku･Ri 適用できるコツ（レビューのコツ） SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 88 「機能要件の合意形成ガイド」 SEC Software Engineering for Mo･No･Zu･Ku･Ri 4. おわりに SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 89 SEC どのように使ったらよいか？ Software Engineering for Mo･No･Zu･Ku･Ri どのような場面で使うことを想定して作ったか？ ・・・活用のヒントとして 1. 開発標準に沿った設計業務を補足するコツ集として 設計に関するドキュメントを介して、ＳＩベンダの開発担当者間、 あるいは開発担当者とユーザ企業情報システム部門・ユーザとの間 のスムーズな意思疎通をはかるために利用する。 2. 教育コンテンツの素材集として ＳＩベンダやユーザ企業の情報システム部門を中心に、 各社の教育コンテンツの素材集として利用する。 3. レビューに臨む際の心得として 情報システム開発のステークホルダ間のコミュニケーションを 円滑にするために、レビューのコツを利用する。 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 90 どのように使ったらよいか？ SEC Software Engineering for Mo･No･Zu･Ku･Ri 悩み・気づき・ヒント ‼ 設計書レビュー時に、 ‼ テスト結果の確認や 基本的なことの指摘 検収時に、手直し要 が多くありません 望が多くありません か？ か？ ‼ カットオーバ後に、 すぐ手直しというこ とが多くありません か？ そんな時には「機能要件の合意形成ガイド」を一度見てみよう。 ⇒そこには発注者と開発者間の合意をより良くするためのヒントがあり ます。 SDM公開講座 (2012.5.17) Copyright © 2010 - 2012 IPA, All Rights Reserved Software Engineering Center 91 SEC ダウンロードはこちらから・・・ http://sec.ipa.go.jp/reports/20100331.html Software Engineering for Mo･No･Zu･Ku･Ri 4.おわりに 情報処理推進機構：ソフトウェ アエンジニ アリングhp.mht SDM公開講座 (2012.5.17) Copyright © 2010 - 2012IPA, All Rights Reserved Software Engineering Center SEC Software Engineering for Mo･No･Zu･Ku･Ri ご静聴ありがとうございました