読者です 読者をやめる 読者になる 読者になる

ステップ3:システム境界を把握する

顧客の要求を確実に仕様にできる要件定義マニュアルで説明される次のステップは「システム境界を把握する」です。このステップでは大きく2つのことを把握します。それはユーザインタフェースとシステムインタフェースです。

ユーザインタフェース

ユーザインタフェースではユースケースモデル、画面・帳票モデルを作成し、ユーザ(アクタ)から見たシステムの境界を明確にします。

ユースケースモデル

ユースケースユースケース記述(ユースケースシナリオ)を作成します。RDRAではユースケース記述は5〜10行程度のイベントフローしか書かないとされています(業務フロー、利用シーン、画面・帳票モデル、機能モデルで補完できるため)。しかし、個人的には業務フローよりもユースケース記述(ユースケースシナリオ)に重点を置きたいため、ユースケース駆動開発実践ガイド (OOP Foundations)を参考にしてユースケースユースケース記述(ユースケースシナリオ)を作成します。

ユースケース

ユースケース駆動開発実践ガイド (OOP Foundations)にて説明されるポイントは以下の通りです。

  • 複雑な表記は使用せず、precedes(先行)とinvokes(呼出)の2種類のみを使用する。
  • パッケージを使って構造化する。
ユースケース記述(ユースケースシナリオ)

ユースケース駆動開発実践ガイド (OOP Foundations)にて説明されるポイントは以下の通りです。

  • 複雑なテンプレートを使用せず、基本シナリオと代替シナリオの2つのみを記述する。
  • 代替シナリオは必ず記述する。
  • ユーザとシステムの対話として記述する。
  • 作成した概念モデルの名称を使用する。
  • 画面が出てくる場合は画面名を明確にする。

さらに追加しておきたいポイントは以下の通りです。

  • ビジネスルールは識別子を指定して参照するようにする。
画面・帳票モデル

画面・帳票モデルは入出力される情報をクラス図として整理します。ポイントとしては、あくまでも情報モデルを明確にすることが目的であるため、デザインなどはこの段階では考慮しません。

システムインタフェース

システムインタフェースではイベントモデル、プロトコルモデルを作成し、外部システム(アクタ)から見たシステムの境界を明確にします。

イベントモデル

イベントモデルは外部システムとの間で発生するイベントの入出力される情報をクラス図として整理します。こちらもポイントは情報モデルを明確にすることが目的です。

プロトコルモデル

プロトコルモデルは発生するイベントと状態の関係を状態遷移図と状態遷移表で整理します。この状態遷移をマトリクスで抜けなく表現することが重要なポイントになります。この辺りは、組込みソフトウェア開発のための構造化モデリング 要求定義/分析/設計からソースコード作成までソフトウェア開発上流工程の基本を構造化手法に学ぶが参考になります。