1.7. ソフトウェア要件の評価及びレビュー

1. 概要

 ソフトウェア開発プロジェクトの成功には、適切なソフトウェア要件の定義と評価が不可欠です。ソフトウェア要件の評価及びレビューは、決定したソフトウェア要件がシステム要件に合致しているか、実現可能かを確認するプロセスです。このプロセスを通じてプロジェクトの方向性を確立し、後続の開発フェーズでの問題を未然に防ぐことができます。

2. 詳細説明

2.1. ソフトウェア要件の評価基準

 ソフトウェア要件を評価する際に考慮すべき基準は、以下の通りです:

2.1.1. 双方向の追跡可能性(双方向のトレーサビリティ)

 各ソフトウェア要件が、上位のシステム要件と下位の設計要素に追跡できることを確認します。これにより、要件の漏れや矛盾を防ぎます。また、変更管理時にも関連する要件を特定し、影響範囲を把握することが容易になります。例えば、ある機能要件が変更された際に、その影響を受ける他の機能やテストケースを迅速に特定することができます。

graph TD
    A[システム要件] <--> B[ソフトウェア要件]
    B <--> C[設計要素]
    B <--> D[テストケース]
    
    style A fill:#f9d5e5,stroke:#333,stroke-width:2px
    style B fill:#eeac99,stroke:#333,stroke-width:2px
    style C fill:#e06377,stroke:#333,stroke-width:2px
    style D fill:#c83349,stroke:#333,stroke-width:2px
    
    classDef default fill:#f9f,stroke:#333,stroke-width:2px;

 この図は、ソフトウェア開発における追跡可能性の関係を示しています。主要な要素と、それらの間の双方向の関連性を以下のように表現しています:

  1. システム要件
  2. ソフトウェア要件
  3. 設計要素
  4. テストケース

図の説明:

  1. システム要件とソフトウェア要件の関係: システム要件は、ソフトウェア要件に詳細化されます。逆に、各ソフトウェア要件は、対応するシステム要件に遡ることができます。
  2. ソフトウェア要件と設計要素の関係: ソフトウェア要件は、具体的な設計要素として実装されます。各設計要素は、それが満たすソフトウェア要件に遡ることができます。
  3. ソフトウェア要件とテストケースの関係: 各ソフトウェア要件に対して、それを検証するためのテストケースが作成されます。各テストケースは、検証対象のソフトウェア要件に紐づいています。

 この双方向の追跡可能性により、以下のような利点が得られます:

  • 要件の漏れや重複の発見が容易になります。
  • 変更の影響範囲を正確に把握できます。
  • テストの網羅性を確認しやすくなります。
  • プロジェクト全体の一貫性と品質を向上させることができます。

 この図を参照しながら、ソフトウェア要件の評価やレビューを行うことで、より効果的に追跡可能性を確保し、高品質なソフトウェア開発を実現することができます。

2.1.2. 外部一貫性

 ソフトウェア要件がシステム要件や外部インターフェース仕様と矛盾していないかを確認します。例えば、システムのAPI仕様が変更された場合、ソフトウェア要件も適宜修正される必要があります【図・表:外部インターフェースと要件の関連】。

2.1.3. 内部一貫性

 ソフトウェア要件間で矛盾がないかを確認します。要件間に矛盾が生じると、開発中や運用中にバグやパフォーマンスの問題が発生するリスクがあります。たとえば、セキュリティ要件がパフォーマンス要件と矛盾している場合、双方のバランスを取るための調整が必要です。

