システム開発とは
システム開発とは、利用者の目的を明らかにする要件定義から、設計・実装・テストを経て成果を確かめるまでの一連の流れです。

依頼者の「使いやすい予約システム」という言葉だけでは、何をもって完成とするか決められません。具体的な利用場面から必要なことを明らかにします。
基本の仕組み

「利用者が空き枠を選び予約を完了できる」は機能要件、「繁忙時も3秒以内に一覧を表示する」は条件を定めた非機能要件の例です。
要件定義で必要なことを合意し、設計で実現方法を決め、実装とテストで確認します。受入テストでは依頼者の目的を満たすかを評価します。
実装が仕様書どおりでも、仕様が利用者の必要とずれていれば目的は達成できません。各要件に確認方法を対応させておきます。
要件から保守まで

開発は、企画→要件定義→設計→実装→テスト→移行→運用・保守の順に進みます。機能要件は「何ができるか」という処理の内容、非機能要件は性能・可用性・信頼性・セキュリティ・保守性など「どの程度の品質で動くか」の条件です。
要件定義の段階で受入れの条件(何を満たせば完成とするか)を決め、利用者側の承認を得ておきます。要件→設計→テストの対応を後からたどれるようにしておくことを追跡可能性(トレーサビリティ)といい、要件の漏れや過剰な機能を見つけやすくなります。
| 工程 | 主な成果 |
|---|---|
| 要件定義 | 必要な機能と品質、受入れの条件 |
| 設計 | 方式・構成、画面や処理の仕様 |
| 実装 | プログラム |
| テスト | テスト結果と修正の記録 |
| 移行・運用・保守 | 本番での稼働と変更への対応 |
試験に出る
- 要件定義は「利用者と合意する」段階、設計は「実現方法を決める」段階として区別します。工程の取り違えに注意します。
- 機能要件と非機能要件の分類。応答時間や性能など条件を定めたものが非機能要件です。
- 受入テストは、仕様書どおりかではなく依頼者の目的を満たすかを評価する点が問われます。
- 仕様どおりの実装でも、仕様が利用者の必要とずれていれば目的を達成できないという考え方。
- 要件ごとに確認方法を対応させておくことが、後戻りを減らす点。
重要な言葉
- 要件定義
- 利用者と合意して、何を実現するかを明らかにする工程。
- 非機能要件
- 応答時間や負荷条件など、機能以外の条件を定めた要件。
- 受入テスト
- 依頼者の目的を満たすかを評価するテスト。
確認問題
確かめよう応答時間の上限は機能そのもの?
主に非機能要件です。どの負荷条件かも併記します。
応答時間の上限は、主に非機能要件に分類される。
実装が仕様書どおりなら、利用者の目的は必ず達成される。
「繁忙時も3秒以内に一覧を表示する」はどの要件ですか。
受入テストで評価する観点は?
依頼者の「使いやすい予約システム」という言葉だけでは、何をもって完成とするか決められません。具体的なから必要なことを明らかにします。
「利用者が空き枠を選び予約を完了できる」は、「繁忙時も3秒以内に一覧を表示する」は条件を定めたの例です。
で必要なことを合意し、設計で実現方法を決め、実装とテストで確認します。では依頼者の目的を満たすかを評価します。
実装が仕様書どおりでも、仕様が利用者の必要とずれていれば目的は達成できません。各要件にを対応させておきます。
出典・参考資料
試験の公式案内と、この記事の参考にした学習資料です。
- IPA:基本情報技術者試験 ↗
- IPA:現行制度の公開問題 ↗
- IPA:試験要綱・シラバス ↗
- IPA:基本情報技術者試験シラバス Ver.9.2(2026年1月) ↗
- Scrum Guides:The Scrum Guide(2020) ↗
編集:Pinternet Works · 更新日:
教材の編集方針・訂正について
