2.2.3. 要件定義の手法

1. 概要

　要件定義とは、システム開発のライフサイクルにおいて非常に重要なプロセスであり、ユーザーの要求をシステムに反映させるために必要な仕様を明確にする工程です。この工程では、クライアントのニーズや業務上の課題を理解し、それらを具体的なシステム要件として定義します。適切な要件定義がなければ、開発されるシステムは本来の目的を果たせず、後工程での手戻りや追加コストの発生リスクが高まります。

　本記事では、要件定義の手法の中でも特に構造化分析手法とオブジェクト指向分析手法に焦点を当て、それらの概念や技法について詳しく解説します。これらの手法は応用情報技術者試験においても重要な出題分野となっており、システムアナリストやプロジェクトマネージャーとして活躍するためにも理解しておくべき内容です。

2. 詳細説明

2.1. 構造化分析手法

　構造化分析手法は、1970年代に登場した体系的なシステム分析手法で、複雑なシステムを階層的に分解して理解しやすくする特徴があります。トップダウンアプローチを採用し、システムを機能的な単位に分割して分析します。

2.1.1. DFD（Data Flow Diagram：データフロー図）

　DFDは、システム内のデータの流れを視覚的に表現する図で、以下の要素で構成されます。

• プロセス：データを加工・変換する処理（円や楕円で表現）
• データフロー：データの流れ（矢印で表現）
• データストア：データを格納する場所（平行線や開いた長方形で表現）
• 外部実体：システムの外部との境界（四角形で表現）

　DFDは通常、レベル0（コンテキスト図）から始まり、レベル1、レベル2と階層的に詳細化されます。これにより、システム全体から詳細な処理まで段階的に把握することができます。

graph LR
    A[外部実体] -->|データフロー| B((プロセス))
    B -->|データフロー| C[データストア]
    C -->|データフロー| D((別プロセス))
    D -->|データフロー| E[外部実体]
    
    style A fill:#f9f9f9,stroke:#333,stroke-width:2px
    style B fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style C fill:#f9f9f9,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style D fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style E fill:#f9f9f9,stroke:#333,stroke-width:2px

図1: DFDの基本要素と表記法

graph TD
    subgraph "レベル0（コンテキスト図）"
        A[顧客] -->|注文情報| B((販売管理システム))
        B -->|出荷情報| C[倉庫]
        D[経理部門] -->|在庫情報| B
        B -->|売上レポート| E[管理部門]
    end
    
    subgraph "レベル1（詳細化）"
        F[顧客] -->|注文情報| G((1.注文処理))
        G -->|注文データ| H[(注文DB)]
        H -->|注文データ| I((2.在庫確認))
        I -->|在庫データ| J[(在庫DB)]
        I -->|出荷指示| K((3.出荷処理))
        K -->|出荷情報| L[倉庫]
        M[経理部門] -->|在庫情報| J
        H -->|売上データ| N((4.レポート生成))
        N -->|売上レポート| O[管理部門]
    end
    
    B -.-> G
    B -.-> I
    B -.-> K
    B -.-> N
    
    style A fill:#f9f9f9,stroke:#333,stroke-width:2px
    style B fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style C fill:#f9f9f9,stroke:#333,stroke-width:2px
    style D fill:#f9f9f9,stroke:#333,stroke-width:2px
    style E fill:#f9f9f9,stroke:#333,stroke-width:2px
    
    style F fill:#f9f9f9,stroke:#333,stroke-width:2px
    style G fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style H fill:#f9f9f9,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style I fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style J fill:#f9f9f9,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style K fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style L fill:#f9f9f9,stroke:#333,stroke-width:2px
    style M fill:#f9f9f9,stroke:#333,stroke-width:2px
    style N fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style O fill:#f9f9f9,stroke:#333,stroke-width:2px

図2: DFDの階層化の例（レベル0からレベル1への分解例）

2.1.2. プロセス仕様

　DFDで表現された各プロセスの内部処理を詳細に記述したものがプロセス仕様です。プロセス仕様はミニ仕様とも呼ばれ、構造化言語（擬似コード）や決定表、フローチャートなどを用いて表現されます。プロセス仕様は、設計者やプログラマーに具体的な処理手順を伝えるために重要な要素です。

　例えば、「注文処理」というプロセスのプロセス仕様は以下のようになります：

プロセス名：注文処理
入力：注文情報（顧客ID、商品ID、数量、配送先）
出力：注文データ（注文ID、顧客ID、商品ID、数量、配送先、注文日時、合計金額）
処理内容：
1. 顧客IDの有効性を確認する
2. 商品IDと数量から在庫を確認する
3. 在庫が不足している場合はエラーメッセージを返す
4. 在庫が十分な場合は、注文IDを生成し、注文情報を注文DBに登録する
5. 商品の単価から合計金額を計算し、注文データに追加する
6. 注文完了メッセージを返す

