システム開発は「いきなり作り始める」ものではありません。
最初に大切なのは「何を作るべきかを明らかにすること」。
その出発点が「要件定義」です。
この記事では、ITパスポートで出題されやすい「要件定義」の流れや種類について、わかりやすく解説します。
要求の調査(ヒアリング)
最初のステップは「お客様や関係者の話を聞くこと」。
ここで大事なのは、「どんなことに困っていて、何を実現したいか」という“ニーズ”をしっかり引き出すことです。
要件の分析
調査で集めた情報を整理し、実際に必要な機能や条件を分類・分析します。
ここでムリな要求や矛盾している内容を見つけて、調整していくことも大切です。
要件定義の分類と内容
業務要件定義
→ 対象業務や業務フローなど、「仕事のやり方」の要件を明らかにします。
機能要件定義
→ システムにどんな「機能」が必要かを定義します(例:検索機能、集計機能など)
非機能要件定義
→ 見えにくいけど超重要な“使いやすさ”や“安全性”の要件です。
非機能要件の種類
種類 | 内容 |
---|---|
可用性 | サービスを止めずに使えるようにする(例:24時間365日稼働) |
性能・拡張性 | 応答速度や同時アクセス数などの処理性能、将来的な拡張性 |
運用・保守性 | 管理しやすく、修正しやすい設計 |
移行性 | 旧システムから新システムへのスムーズな移行 |
セキュリティ | 不正アクセス対策、アクセス権限の制御など |
環境対策 | 電力消費やペーパーレス対応などの配慮 |
要件定義のプロセス
調査 → 分析 → 定義
▼
業務要件/機能要件/非機能要件へ落とし込む

まとめ:要件定義がブレると、すべてがブレる!
システム開発の土台となる要件定義。
しっかりと調査・分析・整理しておくことで、あとからのトラブルや手戻りを防ぐことができます。
「どんなモノをつくるか」を正しく描く――それが成功のカギです!
FAQ(よくある質問)
- Q機能要件と非機能要件ってどう違うの?
- A
機能要件は「できること」、非機能要件は「どうやってそれを使うか」「使いやすさ」など、機能以外の条件です。
- Q非機能要件って後回しでもいい?
- A
いいえ!あとから加えようとすると大幅な修正が必要になるため、最初からしっかり考えることが大切です。
- Q要件定義ってエンジニアが勝手にやるの?
- A
いいえ。お客様・業務部門としっかり話し合って、一緒に決めていく作業です。
練習問題①
要件定義の目的として、最も適切なものはどれか?
A. プログラムのソースコードを記述すること
B. システムの保守マニュアルを作成すること
C. システムに必要な機能や条件を明確にすること
D. システム導入後の運用担当者を育成すること
正解:
C
→要件定義は「何を作るべきか」「どう使われるか」を明らかにする工程です。
練習問題②
非機能要件として適切なものはどれか?
A. 取引先コードを入力すると、取引履歴を表示する機能
B. 商品検索時に3秒以内に結果を返す性能
C. 見積書をPDFで出力する機能
D. 顧客情報を並べ替える機能
正解:
B
→応答時間や処理速度は「性能」に関する条件であり、非機能要件に分類されます。
練習問題③
要件定義の過程に含まれる活動として、最も適切なものはどれか?
A. 実装されたシステムのソースコードレビュー
B. 利用者へのヒアリングによるニーズの調査
C. ハードウェア機器の選定と購入
D. OSやネットワークの保守体制の構築
正解:
B
→ヒアリングによる“要求の調査”は、要件定義の最初の重要なプロセスです。
コメント