概要
- ソフトウェア開発プロセスという記事の子要素となる記事です。
- 要求定義の進め方、アウトプットの例を説明します。
- 要求と要件を理解しないで使っている人が多いので要注意。
要求定義とは
- 発注側が何をしたいのかを形に表した図や書類。
- ビジネス関連の人が頭の中で思い描いているゴールを、図やドキュメントに書く事です。
- 図やドキュメントに書くことによって、空中戦の議論では無く、図やドキュメントをベースとしたディスカッションを行えるようになります。
- 図やディスカッションをベースに議論することにより、MECEな視点でエンティティを捉えられるようになったり、欠陥を見つけやすくします。
- 作る人はビジネス責任者。
- 書き方やディスカッションにはプロダクト開発の責任者もアドバイザとして参加し、クリティカルシンキングを用いながら質問をすることで具現化や問題のあぶり出しを行います。
アウトプット例
- ユースケース図
- 頭の中では思い描けているから普通はドキュメントとして残さないだろうけど、必須です。
- 途中からプロジェクトに参加した人、引き継ぎ、ビジネスサイドとプロダクトサイドのゴールを共通化するために。
- どうせ5分とか10分で書ける図なので、コスパは高いです。
- 以下にユースケースの例を貼り付けます。
- とあるシステムのユースケース図です。
- シンプルなので図を書くほどでは無いと思われてしまいますが、情報量はとても多いです。システムのステークホルダーが明確になり、どのようなインタラクションがあるかが一目でわかります。
- これは、一番抽象度の高いユースケースです。各アクター毎にユースケースを整理した図を書いても良いです。
- UMLはAstah UMLを使っています。
- 要求定義書
- ユースケースを見れば、システムのゴールが大体わかるから、ユースケースで網羅出来ない機能などはドキュメントで補足します。
- スコープ
- 予算
- 期間
- 場合によってはマイルストーン
- ユーザ数
- 対応端末
- アプリ、Web、PC、スマホ、ブラウザ種別
- シーケンス図
- ユースケースだけではビジネスのフローが見えないので、正常系のメインの流れに関してはシーケンス図を書いておきます。ユースケース図だけではわからないユースケースの順番がわかるようになります。
- 上記のユースケース図と同じシステムの、ビジネスレベルのユースケースをどのような順番で行われるか抜き出したシーケンス図です。
- まだ、上流工程なので細かい部分は割愛して、ビジネスレベルのユースケースを決めることにフォーカスしています。この時点で、より少ないシーケンス、少ない同期処理、少ないインタラクションを心がけてブラッシュアップします。
- 要求定義の段階では、同期処理や、タイミング、排他、例外処理に関しては割愛しています。
- 明記はしませんが、このシーケンス図を見ればプロダクト開発責任者の頭の中では考えられているはずです。ビジネスサイドの合意が必要な例外処理は記載しておきます。
- 類似サービス、システムのサーベイ
- 類似サービスがあれば、その実態のあるサービスを見ることでゴールが明確に想像できるようになります。
- ドキュメントにはその差分だけを書けば良いのでドキュメンテーションのコストがかなり減らせます。
要求定義のゴール
- プロジェクト責任者の合意
- ビジネス責任者の合意
- プロダクト開発責任者の合意
要求定義の使われ方
- 要求定義書を、プロダクト開発責任者が合意したら要件定義となります。
- 要求定義がそのまま要件定義になることは考えずらいですが、システム開発の視点からより具体化していき、最終的にビジネス責任者と合意できれば要件定義が完成として良いと思います。
- このプロダクト開発に関わるビジネス関係者、開発関係者が最初に見るようなドキュメントになります。
- 要望定義書は、そのままRFP (Request For Proposal（提案依頼書）)として流用出来ます。
- 自社で要件定義書を作成出来ない場合、ベンダーに要望定義書を投げて要件定義書を作成すると言ったことも可能です。
余談
- 要件定義をRD(Requirements Definition)と略されたりしますが、Request DefinitionもRDなのでどうしてRDと略されるのか謎です。略さないでください。
Comments