要件定義(requirements definition)
- テクノロジ系
- システム開発技術
- 基本情報
- 応用情報
- 重要度 ★★★★☆
利用者が何を実現したいかを聞き取り、システムが満たすべき条件を決める工程。
もう少し詳しい説明
要件定義は、システムが満たすべき条件を決めて、文書にする工程です。
ここで決めるのは「何を作るか」であって、「どう作るか」ではありません。この線引きが要件定義のすべてで、試験でもここが問われます。
「どう作るか」を決めるのは次の設計です。要件定義の段階で「この製品を使う」と手段まで決めてしまうと、本来は選べたはずのやり方を、自分で狭めることになります。
機能要件と非機能要件
決めた条件のことを要件と呼び、大きく2つに分かれます。
| 機能要件 | 非機能要件 | |
|---|---|---|
| 決めること | 何をするか(機能そのもの) | どの程度・どんな品質で動くか |
| 例 | 商品を検索できる、帳票を出せる | 3秒以内に応答する、24時間動く、同時に100人使える |
非機能要件は、言われないと書き落とすほうです。「検索できること」は誰でも思いつきますが、「検索結果が出るまで10秒かかっても仕様どおりなのか」は、先に決めておかないと後で揉めます。
代表的なものは、性能(速さ)、可用性(止まらないこと)、拡張性、運用・保守のしやすさ、移行性(いまのデータをどう移すか)、セキュリティです。移行性は忘れられやすいのですが、試験でも実務でも定番の項目です。
語尾では見分けられません。 非機能要件も「24時間365日稼働できること」のように「〜できること」と書かれますし、機能要件にも「割引率10%を自動計算できる」のように数字が入ります。見るのは語尾ではなく、機能そのものを述べているのか、その機能をどの程度で動かすかを述べているのかです。
誰が決めるのか
要件を決める主役は、作る側ではなく使う側です。何を実現したいかを知っているのは利用者だからです。
ただし、利用者が要件を整理された形で持っていることは、まずありません。「いまの作業がとにかく大変で」という話から実現したいことを引き出し、条件の形に直していくのが開発側の仕事です。この聞き取りと整理までを含めて要件定義と呼びます。
だから合意した内容を文書に残すことが重視されます。口頭で「だいたいこんな感じで」と進めると、完成したものを見てから食い違いが出ます。
なぜ最初が重いのか
要件定義の誤りは、後の工程すべてに運ばれていきます。
「何を作るか」を取り違えたまま設計し、実装し、テストまで通ってしまえば、出てくるのは「正しく作られた、欲しくなかったもの」です。設計以降のテストは決めたとおりに作れたかを見る作業なので、決めた内容そのものが違っていても止まりません。気づけるのは、利用者が実際に使って確かめる受入テストの段階になってからです。
直す手間も同じです。要件定義の段階なら文書を1行直せば済みますが、実装が終わってからだと、設計・プログラム・テストをすべて直すことになります。後の工程になるほど、同じ誤りを直す手間が増える、という点は繰り返し問われます。
前後の工程との関係
要件定義の前後には、似た名前の工程が並びます。位置関係だけ押さえておけば十分です。
| 工程 | やること |
|---|---|
| システム化構想・企画 | そもそも何のために作るかを決める |
| 要件定義 | 何を作るかを決めて、文書にする |
| 設計 | どう作るかを決める |
発注先を選ぶために出す RFP(提案依頼書)は、要件定義でまとまった内容をもとに書かれます。何を作るかが決まっていなければ、提案を求めようがないためです。
覚え方:主語が「利用者」なら要件定義
工程の名前を並べられて迷ったら、その文の主語が誰かを見てください。
- 「利用者が〜したい」「〜できること」 … 要件定義
- 「この機能を、この構造で実現する」 … 設計
要件定義の文に、プログラムの作りや製品名は出てきません。出てきたらそれは設計の話だと判断できます。
試験ではこう出る
科目A(旧・午前)の開発技術分野で出ます。多いのは、示された記述が機能要件か非機能要件かを選ばせる問題と、要件定義・設計・テストのうちどの工程の作業かを問う問題です。応用情報では、要件の抜けや曖昧さが後の工程でどんな不具合として現れるか、という形で問われます。
迷いやすいのは、非機能要件に何が入るかです。応答時間・稼働率・同時利用者数・移行性・セキュリティ・運用や保守のしやすさ、という並びを持っておくと判断しやすくなります。もう1つ、要件定義に手段を書かないという原則も押さえておいてください。「〜という製品を用いて」と書かれた選択肢は、要件ではなく設計の記述です。
関連する用語
- 機能要件・非機能要件
- 要件の2分類。何ができるかが機能要件、どれくらいの品質で動くかが非機能要件
- RFP
- 発注側が提案を求めるために出す文書。要件定義でまとまった内容をもとに書かれる
- ブラックボックステスト
- 外から見て仕様どおりかを確かめるテスト。要件定義で決めたことの答え合わせにあたる
- アジャイル開発
- 要件を先に固めきらず、反復しながら決めていく進め方
- WBS
- 作業を分解して並べたもの。何を作るかが決まってから作れる
- ユーザビリティ
- 使いやすさのこと。非機能要件として扱われることが多い
ミニクイズ
システムの要件定義において、非機能要件に該当するものはどれか。
正解は 3番:利用者が検索ボタンを押してから3秒以内に結果を表示すること
「3秒以内に表示する」は、できることそのものではなく、どれくらいの品質で動くかを定めたものなので非機能要件です。応答時間のほかに、稼働率、同時に使える人数、移行性、セキュリティ、運用や保守のしやすさが非機能要件にあたります。残る3つ、「検索できる」「帳票を出力できる」「一覧で表示できる」は、いずれもシステムが何をするかを述べたもので、機能要件です。見分けるときは語尾ではなく、機能そのものを述べているのか、その機能をどの程度で動かすかを述べているのかを見てください。非機能要件も「24時間稼働できること」のように「〜できる」と書かれるため、語尾だけでは判断できません。
最終更新:2026-09-18