2.1.3. DD（Data Dictionary：データ辞書）

　DDはシステムで使用されるデータの定義を集めたもので、データ項目名、データ型、桁数、制約条件などが記載されます。DFDに表現されているデータフローやデータストアの詳細情報を管理するために使用され、システム内でのデータの一貫性を保つ役割を果たします。

　データ辞書の記述例：

顧客データ = 顧客ID + 顧客名 + 住所 + 電話番号 + メールアドレス + 登録日
顧客ID = {英字1文字} + {数字5文字}　/* 例：A12345 */
顧客名 = {全角文字}　/* 最大50文字 */
住所 = {全角文字}　/* 最大100文字 */
電話番号 = {数字}　/* 10-11桁 */
メールアドレス = {英数字、記号} + '@' + {英数字、記号} + '.' + {英字2-3文字}
登録日 = {日付}　/* YYYY/MM/DD形式 */

2.1.4. 決定表（デシジョンテーブル）

　決定表は複雑な条件分岐をテーブル形式で整理した表現方法です。条件の組み合わせと、それに対応する処理のアクションを明確にすることができます。特に多数の条件分岐がある場合に有効で、条件の網羅性や重複を確認するのに役立ちます。

図3: 決定表の例（シンプルな例）

2.1.5. デシジョンツリー

　デシジョンツリーは条件分岐を木構造で表現したものです。決定表と同様に条件分岐の表現に使われますが、階層的な表現が特徴で、条件判断の流れを視覚的に理解しやすい利点があります。

graph TD
    A{会員である?} -->|はい| B{購入金額10,000円以上?}
    A -->|いいえ| E{購入金額10,000円以上?}
    
    B -->|はい| C{セール期間中?}
    B -->|いいえ| D{セール期間中?}
    
    C -->|はい| J[15%割引]
    C -->|いいえ| K[10%割引]
    
    D -->|はい| L[10%割引]
    D -->|いいえ| M[5%割引]
    
    E -->|はい| F{セール期間中?}
    E -->|いいえ| G{セール期間中?}
    
    F -->|はい| N[15%割引]
    F -->|いいえ| O[10%割引]
    
    G -->|はい| P[5%割引]
    G -->|いいえ| Q[通常価格]
    
    style A fill:#f9f9f9,stroke:#333,stroke-width:2px
    style B fill:#f9f9f9,stroke:#333,stroke-width:2px
    style C fill:#f9f9f9,stroke:#333,stroke-width:2px
    style D fill:#f9f9f9,stroke:#333,stroke-width:2px
    style E fill:#f9f9f9,stroke:#333,stroke-width:2px
    style F fill:#f9f9f9,stroke:#333,stroke-width:2px
    style G fill:#f9f9f9,stroke:#333,stroke-width:2px
    
    style J fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style K fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style L fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style M fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style N fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style O fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style P fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style Q fill:#e6f3ff,stroke:#0066cc,stroke-width:2px

図4: デシジョンツリーの例

2.1.6. コード・ヨードン技法

　コード・ヨードン技法は、構造化分析の代表的な手法の一つで、DFDを中心としたモデリング手法です。エドワード・ヨードンとラリー・コンスタンティンによって提案されました。この技法では、DFD、データ辞書、プロセス仕様、実体関連図（ERD）などを使用してシステムを分析します。この手法は特に「トランザクション分析」が特徴で、システムに入力される各トランザクション（業務の単位）ごとにデータフローを追跡することで、システムの機能を明確化します。

2.1.7. シュレア・メラー技法

　シュレア・メラー技法は、サリー・シュレアとメルヴィン・メラーによって提案された構造化分析手法です。この技法ではDFDに加えて、データ構造図（Data Structure Diagram）や状態遷移図（State Transition Diagram）を使用してシステムを分析します。シュレア・メラー技法の特徴は、「イベント駆動アプローチ」を採用している点で、システムに発生する「イベント」に着目し、それに対する「レスポンス」を分析することでシステムの挙動を明らかにします。

2.2. オブジェクト指向分析手法

　オブジェクト指向分析手法は、現実世界の概念をオブジェクト（対象）として捉え、そのオブジェクトとオブジェクト間の関係に着目してシステムを分析する手法です。データと処理を一体化したオブジェクトという単位でシステムを構築するアプローチです。

2.2.1. UML（Unified Modeling Language：統一モデリング言語）

