要件エンジニアリングのソフトウェア要件分析

ニーズ分析は次のように要約されます。

• 要件の分解：トップダウンアプローチの使用（ソフトウェア要件仕様の概要を作成するため）
  • 主な手がかりとしてビジネスプロセスを取り上げます。オンライントランザクション処理システム、管理情報システムなどに適しています。
  • プログラムの構造を主な手がかりとして考えてください。問題ドメインが複雑でない、またはシステムが問題ドメインに強く関連していない状況に適用できます
  • シナリオベースの分解構造：意思決定支援システム、ユーザー指向の組み込みシステムに適しています
  • データベースの分解構造：データウェアハウスなどのデータプロジェクトに適しています
• デマンドリファイン：ボトムアップアプローチ
  • ビジネスアイテム
  • ビジネスプロセス
  • すべてのドキュメント
  • すべてのレコード
• 需要分析と精製のプロセスにおける競合を排除する

要件モデリング：（UML）

モデリングの目標：

• 需要分析者が実際の状況またはニーズに応じてシステムを視覚化できるように支援します
• ドキュメントの構造または動作を指定する方法を提供する
• システム構築をガイドするテンプレートを与える
• ニーズ分析によって下された決定を文書化する

モデリングのポイント：

• 設計では、計画外の変更を考慮する必要があります
• 文書化される設計
• アーキテクチャをビジュアルモデルで表現すると、変化の意味を理解するのに役立ちます

一般的な要件分析方法：

• 構造化分析（SA）
• オブジェクト指向分析（OOA）
• 問題指向分析（PDOA）

1.構造化分析手法

構造化分析：データフロー指向の需要分析手法であり、システム全体のトランザクション処理、データフロー、および格納されたデータ構造のモデリング（人間の考え方と同様）に特化しています。

モデリングモデルは次のとおりです。

• データフロー図（DFD）（機能モデル）（4つの要素：外部エンティティ、処理、データフロー。データストレージ）
  • 説明情報からエンティティを特定する
  • エンティティ識別子を決定する
  • エンティティ間の関係を確立する
  • 詳細な説明情報を追加
• データディクショナリ（DD）（名前、エイリアス、使用場所、使用範囲、説明、単位/形式）（データフロー図の各コンポーネントの特定の意味を正確に定義できます）
  • データストリームエントリ
    • データストリーム名
    • 解説
    • データフローのソース
    • データの流れ
    • データストリームの構成
  • データ項目の入力
  • データファイルエントリ
  • データ処理項目
• エンティティ関係図（ERD）（データモデル）

一般的な構造化分析手法には次のものがあります。

• データモデリング
• プロセスモデリング
• 行動モデリング
• プロセス、データ関係モデリング
• 情報工学法

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

    オブジェクト指向分析の出発点は、元の要件ドキュメント、または動作仕様です。OOAの真の本質は、ソリューションシステムの高レベルのアーキテクチャを設計することであり、システムの次の開発と設計に役立ちます。

オブジェクト指向分析法：

• 問題ドメインのオブジェクトクラスを特定する
• これらのクラスのプロパティとメソッドを定義する
• これらのクラスの動作を定義する
• これらのクラス間の関係をモデル化する

オブジェクト指向分析ツール：（UML）

• ユースケース図
  • 基本的なユースケースモデル（動作要件のモデリング用）（要件取得フェーズで構築）
  • システムユースケースモデル（動作分析のモデル化に使用）（要件分析フェーズで構築）
• クラス図
• インタラクティブな図
  • シーケンス図（シーケンス図）
  • コラボレーション図
• アクティビティ図
• オブジェクト制約言語
• 状態遷移図（STD）（行動モデリング）

3.制度化分析手法とオブジェクト指向分析手法の比較

同じ機能：

• メインモデルは構造モデルです
• 通常、焦点はソリューションシステムのモデリングにあります
• どちらの方法も需要獲得の分野ではめったに使用されません
• 分析と内部設計の間に明らかな違いはない

分析プロセスの2つの段階：

• ビジネスとプロセスを明確にする
• 要件の詳細を特定する