ユースケース シナリオの書き方

• ひとつのユースケース（use case）に ひとつのユースケース シナリオ（use case scenario）を作成する．
  • エラーや分岐がある場合，それぞれを副シナリオに起こす．…ので，かなり大量のシナリオを作ることも多い．
• ユースケース記述[A1][A2][A3]とはちがうもの．
  • ユースケース シナリオは実際にシステムが使われている場面の具体例を書くもの．
  • ユースケース記述は処理の流れを書くもの．
• どんな文書ができればよい？
  • 完成したシナリオの名詞と名詞句からクラス，動詞と動詞句からメソッドの候補を抽出できるようになっている．クラスとメソッドの抽出がうまくいかない場合，不明瞭な文章で書かれていること（用語の定義があいまいだったり正確に書かれていなかったりなど）が原因と思われる．
  • システムに関連しているひと（ステーク ホルダー）で読みあわせをおこなって，もれや余計なことがかかれていないか認識あわせができる．
  • シナリオがスムーズに運ぶか，無理がないか検証できるものになっている．
  • テストケース，テストシナリオとしても利用できるものになっている．適切に書かれていれば自然にそうなるはず．逆にいえば，シナリオとして想定されていたのにテストしてないとか，仕組み上テストできないとかは何でそうなった？　「つくるものは検証可能でなければならない」ということもお忘れなく．（変なシステムの例： 「π計算プログラム作った」「で，これ答えあってんの？」「さあ？」）
• 何のために？
  • 要求と実装を一致させるため．
    なんとなく「ユーザー登録」とか書いただけでは，いろんな実装ができあがってしまう．窓口の人が口頭で質問しながら登録するのか，ユーザーがネット上で自分で登録するのか，エラーになった場合どうなるつもりなのかなどを書き下し，業務運用者と認識あわせを済ませる．
  • 要求仕様の分析・確定をするためのものなので，あまり詳細に踏み込むべきではない[3]．詳細を書きはじめると，「つくり上こうしてほしい」のような「逆要求」がはじまって変なことになる．ユースケースは（ユースケース記述，ユースケース シナリオともに）システムをブラックボックスとして扱う[4]．

ユースケース シナリオに記述すべき項目

1. ユースケースID，ユースケース名
2. 主アクター
   • 主な登場人物の整理．たとえば，ここに部長とか輸出管理責任者とかでてくれば，そういった役職の人がいる時間帯にしかできない作業なんだとわかる．また，業務担当者が見て思いがけない人が登場するようなら（例えば「え，なんでこのシナリオにシステム管理者とかでてくるの？」とか質問をうけるなど），何か機能的な問題が潜んでいたり，業務内容を誤解している可能性があることを示唆している（かもしれない）．
   • どこまでが「主な登場人物」にあたるかは微妙だけど，例えばエラーが起きた場合などに「保守員に連絡する」ことになっていたからといって保守員を登場させておくのはやりすぎ．あくまで，普通の意味での登場人物でよい．
3. 事前条件，事後条件
   • 開始状態・終了状態でどうなっているかを記述する．
   • 例えば，システムにログインするという手順がある場合，「当該ユーザーがシステムに登録されていること」のような事前条件になるはず．
   • 特に記載すべき条件がないときは「なし」でよい．［事前条件は，むしろ「なし」が望ましい．例えば「ユーザー登録がすんでいること」という事前条件がある場合，レビュー時などに「登録されていない場合は登録画面に遷移するようにできないか」というような「事前条件の除去」の要望がでると思われる．］
4. 主シナリオ，副シナリオ（※副シナリオは「拡張」と呼ぶこともある）
   • アクターとシステムのやりとりを手順として書きだす．
   • 主語を「利用者」（アクターの中の人物）と「システム」（またはシステム名）に統一するとわかりやすくなる．
   • 入力するデータの項目一覧やフォーマットなどは煩雑になるので「関連情報」のほうに書いておく．ユースケース シナリオは，シナリオの確認をするための場なので，細々とした機能の議論がはじまって気が散るのを防ぐため詳細項目は別立てにしておく．
   • 通常の流れを主シナリオにかき，エラーケースなどの枝のシナリオを副シナリオにかく．
5. 関連情報
   • 備考類はここに書く．
   • データ フォーマットや各手順で入力すべきデータの一覧などシナリオ中に書き込むと煩雑になるデータはここに書いておく．

Links