　UMLはオブジェクト指向分析・設計のための標準的な表記法で、以下のような様々な図を用いてシステムを多角的に表現します。

• クラス図：クラスとクラス間の関係を表現
• ユースケース図：システムの機能とアクターの関係を表現
• シーケンス図：オブジェクト間のメッセージのやり取りを時系列で表現
• アクティビティ図：処理の流れを表現
• ステートマシン図：状態の遷移を表現
• コンポーネント図：システムのコンポーネント構成を表現
• 配置図：物理的な配置関係を表現

　UMLを使用することで、開発者間での共通理解が促進され、設計の品質向上につながります。

図5: UMLの主要ダイアグラム例（クラス図、ユースケース図、シーケンス図など）

2.2.2. DOA（Data Oriented Approach：データ中心アプローチ）

　DOAはデータの構造と関係に重点を置いた分析手法です。オブジェクト指向分析の中でも特にデータモデリングを重視するアプローチであり、実体関連モデル（ER図）などを用いてデータ構造を明確にします。DOAでは、まずデータ構造を確立し、その後にそのデータを操作する処理を設計するというアプローチを取ります。

　DOAの主な特徴は以下の通りです：

1. データモデルを最初に定義する
2. データ間の関連性を明確にする
3. データの完全性や整合性を重視する
4. データベース設計と密接に関連している
5. 業務で扱うデータに着目してシステムを分析する

　DOAは、データの安定性が高く、業務プロセスが頻繁に変更される可能性があるシステムに適しています。

3. 応用例

3.1. 構造化分析手法の適用例

　銀行の預金管理システムの開発において、構造化分析手法を適用する例を考えてみます。まず、コンテキストレベル（レベル0）のDFDで全体像を把握し、「顧客」「銀行職員」などの外部実体と「預金管理システム」の関係を明らかにします。次に、レベル1のDFDで「預金入出金処理」「口座開設処理」「残高照会処理」などの主要プロセスに分解します。

　各プロセスの詳細はプロセス仕様によって定義され、例えば「預金入出金処理」では、入金額のチェック、残高の更新などの手順がアルゴリズムとして記述されます。また、「口座」「取引履歴」などのデータストアの構造はDDによって定義されます。

　入出金処理における条件分岐（例：残高不足時の処理、高額取引時の本人確認など）は、決定表またはデシジョンツリーを用いて整理します。これにより、複雑な条件分岐も漏れなく処理できるようになります。

3.2. オブジェクト指向分析手法の適用例

　ECサイトの開発において、オブジェクト指向分析手法を適用する例を考えてみます。UMLを用いた分析では、まずユースケース図で「商品検索」「商品購入」「会員登録」などの機能と、「顧客」「管理者」などのアクターの関係を表現します。

　次に、クラス図で「商品」「カート」「注文」「顧客」などのクラスとその関連を定義します。例えば、「顧客」クラスは「注文」クラスと1対多の関連を持ち、「注文」クラスは「商品」クラスと多対多の関連を持つなどの関係が表現されます。

　購入プロセスの流れはシーケンス図やアクティビティ図で表現し、「カート」の状態変化はステートマシン図で表現します。DOAの観点からは、「商品」「顧客」「注文」などのエンティティとその関係に着目したデータモデルを作成することで、データベース設計の基礎とします。

4. 例題

例題1

　ある企業の在庫管理システムを開発するにあたり、以下の要件が提示されました。

1. 商品の入荷・出荷を記録する
2. 在庫数が一定数量を下回ったら自動的に発注する
3. 商品のカテゴリ別に在庫状況を集計する
4. 担当者による在庫の実地確認結果を記録する

　これらの要件を表現するためのDFDを作成し、主要なデータの項目をDD（データ辞書）形式で定義してください。

graph TD
    A[仕入先] -->|入荷情報| B((在庫管理システム))
    C[出荷先] -->|出荷依頼| B
    B -->|出荷情報| C
    B -->|在庫状況| D[在庫管理者]
    D -->|実地確認結果| B
    B -->|発注依頼| A
    
    subgraph "レベル1 DFD"
        E((1.入荷処理)) -->|入荷データ| F[(商品DB)]
        G((2.出荷処理)) -->|出荷データ| H[(取引履歴DB)]
        G -->|在庫更新| F
        I((3.在庫監視)) -->|自動発注| J((4.発注処理))
        F -->|在庫情報| I
        K((5.在庫確認)) -->|確認結果| F
        F -->|在庫状況| L((6.集計処理))
        L -->|カテゴリ別集計| M[在庫管理者]
    end
    
    B -.-> E
    B -.-> G
    B -.-> I
    B -.-> J
    B -.-> K
    B -.-> L
    
    style A fill:#f9f9f9,stroke:#333,stroke-width:2px
    style B fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style C fill:#f9f9f9,stroke:#333,stroke-width:2px
    style D fill:#f9f9f9,stroke:#333,stroke-width:2px
    
    style E fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style F fill:#f9f9f9,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style G fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style H fill:#f9f9f9,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style I fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style J fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style K fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style L fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style M fill:#f9f9f9,stroke:#333,stroke-width:2px

