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

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

2. ４‐１　要件定義とは Ｈ１０２０４２　小林弘晃

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

4. 要件定義作業の流れ

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

6. 実現できない場合のリスク • 失敗事例 • 受託したシステムに倍以上の開発費がかかった • 約束したシステムを開発できず、費用の回収ができないばかりか違約金を支払った

7. 要件定義工程の長期化 • 要求仕様書が未完成 • 記述内容が抽象的で具体的なことが分からない ↓ ＳＥがユーザと共同して相当部分を作成

8. システム開発の停滞 • あいまいな要求仕様のまま設計工程へ • いずれ後続の開発工程で問題が浮上 ↓ 問題解決が長引くと、開発費が予算超過

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

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

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

12. ４‐２　ＳＥが行う　　　　　　要件定義 Ｈ１０２０４２　小林弘晃

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

14. 要件定義の作業内容

15. 4-3 要求仕様書の分析 H102124　宮澤新一

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

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

18. 要求仕様の理解に努める プロジェクトの全体像を把握する • 最初は、ユーザ企業が目指しているシステム化の狙い、システム化する対象業務・対象範囲などのプロジェクトの全体像を把握する。

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

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

21. 要求仕様の理解に努める 資料を請求する • 要求仕様書だけでは情報が不足しているので、分析に必要な資料を請求する。

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

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

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

25. 疑問点、不明点を抽出する 記入洩れを確認する • 記入洩れを確認するひとつの方法は、要求仕様書の目次レベルで必要な項目が記載されているかどうかを確認すること。

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

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

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

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

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

31. 疑問点、不明点を抽出する ＜あいまいな表現の例＞ • 数量・・・多い、少ない、大量、少量 • サイズ・・・大きい、小さい • 発生頻度・・・たいてい、ときどき、いつも • 増減・・・増加した、減少した、多くなってきた

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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