要件定義書への落とし込み

要件定義の目的

要件定義

システム/ソフトウェアの開発において、実装すべき機能や満たすべき性能などを明確にしていく作業

「発注者の与件/要望を明らかにして、リソースとのバランスを考慮した上で、目的を達成するために何をすべきかを明文化すること」

決定事項を明文化してクライアントとの間でドキュメントとして共有する

その後の設計/制作において基準となるドキュメント

要件定義を行う理由

開発の方向性を定めること

プロジェクトの目的、何のために作るのかを確認する

要望/要求/要件の定義

要望

本当にやりたいかどうか分からず、漠然としている

クライアント視点での希望、理想

効果は不明な状態

要求

やりたいことは明確だが、細部は決まっていない

構造的に文書化されている

要件

やりたいことをどう表現するかを示している

できないことも示している

要件定義のポイント

何を解決するためのものなのか

サイト/サービスは問題や課題を解決するために開発される

一つひとつの機能に課題解決の役割が与えられ、その集合体がサイト/サービス

機能自体にフォーカスしがちだけど、「その機能はどんな問題点/課題を解決するための機能なのか」を明確にすることで、意図した目的につながる

優先度をつける

優先度のつけ方

- その機能がないと、サービスとして成立しない

- 競合サービスがすでに対応しているもの

- 運用でカバーすることが難しい、明らかに非効率なもの

- 営業的な面から、必要となるもの

- 実装することで、大きく改善が見込めるもの

優先度を設定し、その上でスケジュールの見直しや機能の取捨選択を検討するのがよい

納期の認識

要件定義の進め方

1. 意見を引き出し、記録に残す

ヒアリングを行い、クライアントからの与件（要件定義に先だって与えられた前提条件）や要望を聞き出す

https://gyazo.com/99288e82f20dd70cc04b13a6f7ea2cd8

課題が曖昧なときには、プロジェクトの背景にある問題や悩みを明らかにする/整理することがヒアリングの目的

「誰に誰に何を聞くか」という点について、事前に調査/検討して準備する

2. 仮設を立て、解決策も決める

仮設立案

課題を解決する施策を、仮設に基づき立案していく

要望　→　やりたいこと

要件　→　やりたいことをどうすれば実現できるか

つまり、要件には解決策も含める

実現できるものは、「どのようにして」を明確に、実現できないものは「なぜ」も含めて明確にする

要件定義を終えるタイミングでは、要求に対する解決策が提示され、設計に落とし込むレベルまで文章化されていることになる

要件定義をまとめていく段階での資料/成果物がそのままプロジェクトの品質に反映されると考え、要求を要件にまで昇華させ、設計工程に引き継ぐことが求められる

3. 要件定義書にまとめる

要件定義で決めるうべきは「プロジェクトの方針やコンセプト」「設計工程で必要となる項目」

プロジェクト目的、実行範囲、誰に何を見せていくか、情報設計の方針、システム構築、運用の方針、予算、期間など

要件定義書に記載する主な内容例