４章まとめ - システム設計へ橋渡しする要件定義４４０５０８７宮崎雄吾 1 目次４－１４－２４－３４－４４－５４－６要件定義とは SEが行う要件定義作業要求仕様書の分析現状調査システム要件の分析要件定義書の作成とレビュー 2 ４-１要件定義とは４４０５０８７宮崎雄吾 3 要求仕様書と要件定義書  要求仕様書・・・ユーザ企業が「発注者が求めるもの」を記述したドキュメント。  要件定義・・・要件定義を分析し、あいまいな事項を明らかにする作業。要件定義書・・・要件定義のドキュメント。  4 開発事業者にとっての要件定義の位置づけ 5 要件定義がシステム開発に及ぼす影響（１）＜不十分な要件定義がシステム開発に及ぼす影響＞１．実現できない場合のリスクシステム開発の請負契約を締結する場合、要件定義の実施結果には大きなリスクが伴う。 6 要件定義がシステム開発に及ぼす影響（2）２．要件定義工程の長期化要求仕様書が完成していない場合、ＳＥはユーザと一緒になって要求仕様の相当部分を作ることになる。 7 要件定義がシステム開発に及ぼす影響（3）３．システム開発の停滞・混乱契約形態によってシステム設計まで→応役契約ソフト開発以降→請負契約にすることがある。 8 要件定義がシステム開発に及ぼす影響（４）４．稼働後のトラブルテスト段階にきて、ユーザから「依頼したシステムと違う」というクレームがつくことがある。不要なものを開発していたとなれば、それまでの工数が無駄になる。 9 要求仕様の本質的な問題  要件定義は完全には終わることはないユーザ企業と開発事業者の間で適当なところで要件定義を妥協する。ではなぜ要件定義が完結しないのか要求仕様というものの本質に絡んでくる。 10 要件定義書が作れない要因１．業務の詳細設計が開発と同時に並行して進む２．ユーザ企業の要求仕様認識レベルが１００％に達していない３．要求仕様のコミュニケーションが避けられない４．ゴールになるシステムそのものが変動する 11 仕様に対するユーザの認識とＳＥの理解 12 ＳＥが要求定義で果たすべき使命 (1) １．仕様の理解レベルを上げる・・・できるだけ早くユーザが要求する仕様を理解する。２．ユーザの認識レベルを高める・・・要求仕様書の不備を早く見つけ、ユーザと一緒に検討する。３．妥協点を見出す・・・実現可能なシステムのレベルを見出し、ユーザと合意を形成する。 13 ＳＥが要求定義で果たすべき使命（2） 14 ４-２ＳＥが行う要件定義作業４４０５０２３加治正記 15 要件定義の用件＜要件定義書の用件＞  システム設計に必要な情報が記述されていること  あいまいな要求仕様、記述されていない要求仕様がないこと（定義できない要求仕様は明記する）  システム設計に必要な情報を収集しドキュメント化すること  ユーザとシステム要件について合意を形成すること 16 要件定義の作業内容項目内容要求仕様書の分析・要求仕様の理解・追加資料の収集、分析・調査対象の洗い出し現地調査の実施・ヒアリング・現地観察・資料の閲覧システム要件の分析・要求仕様の確認（業務の対象範囲、システム化範囲、システム化ニーズ）・前提条件/制約条件の確認・実行可能性の評価（予算面、工期面、技術面、運用面）・システム設計に必要な情報の管理用件定義書の記述・提案・用件定義書の記述・開発工数・工期の見積もりユーザ承認・説明会、Ｑ＆Ａ 17 ４-３要求仕様書の分析４４０５０２３加治正記 18 要求仕様書分析の手順 1．業務量の見通しを付ける 2．要求仕様の理解に努める 3．疑問点、不明点を抽出する 19 業務量の見通しを付ける  要求仕様書の分量と完成度を確認し、業務量の見通しをつける。  分析手順を大まかにでも計画し、作業工数を見積もる。 20 要求仕様の理解に努める（1）プロジェクトの全体像を把握する  業務仕様の骨格をつかむ  説明を受ける  資料を請求する  21 要求仕様の理解に努める（2）＜請求する資料の例＞        会社パンフレット、組織表製品カタログ製造工程図、設計表・部品表現行システムのシステム設計書、操作マニュアル伝票・帳票類、管理資料現行業務の執務書・BR・業務フロー図、用語集システム設計開発標準、設計標準 22 疑問点、不明点を抽出する（1）  要求仕様書の記載事項は、記載されていない事項の方が多いつもりで取り組む必要がある。  要求仕様書の不備を確認して、疑問点、不明点を明確にし、それらの解決を図る。 23 疑問点、不明点を抽出する（2） 24 疑問点、不明点を抽出する（3）記入洩れを確認する  記入洩れを確認するひとつの方法は、必要な項目が記載されているかどうかを確認すること。 25 疑問点、不明点を抽出する（4） 26 疑問点、不明点を抽出する（5）  記載がない場合は、以下の3つのケースが考えられる。 1．暗黙の前提になっている２．ユーザで検討を洩らしている３．指定なしで、開発者にフリーハンドを与える 27 疑問点、不明点を抽出する（6）当事者にとって常識になっているような事項こそ最重要なことが含まれていることもある。  現状業務を確認する必要がある。  28 疑問点、不明点を抽出する（7） 5W2Hで精査する＜5W2Hで機能要件を確認した例＞ Who(入力者は誰か) When(利用するタイミングはどういうときか) Where(利用する場所はどこか) What(どんな機能が必要か) Why(なぜこの機能を必要とするのか) How to(どういう使い方をするのか) How many(使用頻度はどれくらいか) 29 疑問点、不明点を抽出する（8）あいまいな表現を具体化する    要求仕様書には、データ件数、発生頻度等が示されていないことがある。形容詞的な表現になっていたら、具体的な数字を聞き出して数量表現に改める必要がある。あいまいな表現があれば、個別に確認する必要がある。 30 疑問点、不明点を抽出する（9）＜あいまいな表現の例＞  数量・・・多い、少ない、大量、少量  サイズ・・・大きい、小さい  発生頻度・・・たいてい、ときどき、いつも  増減・・・増加した、減少した、多くなってきた 31 疑問点、不明点を抽出する（10）トラブルの起きやすい箇所を精査する 1．現行業務が変更になる部分  業務量が多い場合は、特に注意する。  運用面を含めて旧来の方法を確認する。  新しい業務方式に移行する方法や準備事項が考慮されているかを確認。  特に大きな変更が現場の利用者にどういう影響を与えるか考慮する。 32 疑問点、不明点を抽出する（11） 2．実現が難しい要件  十分に要求事項を確認しておかないと、後々問題になることがある。 33 疑問点、不明点を抽出する（12） 3．他とのインターフェース  他システムとのインターフェース部分はトラブルが発生しやすいところである。  要求仕様書の中に、どういうインターフェースが記載されているかを調べる。 34 疑問点、不明点を抽出する（13）その他のチェック項目    システム設計に落とし込むのに必要な事項が網羅されているかを確認する。各システム要件や記述内容の間で矛盾点があれば質問する。要求仕様が確定済みでも変更になることがあることを心得ておく。 35 疑問点、不明点を抽出する（14）疑問点や要調査事項を整理する     問題点や疑問点は気づいた時点でメモを残し、リストアップしておく。そうした事項は未確定項目としてリストアップしておく。重要なものは定期的に検討状況を確認し、必ず、要件定義の段階で片づけるようにする。十分に理解できない点や、主要なシステム機能については、現地調査課題としてリストアップしておく。 36 ４-４現状調査４４０５０１９小尾雅人 37 現状調査の手順（1）調査目的として以下のものがある。     システムを構築する目的や基本的な考え方を把握する主要な業務の処理フローを調査する要求仕様の疑問点を確認する業務の発生回数や所要時間などの基礎データを収集する 38 現状調査の手順（2）  調査目的に応じて、適切な調査対象(ヒアリング相手や監査する業務)を選定し、実施方法・手順、実施日時を決めて取りかかる必要がある。 39 現状調査の手順（3）  現地調査は何回も繰り返すことはできないので、計画を立てて事前に十分な準備を行なうことが欠かせない。 40 現状調査の手順（4）＜現地調査の基本的な手順＞ 1．現地調査を行なう目的を明確にする 2．この目的を実現するための方法手順を考える 3．現地調査を行う日時・場所の了解をとる 4．事前の準備を行い、実施する 5．結果をまとめ、問題点を整理する 41 ヒアリング（1）ヒアリングの準備(1)  限られた時間に聞きたい事項を確実にカバーできるようにするため、事前に質問項目をリストアップしておく。  正確な内容を引き出すためには、アンケートを併用することも有効である。 42 ヒアリング（2）ヒアリングの準備(2)  あらかじめヒアリング相手に聴取内容を伝える。  ヒアリングを受ける相手にしても、事前に聴取内容がわかっていれば、前もって回答内容を考えておくこともできるし、説明用の資料を用意することもできる。 43 ヒアリング（3）ヒアリングの準備(3)  質問したい項目がたくさんある相手でも、1回あたりの面談時間はあまり長くならないように設定する。  1時間程度がひとつの目安になる。  何回かに分けて実施する方が好都合である。 44 ヒアリング（4）ヒアリングの実施  ヒアリングする対象者はプロジェクトチームのリーダーを始めとする主要メンバーや利用現場の関係者が該当する。 45 ヒアリング（5）ヒアリングの方法(1)  初めて面談するときは、システムを構築する目的や基本的な考え方について自由に話してもらい、プロジェクトについて理解を深めると同時に、相手の考え方や価値観をつかむようにする。 46 ヒアリング（6）ヒアリングの方法(2)  現状の業務について説明を受けるときは、その業務の関連事項も質問し、業務の背景にある情報を引き出すなど、せっかくの機会を活かす。 47 ヒアリング（7）ヒアリングの方法(2) ＜質問の項目例＞      現行の業務について問題と感じていること現行の業務における例外事項、異例処理現行システムに対する評価、問題とかんじていること新システムに対して期待すること現行システムから新システムへの移行方法 48 ヒアリング（8）ヒアリングの方法(3)  実務担当者をヒアリングする場合は、最初から質問リストに従って質問を始めると警戒されたりするので、担当している業務内容について説明してもらうぐらいから始めるのが適当。 49 ヒアリング（9）ヒアリングの方法(4)  業務の詳細を確認するためには、用意したリストに沿って質問を行なうとともに、回答内容をもとに、より細かな質問を行い、詳しい情報を引き出す。 50 ヒアリング（10）ヒアリングの方法(5)  ヒアリング時には、キーワードや数値をメモしておき、事後に記録を残す。ヒアリングの方法(6)  できるだけ、ヒアリングは書記役とペアを組んで行なう。 51 その他の考慮事項(1)  ヒアリングは、プロジェクトにおけるキーパーソンを見つける重要な機会になる。  ヒアリングの相手は、今後、システム開発の過程で、相談を持ちかけたり、協力をお願いしたりする人達になるので、ヒアリングの機会を通じて、よい関係が作れるように心掛ける。 52 その他の考慮事項(2)  一般にヒアリング先では、どういう専門家が来るのかと期待と懸念を抱いている。  顧客からSEの真価を問われる場面でもある。 53 その他の考慮事項(3)  ヒアリングを行うまでには、その業界に関する市販本を読むとか、その会社の新入社員向けテキストを借用して目を通したりして、その業界の基本的な知識・業務知識を身につけるように心掛ける。 54 その他の考慮事項(4)  一般に、質問リストに沿って質問している間は当たりさわりのない公式的な回答しか返ってこない。  いろいろな話を聞くには、ある程度相手に自由に話してもらう方がいい結果につながる。  肝心の質問を洩らしてしまうといけないので、会話をうまくリードする必要がある。 55 現場での観察（1）  システム化対象の業務の実施を把握するため、システムを利用する現場に足を運んで調査や観察を行い、業務の流れや作業内容を把握する。 56 現場での観察（2） 1．データの流れを追っていく工程分析 2．作業現場で作業状況の推移を観察する作業測定 57 現場での観察（3）  ひとつの業務プロセスを取り上げてみると、それがいくつかの作業手順に分かれていることがわかる。  工程分析では、作業手順に沿って、作業内容と情報の流れを追跡し、プロセスチャートにまとめる。 58 現場での観察（4）  要件定義段階では、作業測定を行なうことはあまりないが、必要があれば、連続時間研究法や、ワークサンプリング法などの手法を用いて時間測定を行なう。 59 現場での観察（5）  要件定義を進める上で、書類の調査や話を聞くだけではなく、一度は現場の業務状況を観察しておく価値がある。 60 ４-５システム要件の分析４４０５０３７坂本康輔 61 要求仕様の詳細確認機能要件確認事項業務機能対象範囲・利用目的・処理ルール・仕様データ・使用者・頻度などインプットデータ名・入力形式・件数・頻度・出力目的・利用目的アウトプット帳票・入力形式・件数・頻度・出力先その他要件性能要件・品質要件・セキュリティ要件・移行事項・他システムとのインターフェース等 62 その他システム要件確認事項開発方式確認事項ハードウエア開発標準設計標準開発環境開発言語などソフトウエアサーバ構成機械仕様端末台数ディスク容量ネットワーク回線接続拠点方式容量プロトコル運用体制稼働時間帯オペレーション要因連絡体制など 63 実現可能性の評価  指定された金額・計画の範囲内で開発が可能か  指定された前提要件で機能要件が実現可能か  技術面、能力面で対応可能か 64 ４-６要件定義書の作成とレビュー 4405049 砂押佳佑 65 要件定義書の２つの側面  発注先との合意文書である。  システム設計に対する仕様書である。これらより、要件定義書とはこれから行なうシステム開発の枠組みを決めることを意味する。一番の目的は、記載内容について発注先の確認を受け、合意を得ること。 66 読みやすくする工夫  合意事項を明瞭に記述する必要がある。そのため、読みやすくする工夫も必要。例えば、・箇条書き、図や表を多用・要求仕様書からの変更点や追加項目を明示・詳細な記述とは別に要点をまとめた物を付記・相手のレベルに合わせた表現を心掛ける 67 要件定義書のレビュー  要件定義書を提出する前に開発事業者の内部でレビューする必要がある。その留意点として、     必ず、複数の人間でレビューする。レビューを担当する人間の担当分野と役割を明確にする主要な業務機能、難易度の高い機能、開発工数、開発スケジュールなど重要なポイントを明確にする重要な部分は複数のメンバーで別途詳細にレビューする 68