本文へ移動

基本情報技術者試験 · 学習ガイド

システム開発の全体像

システム開発とは

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

エルくんが説明する図解。要望→測定可能な要件→設計→実装→要件に戻る受入確認の流れ。
考え方の例:「利用者が空き枠を選び予約完了できる」は機能要件、「繁忙時も3秒以内に一覧を表示する」は条件を定めた非機能要件の例です。

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

基本の仕組み

基本の仕組みの図解。中央に予約画面を1つ置き、左側に「空き枠を選んで予約を完了できる」機能要件、右側に「繁忙時も3秒以内に一覧を表示する」非機能要件を、同じ画面へ向かう線で対応づける。左右は細い仕切りで分け、別々の場面にはしない。
覚えること:空き枠予約/繁忙時も3秒以内に一覧表示

「利用者が空き枠を選び予約を完了できる」は機能要件、「繁忙時も3秒以内に一覧を表示する」は条件を定めた非機能要件の例です。

要件定義で必要なことを合意し、設計で実現方法を決め、実装とテストで確認します。受入テストでは依頼者の目的を満たすかを評価します。

実装が仕様書どおりでも、仕様が利用者の必要とずれていれば目的は達成できません。各要件に確認方法を対応させておきます。

要件から保守まで

要件から保守までの図解。左から「要件」「設計」「テスト」のカードを矢印で並べ、各カードの下を一本の対応線でつなぐ。工程の順序と、後から対応をたどれることを描き分ける。
覚えること:要件→設計→テストの対応をたどる

開発は、企画→要件定義→設計→実装→テスト→移行→運用・保守の順に進みます。機能要件は「何ができるか」という処理の内容、非機能要件は性能・可用性・信頼性・セキュリティ・保守性など「どの程度の品質で動くか」の条件です。

要件定義の段階で受入れの条件(何を満たせば完成とするか)を決め、利用者側の承認を得ておきます。要件→設計→テストの対応を後からたどれるようにしておくことを追跡可能性(トレーサビリティ)といい、要件の漏れや過剰な機能を見つけやすくなります。

要件から保守まで
工程主な成果
要件定義必要な機能と品質、受入れの条件
設計方式・構成、画面や処理の仕様
実装プログラム
テストテスト結果と修正の記録
移行・運用・保守本番での稼働と変更への対応

試験に出る

  • 要件定義は「利用者と合意する」段階、設計は「実現方法を決める」段階として区別します。工程の取り違えに注意します。
  • 機能要件と非機能要件の分類。応答時間や性能など条件を定めたものが非機能要件です。
  • 受入テストは、仕様書どおりかではなく依頼者の目的を満たすかを評価する点が問われます。
  • 仕様どおりの実装でも、仕様が利用者の必要とずれていれば目的を達成できないという考え方。
  • 要件ごとに確認方法を対応させておくことが、後戻りを減らす点。

重要な言葉

要件定義
利用者と合意して、何を実現するかを明らかにする工程。
非機能要件
応答時間や負荷条件など、機能以外の条件を定めた要件。
受入テスト
依頼者の目的を満たすかを評価するテスト。

確認問題

確かめよう応答時間の上限は機能そのもの?

主に非機能要件です。どの負荷条件かも併記します。

応答時間の上限は、主に非機能要件に分類される。

実装が仕様書どおりなら、利用者の目的は必ず達成される。

「繁忙時も3秒以内に一覧を表示する」はどの要件ですか。

受入テストで評価する観点は?

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

「利用者が空き枠を選び予約を完了できる」は、「繁忙時も3秒以内に一覧を表示する」は条件を定めたの例です。

で必要なことを合意し、設計で実現方法を決め、実装とテストで確認します。では依頼者の目的を満たすかを評価します。

実装が仕様書どおりでも、仕様が利用者の必要とずれていれば目的は達成できません。各要件にを対応させておきます。

出典・参考資料

試験の公式案内と、この記事の参考にした学習資料です。

編集:Pinternet Works · 更新日:

教材の編集方針・訂正について