【上流_1日目_2回目】要件定義1冊目

背景

今まで開発側にいることが多く、設計をバリバリやっていた訳ではないですが、要件定義をやることになったため、学習及びアウトプットをして、理解を深めることにしました。

学習アウトプット

事業内容を共有

• お客さんがどのようなビジョンや方向性、目標を描いているかを明確に理解する
  →それをしないと、お客さんにとって役に立たないシステムを作ってしまう恐れがある。

ステークホルダーへの影響度

ステークホルダーへの距離感や、影響度によって仕事の仕方が違うとのこと

ステークホルダーへの影響度(低)	ステークホルダーへの影響度(大)
ステークホルダーを常に満足させる	共同して同意を得ながら緊密に仕事をする
監視を怠らない	報告を徹底する

※上下は「ステークホルダーからの影響度で上が高い」

要件定義の進め方

• TODOを上げる
  →どの要件を行なっていくのか

• 役割分担
  →誰がそれを担当するのか

• 会議について
  →どのような会議を設けて、いつ実施するのか

• wbsやガントチャートの作成
  →いつまでにこなすのかを決めていく

要件定義者がやるべきこと

• 意見の衝突などが起きても上手く進むように、物事を進めていく。

• 全ての要求をこなせるわけではないので、チームのこなせる作業量などを加味して、取捨選択(優先順位)を行なっていく

優先順位
・絶対に必要
・できれば欲しいよね
・予算や納期が間に合うならやる
・いらない
→上記の順で本当に必要な機能などを整理していく必要がある

計画書を作成する

• 体制やスケジュール等を引き、どのようにこなしていくのかをきちんと、ユーザーに承諾を得る必要がある。

要件定義の進め方

• 既存の機能を改善したい場合は、現行業務の調査が不可欠
  →なりたい理想と、現状の比較を行い、ギャップを埋めるために必要な問題点を洗い出す

• 業務フローなどを整理し、誰でも簡単に見てわかるような図に落とし込む

• ER図やクラス図などを用いて、データ構造等を明確化する

必要機能の洗い出し

• バッチ処理などを含めて、どのような機能が必要なのかを洗い出す
• どのような画面があればお客さんの依頼を叶えることができるかを洗い出す
• 帳票の出力が必要であれば、どのような帳票を出せばいいのかを検討する
• 業務要件に必要なデータ構造なども洗い出す