この記事は、PD-S（システム）試験（仮称）科目B 第1章「システムアーキテクチャに関すること」の2節目、小項目1-2「システム要件における機能要件の定義（データ構造の設計を含む）」の教科書です。前節（1-1）で定義した業務要件を、いよいよ「システムが何をするか」＝機能要件へ具体化する工程を扱います。シラバス案がこの小項目に挙げる4つの技能を全て取り上げ、要求の収集・調整のやり方から、機能要件を定義する観点、そしてカッコ書きでわざわざ明示された「データ構造の設計」＝データモデル（ER図）まで、前提知識ゼロから解説します。
この節の全体像 — 4つの技能は「入口」と「中身」に分かれる
シラバス案は小項目1-2に「目標とする技能の例」を4つ挙げています。前半2つは要求をシステム要件へ変換する入口の技能（実は小項目1-3と共通）、後半2つが機能要件そのものの中身を定義する技能です。
前提知識：「要求」と「要件」はどう違うか
この節を正確に読むために、まず要求（request/requirement）と要件（defined requirement）の使い分けを固めます。日常では同じ意味で使われがちですが、要件定義の文脈でははっきり区別します。
つまり「要求」は材料、「要件」は製品です。技能1・2はまさに「材料を集めて製品に仕上げる」工程を指しています。そして機能要件とは、システム要件のうち「システムが何をするか」を定めたもの（「どれだけうまく動くか」を定める非機能要件は次節1-3）でした。
入口：要求を集め、調整し、システム要件にする（技能1・技能2）
技能1：関係者から情報を収集し、要求をシステム要件として定義する
関係者から情報を収集し，整理して，要求をシステム要件として定義するスキル
要求は、待っていても正しい形では出てきません。能動的に収集する必要があります。実務で広く使われる収集手法と、それぞれの得意・不得意をおさえましょう。
| 収集手法 | やり方 | 得意なこと／注意点 |
|---|---|---|
| ヒアリング（インタビュー） | 関係者に個別・対面で聞き取る | 背景・本音まで深掘りできる。話者の立場に偏るため複数部門に実施する |
| アンケート | 質問票で広く回答を集める | 多人数の傾向を短期間で把握できる。深掘りには不向き |
| 現場観察 | 実際の業務の様子を見る | 本人も自覚していない暗黙の手順・例外処理を発見できる |
| 既存資料の分析 | 帳票・マニュアル・現行システムの仕様書を読み込む | 業務の全体像とデータ項目の洗い出しに有効。資料が実態と乖離していることがある |
| プロトタイプ | 画面などの試作品を見せて反応を得る | 「見れば分かる」タイプの要求を引き出せる。試作品が仕様と誤解されるリスク |
集めた要求は、整理（重複の統合・粒度の統一・曖昧語の排除）を経て、検証可能な文としてシステム要件に定義します。「速く表示する」ではなく「一覧画面を3秒以内に表示する」のように、後からテストで確認できる書き方にすることが定義の質を決めます。
技能2：矛盾する要求を調整し、総合的に取りまとめる
矛盾する要求を調整し，個々の要求を総合的に取りまとめるスキル
複数の部門から要求を集めれば、必ず衝突が起きます（営業「入力は最小限にしたい」⇔ 経理「分析のため詳細に入力してほしい」）。調整の基本原則は1-1で学んだとおり、業務課題と制約条件に照らして優先順位を判断することです。加えて、システム要件レベルの調整では次の道具が効きます。
- 優先度の区分：すべての要求を「必須（ないと業務が成立しない）／重要（強く望まれる）／任意（あれば便利）」のように区分し、予算・納期と突き合わせて採否を決める。
- トレーサビリティ（追跡可能性）：各システム要件がどの業務要件に由来するかの対応関係を表で管理する。由来を説明できない要件は「誰かの思いつき」の可能性が高く、調整時に削る候補になる。
- 合意の記録：採用しなかった要求も「不採用の理由」と共に記録する。後から蒸し返されたときの説明根拠になる。
中身①：機能要件を定義する5つの観点（技能3）
対象業務の業務内容を踏まえ，対象業務の業務要件を実現するために必要なシステム機能として，業務を構成する機能間の情報（データ）の流れ，対象となる人の作業，システム機能の実現範囲，情報管理の方法，他システムとのインタフェースなど，機能要件を明確化し，定義するスキル
この長い一文は、機能要件を定義するときのチェックリスト（5つの観点）として読むのが正解です。1つずつ分解します。
図1：機能要件を定義する5つの観点（シラバス案・技能の例③の分解）
観点1：機能間の情報（データ）の流れ
業務は「受注→在庫引当→出荷指示→請求」のような機能の連なりであり、機能から機能へデータが流れることで成立します。「受注機能は、受注データを在庫引当機能に渡す」というレベルで、どの機能がどのデータを作り、誰に渡すかを漏れなく定義します。この可視化の代表道具が後述のDFDです。
観点2：対象となる人の作業
すべてをシステムがやるわけではありません。「与信限度額を超える注文は人が承認する」のように、人とシステムの役割分担を明確にします。ここが曖昧だと「システムがやってくれると思っていた」という運用開始後の事故になります。
観点3：システム機能の実現範囲
今回の開発でどこまでを作るか（スコープ）の線引きです。「返品処理は対象外（現行の手作業を継続）」「多言語対応は次期フェーズ」のように、やらないことを明文化するのが実務のコツ。範囲の曖昧さは、後工程の追加要求（スコープクリープ）の温床になります。
観点4：情報管理の方法
データをどこで・誰が・どう管理するか。例えば「顧客情報は本システムで一元管理し、他システムは参照のみ」「注文データの訂正は当日中のみ可、以降は赤黒処理」など。データの正本（マスタ）がどこかを決めないと、同じ顧客が複数システムで別々に更新され、情報が食い違っていきます。
観点5：他システムとのインタフェース
連携先ごとに「何のデータを・どの形式で・どのタイミングで（リアルタイム／日次バッチ等）・どちらから」受け渡すかを定義します。1-1の技能6で決めた連携の基本方針を、ここで機能要件として具体化する関係です。
中身②：業務モデルとデータモデルを定義する（技能4）
業務モデル及びデータモデルを定義するスキル
小項目名にわざわざ「（データ構造の設計を含む）」と書かれている理由がこの技能4です。機能（処理）だけ定義してもシステムは作れません。その機能が扱うデータの構造を同時に設計する必要があります。
業務モデル：業務の構造を図で定義する
業務モデルは「業務がどういう機能で構成され、情報がどう流れるか」をモデル化したもの。代表的な表現がDFD（データフローダイアグラム）です。DFDは次の4要素だけで業務を描きます。
- 外部実体：システムの外にいる相手（顧客、取引先、他システム）
- プロセス：データを加工・変換する機能（受注登録、在庫引当）
- データストア：データの保管場所（受注ファイル、顧客台帳）
- データフロー：それらの間を流れるデータ（矢印）
DFDの利点は、処理の順序ではなくデータの流れに着目するため、「どの機能がどのデータを必要とし、どこに保管するか」＝観点1と観点4がそのまま図になることです。時系列の手順を描きたいときは、部門ごとのレーンに作業を並べる業務フロー図（スイムレーン形式）を使い分けます。
データモデル：データの構造をER図で定義する
データモデルは「業務で扱うデータにどんな種類があり、互いにどう関係するか」を定義したもの。代表的な表現がER図（実体関連図）です。
図2：ER図の基本 — 受注業務のデータモデル例（顧客・注文・注文明細・商品）
図2で注目してほしいのが「注文明細」の存在です。1回の注文で複数の商品を買え、1つの商品は多くの注文に登場する——つまり注文と商品は多対多の関係です。多対多のままではデータベースでうまく管理できないため、間に「注文明細（どの注文で・どの商品を・何個）」という連関エンティティを挟んで、1対多×2つに分解します。これはデータモデリングの最頻出パターンです。
もう1つの基本原則が正規化の考え方です。詳細な手順（第1〜第3正規形）はデータベース設計の領域ですが、発想は単純で、「同じ事実は1か所にだけ記録する」こと。注文明細に顧客住所をコピーして持つと、引っ越し1回で大量の行を直す羽目になり、直し漏れ＝データ不整合が生まれます。住所は顧客エンティティにだけ持たせ、注文からは顧客番号で参照する——この「重複を排除して参照でつなぐ」感覚が、技能4の言う「データモデルを定義するスキル」の土台です。
混同しやすい概念の整理
| 紛らわしいペア | 違いの核心 |
|---|---|
| 要求 ⇔ 要件 | 要求は関係者が表明した生の希望（曖昧・矛盾あり）。要件は収集・調整を経て合意・文書化した条件（検証可能な文で書く） |
| 機能要件 ⇔ 非機能要件 | 機能要件＝システムが何をするか（本節1-2）。非機能要件＝どれだけうまく動くか（次節1-3） |
| 業務モデル ⇔ データモデル | 業務モデル＝機能と情報の流れの構造（DFD等）。データモデル＝データの種類と関係の構造（ER図）。両方そろって技能4 |
| DFD ⇔ 業務フロー図 | DFDはデータの流れに着目（順序は表さない）。業務フロー図は作業の順序・分担に着目（スイムレーン） |
| エンティティ ⇔ 属性 | エンティティは管理対象のまとまり（顧客）。属性はその項目（顧客番号・氏名）。行を一意に特定する属性が主キー |
確認クイズ（4問）
この節の理解度チェックです（当サイト独自の予想問題。公式の出題ではありません）。
「要求」と「要件」の関係の説明として、最も適切なものはどれか。
機能要件の定義において、シラバス案が挙げる観点に含まれないものはどれか。
受注業務のデータモデルで、「注文」と「商品」の間に「注文明細」エンティティを設ける主な理由として、最も適切なものはどれか。
「どの機能がどのデータを作り、どこに保管し、誰に渡すか」というデータの流れを可視化したい。用いるモデルとして最も適切なものはどれか。
まとめ：小項目1-2で身につけること
- 技能4つの構造＝入口（要求→システム要件：収集・整理・調整）＋中身（機能要件の明確化とモデル定義）。
- 要求は材料、要件は製品。検証可能な文で定義し、矛盾は業務課題と制約条件を拠りどころに、優先度区分とトレーサビリティで調整する（技能1・2）。
- 機能要件の定義は5つの観点で抜けチェック：①データの流れ ②人の作業 ③実現範囲 ④情報管理の方法 ⑤他システムIF（技能3）。
- 業務モデル（DFD＝流れ）とデータモデル（ER図＝構造）を両方定義する（技能4）。多対多は連関エンティティで1対多×2に分解、同じ事実は1か所にだけ記録（正規化の発想）。
- 要件定義段階のデータモデルは概念レベル（エンティティ・主要属性・関連と多重度）まで。物理設計は後工程。
関連記事・次に読む
出典（一次情報）
- IPA「プロフェッショナルデジタルスキル（システム）試験（仮称）科目B シラバス（案 Ver0.2）」大項目1・小項目1-2（2026年7月31日更新）[link]。本文中の「技能の例」引用は同シラバス案からの原文引用です。
- IPA「情報処理技術者試験・情報処理安全確保支援士試験 出題範囲等の改定案 Ver.1.0」（2026年3月）
※試験名は仮称、内容は検討段階の案です。試験の形式・時間・配点・合格基準は未公表のため本記事では扱いません。技術解説（要求収集の手法、DFD・ER図・正規化など）は一般に確立した知識に基づく当サイトの解説で、シラバスの記載そのものではありません。確認クイズは当サイト独自の予想問題です。正式シラバス公開時に内容を更新します。
