要件定義は、発注側が実現したい業務上の目的を、開発・設計・テストで確認できる条件へ具体化する工程です。結論として、RFPで依頼の方向を伝え、要件定義で必要な内容と制約を合意し、設計で実現方法を決め、テストで要件を満たしたか確かめます。この流れを押さえると、似た用語を重複なく整理できます。
要件定義の定義とRFPからの流れ
RFP（提案依頼書）は、発注側が解決したい課題、予算、期限、提案してほしい範囲を示して、候補の提供者から提案を受ける文書です。RFP自体が詳細な設計図ではありません。選定後、利用部門と開発側が業務の目的、必要な機能、性能や安全性などを確認し、要件として合意する作業が要件定義です。
- RFP：課題と依頼条件を示し、提案を集める。
- 要件定義：何を実現し、どの条件を満たすかを決める。
- 設計：決めた要件を画面、データ、処理、構成へ落とし込む。
- テスト：要件どおりに動き、利用できるかを確認する。
業務要件・機能要件・非機能要件の比較
| 種類 | 問い | 例 |
|---|---|---|
| 業務要件 | 業務をどう変えたいか | 申請の受付状況を部署で共有し、確認の電話を減らす |
| 機能要件 | システムに何をさせるか | 申請、承認、差戻し、状況検索をできるようにする |
| 非機能要件 | どの程度の品質や条件で動くか | 繁忙時にも応答でき、権限別に閲覧を制御する |
業務要件は業務上の成果、機能要件はシステムの働き、非機能要件は性能・可用性・セキュリティなどの品質条件です。たとえば「申請状況を見えるようにする」は業務要件、「状況を検索できる」は機能要件、「同時に多くの利用者が検索しても待たせない」は非機能要件です。
設計とテストへどうつながるか
設計では、要件を実現するための画面項目、データの持ち方、処理の順序、権限の分け方を決めます。要件定義で「承認者が不在でも処理を止めない」と決めたなら、設計で代理承認の条件や通知方法を具体化します。テストでは、承認・差戻しという機能だけでなく、代理承認が必要な状況で条件どおりに進むかを確認します。要件が曖昧だと、設計の判断基準もテストの合否基準も失われます。
仕事と日常生活での具体例
仕事では、経費精算システムの導入で「月末の差戻しを減らしたい」が業務要件です。「領収書画像を添付し、上長が承認できる」が機能要件、「経理担当者だけが支払情報を見られる」が非機能要件に当たります。RFPで各社の提案を比べ、選定後に要件を詰め、設計とテストへつなげます。
日常生活では、地域サークルがイベント参加の仕組みを作る場合を考えます。「参加人数を早く把握したい」が目的で、「参加・取消・定員表示」が機能、「個人の連絡先を参加者全員に見せない」が非機能の条件です。作り方を先に決めるより、何を実現したいかと守る条件を定めるのが要件定義です。
確認問題
問題1：複数の事業者から提案を受けるため、発注側が課題や期限を示す文書はどれですか。
- A RFP
- B 要件定義書
- C 外部設計書
- D テスト仕様書
答え：A。RFPは提案依頼のための文書です。選定後に実現内容を詰めるのが要件定義です。
問題2：「閲覧は部門ごとの権限で制御する」はどの要件ですか。
- A 業務要件
- B 機能要件
- C 非機能要件
- D RFP
答え：C。セキュリティや権限は品質・制約に関わる非機能要件として整理します。
次に読む記事
- RFPとは？RFI・RFQとの違い：要件定義の前に、発注側が何を依頼し比較するのかを確認するためです。
- 外部設計とは？内部設計との違い：定義した要件を利用者視点の画面や機能へ落とし込む工程を学ぶためです。
- 単体テスト・結合テスト・システムテストの違い：要件をどのテストで確認していくかを工程順に理解するためです。
要件定義は、希望をそのまま並べる作業ではありません。RFPから受け取った目的を、設計でき、テストで確認できる条件へ変える工程です。業務・機能・非機能の三つを分け、後工程とのつながりで覚えましょう。
