要件定義と機能要件・非機能要件
要件定義プロセスで「やること」を企画・開発・テストの作業と見分けられるようになる。非機能要件を機能要件と区別でき、プライバシーバイデザインとUMLの定義問題も迷わず解けるようになる。
要件定義は「何を作るか」を決める工程で、ここがずれると後工程の手直しが一番高くつきます。試験では、隣の工程の作業を混ぜた選択肢から要件定義の作業を選ぶ問題と、機能要件か非機能要件かを判別する問題が繰り返し出ています。
このレッスンで稽古する（用語チェック・過去問）結論：要件定義は「関係者から聞き出し、整理し、合意する」工程
要件定義プロセスでは、利害関係者（ステークホルダ：システムに関わる人や組織）を洗い出し、その人たちのニーズ・要望・制約条件を明らかにして、合意を取ります。
前のレッスンで学んだ企画プロセスは「なぜ・何のためにシステム化するか（方針と計画）」を決める工程でした。要件定義はその次に来る工程で、「新しい業務とシステムに何が必要か」を決めます。どう作るか（方式設計）は、さらに後のシステム開発プロセスで決めます。
たとえるなら家づくりです。企画は「子どもが生まれるので家を建てる、予算は○円」と決める段階、要件定義は家族全員から「部屋は4つ、段差なし、駐車場2台」と聞き出してまとめ、全員の合意を取る段階です。設計図を描くのはその後になります。
工程の並びと、各工程の「やること」
flowchart LR
A["企画<br>方針・計画"] --> B["要件定義<br>聞き出す・合意する"] --> C["システム開発<br>方式設計"] --> D["ソフトウェア実装<br>設計・テスト"] --> E["運用・評価<br>効果の確認"]
試験は、隣り合う工程の作業を選択肢に混ぜてきます。キーワードでどの工程の作業かを判定してください。
| 工程 | 選択肢に出るキーワード | 例 |
|---|---|---|
| 企画 | システム化の方針、実施計画、事業環境の分析、事業目標の作成 | 法規制や経済状況を分析し事業目標を作る |
| 要件定義 | 利害関係者の識別、ニーズ・要望・制約条件、新しい業務の手順・ルール、合意 | 新業務の手順と制約を明確にし関係者間で合意する |
| システム開発 | システムの機能・能力の定義、システム方式設計、ハード／ソフトの実現方式 | ハードとソフトの分担を決める |
| ソフトウェア実装 | ソフトウェアの方式設計、適格性の確認、テスト | DBやソフトウェアのテストを実施する |
| 運用・評価 | 投資効果・業務効果の実績を評価 | 稼働後に効果を測る |
「設計」「実現方式」「テスト」「実績評価」が出てきたら要件定義ではありません。
要件定義プロセスの中の4つの活動
共通フレーム（ソフトウェア開発の作業や用語を標準化した日本の枠組み）では、要件定義の中身を次の4活動に分けています。特に「識別」と「評価」の取り違えがよく問われます。
| 活動 | やること | 見分けるキーワード |
|---|---|---|
| 利害関係者の識別 | 誰が関係者か、どの工程で誰が参画するかを明確にする | 関係者・参画・誰が |
| 要件の識別 | 関係者から要件を漏れなく引き出し、制約条件や運用シナリオを明らかにする | 引き出す・洗い出す |
| 要件の評価 | 引き出した要件の矛盾や曖昧さをなくし、一貫性のある集合に整理する | 矛盾・曖昧・整理 |
| 要件の合意 | 問題点の解決方法を説明し、関係者の合意を得る | 説明・合意 |
覚え方は「誰に聞くか → 聞き出す → 整える → 決める」の順です。
機能要件と非機能要件（ここが最頻出）
機能要件は「システムが何をするか」、非機能要件は「それをどれくらいの品質でやるか」と押さえます。非機能要件には、品質要件・技術要件・運用要件が含まれます。
レストランでたとえると、「注文を受けて料理を出す」が機能要件です。「10分以内に出す」「停電しても営業できる」「メニューを増やしても回る」が非機能要件にあたります。
| 機能要件 | 非機能要件 | |
|---|---|---|
| 一言で | 何をするか | どれくらいの品質・条件でやるか |
| 典型項目 | システム機能の実現範囲、機能間の情報（データ）の流れ、他システムとのインタフェース、利用者の作業 | 可用性、性能、拡張性、運用性、保守性、移行性、セキュリティ |
| 作業の例 | 実現する機能の範囲を定義する、データの流れを明確にする | 品質要件・技術要件・運用要件を明確にする、開発基準や標準の技術要件を作る |
| API設計でいうと | エンドポイントと入出力の定義 | 応答時間・稼働率・レート制限・認証方式 |
注意点：「他システムとのインタフェースを明確にする」は機能要件です。「つなぐ」という機能そのものだからです。逆に「プログラム言語に合わせた開発基準・標準の技術要件を作る」は、機能ではなく作り方の品質ルールなので非機能要件に入ります。
要件の種類全体の中での位置づけ
「非機能要件項目はどれか」と聞かれたときは、他の要件の種類と並べて見分けます。
| 要件の種類 | 中身 |
|---|---|
| 経営要件（企画で扱う） | 経営上のニーズ、業務上の課題、求められる成果・目標 |
| 業務要件 | 新しい業務の在り方、業務手順、入出力情報、組織・責任・権限、業務上の制約 |
| 機能要件 | 利用者の作業、システム機能の実現範囲、機能間の情報の流れ |
| 非機能要件 | システム基盤に関わる可用性・性能・拡張性・運用性・保守性・移行性など |
「システム基盤」「〜性」がずらっと並んでいたら非機能要件です。IPAの「非機能要求グレード」でも、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境（エコロジー）の6分類が使われています。
プライバシーバイデザイン（出題は少なめ）
プライバシーバイデザインは、個人情報の漏えいや目的外利用を防ぐ仕組みを、上流工程（企画・設計の段階）からあらかじめシステムに組み込むという考え方です。後から対策を足すのではなく、最初から設計に入れる点がポイントです。
| 用語 | 中身 |
|---|---|
| プライバシーバイデザイン | 設計段階から個人情報保護の機能を組み込む考え方 |
| プライバシーマーク | 個人情報を適切に扱う事業者に与えられる認定マーク（JIPDECが付与） |
| 情報セキュリティ方針 | 組織としてセキュリティにどう取り組むかを示した文書 |
| セキュリティレベル | 守る強さの度合い |
UML（出題は少なめ・免除試験で出る）
UMLは、OMG（オブジェクト指向技術の標準化団体）が標準化した、オブジェクト指向開発のためのモデリング言語です。クラス図・シーケンス図・アクティビティ図など、目的に応じた複数の図法を、標準化された記法で描き分けます。
| 図法・言語 | 中身 |
|---|---|
| UML | オブジェクト指向のモデリング言語。目的別に複数の図を使う |
| E-R図 | エンティティ・属性・関連で表すデータ中心の図 |
| DFD | データの発生源・処理・蓄積場所をデータの流れの矢印でつなぐ図 |
| デシジョンテーブル | 条件の組合せと動作を表で網羅する |
| IDL | オブジェクトのインタフェース記述言語 |
| SQL | 関係データベースの操作言語 |
| XML | 文書・データの構造を記述するマークアップ言語 |
試験での問われ方
- 「要件定義プロセスで実施すべきものはどれか」：企画（方針・事業目標）、開発（方式設計）、実装（テスト・適格性確認）、運用（効果評価）の作業が混ぜられます。**「関係者」「ニーズ・制約」「業務の手順・ルール」「合意」**を含む選択肢を選びます。
- 「要件の識別で実施する作業は」：識別・評価・合意の説明が並びます。「引き出す」が識別、「矛盾・曖昧をなくす」が評価、「合意を得る」が合意です。
- 「非機能要件はどれか／非機能要件の定義で行う作業は」：機能範囲・データの流れ・インタフェースといった機能要件側の選択肢がひっかけになります。品質・技術・運用・〜性・開発基準を含むものが正解です。
- 用語の定義問題（プライバシーバイデザイン・UML）：似た名前の別物（プライバシーマーク、E-R図、DFD、IDL、SQL、XML）と見分けさせます。
要点（試験直前に読む）
- 要件定義＝利害関係者を識別し、ニーズ・要望・制約条件を明らかにし、新しい業務の手順・ルールについて合意する工程。
- 要件定義の4活動は「関係者の識別 → 要件の識別（引き出す）→ 要件の評価（矛盾・曖昧をなくす）→ 要件の合意（説明して合意）」の順。
- 方針・事業目標は企画、方式設計・実現方式はシステム開発、テスト・適格性確認は実装、効果の実績評価は運用後の作業。
- 機能要件＝何をするか（機能範囲・データの流れ・インタフェース）。非機能要件＝品質・技術・運用の要件（可用性・性能・拡張性・運用性・保守性・移行性、開発基準）。
- プライバシーバイデザイン＝個人情報保護を設計段階から組み込む考え方。UML＝OMGが標準化したオブジェクト指向のモデリング言語。
ひっかけ
- 「事業目標を作成する」「システム化の方針を立案する」は企画の作業で、要件定義ではない。「方針」「目標」という語が見えたら企画を疑う。
- 「システム方式設計で実現方式を確立する」「方式設計と適格性の確認」は開発・実装の作業。「設計」「テスト」が入っていたら要件定義の選択肢から外す。
- 要件の識別と要件の評価の取り違え。「漏れなく引き出す・運用シナリオ」なら識別、「矛盾・曖昧をなくして整理」なら評価。
- 非機能要件の問題で「他システムとのインタフェース」「機能範囲」「データの流れ」を選ばせるひっかけ。これらは機能要件で、非機能要件は「〜性」「品質・技術・運用」「開発基準」。
- UMLを問う問題で、E-R図（エンティティと関連）やDFD（データの流れの矢印）の説明が混ざる。「オブジェクト指向」「標準化されたモデリング言語」「複数の図法」を含むものがUML。
用語（17）
利害関係者のニーズ・要望・制約条件を明らかにし、新しい業務とシステムに必要なことを決めて合意する工程。
⚠ 企画プロセス（システム化の方針・計画を立てる）やシステム開発プロセス（方式設計で実現方法を決める）と混同しやすい。「合意」「関係者」「制約条件」は要件定義、「方針」は企画、「設計」は開発と見分ける。
利用者・発注者・運用者など、システムに関わり合いを持つ人や組織。
利害関係者から要件を漏れなく引き出し、制約条件や運用シナリオを明らかにする活動。
⚠ 要件の評価（矛盾・曖昧さをなくして整理する）と取り違えやすい。「引き出す」なら識別、「整理する」なら評価。
引き出した要件の矛盾や曖昧な点をなくし、一貫性のある要件の集合に整理する活動。
⚠ 要件の識別（引き出す）や要件の合意（説明して合意を得る）と区別する。
矛盾した要件や実現できない要件などの解決方法を利害関係者に説明し、合意を得る活動。
⚠ 要件の評価との違いは、関係者に説明して承認をもらう段階かどうか。
予算・期限・法規制・既存環境など、システムが守らなければならない前提や制限。
システムが何をするかを表す要件で、機能の実現範囲、機能間のデータの流れ、他システムとのインタフェースなどを指す。
⚠ 非機能要件と対になる。「何をするか」が機能要件、「どれくらいの品質でやるか」が非機能要件。他システムとのインタフェースは機能要件に入る。
機能以外の要件で、可用性・性能・拡張性・運用性・保守性・移行性・セキュリティなどの品質要件と、技術要件・運用要件を指す。
⚠ 機能要件（機能範囲・データの流れ・インタフェース）と混同させる選択肢が定番。「〜性」「品質」「技術要件」「開発基準」なら非機能要件。
新しい業務の在り方、業務手順、入出力情報、組織・責任・権限、業務上の制約などをまとめた要件。
⚠ システム機能の範囲を扱う機能要件や、システム基盤の品質を扱う非機能要件と区別する。
システムが止まらずに使い続けられる度合い。
IPAがまとめた非機能要件の整理表で、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境の6分類で要求の水準を決めるもの。
個人情報の漏えいや目的外利用を防ぐ機能を、企画・設計の段階からシステムに組み込んでおく考え方。
⚠ プライバシーマーク（個人情報を適切に扱う事業者への認定マーク）と混同しやすい。設計の考え方か、認定制度かで見分ける。
個人情報を適切に取り扱っている事業者に対して付与される認定マーク。
⚠ プライバシーバイデザインは設計の考え方で、こちらは事業者を認定する制度。
OMGが標準化した、オブジェクト指向開発で使うモデリング言語で、目的に応じた複数の図法を標準化された記法で描き分ける。
⚠ E-R図（データ中心で、エンティティと関連を描く）、DFD（データの流れを矢印で描く）、IDL（インタフェース記述言語）、SQL（DB操作言語）、XML（マークアップ言語）と区別する。
UMLなど、オブジェクト指向技術の標準を策定している国際的な標準化団体。
データの発生源・処理・蓄積場所を、データの流れを示す矢印でつないで表す図。
⚠ UMLの説明として出されるひっかけ。「データの流れ」「発生・吸収・蓄積」ならDFD。
対象をエンティティ（実体）とその属性、エンティティ間の関連で表す、データ中心の図。
⚠ UMLの説明として出されるひっかけ。「エンティティ」「データ中心アプローチ」ならE-R図。
このレッスンの過去問
- 要件定義プロセスで実施すべき事項平成30年度 秋期 基本情報技術者試験 午前 問65
- 非機能要件の定義(品質に関する要件)平成31年度 春期 基本情報技術者試験 午前 問66
- プライバシーバイデザインの定義令和元年度 秋期 基本情報技術者試験 午前 問64
- UMLの定義(OMGのモデリング言語)基本情報技術者試験 科目A免除 修了試験 20170723 実施分 問63