1.はじめに
要件定義は、プロジェクトの成功に不可欠なステップになります。
要件定義の出来が、その後の基本設計から開発、テストそしてリリースまででのバグの発生や、プロジェクトの成功するか否かに影響を与えるので、非常に大事な工程となっています。
要件定義で行う要件収集は、システムがどのように動作するべきか、ユーザー(クライアント)が何を期待しているかを明確にするための重要なプロセスになります。
2. 要件収集の方法
要件定義で行う要件収集にはいくつか方法があり、大体のプロジェクトでは以下の内容を要件定義工程の中で全て行うことが多いです。
1. ヒアリング:
システムの関係者やエンドユーザーと直接対話し、彼らのニーズや期待を聞き出す方法です。
質問を準備し、具体的な要求を引き出すためのフォローアップ質問を行います。
また、エンドユーザーからの要望も取り込み、それが実現可能か否かなども要件定義の中で判断をしていき、両者の認識のすり合わせ、そして次の工程である基本設計に向けて設計不備が起こらないように要件定義書というものを作成し、ヒアリングの内容の取り込みなどを行なっていきます。
Webシステム系を例に出すと、画面の要件定義書に限って言えば、要件定義書には画面レイアウトであったり、その画面に存在する画面項目を網羅、初期表示ではどの内容を表示するのか、ボタン等がある場合は、ボタン押下時のイベントはどんなことが起こるのかなどを細かく記載していきます。
2. 文書分析:
既存のシステムやプロセスに関する文書を分析し、現行の要件や改善点を把握する方法です。
仕様書、業務マニュアル、報告書、現行システムなどがある場合はそのシステムのソースコードなどが対象になります。
主に、下記の流れで分析は行なっていきます。
• 収集: 既存の仕様書、業務マニュアル、報告書など関連する文書を収集します。
• 分析: 収集した文書を詳細に分析し、現行のシステムの要件や課題を把握します。
特に、システムの制約や既知の問題点を明らかにすることが重要です。
• 要約: 分析結果を要約し、新たな要件定義に反映させます。
必要に応じて、利害関係者との確認を行い、要件の妥当性を確認します。
筆者が経験した範囲では、現行システムからの更改のお仕事をした際に、現行ソースを一つずつ解析し、それを一旦設計書として落とし込んでから、エンドユーザーとそれを用いてシステム更改の内容を決めていくという流れで業務を行いました。
ソースを解析し、設計書に落とし込むことでシステム更改時に気をつけるべき点や、現行で不便なところなどが可視化できるので、このような作業は非常に重要になってきます。
2. 要件の分類とドキュメント化
• 機能要件と非機能要件の違い
機能要件:
機能要件は、システムが提供する具体的な機能やサービスを指します。
これには、ユーザーがシステムをどのように使用するか、システムがどのように動作するかに関する要件が含まれます。
• ユーザーインターフェース: ユーザーがどのようにシステムにアクセスし、操作するかの要件。
例として、ログイン画面、ダッシュボード、データ入力フォームなどがあります。
• データ処理: システムがどのようにデータを処理するかの要件。
例えば、データの収集、計算、フィルタリング、集計など。
• 出力: システムがどのように結果を出力するかの要件。
例として、レポートの生成、通知の送信、データエクスポートなどがあります。
• ビジネスロジック: 特定のビジネスルールに従った処理要件。
例えば、特定の条件下でのディスカウント計算、在庫管理のルールなど。
非機能要件:
非機能要件は、システムの性能、信頼性、拡張性、セキュリティ、使いやすさなど、システムの品質や特性に関する要件です。
• 性能: システムの応答時間、処理速度、スループットなど。
例として、「システムは1000件のトランザクションを1秒以内に処理する」など。
• 信頼性: システムの可用性、フォールトトレランス、リカバリ機能。
例として、「システムの稼働時間は99.9%であること」や「障害発生時には自動的に復旧する」など。
• 拡張性: システムが将来的にどの程度拡張可能であるか。
例として、「新しい機能を追加する際にシステムの再設計が不要である」など。
• セキュリティ: データ保護、認証、アクセス制御など。
例として、「全てのユーザーは強力なパスワードで認証される」や「データは暗号化されて保存される」など。
• 使いやすさ: ユーザーがシステムをどの程度簡単に使用できるか。
例として、「システムは直感的なインターフェースを提供する」や「ユーザーマニュアルを提供する」など。
• 要件定義書の作成方法
1. 概要の記載
概要の記載は、要件仕様書の冒頭部分であり、プロジェクトの目的や範囲、背景情報、前提条件などを明確にするためのセクションです。この部分がしっかりと記載されていることで、利害関係者全員がプロジェクトの全体像を理解しやすくなります。
• プロジェクトの目的と範囲
プロジェクトの目的:
プロジェクトの目的は、プロジェクトが達成しようとしている最終的な目標を明確に記載します。この部分では、システムが解決しようとしている問題や、提供する価値について具体的に説明します。
• 例:
• 新しい顧客管理システムの導入により、顧客情報の一元管理とアクセスの迅速化を図る。
• 現行の在庫管理システムの効率を向上させ、在庫精度を高め、コスト削減を実現する。
プロジェクトの範囲:
プロジェクトの範囲は、プロジェクトがカバーする機能やサービス、そしてプロジェクトの実施範囲を具体的に定義します。これにより、プロジェクトの範囲外の項目が明確になり、要件の追加や変更の管理が容易になります。
• 例:
• 本プロジェクトは、顧客データの収集、管理、検索、分析機能を含み、顧客へのメール送信機能や外部システムとの連携は含まない。
• 新しい在庫管理システムは、倉庫内の全ての在庫アイテムの追跡を対象とし、サプライチェーン管理システムとの統合は含まない。
• 背景情報と前提条件
背景情報:
背景情報は、プロジェクトが開始された理由や背景にある状況を説明します。この情報は、プロジェクトの必要性や重要性を理解するのに役立ちます。
• 例:
• 現在の顧客管理システムは、手動でのデータ入力が多く、エラーが頻発しているため、新しいシステムの導入が必要とされている。
• 既存の在庫管理システムは、古くなり保守が困難であり、新しい技術を使用したシステムへの移行が求められている。
前提条件:
前提条件は、プロジェクトの実施において既に決定されている事項や、システム設計の基盤となる条件を記載します。これには、利用する技術やシステム、外部の依存関係などが含まれます。
• 例:
• 新しいシステムは、現行のデータベース管理システム（Oracle Database）を引き続き使用する。
• プロジェクトは、既存のネットワークインフラを使用し、新しいハードウェアの導入は含まない。
• システムのユーザーは、現在の従業員300名を想定して設計される。
具体例
以下に、具体的な概要の記載例を示します。
プロジェクト概要
プロジェクト名: 顧客管理システム導入プロジェクト
目的:
顧客情報の一元管理とアクセスの迅速化を図り、顧客対応の効率を向上させること。
範囲:
本プロジェクトは、顧客データの収集、管理、検索、分析機能を含む。顧客へのメール送信機能や外部システムとの連携は含まない。
背景情報:
現在の顧客管理システムは、手動でのデータ入力が多く、エラーが頻発している。これにより、顧客対応に時間がかかり、顧客満足度が低下している。
前提条件:
新しいシステムは、現行のデータベース管理システム（Oracle Database）を引き続き使用する。また、システムのユーザーは、現在の従業員300名を想定して設計される。
2. 機能要件の記載
機能要件は、システムが提供する具体的な機能やサービスを詳細に記載する部分です。各機能の詳細な説明、ユーザーシナリオやユースケース、入力と出力の仕様を明確にすることで、システム開発の指針となり、期待通りのシステムを構築するための基盤を提供します。
• 各機能の詳細な説明
各機能の詳細な説明は、システムが提供する具体的な機能や操作を明確にするために記載します。以下に、機能の詳細な説明の例を示します。
1. ログイン機能
• 説明: ユーザーがシステムにアクセスするために使用する認証機能。ユーザー名とパスワードの入力により、認証が行われる。
• 具体例:
• ユーザー名とパスワードの入力フィールド
• 「ログイン」ボタン
• 認証成功時はユーザーダッシュボードへリダイレクト
• 認証失敗時はエラーメッセージを表示
2. データ入力機能
• 説明: ユーザーがデータを入力し、システムに保存するための機能。
• 具体例:
• データ入力フォーム（テキストフィールド、ドロップダウンメニュー、チェックボックスなど）
• 「保存」ボタン
• 入力データのバリデーション
• データ保存成功時の確認メッセージ
3. レポート生成機能
• 説明: ユーザーが特定の条件に基づいてレポートを生成する機能。
• 具体例:
• レポート生成のためのフィルタ設定（期間、カテゴリなど）
• 「レポート生成」ボタン
• 生成されたレポートの表示およびエクスポート（PDF、Excel）
• ユーザーシナリオやユースケース
ユーザーシナリオやユースケースは、システムの機能を実際にどのように使用するかを具体的に示すものです。これにより、利害関係者はシステムの使い方を直感的に理解できます。
ユーザーシナリオの例:
• シナリオ1: 新規ユーザーの登録
• 背景: 新しいユーザーがシステムを使用するためにアカウントを作成する必要がある。
• ステップ:
1. ユーザーは「新規登録」ページにアクセスする。
2. 必要な情報（名前、メールアドレス、パスワード）を入力する。
3. 「登録」ボタンをクリックする。
4. システムは入力情報をバリデートし、アカウントを作成する。
5. 登録完了メッセージを表示し、ユーザーをログインページにリダイレクトする。
ユースケースの例:
• ユースケース1: 顧客情報の検索
• アクター: 営業担当者
• 前提条件: 営業担当者はシステムにログインしている。
• ステップ:
1. 営業担当者は「顧客検索」ページにアクセスする。
2. 顧客名または顧客IDを入力する。
3. 「検索」ボタンをクリックする。
4. システムは入力された情報に基づいて顧客データベースを検索する。
5. 該当する顧客情報を表示する。
• 結果: 営業担当者は顧客の詳細情報を確認できる。
• 入力と出力の仕様
入力と出力の仕様は、システムの各機能がどのようなデータを受け取り、どのようなデータを生成するかを明確にするために記載します。
入力の仕様:
• ログイン機能:
• 入力:
• ユーザー名（テキスト）
• パスワード（テキスト、マスク表示）
• バリデーション:
• ユーザー名：必須項目、最大50文字
• パスワード：必須項目、最小8文字、英数字混在
• データ入力機能:
• 入力:
• フィールド1（テキスト、最大100文字）
• フィールド2（選択肢、ドロップダウンメニュー）
• フィールド3（日付、カレンダー入力）
出力の仕様:
• ログイン機能:
• 出力:
• 認証成功時：ユーザーダッシュボードへのリダイレクト
• 認証失敗時：エラーメッセージ（「ユーザー名またはパスワードが正しくありません」）
• レポート生成機能:
• 出力:
• 生成されたレポート（PDF、Excel）
• レポート生成の成功メッセージ（「レポートが正常に生成されました」）
3. 非機能要件の記載
非機能要件は、システムの性能、信頼性、セキュリティ、拡張性、使いやすさなど、システムの品質や特性に関する要件を定義します。これらの要件は、システムの全体的なユーザーエクスペリエンスや信頼性に大きな影響を与えます。
• 性能要件（応答時間、スループットなど）
性能要件は、システムの動作速度や処理能力に関する要件です。
• 応答時間:
• システムの各機能に対して、ユーザーの操作に応答するまでの時間を定義します。
• 例: 「ログインページの応答時間は2秒以内にする」「検索結果の表示は1秒以内に行う」
• スループット:
• システムが一定時間内に処理できる作業量を定義します。
• 例: 「システムは1分間に1000件のトランザクションを処理できること」「同時接続ユーザー数は1000人まで対応可能とする」
• 信頼性要件（可用性、バックアップ、リカバリ）
信頼性要件は、システムの安定性と可用性に関する要件です。
• 可用性:
• システムが一定期間内に利用可能であることを定義します。
• 例: 「システムの稼働時間は99.9%を維持する」「システムのダウンタイムは年間8時間未満とする」
• バックアップ:
• システムのデータを定期的にバックアップする方法を定義します。
• 例: 「全データのバックアップは毎日夜間に実行する」「バックアップデータは3世代分保存する」
• リカバリ:
• 障害発生時にシステムを復旧する方法を定義します。
• 例: 「障害発生から1時間以内にシステムを復旧させる」「データ損失が発生した場合、直近のバックアップから復元する」
• セキュリティ要件（認証、権限管理、データ保護）
セキュリティ要件は、システムの保護とデータの安全性に関する要件です。
• 認証:
• システムにアクセスするユーザーの本人確認方法を定義します。
• 例: 「ユーザーはIDとパスワードによる認証を受ける」「二要素認証を導入する」
• 権限管理:
• システム内の各ユーザーに対してアクセス可能な範囲を制御します。
• 例: 「管理者は全機能にアクセスできるが、一般ユーザーは自身のデータのみアクセス可能」「権限はロールベースで管理する」
• データ保護:
• データの暗号化や保護方法を定義します。
• 例: 「すべての通信データはSSL/TLSで暗号化する」「データベースの機密情報は暗号化して保存する」
• 拡張性要件（将来の拡張性、モジュール化）
拡張性要件は、システムが将来的にどの程度容易に拡張できるかに関する要件です。
• 将来の拡張性:
• システムが新しい機能や増加するユーザー数に対応できることを定義します。
• 例: 「システムは将来のユーザー増加に対応できるよう設計する」「新しいモジュールや機能を追加しやすいアーキテクチャを採用する」
• モジュール化:
• システムを独立したモジュールとして設計し、各モジュールが容易に追加・変更可能であることを定義します。
• 例: 「各機能は独立したモジュールとして実装し、インターフェースを公開する」「モジュール間の依存関係を最小限に抑える」
• 使いやすさ要件（ユーザビリティ、ドキュメンテーション）
使いやすさ要件は、ユーザーがシステムをどの程度簡単に使用できるかに関する要件です。
• ユーザビリティ:
• システムの操作性や直感的な使用感を定義します。
• 例: 「ユーザーインターフェースは直感的で分かりやすいデザインとする」「重要な機能は3クリック以内でアクセス可能とする」
• ドキュメンテーション:
• ユーザー向けのマニュアルやヘルプ機能を定義します。
• 例: 「ユーザーマニュアルをオンラインで提供し、定期的に更新する」「システム内にコンテキストヘルプを実装する」
4. 制約条件と前提条件の記載
制約条件と前提条件の記載は、システム設計や実装において重要な役割を果たします。これらを明確にすることで、プロジェクトの範囲や実現可能性についての共通理解を得ることができます。
• システム設計や実装に影響を与える制約
制約条件は、システムの設計や実装において制限される要因や条件を指します。これには、技術的、予算的、時間的、法的な制約が含まれます。
1. 技術的制約:
• 使用する技術の選定:
• 例: 「システムはJavaで開発する」「データベースはPostgreSQLを使用する」
• 互換性:
• 例: 「既存のシステムと互換性があること」「特定のハードウェア上で動作すること」
2. 予算的制約:
• プロジェクトの予算:
• 例: 「プロジェクトの総予算は1000万円以内とする」「追加のハードウェア購入費用は予算に含まれない」
3. 時間的制約:
• プロジェクトのスケジュール:
• 例: 「プロジェクトは6ヶ月以内に完了する」「開発フェーズは3ヶ月以内に完了する」
4. 法的・規制的制約:
• 法的要件:
• 例: 「システムはGDPRに準拠すること」「データ保護法に従って設計されること」
• 業界規制:
• 例: 「医療情報システムはHIPAAに準拠すること」
• 前提条件と依存関係
前提条件は、プロジェクトの実施にあたって既に決定されている条件や、システム設計の基盤となる要素を指します。依存関係は、プロジェクトが他のシステム、プロジェクト、または外部要因に依存する要素です。
1. 前提条件:
• 既存のインフラ:
• 例: 「現行のネットワークインフラを使用する」「既存のデータベース管理システム（Oracle Database）を継続使用する」
• 利用者:
• 例: 「システムのユーザーは現在の従業員300名を想定する」「ユーザーは基本的なITスキルを持っている」
• システムの動作環境:
• 例: 「システムはWindowsとLinux環境で動作する」「ウェブブラウザは最新のバージョンを使用する」
2. 依存関係:
• 他のプロジェクト:
• 例: 「新しいCRMシステムが導入されることが前提となる」「サプライチェーン管理システムのアップデートと連携する」
• 外部システム:
• 例: 「システムは外部の決済ゲートウェイと連携する」「APIを通じて第三者サービスとデータを交換する」
• 外部要因:
• 例: 「法改正に伴うシステムの変更が必要となる」「クラウドサービスの提供状況に依存する」
具体例
以下に、制約条件と前提条件の具体的な記載例を示します。
制約条件
1. 技術的制約
• システムはJavaで開発し、データベースはPostgreSQLを使用する。
• 既存の顧客管理システムと互換性を保つこと。
2. 予算的制約
• プロジェクトの総予算は1000万円以内とする。
• 追加のハードウェア購入費用は予算に含まれない。
3. 時間的制約
• プロジェクトは6ヶ月以内に完了する。
• 開発フェーズは3ヶ月以内に完了する。
4. 法的・規制的制約
• システムはGDPRに準拠すること。
• 医療情報システムはHIPAAに準拠すること。
前提条件と依存関係
1. 前提条件
• 現行のネットワークインフラを使用する。
• 既存のデータベース管理システム（Oracle Database）を継続使用する。
• システムのユーザーは現在の従業員300名を想定する。
2. 依存関係
• 新しいCRMシステムが導入されることが前提となる。
• システムは外部の決済ゲートウェイと連携する。
• 法改正に伴うシステムの変更が必要となる。
5. 承認とレビューのプロセス
要件仕様書のレビューと承認プロセス、および変更管理のプロセスは、システム開発の品質と精度を確保するために重要なステップです。これにより、全ての利害関係者が要件に合意し、プロジェクトの進行中に発生する変更を適切に管理することができます。
• 要件仕様書のレビューと承認手順
要件仕様書のレビューと承認手順は、文書が正確で完全であることを確認するためのステップです。以下に、一般的な手順を示します。
1. 初期ドラフトの作成:
• 要件収集後、ビジネスアナリストやプロジェクトマネージャーが要件仕様書の初期ドラフトを作成します。
2. 内部レビュー:
• 開発チーム、テストチーム、セキュリティチームなど、プロジェクトに関わる内部メンバーが要件仕様書をレビューします。
• 各チームは、自分たちの視点から要件を確認し、問題点や改善点をフィードバックします。
3. 利害関係者レビュー:
• 内部レビュー後、主要な利害関係者（プロジェクトスポンサー、システムユーザー、法務部門など）に要件仕様書を共有し、レビューを依頼します。
• 利害関係者は、要件が自分たちの期待やニーズに合致しているかを確認し、フィードバックを提供します。
4. フィードバックの収集と統合:
• すべてのフィードバックを収集し、必要な修正や変更を要件仕様書に反映します。
• ビジネスアナリストやプロジェクトマネージャーは、フィードバックを統合し、最終ドラフトを作成します。
5. 最終承認:
• 最終ドラフトを再度利害関係者に提示し、正式な承認を得ます。
• 承認は、サインオフや電子的な承認（例：電子メール、ドキュメント管理システム）を通じて行います。
6. ドキュメントの保存と共有:
• 承認された要件仕様書は、ドキュメント管理システムやプロジェクト共有フォルダに保存し、関係者全員にアクセス可能な状態にします。
• 変更管理のプロセス
プロジェクトの進行中に要件の変更が必要になる場合があります。変更管理のプロセスは、これらの変更を適切に評価、承認、実装するための手順を定義します。
1. 変更リクエストの提出:
• 変更が必要な場合、変更リクエスト（Change Request）を提出します。変更リクエストには、変更の理由、影響範囲、優先度などを記載します。
2. 変更リクエストの評価:
• 変更管理委員会（Change Control Board, CCB）またはプロジェクトマネージャーが、提出された変更リクエストを評価します。
• 評価項目には、変更の必要性、影響範囲、リスク、コスト、スケジュールへの影響などが含まれます。
3. 影響分析:
• 変更がシステムやプロジェクトに与える影響を詳細に分析します。これには、技術的な影響、コスト増加、スケジュールの遅延などが含まれます。
4. 承認または却下:
• 変更リクエストを承認するか却下するかを決定します。承認された場合は、変更の優先順位と実施スケジュールを決定します。
• 承認は、CCBまたはプロジェクトスポンサーが行います。
5. 変更の実施:
• 承認された変更は、開発チームや関連する担当者によって実施されます。
• 変更の実施状況は、プロジェクトマネージャーが監視し、進捗を報告します。
6. 変更後のレビューと検証:
• 変更が実施された後、システム全体に対する影響を再評価し、変更が意図した通りに機能しているかを検証します。
• 必要に応じて、追加のテストや品質保証プロセスを実施します。
7. ドキュメントの更新:
• 変更が反映された要件仕様書や関連ドキュメントを更新し、最新の情報を利害関係者と共有します。
• 変更履歴を管理し、将来の参照用に記録します。
具体例
以下に、要件仕様書のレビューと承認手順、および変更管理のプロセスの具体的な記載例を示します。
要件仕様書のレビューと承認手順
1. 初期ドラフトの作成:
• 要件収集後、ビジネスアナリストが要件仕様書の初期ドラフトを作成する。
2. 内部レビュー:
• 開発チーム、テストチーム、セキュリティチームが要件仕様書をレビューし、フィードバックを提供する。
3. 利害関係者レビュー:
• プロジェクトスポンサー、システムユーザー、法務部門が要件仕様書をレビューし、フィードバックを提供する。
4. フィードバックの収集と統合:
• 収集したフィードバックを統合し、ビジネスアナリストが最終ドラフトを作成する。
5. 最終承認:
• 最終ドラフトを利害関係者に提示し、正式な承認を得る。
6. ドキュメントの保存と共有:
• 承認された要件仕様書をドキュメント管理システムに保存し、関係者全員にアクセス可能とする。
変更管理のプロセス
1. 変更リクエストの提出:
• 変更が必要な場合、変更リクエストを提出する（例：変更リクエストフォームを使用）。
2. 変更リクエストの評価:
• 変更管理委員会が提出された変更リクエストを評価する。
3. 影響分析:
• 変更の影響を詳細に分析する。
4. 承認または却下:
• 変更リクエストを承認または却下する。
5. 変更の実施:
• 承認された変更を開発チームが実施する。
6. 変更後のレビューと検証:
• 変更後、システム全体に対する影響を再評価し、変更が意図した通りに機能しているかを検証する。
7. ドキュメントの更新:
• 変更が反映された要件仕様書や関連ドキュメントを更新し、最新の情報を共有する。
要件のドキュメント化のポイント
• 一貫性と明確さ: 用語やフォーマットを統一し、全ての要件が一貫して明確に記述されていること。
• 完全性: 全ての必要な要件が網羅されていること。漏れがないようにチェックリストを活用することも有効です。
• 可追跡性: 要件の出典や理由を明確にし、要件がどのようにして導き出されたかを追跡できるようにすること。
• レビューとフィードバック: 要件仕様書は利害関係者と共有し、フィードバックを受けることで、より正確で完全な要件を確立することができます。
これにより、要件定義のプロセスが効率化され、システムの設計と開発がスムーズに進行することが期待できます。
