システムを作るときって、いきなりプログラムを書き始めるんですか？
それをやると大変なことになるよ。家を建てるときも、まず「部屋はいくつ？」「予算は？」と希望を固めるよね。システムでそれに当たるのが要件定義なんだ。
要件定義はシステム開発の出発点
要件定義 とは、新しいシステムに 何をさせたいか・どんな性能が必要か を明らかにし、関係者で合意する作業です。ここで決めた内容（要件）が、その後の設計・開発・テストのすべての基準になります。
要件って、誰が決めるんですか？
システムを使う人（利用部門）、お金を出す人（経営者）、作る人（開発者）、動かす人（運用担当）…いろんな利害関係者の要求を集めて整理するんだ。全員の合意をとっておかないと、完成してから「こんなはずじゃなかった」となってしまうよ。
要件定義では、まず業務のやり方そのものを整理し（業務要件）、それを実現するためにシステムに必要なことを決めていきます（システム要件）。システム要件は、大きく 機能要件 と 非機能要件 に分けられます。
機能要件と非機能要件
パン屋さんが、パンのネット予約システムを作る場合で考えてみましょう。
| 機能要件 | 非機能要件 | |
|---|---|---|
| 何を決める？ | システムが提供する機能 | 機能以外の品質・性能・制約 |
| 問いかけ | 「何ができる？」 | 「どれくらい速い？止まらない？安全？」 |
| 例 | 予約する、検索する、印刷する | 応答時間、稼働率、セキュリティ、保守のしやすさ |
| 見落とされやすさ | 利用者が要望を出しやすい | 利用者が言い出しにくく、見落とされやすい |
機能要件は「動詞（〜できる）」、非機能要件は「形容詞（速い・安全・止まらない）」。
問題文の要件が「〜できること」なら機能要件、「〜秒以内」「〜%以上」のように数値や品質の程度を表していれば非機能要件の可能性が高い、と考えましょう。
非機能要件の主な種類
非機能要件は種類が多く、漏れやすいのが特徴です。IPA（情報処理推進機構）は、非機能要件を漏れなく決めるための 非機能要求グレード を公開しており、次の6つの大項目に整理しています。
| 大項目 | 内容 | 例 |
|---|---|---|
| 可用性 | 止まらずに使い続けられるか | 稼働率99.9%以上、障害時は1時間以内に復旧 |
| 性能・拡張性 | 速さ、利用者やデータが増えたときの対応 | 応答3秒以内、同時1,000アクセスに対応 |
| 運用・保守性 | 運用や保守のしやすさ | 毎日バックアップをとる、監視の方法 |
| 移行性 | 今のシステムからの移り替え | 旧システムのデータをすべて引き継ぐ |
| セキュリティ | 情報を守る仕組み | 通信と個人情報を暗号化、アクセス権の管理 |
| システム環境・エコロジー | 設置場所や環境への配慮 | 消費電力、設置スペースの制約 |
「パスワードで本人確認をする」「アクセスログを記録する」のように、セキュリティに関する要件でも書き方によっては機能要件として扱われることがあります。試験では、応答時間・稼働率・復旧時間・同時アクセス数のような数値で程度を示す要件が非機能要件の典型例として出題されます。
要件定義で気をつけること
- 利害関係者を漏れなく巻き込む：利用部門だけでなく、運用担当や経営層の要求も確認する
- あいまいな言葉を避ける：「速く表示する」ではなく「3秒以内に表示する」と測定できる形にする
- 合意を記録に残す：要件定義書としてまとめ、関係者の承認を得る
- 後から変えるほど高くつく：テスト中や運用開始後の要件変更は、設計・プログラム・テストのやり直しにつながる
試験に出るポイント
- 要件定義＝システムに求める機能や性能を明確にし、利害関係者の合意を得る工程
- 流れは システム化計画 → 要件定義 → （調達）→ 設計・開発 → テスト → 運用・保守
- 機能要件＝システムが「何をするか」（予約・検索・印刷など）
- 非機能要件＝性能・可用性・セキュリティ・保守性など「機能以外の品質」
- 要件の誤りは後工程で見つかるほど修正コストが大きい