4

章 システム設計へ 橋渡しする要件定義

４

‐

１ 要件定義とは

Ｈ１０２０４２ 小林弘晃

要求仕様書と要件定義書

 要求仕様書とは  システム開発に対し「発注者が求めるもの」を記 述したドキュメント  要件定義書とは  「発注者が求めるもの」を分析し、システム開発 者の観点から要求をドキュメント化したもの

要件定義作業の流れ

要件定義の重要性

 要件定義が不十分な場合、システム開発に 及ぼす影響  実現できない場合のリスク  要件定義工程の長期化  システム開発の停滞  稼動後のトラブル

実現できない場合のリスク

 失敗事例  受託したシステムに倍以上の開発費がかかった  約束したシステムを開発できず、費用の回収がで きないばかりか違約金を支払った

要件定義工程の長期化

 要求仕様書が未完成  記述内容が抽象的で具体的なことが分からない ↓ ＳＥがユーザと共同して相当部分を作成

システム開発の停滞

 あいまいな要求仕様のまま設計工程へ  いずれ後続の開発工程で問題が浮上 ↓ 問題解決が長引くと、開発費が予算超過

稼動後のトラブル

 稼動後、トラブル続きのシステム ユーザから仕様変更が多い ↓ 仕様検討待ちや仕様変更対応が重なる ↓ 開発スケジュールの遅れ ↓ テスト不十分なまま稼動

要求仕様の本質的な問題

 業務の詳細設計が開発と同時に平行して進 む  ユーザ企業の要求仕様認識レベルが１００％ に達していない  要求仕様のコミュニケーションギャップが避け られない  ゴールになるシステムそのものが変動する

仕様に対するユーザの認識と ＳＥの理解  ユーザの認識レベル、ＳＥの理解レベルは図４ ‐ ３の ように時系列的に推移する

４

‐

２ ＳＥが行う 要件定義

Ｈ１０２０４２ 小林弘晃

要件定義の要件

 達成していなければならない要件  システム設計に必要な情報が記述されている  あいまいな要件仕様、記述されていない要求仕 様がない  システム設計に必要な情報を収集しドキュメント 化する  ユーザとシステム要件について合意を形成する

要件定義の作業内容

4-3

要求仕様書の分析

H102124

宮澤新一

要求仕様書分析の手順

1 ．業務量の見通しを付ける 2 ．要求仕様の理解に努める 3 ．疑問点、不明点を抽出する

業務量の見通しを付ける

 要求仕様書を受け取ったら、まず、要求仕様 書の分量と完成度を確認し、業務量の見通し をつける。  与えられた期限にできるものかどうか、また、 分析手順を大まかにでも計画し、作業工数を 見積もる。

要求仕様の理解に努める

プロジェクトの全体像を把握する  最初は、ユーザ企業が目指しているシステム化の 狙い、システム化する対象業務・対象範囲などのプ ロジェクトの全体像を把握する。

要求仕様の理解に努める

業務仕様の骨子をつかむ  業務仕様についても、仕様の詳細は後回しにし、始 めは骨格をつかむようにする。  中心となる業務を流れに沿って業務仕様を追いか ける。  要求仕様書が文章で書かれていたら、フローチャー トを作成するなど図式化して理解に努める。

要求仕様の理解に努める

説明を受ける  ユーザ企業の窓口担当者に依頼して、最初に要求 仕様書の内容を説明してもらう必要がある。  要求仕様書に記載されていない計画段階の問題が 見えてきたり、要求仕様書の手薄な部分を推測でき るようになったりする。

要求仕様の理解に努める

資料を請求する  要求仕様書だけでは情報が不足しているので、分 析に必要な資料を請求する。

要求仕様の理解に努める

＜請求する資料の例＞  会社パンフレット、組織表  製品カタログ  製造工程図、設計表・部品表  現行システムのシステム設計書、操作マニュアル  伝票・帳票類、管理資料   現行業務の執務書・ BR ・業務フロー図、用語集 システム設計開発標準、設計標準

