2.2.2. 要件の定義

1. 概要

　要件定義とは、システム開発プロジェクトにおいて、構築すべきシステムが満たすべき要件を明確化するプロセスです。これは、システム開発の基盤となる重要な作業であり、この段階での曖昧さや誤解は、開発の後工程での大きな問題や手戻りの原因となります。

　要件定義では、利害関係者（ステークホルダー）の要求を丁寧に聞き取り、それをシステムが満たすべき要件として明確に定義します。適切に実施された要件定義は、開発の方向性を正しく導き、プロジェクトの成功率を大きく高めます。

表1: 要件の種類と特徴

2. 詳細説明

2.1. 業務要件定義

　業務要件定義とは、システムが支援すべき業務内容や業務プロセスを定義するものです。ここでは、業務の目的、業務上の課題、業務の流れなどを明確化します。業務要件定義では、以下の観点が重要です。

• 業務目標・課題の明確化
• 業務プロセスの定義
• 業務処理手順の詳細化
• 業務上のルールやポリシーの明確化
• 業務に関わる組織・役割の定義

2.2. 機能要件定義

　機能要件定義とは、システムが提供すべき機能を明確化するものです。具体的には、システムが何をすべきか、どのような処理を行うべきかを定義します。機能要件には以下が含まれます。

• システムの主要機能
• 入出力情報の定義
• 処理ルールの定義
• ユーザインタフェースの要件
• 周辺インタフェース要件（他システムとの連携方法）

2.3. 非機能要件定義

　非機能要件定義とは、システムの品質特性に関する要件を定義するものです。システムがどのように動作すべきかに関する要件で、以下の要素が含まれます。

2.3.1. 性能要件

　性能要件には、レスポンスタイム、スループット、処理能力などが含まれます。例えば「画面表示は3秒以内に完了すること」などです。

2.3.2. セキュリティ要件

　セキュリティ要件には、認証・認可の方法、データの暗号化、アクセス制御、監査証跡などが含まれます。例えば「パスワードは8文字以上で英数字混在とすること」などです。

2.3.3. 可用性・信頼性要件

　システムの稼働率や障害発生時の対応、バックアップの方針などを定義します。例えば「システムの年間稼働率は99.9%以上とすること」などです。

2.4. 情報・データ要件

　情報・データ要件では、システムで扱うデータの種類、構造、量、品質、保存期間などを定義します。具体的には以下の要素を含みます。

• データ項目の定義
• データ間の関連性
• データ量の見積もり
• データの保存期間
• データの品質基準

2.5. 運用要件

　運用要件では、システムの運用に関する要件を定義します。具体的には以下の要素を含みます。

• バックアップ・リカバリの方針
• 監視・運用体制
• ジョブスケジュール
• 障害対応手順
• 運用マニュアルの作成方針

2.6. 移行要件

　移行要件では、既存システムから新システムへの移行に関する要件を定義します。具体的には以下の要素を含みます。

• データ移行の方針
• 移行スケジュール
• 並行運用の方針
• 移行リスクとその対策
• 移行作業の体制

2.7. 保守要件

　保守要件では、システム稼働後の保守に関する要件を定義します。具体的には以下の要素を含みます。

• 保守体制
• バージョンアップの方針
• 障害対応のSLA（Service Level Agreement）
• 改修対応の方針
• 保守コストの見積もり

2.8. 要件定義時の注意点

　要件定義を行う際の主な注意点は以下の通りです。

• 曖昧な表現を避け、明確かつ具体的に記述する
• 要件間の矛盾や重複がないよう注意する
• 実現可能性や費用対効果を考慮する
• ステークホルダー間で認識の齟齬がないよう合意形成を図る
• 将来的な拡張性や変更に対応できるよう考慮する
• 優先順位を明確にし、必須要件とオプション要件を区別する

3. 応用例

3.1. 医療情報システムでの要件定義

　医療機関での電子カルテシステム導入の場合、以下のような要件定義が行われます。

• 業務要件定義: 診察から会計までの業務処理手順、診療科ごとの業務フロー、処方箋発行のルールなど
• 機能要件定義: 患者情報管理機能、診察予約機能、処方箋発行機能など
• 非機能要件定義:
  • 性能要件: 患者情報表示は1秒以内、1日最大1000人の患者処理に対応
  • セキュリティ要件: 個人情報保護法対応、アクセス制御、監査証跡の保存
