ユースケースもろもろメモ

ユースケースについて、自分向けの雑多なメモ。

• とりあえずこの本

ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

• ユースケースの利点
  • ユーザの視点
  • 拡張できる
  • ユースケースは業務上のゴール
  • ゴール指向

• 要求〜ユースケース図〜ユースケース仕様〜クラス定義
  • ドメイン要求
• システム内部
  • →ユースケース図（システム）
  • →ユースケース仕様（キー概念）
  • →ユースケース実現（コラボレーション）
• システム外側
  • ビジネスプロセスモデル（アクティビティ図）
  • ビジネス概念モデル(クラス図)

• 要素
  • アクター
  • 事前条件
  • ゴール
  • イベントフロー(主成功シナリオ)

• イベントフロー
  • ループは入れていいが条件はいれない
  • 条件は例外フロー、代替フロー、拡張フローで記述

• シナリオ
  • 具体的な値を入れる（1000円払う等）

• UCの典型シナリオ
  1. UC名
  2. 事前条件
  3. 事後条件
  4. イベントフロー基本系列
  5. イベントフロー拡張系列（代替フロー、例外フロー）

• UCの粒度
  • Cockburnのレベル
  • ゴール＝ユーザ目的=「ひと仕事のレベル」=1トランザクションにもなりふる=数十秒から数分くらい
  • 要約レベルでは大きすぎる。サブ機能レベルでは小さすぎる

• 段階的なUC仕様の定義段階
  1. アクターと利用目的：アクターの目的とスコープが決定できる
  2. 基本フロー（主成功シナリオ）：ざっくりとした見積もりができるレベル
  3. 事前・事後・拡張条件のリストアップ：少し大変：UC書くスキルも必要なる
  4. 拡張条件・拡張フロー
  • どのレベルまで記述するかはユースケースを理解しているPM,アーキテクトを含めて検討する必要がある

• 基本フローの留意点
  • ステップはシンプルに。誰が何を。
  • 極力システムに依存しないように書く（入力するや指定する等の言葉を使用）

• 事前条件
  • UCが開始するための条件
  • 例）ログインしている、利用者カードを保持している
  • UCに因果関係がある場合
  • 当然なりたつことは除外できる

• 事後条件
  • システムが更新された結果(成功時の保証条件)
  • 事後条件無しはありえない
    • 最低保証：例）ログには記録されていること、残高が保証されている、カードが戻ってこないといけない
    • 成功時保証：例）注文が確定されていること、

• 拡張条件
  • 基本フローに対しての、別のやり方の可能性。例外。
    • 4a 代替　4番のステップに対する代替フロー
    • 4b 例外　4番のステップに対する例外フロー
    • *a すべてのステップで有効な場合はのように記述する
  • 設計、アーキテクチャ設計に必要な条件を見極めるために必要。
  • 事前条件におくか、拡張条件におくかで悩む場合がある
  • 例外と代替も悩む場合がある。成功時保証が達成される場合は代替。
  • 代替フロー・例外フローから別のユースケースを呼び出すこともある
  • 代替フロー、例外フロー内で代替・例外を呼び出すことはできる。しかし本来は基本フローと拡張フローの2階層で管理するべき。基本方針として書きすぎないほうが良い。複雑になる場合はユースケースの位置づけを再検討するべき。
  • RationalUnifiedProcessでは例外をメインフローの後ろに[ex01]と書く記法。基本フロー内に[ex01]と書くことで例外の発生箇所が明確。
  • 拡張条件については質問が相次いだ。ここの粒度をあわせるには事前教育と取り決めが必要と感じた。

• トリガー
  • ユースケースを開始させるイベント
  • 無理しないでも良い

• ユースケースの不得意領域
  • システム領域が決まっていない場合
  • 人間を主体にできないシステム（ロボットなど）
  • イベント、時間の概念
  • 非機能要求
  • 組み込み系、制御系（相互作用、タイマー）
  • UI主体(CAD)

• ユースケースだけで無理しない
  • 業務フローと併用

• ユースケース管理
  • ユースケースフィーチャマトリクス

• ユースケースの関係（サブ機能、再利用視点になりがちなので利用には注意が必要）
  • include:共通サブルーチン
  • extend:拡張
  • generalization:抽象化
• アクターの関係（難しくないので使用は問題ない）
  • 汎化

• 要求との関係
  • UCがすべてではない。（半分とか1/3）
  • 非機能要求、UI、データ形式、ビジネスルール...

• 要求の分類
  • FURPS+（ファルプス）
    • F:機能性
    • U:使用容易性
    • R:信頼性
    • P:性能
    • S:サポート容易性
    • ＋:プロジェクト制約
  • ISO9126/JIS X0129

• 仕様変更の理由
  • 要求仕様書がわかりにくい
  • 非機能要求の確認漏れ

• 要求仕様
  • ユーザー側が作れればベストだが、開発側がつくるもの
  • レビュー：ユーザ、テスト担当、設計プログラマ、アーキテクトにレビューしてもらう

• 要求アウトライン
  • 目標・スコープ
  • ユースケース
  • 技術
  • 条件
  • 非機能要求
  • etc

• ビジネスルール
  • 5種類（Ron Ross）
  • 用語の整理が重要

• アジャイル開発との相性も悪くない
  • 重要なユースケースから実装していく

• 参考
  • ユースケースポイント法
  • ロバストネス分析

手を動かす書き方演習やレビュー演習がためになりました。