疑問点、不明点を抽出する

 要求仕様書の記載事項は全体からすると一 部で、記載されていない事項の方が多いつも りで取り組む必要がある。  記述内容のヌケやオチ、あいまいな記述、矛 盾点、そうした要求仕様書の不備を確認して、 疑問点、不明点を明確にし、それらの解決を 図る。

疑問点、不明点を抽出する

疑問点、不明点を抽出する

記入洩れを確認する  記入洩れを確認するひとつの方法は、要求仕様書 の目次レベルで必要な項目が記載されているかど うかを確認すること。

疑問点、不明点を抽出する

疑問点、不明点を抽出する

 記載がない場合は、以下の 3 つのケースが考 えられる。 1 ．暗黙の前提になっている ２．ユーザで検討を洩らしている ３．指定なしで、開発者にフリーハンドを与える

疑問点、不明点を抽出する

 当事者にとって常識になっているような事項 こそ最重要なことが含まれていることもある ので、要注意である。  要求仕様書に現状業務について記載がない 場合は、現状業務を確認する必要がある。

疑問点、不明点を抽出する

5W2H

で精査する ＜ 5W2H で機能要件を確認した例＞ Who( 入力者は誰か ) When( 利用するタイミングはどういうときか ) Where( 利用する場所はどこか ) What( どんな機能が必要か ) Why( なぜこの機能を必要とするのか ) How to( どういう使い方をするのか ) How many( 使用頻度はどれくらいか )

疑問点、不明点を抽出する

あいまいな表現を具体化する  要求仕様書には、データ件数、発生頻度等が示さ れていないことがある。  形容詞的な表現になっていたら、具体的な数字を聞 き出して数量表現に改める必要がある。  あいまいな表現があれば、個別に確認する必要が ある。

疑問点、不明点を抽出する

＜あいまいな表現の例＞  数量・・・多い、少ない、大量、少量  サイズ・・・大きい、小さい  発生頻度・・・たいてい、ときどき、いつも  増減・・・増加した、減少した、多くなってきた

疑問点、不明点を抽出する

トラブルの起きやすい箇所を精査する 1 ．現行業務が変更になる部分  業務量が多い場合は、特に注意する。  運用面を含めて旧来の方法を確認する。  新しい業務方式に移行する方法や準備事項が考 慮されているかを確認。  特に大きな変更が現場の利用者にどういう影響 を与えるか考慮する。

疑問点、不明点を抽出する

2 ．実現が難しい要件  一般に実現が難しい機能や開発に時間がかかる 機能、特殊なノウハウや使用していないソフト利 用技術が要求される場合は要チェック。  十分に要求事項を確認しておかないと、後々問 題になることがある。

疑問点、不明点を抽出する

3 ．他とのインターフェース  他システムとのインターフェース部分はトラブル が発生しやすいところである。  要求仕様書の中に、どういうインターフェースが 記載されているかを調べる。  ひとつのシステムが処理するデータは、そのシス テム内で入力するか、作り出すか、他のシステム からデータを受け取るかのいずれかになる。

疑問点、不明点を抽出する

その他のチェック項目  システム設計に落とし込むのに必要な事項が網羅 されているかを確認する。  各システム要件や記述内容の間で矛盾点があれば 質問する。  要求仕様が確定済みでも変更になることがあること を心得ておく。

疑問点、不明点を抽出する

疑問点や要調査事項を整理する  要求仕様書の分析過程で見つかった問題点や疑問 点は気づいた時点でメモを残し、リストアップしておく。  すぐに解決しない項目も多くなるはずですから、そう した事項は未確定項目としてリストアップしておく。

疑問点、不明点を抽出する

疑問点や要調査事項を整理する  重要なものは定期的に検討状況を確認し、必ず、要 件定義の段階で片づけるようにする。  要求仕様書を分析するだけで十分に理解できない 点や、主要なシステム機能については、現地調査課 題としてリストアップしておく。

4-4

現状調査

H102124

宮澤新一 株式会社ディー・アート 上野淳三・広田直俊・白井伸児 [ 著 ] 「システム設計の考え方」

現状調査の手順

調査目的として以下のものがある。  システムを構築する目的や基本的な考え方を把握 する  主要な業務の処理フローを調査する  要求仕様の疑問点を確認する  業務の発生回数や所要時間などの基礎データを収 集する

