Transcript 要求仕様書と要件定義書

4章 システム設計へ
橋渡しする要件定義
４４０４０２２
大久保 岳洋
要求仕様書と要件定義書
 要求仕様書
・・・ユーザ企業が「発注者が求めるもの」を
記述したドキュメント。
 要件定義
・・・要件定義を分析し、あいまいな事項を
明らかにする作業。
 要件定義書
・・・要件定義のドキュメント。
要件定義書が作れない要因
１．業務の詳細設計が開発と同時に並行して進む
２．ユーザ企業の要求仕様認識レベルが１００％に
達していない
３．要求仕様のコミュニケーションが避けられない
４．ゴールになるシステムそのものが変動する
ＳＥが要求定義で果たすべき使命（１）
１．仕様の理解レベルを上げる
・・・できるだけ早くユーザが要求する仕様
を理解する。
２．ユーザの認識レベルを高める
・・・要求仕様書の不備を早く見つけ、
ユーザと一緒に検討する。
３．妥協点を見出す
・・・実現可能なシステムのレベルを見出し、
ユーザと合意を形成する。
ＳＥが要求定義で果たすべき使命（２）
要件定義の作業内容
要求仕様書分析の手順
1．業務量の見通しを付ける
2．要求仕様の理解に努める
3．疑問点、不明点を抽出する
疑問点、不明点を抽出する（１）
要求仕様書の記載事項は、記載されていな
い事項の方が多いつもりで取り組む必要が
ある。
要求仕様書の不備を確認して、疑問点、不明
点を明確にし、それらの解決を図る。
疑問点、不明点を抽出する（２）
記載がない場合は、以下の3つのケースが考
えられる。
1．暗黙の前提になっている
２．ユーザで検討を洩らしている
３．指定なしで、開発者にフリーハンドを与える
疑問点、不明点を抽出する（３）
5W2Hで精査する
Who(入力者は誰か)
When(利用するタイミングはどういうときか)
Where(利用する場所はどこか)
What(どんな機能が必要か)
Why(なぜこの機能を必要とするのか)
How to(どういう使い方をするのか)
How many(使用頻度はどれくらいか)
疑問点、不明点を抽出する（４）
あいまいな表現を具体化する
例
数量・・・多い、少ない、大量、少量
サイズ・・・大きい、小さい
発生頻度・・・たいてい、ときどき、いつも
増減・・・増加した、減少した、多くなってきた
疑問点、不明点を抽出する（５）
トラブルの起きやすい箇所を精査する
1．現行業務が変更になる部分
2．実現が難しい要件
3．他とのインターフェース
現状調査の手順（１）
調査目的として以下のものがある。
システムを構築する目的や基本的な考え方
を把握する
主要な業務の処理フローを調査する
要求仕様の疑問点を確認する
業務の発生回数や所要時間などの基礎デー
タを収集する
現状調査の手順（２）
＜現地調査の基本的な手順＞





1．現地調査を行なう目的を明確にする
2．この目的を実現するための方法手順を考える
3．現地調査を行う日時・場所の了解をとる
4．事前の準備を行い、実施する
5．結果をまとめ、問題点を整理する
ヒアリング（１）
ヒアリングの準備
限られた時間に聞きたい事項を確実にカバーでき
るようにするため、事前に質問項目をリストアップし
ておく。
正確な内容を引き出すためには、アンケートを併用
することも有効である。
1時間程度がひとつの目安になる。
何回かに分けて実施する方が好都合である。
ヒアリング（２）
ヒアリングの方法
初めて面談するときは、システムを構築する目的や
基本的な考え方について自由に話してもらい、プロ
ジェクトについて理解を深めると同時に、相手の考
え方や価値観をつかむようにする。
現場での観察
1．データの流れを追っていく工程分析
2．作業現場で作業状況の推移を観察する作
業測定
実現可能性を評価するポイント
指定された予算、スケジュールの範囲内で開
発が可能か
指定された前提条件で要求される機能要件
が実現可能か
技術面能力面で対応可能か
要件定義書の2側面
発注先との合意文書である
システム設計の対する仕様書である
いずれも要件定義書がシステム開発の枠組
みを決めることを意味する
要件定義書の様式
最初に提示された要求仕様書に従う考えもある
しかし、発注者の書類は読みづらくても読ん
でもらえるため、参考にはならない
様式の指定には従う
要件定義書の構成
システム開発の対象が広範囲にわたる場合
システム機能を適当なサブシステム単位に分
ける
システム全体の共通編と機能別のサブシス
テム編で構成する