flowchart TD
    A[要件リストの作成] --> B[要件の分類]
    B --> C{矛盾の可能性がある\n要件ペアの特定}
    C --> |Yes| D[詳細分析]
    C --> |No| E[次の要件ペアへ]
    D --> F{矛盾が確認されたか?}
    F --> |Yes| G[矛盾の解決]
    F --> |No| E
    G --> H[要件の更新]
    E --> I{すべての要件ペアを\n確認したか?}
    I --> |Yes| J[内部一貫性レポートの作成]
    I --> |No| C
    H --> C

    style A fill:#f9d5e5,stroke:#333,stroke-width:2px
    style B fill:#eeac99,stroke:#333,stroke-width:2px
    style C fill:#e06377,stroke:#333,stroke-width:2px
    style D fill:#c83349,stroke:#333,stroke-width:2px
    style E fill:#f9d5e5,stroke:#333,stroke-width:2px
    style F fill:#e06377,stroke:#333,stroke-width:2px
    style G fill:#c83349,stroke:#333,stroke-width:2px
    style H fill:#eeac99,stroke:#333,stroke-width:2px
    style I fill:#e06377,stroke:#333,stroke-width:2px
    style J fill:#f9d5e5,stroke:#333,stroke-width:2px

    classDef default fill:#f9f,stroke:#333,stroke-width:2px;

 この図は、内部要件の矛盾を検出するプロセスを示しています。各ステップの説明は以下の通りです:

  1. 要件リストの作成: すべてのソフトウェア要件をリストアップします。
  2. 要件の分類: 要件を機能別、モジュール別などで分類し、関連する要件グループを作成します。
  3. 矛盾の可能性がある要件ペアの特定: 分類された要件グループ内で、潜在的に矛盾する可能性のある要件ペアを特定します。
  4. 詳細分析: 特定された要件ペアについて、詳細な分析を行います。
  5. 矛盾の確認: 詳細分析の結果、実際に矛盾が確認されたかどうかを判断します。
  6. 矛盾の解決: 矛盾が確認された場合、関係者と協議して矛盾を解決します。
  7. 要件の更新: 矛盾解決の結果に基づいて、該当する要件を更新します。
  8. 次の要件ペアへ: 矛盾が確認されなかった場合、または解決後に次の要件ペアの確認に進みます。
  9. すべての要件ペアの確認: すべての要件ペアについて上記のプロセスを繰り返し、確認が完了したかどうかを判断します。
  10. 内部一貫性レポートの作成: すべての確認が完了したら、内部一貫性に関するレポートを作成します。

 このプロセスを通じて、ソフトウェア要件の内部一貫性を系統的に確認し、矛盾を検出・解決することができます。これにより、要件定義の品質が向上し、後続の開発フェーズでの問題を未然に防ぐことができます。

2.1.4. テスト可能性

 各要件が具体的で測定可能であり、テストによって検証できることを確認します。テスト可能な要件には、具体的な入力、出力、期待される動作が明示されている必要があります。これにより、テストケースを効果的に設計し、検証が可能となります。