現状調査の手順

 調査目的に応じて、適切な調査対象 ( ヒアリン グ相手や監査する業務 ) を選定し、実施方法・ 手順、実施日時を決めて取りかかる必要があ る。

現状調査の手順

 現地調査は何回も繰り返すことはできないの で、計画を立てて事前に十分な準備を行なう ことが欠かせない。

現状調査の手順

＜現地調査の基本的な手順＞ 1 ．現地調査を行なう目的を明確にする 2 ．この目的を実現するための方法手順を考える 3 ．現地調査を行う日時・場所の了解をとる 4 ．事前の準備を行い、実施する 5 ．結果をまとめ、問題点を整理する

ヒアリング

ヒアリングの準備 (1)  限られた時間に聞きたい事項を確実にカバーで きるようにするため、事前に質問項目をリストアッ プしておく。  正確な内容を引き出すためには、アンケートを併 用することも有効である。

ヒアリング

ヒアリングの準備 (2)  あらかじめヒアリング相手に聴取内容を伝える。  ヒアリングを受ける相手にしても、事前に聴取内 容がわかっていれば、前もって回答内容を考えて おくこともできるし、説明用の資料を用意すること もできる。

ヒアリング

ヒアリングの準備 (3)  質問したい項目がたくさんある相手でも、 1 回あた りの面談時間はあまり長くならないように設定す る。  1 時間程度がひとつの目安になる。  何回かに分けて実施する方が好都合である。

ヒアリング

ヒアリングの実施  ヒアリングする対象者はプロジェクトチームの リーダーを始めとする主要メンバーや利用現 場の関係者が該当する。

ヒアリング

ヒアリングの方法 (1)  初めて面談するときは、システムを構築する目的 や基本的な考え方について自由に話してもらい、 プロジェクトについて理解を深めると同時に、相 手の考え方や価値観をつかむようにする。

ヒアリング

ヒアリングの方法 (2)  現状の業務について説明を受けるときは、その 業務の関連事項も質問し、業務の背景にある情 報を引き出すなど、せっかくの機会を活かす。

ヒアリング

ヒアリングの方法 (2) ＜質問の項目例＞   現行の業務について問題と感じていること 現行の業務における例外事項、異例処理    現行システムに対する評価、問題とかんじているこ と 新システムに対して期待すること 現行システムから新システムへの移行方法

ヒアリング

ヒアリングの方法 (3)  実務担当者をヒアリングする場合は、最初から質 問リストに従って質問を始めると警戒されたりす るので、担当している業務内容について説明して もらうぐらいから始めるのが適当。

ヒアリング

ヒアリングの方法 (4)  業務の詳細を確認するためには、用意したリスト に沿って質問を行なうとともに、回答内容をもとに、 より細かな質問を行い、詳しい情報を引き出す。

ヒアリング

ヒアリングの方法 (5)  ヒアリング時には、キーワードや数値をメモしてお き、事後に記録を残す。 ヒアリングの方法 (6)  できるだけ、ヒアリングは書記役とペアを組んで 行なう。

その他の考慮事項

(1)  ヒアリングは、プロジェクトにおけるキーパー ソンを見つける重要な機会になる。  ヒアリングの相手は、今後、システム開発の 過程で、相談を持ちかけたり、協力をお願い したりする人達になるので、ヒアリングの機会 を通じて、よい関係が作れるように心掛ける。

その他の考慮事項

(2)  一般にヒアリング先では、どういう専門家が 来るのかと期待と懸念を抱いている。  顧客から SE の真価を問われる場面でもある。

その他の考慮事項

(3)  ヒアリングを行うまでには、その業界に関する 市販本を読むとか、その会社の新入社員向 けテキストを借用して目を通したりして、その 業界の基本的な知識・業務知識を身につけ るように心掛ける。

その他の考慮事項

(4)  一般に、質問リストに沿って質問している間 は当たりさわりのない公式的な回答しか返っ てこない。  いろいろな話を聞くには、ある程度相手に自 由に話してもらう方がいい結果につながる。  肝心の質問を洩らしてしまうといけないので、 会話をうまくリードする必要がある。