商品 = 商品ID + 商品名 + カテゴリID + 単価 + 発注点 + 標準発注数量
入荷情報 = 入荷ID + 商品ID + 入荷日時 + 入荷数量 + 仕入先ID
出荷情報 = 出荷ID + 商品ID + 出荷日時 + 出荷数量 + 出荷先ID
在庫状況 = 商品ID + 現在庫数 + 最終更新日時
実地確認結果 = 確認ID + 商品ID + 確認日時 + 確認数量 + 担当者ID + 備考

例題2

　ホテル予約システムにおいて、以下の条件に基づく部屋の料金計算ルールがあります。

• 平日と休日で基本料金が異なる
• 会員ランク（一般・シルバー・ゴールド）によって割引率が異なる
• 連泊日数（1泊・2〜4泊・5泊以上）によって追加割引がある
• キャンペーン期間中は全ての予約に10%の追加割引がある

　これらの条件を表現する決定表（デシジョンテーブル）を作成してください。

例題3

　図書館管理システムを開発するにあたり、オブジェクト指向分析手法を用いて設計を行います。以下の要件に基づいて、UMLのクラス図の一部を作成してください。

• 図書館には複数の書籍があり、各書籍には題名、著者、出版社、ISBN、分類などの情報がある
• 利用者は図書館に会員登録することで、書籍を借りることができる
• 利用者の情報として、氏名、住所、電話番号、会員ID、登録日などを管理する
• 書籍の貸出情報として、貸出日、返却予定日、実際の返却日、貸出状態などを管理する
• 一人の利用者は同時に最大5冊まで借りることができる

classDiagram
    class 利用者 {
        -会員ID: String
        -氏名: String
        -住所: String
        -電話番号: String
        -登録日: Date
        -現在貸出数: int
        +書籍を借りる(書籍): boolean
        +書籍を返却する(書籍): void
        +貸出可能か確認する(): boolean
    }
    
    class 書籍 {
        -ISBN: String
        -題名: String
        -著者: String
        -出版社: String
        -分類: String
        -状態: String
        +検索する(キーワード): List~書籍~
        +状態確認する(): String
        +利用可能か(): boolean
    }
    
    class 貸出 {
        -貸出ID: String
        -貸出日: Date
        -返却予定日: Date
        -実際の返却日: Date
        -貸出状態: String
        +延長する(日数): boolean
        +返却する(): void
        +延滞確認する(): boolean
    }
    
    利用者 "1" -- "*" 貸出: 借りる
    貸出 "*" -- "1" 書籍: 対象
    
    note for 利用者 "現在貸出数が5冊未満の場合のみ\n新たな貸出が可能"
    note for 貸出 "貸出状態：貸出中、返却済み、延滞中"
    note for 書籍 "状態：利用可能、貸出中、予約中、修理中"

5. まとめ

　要件定義の手法として、構造化分析手法とオブジェクト指向分析手法について学びました。構造化分析手法はDFD、プロセス仕様、DD、決定表、デシジョンツリーなどのツールを用いて、システムの機能とデータの流れに着目した分析を行います。コード・ヨードン技法やシュレア・メラー技法はこの分析手法の代表的なアプローチです。

　一方、オブジェクト指向分析手法はUMLを活用して、システムをオブジェクト（クラス）とその関連として捉え、現実世界に近いモデル化を実現します。また、DOA（データ中心アプローチ）はデータ構造に重点を置いた分析方法として、システムのデータモデルを明確化します。

　両手法には表1に示したように、それぞれ特徴やメリット・デメリットがあります。実際のプロジェクトでは、システムの特性や要件に応じて適切な手法を選択したり、両手法を組み合わせたりすることが重要です。例えば、全体像の把握には構造化分析手法のDFDを用い、詳細設計にはオブジェクト指向分析手法のUMLを使うといった組み合わせも効果的です。

　要件定義は、システム開発の成功を左右する重要な工程です。適切な要件定義手法を選択・適用することで、クライアントの要求を正確に理解し、後工程でのトラブルを未然に防ぐことができます。情報技術者を目指す方は、これらの要件定義手法の基本概念と特徴を理解し、適切な場面で活用できるようになることが重要です。