Transcript 4章まとめ ～システム設計へ橋渡しする要件定義～

４章まとめ
- システム設計へ橋渡
しする要件定義 ４４０５０８７ 宮崎雄吾
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