現場での観察

 システム化対象の業務の実施を把握するた め、システムを利用する現場に足を運んで調 査や観察を行い、業務の流れや作業内容を 把握する。

現場での観察

1 ．データの流れを追っていく工程分析 2 ．作業現場で作業状況の推移を観察する作 業測定

現場での観察

 ひとつの業務プロセスを取り上げてみると、そ れがいくつかの作業手順に分かれていること がわかる。  工程分析では、作業手順に沿って、作業内容 と情報の流れを追跡し、プロセスチャートにま とめる。

現場での観察

 要件定義段階では、作業測定を行なうことは あまりないが、必要があれば、連続時間研究 法や、ワークサンプリング法などの手法を用 いて時間測定を行なう。

現場での観察

 要件定義を進める上で、書類の調査や話を 聞くだけではなく、一度は現場の業務状況を 観察しておく価値がある。

４

-

５ システム要件の分析

 分析作業 要求仕様の詳細を確認するとともに、要求 仕様の実現可能性を評価する。  要求仕様の確認事項 業務機能や入出力データなど業務面の機 能要件と、ハードウェア・ソフトウェアなどのシ ステムに構成に関する要件がある。

要求仕様の詳細確認

 システム開発を進める上で、制約になりそう な要件について、変更不可の絶対条件か、あ る程度相談に応じてもらえる弱い条件かを確 認する。

実現可能性の評価

 要求仕様書の中にはユーザ企業の期待や願 望が混じっている。発注者の希望は尊重すべ きであるが、実現可能性をきちんと評価する 必要がある。  特に要件定義の結果に基づいて開発請負契 約を締結する場合は、開発事業者にとってこ の実現性評価は非常に重要な作業である。

実現可能性を評価するポイント

 指定された予算、スケジュールの範囲内で開 発が可能か  指定された前提条件で要求される機能要件 が実現可能か  技術面能力面で対応可能か

４ ６ 要件定義書の作成とレビュー  要件定義書には次の側面がある。 １．発注先との合意文書である ２．システム設計に対する仕様書である  いずれも、要件定義書がこれから行うシステ ム開発の枠組みを決めることを意味する。

要件定義書の作成

 要件定義書の一番の目的は、記載内容につ いて発注先の確認を受け、合意を得ることに ある。  一般的な留意点は４つある。

合意事項を明瞭に記述する

 確定していない要求仕様が残っていたら、重 要なものとそうでないものを選別し、重要なも のについては、できるだけ要件定義の段階で 決着を付けるようにする。  重要でないものは、要件定義書の本文に記 載せず、別途覚書にするとか、後工程への引 継資料として備忘録的に記録を残す。

見やすく、わかりやすい工夫をする  要件定義書を提出してもユーザ側ではなか なか読んでもらえないものである。  読む側では、提出された書類は分量が多く、 たいてい生硬で読みづらいことを理由にあげ る。

読みやすくする工夫例

 箇条書き、図や表を多用し、見やすくする  要求仕様書からの変更点や追加項目を明示 する  詳細な記述とは別に要点をまとめたものを付 記する  専門用語や技術用語はできるだけ避ける（相 手のレベルに合わせる）

要件定義書の様式は 指定があればそれに従う  最初に提示された要求仕様書の書式に従う のもひとつの考え方であるが、発注者が作る 書類は読みづらくても読んでもらえるものな ので、参考にならないケースが多いかもしれ ない。

要件定義書のレビュー

 要件定義書を提出する前に開発事業者の内 部でレビューする必要がある。

レビューの留意点

 必ず、複数の人間でレビューする  レビューを担当する人間の担当分野と役割を 明確にする  主要な業務機能、難易度の高い機能、開発 工数、開発スケジュールなど重要なポイント を明確にする  重要な部分は複数のメンバーで別途詳細に レビューする

要件定義書の構成

 システム開発の対象が広範囲にわたる場合 は、システム機能を適当なサブシステム単位 に分け、システム全体の共通編と機能別の サブシステム編で構成する。