業務で要件定義書を作成する予定です。
ざっくり、プロジェクトの概要としては、社内業務の効率化を目的としたBtoB向けのシステムで、ユーザー数は数百名規模、開発体制は5名程度のチームで8〜9ヶ月ほどの開発期間を想定しています。
以下のような点で悩んでおり、皆さまのご意見・知見をいただければと思い投稿いたしました。
- 要件定義書に記載する機能要件の粒度について
- 非機能要件はどの程度明文化すべきか
- 開発ベンダーやチームに共有する際、どこまで詳細に記述すべきか
1について、例えば「ユーザー管理機能」のような大項目にとどめるか、「ユーザーの新規登録、編集、削除」まで細分化すべきかなど。
2について、中小規模のBtoBシステムにおいて、どこまで定義しておくべきか悩んでいます。
3について、どこまでを含めるかの線引きが知りたいです。
実例などもあれば、併せて教えていただけると大変助かります。
よろしくお願いいたします。
回答6件
#1
総合スコア75
投稿2025/06/02 09:16
私の考える要件定義書はエンドユーザとSEの間で取り決めた仕様を定義する位置づけのもので、技術的な単語は極力使わないようにしています。
1と2は何が出来て何が出来ないのか、「エンドユーザが見て分かるように」詳しく書けることは全部書く。
3は、もし技術的な事なら要件定義書には不要。(外部設計書に定義する)
要件定義書にモリモリIT用語使うと客が理解できず「なんかよくわからないけどヨシ！」と深く仕様検討されずで、開発後期に仕様変更の嵐になる事が多いので、誰でも理解できるドキュメント作成を心がけています。
いろんな意見があると思うけど、客と仕様の合意が出来るなら好きなように書けば良いとは思います。
なお、ベンダに見せることは考えずに作成しています。
前述の通り、外部設計書がその役割を担うと考えているからです。
#4
#2
回答ありがとうございます！
仰る通り、ベストプラクティスや厳密な回答を求めるのは難しいかもしれないですね...。ただ、やはり要件定義の粒度や記述内容について、ある程度の指針がないと不安なので、もう少し具体的に質問させてください。
例えば、私の質問にあった「ユーザー管理機能」を例に挙げると、「ユーザーの新規登録、編集、削除」のような機能レベルまで落とし込むべきでしょうか？それとも、「ユーザーの新規登録画面では、氏名、メールアドレス、パスワードを入力できる」といったUIレベルまで落とし込む必要があるのでしょうか？
また、非機能要件についても、どこまで記述すべきか悩んでいます。例えば、レスポンスタイムやセキュリティ要件など、どこまで具体的に定義すべきでしょうか？開発規模や開発期間を考慮した上で、現実的な記述範囲の目安があれば教えていただきたいです。
参考にされた要件定義書のサンプルやテンプレートなどがあれば、ご共有いただけると嬉しいです。もちろん、機密情報が含まれる部分は伏せていただいて構いません。
お手数をおかけしますが、よろしくお願いいたします！
#5
総合スコア75
投稿2025/06/10 01:35
どこまで要件定義書に書くかは自由にして下さい。
(って書くと冷たいやつだと思われるんだけど、好きにしろとしか言いようがない……)
要件定義と外部設計の違いは下記のとおりです。
要件定義……何ができるかを定義
外部設計……どう実現するかを設計
ってAIに教えてもらいました。
何していいか想像もつかないなら、要件定義を外部委託したほうが早いような気もします。
#6
総合スコア2062
投稿2025/06/25 03:51
あなたは発注側の立場ということでいいですか?
要件定義書に記載する機能要件の粒度について
要件なので、必要と思うものは全部書くべきです。ただし要件定義書としてまとめるとボリュームが増えすぎるので、要件定義はなるべくシンプルに、細かい記述は画面設計案として提示し、その案をベースに協議の上で開発ベンダが画面設計書を書くのもよいでしょう。
そもそも要件定義・外部設計・内部設計・開発・テストなどとフェーズをわけているのではと思いますが、「要件定義、外部設計で1契約、それ以降を1契約」などとしていますか? もしそうなら要件定義、外部設計の後に、後半の見積もりや契約締結が必要ですかね?
であれば実現してほしいことは要件定義か外部設計のいずれかで合意できればいいわけです。どっちに書くかは極論どうでもいい。
そうではなく、予算と期間を決めアジャイルで進めるなら、実現してほしいことを最初に全部書き上げる必要すらないわけです。今回の進め方はどちらかなのかをふまえ、どの段階で実現したいことを確定させるべきか考えてみてください。
例えば「ユーザー管理機能」のような大項目にとどめるか、「ユーザーの新規登録、編集、削除」まで細分化すべきかなど。
要件や外部設計のいずれかの段階では必要です。
わたしならこんな感じで書きます。
・基本機能 ・情報管理共通機能 ・検索・一覧機能 (例: 受注日や商品情報などを元に受注一覧を表示するなど) 検索用のフォームを持つ。 一覧表示の際は、一般的なページング機能を持つ。 ・詳細表示機能 (例: 特定受注の詳細情報を表示する) ・新規登録機能 (例: 新たな受注を登録する) ・編集機能 (例: 特定受注の情報修正や、キャンセルなどのアクションを行う) 新規登録機能と似ているが、受注ID や受注日時など変更不可な情報を持つ。 また状態などにより編集不可の場合がある。 編集可能項目は操作者の権限により変動する。 ・CSV ダウンロード機能。検索・一覧表示結果を CSV でダウンロードする 受注など CSV 生成に長時間を要することが考えられる場合は、バックグラウンドで CSV 生成を行うなどの 工夫を行う。 ・CSV アップロード機能。～～～～ 注: 削除機能は実装しない。編集機能により該当情報を有効フラグを落とすことで論理削除したものとする。 ・画面と機能のマッピング案 画面と機能のマッピング案を下記に示す。これはあくまで現時点での案であり、協議によりブラッシュアップしたうえで外部設計フェーズで確定する。 受注情報: ・検索・一覧機能 ・詳細表示機能 ・編集機能 商品情報: ・検索・一覧機能 ・詳細表示機能 ・CSVダウンロード機能 ※商品情報は基幹システムから自動連係するため編集機能は不要で、表示のみ ユーザ情報: ・検索・一覧機能 (管理者用) ・詳細表示機能 (ユーザ用、管理者用) ・編集機能(ユーザ用) (自身の氏名・メールアドレスのみ変更可能) ・編集機能(管理者用) (氏名・メールアドレス・権限情報・部署情報・有効フラグなど変更可能) ・CSVダウンロード機能(管理者用) ・CSVアップロード機能(管理者用)
なお私は後から揉めるのが嫌なので、
・検索フォームの日付は 開始年月日～終了年月日 による期間指定を可能とする。 「2023年～」「～2024年」「2023年3月10日～」「2023年3月～2024年」などと一部情報のみでも検索可能とする
といった細かいことも要件定義フェーズで書きます。
非機能要件はどの程度明文化すべきか
必要と思うものは全部書くべきです。
開発ベンダーやチームに共有する際、どこまで詳細に記述すべきか
どういうことでしょうか。要件なんだから開発ベンダーやチームにそのまま出すのが普通では?
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。