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

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

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

  • とりあえずこの本

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

ユースケース実践ガイド―効果的なユースケースの書き方 (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
  • 仕様変更の理由
    • 要求仕様書がわかりにくい
    • 非機能要求の確認漏れ
  • 要求仕様
    • ユーザー側が作れればベストだが、開発側がつくるもの
    • レビュー:ユーザ、テスト担当、設計プログラマ、アーキテクトにレビューしてもらう
  • 要求アウトライン
  • ビジネスルール
    • 5種類(Ron Ross)
    • 用語の整理が重要

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