use case patterns の備忘録

『Patterns for Effective Use Cases』から、パターンの要約をメモっておく。

■■■ Team のパターン
★ SmallWritingTeam
各成果物をレビューして仕上げる担当者数は２，３人に抑える事。大人数を動員するときは TwoTierReview パターンを使う事。

★ ParticipatingAudience
顧客や内部のステークホルダに、なるべく積極的にユースケース作成プロセスに参加してもらう事。

★ BalancedTeam
異なる専門分野の人をチーム構成に含めて、ステークホルダの利益を開発プロセスの中で擁護していく事。特に設計者とエンドユーザは確実にチームに含める事。

■■■ Process のパターン
★ BreadthBeforeDepth
まず最初に概観レベルのユースケースを作っておいてから、関連するユースケース群を横断しつつ、詳細レベルの記述を段々と追加するような作業の流れに従う事で、労力の無駄な消耗を防ぐ事。

★ SpiralDevelopment
イテレーションを繰り返す中で、ユースケースの精度と正確性がだんだんと増加していくように、反復的かつ「広さ優先」の作法でユースケースを開発していく事。

★ MultipleForms
プロジェクトに関連するリスクと、関係者の好みを汲み取りつつ、ユースケースの書式を選択する事。

★ TwoTierReview
２つのタイプのレビューを催す事：第一にチームの内輪だけで数回行う小さなレビュー。第二に完全なグループで、一回だけ行うレビュー。

★ QuittingTime
ユースケースが出来上がってステークホルダや開発者など聴衆のニーズを満たした時点で、そのユースケース開発はとっとと止めてしまう事。

★ WritersLicense
書き方の小さな違いに無駄にこだわらない事。一たび QuittingTime の条件を通ったユースケースについては、ライタが小さな様式の違いに関する"ライセンス"を得る事ができるようにする事。

■■■ Use Case Set のパターン
★ SharedClearVision
システムの目的を明確化し、組織のミッションを支援するような声明を準備して、プロジェクトに関係する全員が読めるように公開する事。

★ VisibleBoundary
システムと対話する人間と設備の両方を列挙して、システムとその環境との境界を可視化する事。

★ ClearCastOfCharacters
システムと対話するものであるアクタと、システムに対して果たすべきものであるロールを識別し、それぞれについて明確に説明する事。

★ UserValuedTransactions
アクターのビジネス上の目的を満たすためにシステムが提供する、価値のあるサービスを識別する事。

★ EverUnfoldingStory
展開して詳細を見たり、畳み込んで全体的な文脈を重点的に示したりできるような、階層的なストーリとしてユースケース・セットを組み立てる事。

■■■ Use Case のパターン
★ CompleteSingleGoal
よく定義された完全な一個のゴールを示すように、各ユースケースを書く事。（そのゴールは、EveryUnfoldingStory における任意のレベルでもある。）

★ VerbPhraseName
プライマリ・アクターのゴールを表現するような、能動態の動詞句でユースケースを名づける事。

★ ScenarioPlusFragments
失敗を考慮しない単純なシナリオでサクセス・ストーリーラインを書き、その下に代替事象の発生を示すストーリの断片を記述する事。

★ ExhaustiveAlternatives
処理すべき全ての代替および失敗を、ユースケースにおいて漏れなく捕捉しておく事。

★ Adornments
ユースケース・テンプレートのシナリオ・テキストの外に、ユースケースの関連付けに役立つ補足情報を保持するための追加フィールドを作成する事

★ PreciseAndReadable
ステークホルダが読んで評価する気になるレベルの読み易さで、尚且つ、自分達が何を構築しているのか開発者が理解できるレベルの正確さで、ユースケースを書く事。

■■■ Scenarios and Steps のパターン
★ DetectableConditions
検出可能な条件のみを含める事。システムに与える正味の効果が同じである条件はマージする事。

★ LeveledSteps
シナリオの長さは、３ステップから９ステップにする事。

★ ActorIntentAccomplished
各ステップを記述する際、どのアクターがアクションを実行し、それにより何をアクターが得る事になるのか明確に示す事。

★ ForwardProgress
アクターを前に進めないステップは排除するかマージする事。読者がシナリオの進行に付いて来れなくなる様なややこしい経路は簡略化する事。

★ TechnologyNeutral
各ステップを書く際、IT技術に中立となるよう留意する事。

■■■ Use Case 間の関連のパターン
★ CommonSubBehavior
「包含」される下位レベルのユースケースを用いて、共有されるアクションのコースを表現する事。

★ InterruptsAsExtensions
シナリオの多くのステップに代替コースが割り込んで来る場合、拡張ユースケースを作る事。

★ PromotedAlternative
ユースケースに過度に影響する複雑な代替は、分離したユースケースへの移動を考慮する事。

★ CapturedAbstraction
汎化した抽象ユースケースの作成を考慮する事。その抽象ユースケースを特化する具象的・個別的なシナリオは、それ自身の具象ユースケースに置く事。

■■■ 既存 Use Cases の編集のパターン
★ RedistributeTheWealth
長くて扱いにくい経路や、複雑すぎる拡張は、それ自身のユースケースを別途作って移動する事。

★ MergeDroplets
関連する小さなユースケースやユースケースの断片は、同じゴールに関連するものをマージして、別途ユースケースを作成する事。

★ CleanHouse
システムに価値をもたらさなかったり、既にアクティブ･リストにないユースケースは取り除いてしまう事。