graph TD
    A[テスト可能性の評価基準]
    A --> B[明確性]
    A --> C[測定可能性]
    A --> D[一貫性]
    A --> E[完全性]
    A --> F[実現可能性]

    B --> B1["例: ログイン画面は3秒以内に表示されること"]
    C --> C1["例: システムは1時間あたり1000件のトランザクションを処理できること"]
    D --> D1["例: すべてのエラーメッセージは英語と日本語で表示されること"]
    E --> E1["例: ユーザー登録機能には、入力、確認、完了の全ステップが含まれていること"]
    F --> F1["例: データベースのバックアップは1時間以内に完了すること"]

    style A fill:#f9d5e5,stroke:#333,stroke-width:2px
    style B fill:#eeac99,stroke:#333,stroke-width:2px
    style C fill:#e06377,stroke:#333,stroke-width:2px
    style D fill:#c83349,stroke:#333,stroke-width:2px
    style E fill:#5b9aa0,stroke:#333,stroke-width:2px
    style F fill:#d6d4e0,stroke:#333,stroke-width:2px
    
    classDef example fill:#f8f9fa,stroke:#333,stroke-width:1px;
    class B1,C1,D1,E1,F1 example;

 この図は、ソフトウェア要件のテスト可能性を評価する際の主要な基準と、それぞれの基準に対する具体例を示しています。各評価基準と例の説明は以下の通りです:

  1. 明確性: 要件が曖昧さなく明確に記述されていること。 例:「ログイン画面は3秒以内に表示されること」
    • この例は、具体的な時間制限を指定しており、テストで明確に検証できます。
  2. 測定可能性: 要件が定量的に測定可能であること。 例:「システムは1時間あたり1000件のトランザクションを処理できること」
    • この例は、具体的な数値目標を設定しており、性能テストで測定可能です。
  3. 一貫性: 要件が他の要件と矛盾せず、一貫していること。 例:「すべてのエラーメッセージは英語と日本語で表示されること」
    • この例は、システム全体で一貫したエラーメッセージの表示方法を指定しており、テストで確認できます。
  4. 完全性: 要件が必要なすべての情報を含んでいること。 例:「ユーザー登録機能には、入力、確認、完了の全ステップが含まれていること」
    • この例は、機能の全ステップを明記しており、テストで各ステップの存在を確認できます。
  5. 実現可能性: 要件が技術的および運用的に実現可能であること。 例:「データベースのバックアップは1時間以内に完了すること」
    • この例は、具体的な時間制限を設定しており、実際の環境でテスト可能です。

 これらの評価基準と例を参考にすることで、ソフトウェア要件のテスト可能性を向上させることができます。テスト可能な要件を定義することで、以下のような利点があります:

  • テストの設計と実行が容易になります。
  • 要件の検証が明確になり、品質の向上につながります。
  • 開発チームと品質保証チーム間のコミュニケーションが改善されます。
  • プロジェクトの進捗状況を客観的に評価しやすくなります。

 この図を活用して、ソフトウェア要件の定義時にテスト可能性を意識し、より品質の高い要件定義を行うことができます。

2.1.5. ソフトウェアシステムの実現可能性

 技術的、予算的、スケジュール的な観点から、ソフトウェアシステムが実現可能であるかを確認します。要件が過度に複雑であったり、リソースが不足している場合、システム全体の品質や納期に影響が出る可能性があります。

2.1.6. 運用及び保守の実現可能性

 開発後のシステム運用や保守が実行可能であるかを確認します。特に、将来的な拡張や更新を考慮して、保守性を高める設計が求められます。例えば、ログ出力やモニタリング機能が運用の実効性に直結するため、これらの要件も適切に定義される必要があります。

2.2. ソフトウェア要件定義書のレビュー

2.2.1. レビュー参加者

 システムの取得者(顧客)と供給者(開発チーム)が共同でレビューを行います。必要に応じて、エンドユーザーや専門家も参加することが推奨されます。これにより、多角的な視点から要件を評価でき、実務的な運用やユーザー目線での改善が図られます。

2.2.2. レビュー方式

 ソフトウェア要件のレビュー方式には以下があります:

  • ウォークスルー:要件を順番に確認していく方法。軽微な修正が必要な際に有効です。
  • インスペクション:厳格な手順に従って詳細にチェックする方法。問題の重大さに応じて、修正計画を立案します。
  • テクニカルレビュー:技術的な観点から要件を評価する方法。特に技術的な実現可能性やリスクを評価する際に用います。
