機能スコープと設計スコープ

　あるビジネスのシナリオを書く時、スコープを意識するのが重要なのだが、機能スコープと設計スコープを意識して使い分けるのが重要と改めて認識した。

　「ユースケース実践ガイド―効果的なユースケースの書き方」で、機能スコープと設計スコープの話が出てくる。
　機能スコープは、システムが提供するサービスを意味する。成果物は、アクタ・目的リストとユースケース概要の2つ。これらは、ペルソナ・シナリオ法を使えば、アクタごとのシナリオとして洗い出すことができる。
　これらのユースケースは、受け入れテストで使える。

　設計スコープは、ハードやソフトもこめて設計するシステムの集合を意味する。このイメージがなかなか湧かなかった。本の例を見ていると、イメージとしてはDFDやER図に似ていないか？
　つまり、システムとして設計すべき機能なのか、設計外の機能なのか、を把握するには、企業・システム・サブシステムの視点からデータの受け渡しをイメージしないと書けない気がする。

　とある勉強会でシナリオを書くタスクを背負ったが、メンバーのシナリオに対するイメージがバラバラで、どんなシナリオを書けば概念モデルや詳細モデルが書けるのか、プロセスすら分からなかった。
　今になってようやく、下記の成果物は必須だと分かった。

１．各シナリオ・機能がスコープ内にあるかチェックするためのIn/Outリスト
　→議論が発散しそうになったら、どんな要求がシステムに必要なのか、原点に立ち戻る時に使う。

２．アクタ別のシナリオを書いたユースケース概要
　→ペルソナ・シナリオ法はオブジェクト図の位置づけに相当する。アクタ・目的リストはクラス図の位置づけに相当する。受け入れテストで使える。

３．色んな視点からシステムを眺めた時の設計スコープの図
　→モデリングを行う時、どのシステムに着目して詳細化していくのか、を確認するのに使う。

　ユースケースなんてモデリングで意味があるのか、と常々思っていたのだが、モデリングを行う前の仕込み段階であるシナリオを書きまくっていくうちに、ユースケースの威力が分かってきた。
　モデリングへ辿りつくには、シナリオを具体化したユースケースが必要。そのシナリオはスコープに大きく依存している。

　シナリオやユースケースを書いていると気づいたのは、IF文を極力排除していること。IF文を使う箇所はアクタ別のシナリオに分けられる時が多い。

　ユースケースは奥が深い！