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

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