特徴ウォークスルーインスペクションテクニカルレビュー
目的要件の理解促進と問題点の発見欠陥の体系的な検出と品質向上技術的な観点からの妥当性確認
形式性比較的非公式高度に形式的やや形式的
準備の程度軽度綿密中程度
参加者開発者、ステークホルダー開発者、専門のインスペクター技術専門家、開発者
所要時間短~中長い中程度
文書化の程度低~中高い中程度
欠陥検出の効率中程度高い中~高
主な成果物議事録、問題点リスト詳細な欠陥リスト、改善提案技術的評価レポート
適用タイミング開発の早期段階各フェーズの終了時技術的な決定が必要な時点
教育効果高い中程度高い

 この比較表は、ソフトウェア要件定義におけるレビュー方式を比較しています。各レビュー方式の特徴と適用場面について、以下に詳しく説明いたします:

  1. ウォークスルー
    • 比較的非公式で柔軟性が高い方式です。
    • 主に要件の理解促進と問題点の発見を目的としています。
    • 準備は軽度で、短時間で実施できるため、開発の早期段階で頻繁に利用できます。
    • 参加者間のコミュニケーションを促進し、教育効果が高いのが特徴です。
  2. インスペクション
    • 高度に形式的で、綿密な準備を必要とする方式です。
    • 主に欠陥の体系的な検出と品質向上を目的としています。
    • 専門のインスペクターが参加し、詳細な欠陥リストと改善提案を作成します。
    • 欠陥検出の効率が高く、各開発フェーズの終了時に適しています。
  3. テクニカルレビュー
    • やや形式的で、技術的な観点からの妥当性確認を目的としています。
    • 技術専門家が参加し、技術的な評価レポートを作成します。
    • 準備と所要時間は中程度で、技術的な決定が必要な時点で実施します。
    • 技術的な知識の共有や議論を通じて、高い教育効果が期待できます。

 これらのレビュー方式は、プロジェクトの状況や目的に応じて適切に選択・組み合わせることが重要です。例えば:

  • プロジェクトの初期段階では、要件の理解促進のためにウォークスルーを頻繁に行い、
  • 重要なマイルストーン時にはインスペクションを実施して品質を確保し、
  • 技術的に複雑な部分についてはテクニカルレビューを行う

といった組み合わせが考えられます。

 この比較表を参考にしながら、プロジェクトの特性や段階に応じて適切なレビュー方式を選択することで、効果的なソフトウェア要件の評価とレビューを実施することができます。

3. 応用例

3.1. 金融システム開発での適用

 銀行のオンラインバンキングシステム開発において、セキュリティ要件の評価とレビューを行います。この際、双方向の追跡可能性を確保し、セキュリティポリシーとの外部一貫性を確認します。また、内部一貫性とテスト可能性を重視し、具体的なセキュリティテストシナリオを策定することで、要件が実際に満たされているかを検証します。

graph TD
    A[システム要件: セキュアなオンラインバンキング]
    B[ソフトウェア要件: データ暗号化]
    C[ソフトウェア要件: 多要素認証]
    D[ソフトウェア要件: アクセス制御]
    E[設計要素: AES暗号化アルゴリズム]
    F[設計要素: OTP生成モジュール]
    G[設計要素: RBAC実装]
    H[テストケース: 暗号化強度テスト]
    I[テストケース: 多要素認証バイパステスト]
    J[テストケース: 権限別アクセステスト]

    A --> B
    A --> C
    A --> D
    B --> E
    C --> F
    D --> G
    B --> H
    C --> I
    D --> J

    classDef systemReq fill:#f9d5e5,stroke:#333,stroke-width:2px;
    classDef softwareReq fill:#eeac99,stroke:#333,stroke-width:2px;
    classDef designElement fill:#e06377,stroke:#333,stroke-width:2px;
    classDef testCase fill:#c83349,stroke:#333,stroke-width:2px;

    class A systemReq;
    class B,C,D softwareReq;
    class E,F,G designElement;
    class H,I,J testCase;

 この図は、金融システム開発、特にオンラインバンキングシステムにおけるセキュリティ要件の追跡可能性を示しています。図の要素と関係性について説明します:

  1. システム要件:
    • 「セキュアなオンラインバンキング」という上位レベルのシステム要件が設定されています。
  2. ソフトウェア要件: システム要件から以下の3つのソフトウェア要件が導出されています。
    • データ暗号化
    • 多要素認証
    • アクセス制御
  3. 設計要素: 各ソフトウェア要件に対応する具体的な設計要素が定義されています。
    • データ暗号化 → AES暗号化アルゴリズム
    • 多要素認証 → OTP(ワンタイムパスワード)生成モジュール
    • アクセス制御 → RBAC(ロールベースアクセス制御)実装
  4. テストケース: 各ソフトウェア要件を検証するためのテストケースが作成されています。
    • データ暗号化 → 暗号化強度テスト
    • 多要素認証 → 多要素認証バイパステスト
    • アクセス制御 → 権限別アクセステスト

 この図が示す追跡可能性の利点は以下の通りです:

  1. 要件の網羅性確認: システム要件からソフトウェア要件、設計要素、テストケースまで一貫して追跡できるため、セキュリティ要件の漏れを防ぐことができます。
  2. 影響分析の容易化: 例えば、暗号化アルゴリズムの変更が必要になった場合、関連するソフトウェア要件やテストケースを容易に特定できます。
  3. テストの充実化: 各ソフトウェア要件に対応するテストケースが明確になるため、セキュリティテストの網羅性を高めることができます。
  4. コンプライアンスの証明: 金融規制当局への報告や監査において、セキュリティ要件の実装と検証の過程を明確に示すことができます。
  5. チーム間コミュニケーションの改善: 開発者、テスター、セキュリティ専門家など、異なる役割の人々が共通の参照点を持つことができます。

 この追跡可能性の図を活用することで、金融システム開発におけるセキュリティ要件の管理を効果的に行い、高品質で安全なオンラインバンキングシステムの開発を支援することができます。

