基本情報技術者 学習ページ|科目A・システム開発技術
要件を具体化し追跡する
要件定義では、何を実現するかだけでなく、性能や信頼性などの品質条件も明確にします。利用者との認識をそろえ、要件を設計やテストまで追跡できる形にすることが重要です。
目標と対象範囲
システム要件定義では、まずシステム化の目標と対象範囲を明確にします。目標は、システム化によって解決したい業務上の課題や達成したい状態を示します。対象範囲では、対象業務、対象部署、利用者、外部システムとの境界などを定めます。範囲が曖昧だと、後になって必要機能や責任分担の認識がずれるため、何を含み何を含まないかを関係者で確認します。
目標と対象範囲を先に定め、システムの境界を明確にする。
機能要件と非機能要件
機能要件は、検索、登録、計算、帳票出力など、システムが利用者に提供する処理や振る舞いを示します。非機能要件は、性能、信頼性、可用性、セキュリティ、使用性など、機能以外の品質や制約に関する条件です。例えば「商品を条件指定で検索できる」は機能要件、「検索結果を通常2秒以内に表示する」は性能に関する非機能要件です。レスポンスタイムは応答までの時間、スループットは単位時間当たりの処理量を表します。
何をするかが機能要件、どの品質で行うかが非機能要件。
利用場面を表す
ユースケースは、利用者などのアクターが目標を達成するために、システムとどのようにやり取りするかを整理する方法です。アクターは人に限らず、対象システムとやり取りする外部システムなども含みます。ユーザーストーリーは、利用者の立場から「誰が、何のために、何をしたいか」を短い文章で表し、要求の価値を共有するために用いられます。両者は利用者視点で要求を具体化しますが、表現方法や詳細度は同じではありません。
ユースケースはアクターとシステムのやり取りを表す。
画面を早く確かめる
モックアップは、画面配置や操作イメージなど外観を早い段階で確認するための試作物で、内部処理を実装しないこともあります。プロトタイプは、要求や仕様の妥当性、操作性、実現可能性などを確認するために作る試作版で、一部の機能を動作させる場合があります。完成品を作り込む前に利用者から反応を得ることで、要求の漏れや認識違いを発見しやすくなります。試作物で確認した内容は正式な要件へ反映して管理することが大切です。
モックアップやプロトタイプで要件を早期に具体化する。
レビューと追跡可能性
要件のレビューでは、利用者、開発側、運用側などの関係者が、要件の正しさ、完全性、一貫性、実現可能性などを確認します。双方向のトレーサビリティは、上位の要求から設計・実装・テストなど下位の成果物を追えるだけでなく、下位の成果物から元の要求へもたどれる状態です。これにより、要件変更の影響範囲や、各要件に対応するテストの有無を確認しやすくなります。トレーサビリティマトリクスは、その対応関係を表形式で管理する方法の一つです。
双方向に追跡できれば変更影響と対応漏れを確認しやすい。
本番の形で解いてみる
科目Aの形: 四肢択一(表を読む)(このページのために作った問題)
次の要件P〜Rを、機能要件と非機能要件に分類した組合せとして、最も適切なものはどれか。
| 要件 | 内容 |
|---|---|
| P | 利用者が注文履歴を期間指定で検索できる |
| Q | 通常時は検索要求の95%を2秒以内に応答する |
| R | 注文を確定したとき、注文数に応じて在庫数を減算する |
- P=機能要件、Q=非機能要件、R=機能要件
- P=機能要件、Q=機能要件、R=非機能要件
- P=非機能要件、Q=機能要件、R=機能要件
- P=非機能要件、Q=非機能要件、R=機能要件
答えと解説を見る
正解: P=機能要件、Q=非機能要件、R=機能要件
Pは検索というシステムの振る舞いを定める機能要件です。Qは応答時間という性能条件なので非機能要件です。Rは注文確定時の在庫更新というシステムの振る舞いを定めるため、機能要件です。
まちがえやすい点: 性能や信頼性などの品質条件を、検索や更新などの具体的な処理機能と取り違えない。
科目Aの形: 四肢択一(このページのために作った問題)
ユースケースにおけるアクターの説明として、最も適切なものはどれか。
- 対象システム内部で処理を実行するプログラムモジュールを表す
- 対象システムとやり取りし、目的達成のためにサービスを利用する外部の役割を表す
- アクターと対象システムの間で行われる一連のやり取りそのものを表す
- 利用者の立場から要求の価値を短い文章で表した記述を表す
答えと解説を見る
正解: 対象システムとやり取りし、目的達成のためにサービスを利用する外部の役割を表す
アクターは、対象システムの外部からシステムとやり取りする役割を表します。利用者だけでなく、対象システムと連携する外部システムがアクターになる場合もあります。
まちがえやすい点: アクターは個人名ではなく、対象システムとの関係で見た外部の役割として捉える。
科目Aの形: 四肢択一(このページのために作った問題)
双方向のトレーサビリティを確保する主な目的として、最も適切なものはどれか。
- 要件から設計・テストへ、また設計・テストから元の要件へ対応関係をたどれるようにする
- 要件から設計・テストへたどれるようにし、テストから要件への対応は記録しない
- テストから元の要件へたどれるようにし、要件から設計・テストへの対応は記録しない
- 要件ごとの担当者を一覧にし、要件の変更を承認者だけが行えるようにする
答えと解説を見る
正解: 要件から設計・テストへ、また設計・テストから元の要件へ対応関係をたどれるようにする
双方向のトレーサビリティでは、上位要求から下位成果物への追跡と、下位成果物から元の要求への逆方向の追跡の両方を可能にします。変更影響や対応漏れの確認に役立ちます。
まちがえやすい点: 追跡可能性は変更を禁止する仕組みではなく、変更時の影響や対応を確認するための仕組み。
基本情報の学習ページ
ほかの学習ページの一覧と、2択の用語カード(750語)は、基本情報技術者のページにあります。
基本情報技術者のページへ →このページの内容は、IPA「基本情報技術者試験 シラバス Ver.9.2」(2026年1月公表)と試験要綱Ver.5.6の範囲にもとづきます(2026年10月確認)。IPAは2027年度春ごろから新しい試験制度に移る予定です。