• 周辺インタフェース要件: レセプトコンピュータとの連携、検査機器との連携
• 情報・データ要件: 患者基本情報、診療記録、処方情報のデータ構造と保存期間
• 運用要件: 24時間365日稼働、定期バックアップ、障害時の対応手順
• 移行要件: 過去の紙カルテからのデータ移行計画、移行期間中の運用方針
• 保守要件: システム障害対応の体制、定期的なバージョンアップ計画

3.2. EC（電子商取引）サイトでの要件定義

　EC（電子商取引）サイト構築の場合、以下のような要件定義が行われます。

• 業務要件定義: 受注から出荷までの業務処理手順、返品対応フロー、在庫管理方法
• 機能要件定義: 商品検索機能、注文機能、決済機能、会員管理機能
• 非機能要件定義:
  • 性能要件: トップページ表示は2秒以内、同時アクセス1000ユーザーに対応
  • セキュリティ要件: クレジットカード情報の暗号化、不正アクセス検知
• 周辺インタフェース要件: 決済代行サービスとの連携、物流システムとの連携
• 情報・データ要件: 商品マスタ、顧客情報、注文履歴のデータ構造と保存期間
• 運用要件: サイト監視体制、障害時の対応手順、バックアップ方針
• 移行要件: 既存ECサイトからの移行計画、商品データの移行方法
• 保守要件: システム改修の頻度と体制、セキュリティアップデートの方針

4. 例題

例題1

あるオンラインショッピングサイトの要件定義において、以下の記述のうち、非機能要件定義に該当するものを選びなさい。

A. 商品検索機能では、キーワード検索とカテゴリ検索が可能であること B. システムは、ピーク時の1時間あたり10,000件の注文処理が可能であること C. 商品マスタには、商品ID、商品名、価格、在庫数を管理すること D. 注文確定後、顧客にメールで注文確認を送信すること

例題2

要件定義プロセスにおける以下の作業のうち、業務要件定義に該当するものを選びなさい。

A. システムのレスポンスタイムを定義する B. システムで扱うデータ項目を定義する C. 業務処理手順を詳細化する D. システムの障害対応手順を定義する

例題3

次の記述のうち、セキュリティ要件に該当するものを選びなさい。

A. システムは、1日あたり最大10万件のトランザクション処理が可能であること B. パスワードは、英数字混在8文字以上で、90日ごとに変更を強制すること C. システムのバックアップは、毎日深夜に自動的に取得すること D. 既存システムからのデータ移行は、サービス開始の2週間前に実施すること

例題4

あるWebシステムの要件定義において、以下の記述のうち、周辺インタフェース要件に該当するものを選びなさい。

A. ユーザー認証は、社内の統合認証システムと連携して行うこと B. システムは、24時間365日の稼働に対応すること C. 画面表示は、日本語と英語の切り替えが可能であること D. データベースのバックアップは、1日1回取得すること

例題5

ECサイトの開発プロジェクトにおいて、以下の要件を適切な分類（業務要件、機能要件、非機能要件、情報・データ要件、周辺インタフェース要件、運用要件、移行要件、保守要件）に分類しなさい。

1. 商品の在庫数が5個未満になったら、自動的に発注処理を行うこと
2. システムは、クレジットカード決済代行サービスと連携すること
3. 顧客情報は、GDPR（EU一般データ保護規則）に準拠して管理すること
4. システムは、ピーク時（クリスマス時期）に1分間に1000人の同時アクセスに耐えること
5. 既存の顧客データベースから新システムへのデータ移行は、2週間以内に完了すること

5. まとめ

　要件定義は、システム開発の基盤となる重要なプロセスです。要件定義では以下の内容を明確化します。

1. 業務要件定義: システムが支援すべき業務内容や業務処理手順を定義
2. 機能要件定義: システムが提供すべき機能を定義
3. 非機能要件定義:
   • 性能要件: レスポンスタイム、スループットなど
   • セキュリティ要件: 認証・認可、暗号化など
   • 可用性・信頼性要件: 稼働率、障害対応など
4. 情報・データ要件: システムで扱うデータの定義
5. 周辺インタフェース要件: 他システムとの連携方法
6. 運用要件: システム運用に関する要件
7. 移行要件: 既存システムからの移行に関する要件
8. 保守要件: システム保守に関する要件

　要件定義は、システム開発の成否を左右する重要なプロセスです。十分な時間をかけて、ステークホルダーの要求を丁寧に聞き取り、曖昧さを排除した明確な要件を定義することが、成功するシステム開発の第一歩となります。

表2: 要件定義書サンプルテンプレート