3.2. 医療システムでの実践

 電子カルテシステムの開発では、患者データの保護と可用性のバランスが重要です。ソフトウェア要件の評価では、法令遵守や保守性、運用の実現可能性を特に確認します。また、レビューには医療従事者を含め、実務的な視点での要件確認が行われます。

flowchart TD
    A[運用開始] --> B[日常的な監視]
    B --> C{問題発生?}
    C -->|Yes| D[問題の分析]
    C -->|No| B
    D --> E[対応策の策定]
    E --> F[変更の実施]
    F --> G[変更の検証]
    G --> H{検証OK?}
    H -->|Yes| I[本番環境への適用]
    H -->|No| E
    I --> J[ユーザーへの通知]
    J --> K[運用マニュアルの更新]
    K --> L[定期的な評価]
    L --> M{改善の必要性?}
    M -->|Yes| N[改善計画の立案]
    M -->|No| B
    N --> O[大規模更新の実施]
    O --> P[新バージョンの運用開始]
    P --> B

    style A fill:#f9d5e5,stroke:#333,stroke-width:2px
    style B fill:#eeac99,stroke:#333,stroke-width:2px
    style C fill:#e06377,stroke:#333,stroke-width:2px
    style D fill:#c83349,stroke:#333,stroke-width:2px
    style E fill:#f9d5e5,stroke:#333,stroke-width:2px
    style F fill:#eeac99,stroke:#333,stroke-width:2px
    style G fill:#e06377,stroke:#333,stroke-width:2px
    style H fill:#c83349,stroke:#333,stroke-width:2px
    style I fill:#f9d5e5,stroke:#333,stroke-width:2px
    style J fill:#eeac99,stroke:#333,stroke-width:2px
    style K fill:#e06377,stroke:#333,stroke-width:2px
    style L fill:#c83349,stroke:#333,stroke-width:2px
    style M fill:#f9d5e5,stroke:#333,stroke-width:2px
    style N fill:#eeac99,stroke:#333,stroke-width:2px
    style O fill:#e06377,stroke:#333,stroke-width:2px
    style P fill:#c83349,stroke:#333,stroke-width:2px

    classDef default fill:#f9f,stroke:#333,stroke-width:2px;

 この図は、医療システム、特に電子カルテシステムの運用・保守の流れを示しています。各ステップについて詳細に説明します:

  1. 運用開始: システムの本格的な運用が開始されます。
  2. 日常的な監視: システムのパフォーマンス、セキュリティ、データ整合性などを常時監視します。
  3. 問題発生の検知: 監視中に問題が検出されたかどうかを判断します。
  4. 問題の分析: 発生した問題の原因や影響範囲を詳細に分析します。
  5. 対応策の策定: 問題解決のための具体的な対応策を立案します。
  6. 変更の実施: 策定した対応策に基づいて、システムの変更を実施します。
  7. 変更の検証: 実施した変更が期待通りの効果を持つか検証します。
  8. 検証結果の確認: 検証結果が良好かどうかを判断します。
  9. 本番環境への適用: 検証済みの変更を本番環境に適用します。
  10. ユーザーへの通知: システム変更について、医療スタッフなどのユーザーに通知します。
  11. 運用マニュアルの更新: 変更を反映して、運用マニュアルを更新します。
  12. 定期的な評価: システムの性能、利用状況、ユーザー満足度などを定期的に評価します。
  13. 改善の必要性判断: 評価結果に基づいて、大規模な改善が必要かどうかを判断します。
  14. 改善計画の立案: 大規模な改善が必要な場合、具体的な計画を立案します。
  15. 大規模更新の実施: 立案した計画に基づいて、システムの大規模更新を実施します。
  16. 新バージョンの運用開始: 更新されたシステムの運用を開始し、サイクルが再開します。

 この運用・保守の流れは、以下の点で医療システムの特性を反映しています:

  • 継続的な監視と迅速な対応:医療現場での即時性を考慮し、問題の早期発見と迅速な対応を重視しています。
  • 慎重な変更プロセス:患者の安全に直結するため、変更の実施と検証を慎重に行います。
  • ユーザーコミュニケーション:医療スタッフへの適切な情報提供を重視しています。
  • 定期的な評価と改善:医療技術や規制の変化に対応するため、システムの定期的な評価と改善を組み込んでいます。

 この図を参考にすることで、医療システムの運用・保守における重要なステップと考慮事項を理解し、効果的な運用・保守計画を立案することができます。また、この流れは、システム要件の実現可能性を評価する際の指標としても活用できます。

4. 例題

例題1

問題:ソフトウェア要件の評価基準として、「双方向の追跡可能性」が重要である理由を説明してください。

回答例:双方向の追跡可能性が重要な理由は以下の通りです:

  1. 要件の網羅性確認:上位要件から下位要件まで追跡することで、必要な要件が漏れなく定義されているか確認できる。
  2. 影響範囲の特定:要件変更時に、関連する上位・下位の要件を容易に特定でき、影響範囲を正確に把握できる。
  3. 整合性の確保:各要件間の関連性を明確にすることで、要件全体の整合性を確保しやすくなる。
  4. テストの効率化:要件とテスト項目の関連付けが容易になり、テストの漏れを防ぎ、効率的なテスト計画が立てられる。

例題2

問題:ソフトウェア要件定義書のレビューにおいて、システムの取得者及び供給者が共同でレビューを行うことの利点を3つ挙げてください。

回答例

  1. 多角的な視点:取得者側の業務知識と供給者側の技術知識を組み合わせることで、より包括的な評価が可能になる。
  2. 認識の齟齬解消:要件に対する解釈の違いを早期に発見し、修正することができる。
  3. 合意形成の促進:共同レビューを通じて、両者間で要件に対する共通理解と合意を形成しやすくなる。

5. まとめ

 ソフトウェア要件の評価及びレビューは、ソフトウェア開発プロジェクトの成功に不可欠なプロセスです。双方向の追跡可能性、一貫性、テスト可能性、実現可能性などの評価基準

に基づいて要件を慎重に評価し、システムの取得者と供給者が共同でレビューを行うことで、質の高いソフトウェア要件を定義できます。このプロセスにより、プロジェクトの方向性を明確にし、後続の開発フェーズでの問題を未然に防ぐことが可能となります。