#book #r2021  # Summary ## ユースケースとは - 一連のバリエーションからなるシナリオ群をユーザーの観点で1つにまとめたもの - ユースケースは、様々な目的がある - ビジネスの作業プロセスを記述する - 要求に関する議論に使う - 機能要求とする - ドキュメントにする - ユースケースを書く5つの重要度 - 要求を発見するため(未決定事項があっても良い、書きながら議論しながら発見する) - 再設計などのためにモデリング(ステップ20点をおく) - 規模の評価(要求はあとで詳細化しても良い) - 短期決戦(略式で概要だけを書く) - 詳細な機能要求(コストをかけて詳細に書く) - [Steve Adolph](https://steveadolph.com/) は、ユースケースを使うのは要求をドキュメントに記述するというよりむしろ要求を発見するためであると述べてる ## ユースケースの書き方 1. 単純な文法で書く 2. 「誰が」を明らかにする 3. 自分の目線ではなく、鳥瞰図として書く 4. 処理が進んでることを表す (詳細すぎるステップでは、処理は進まない) 5. アクターの動作ではなく意図を表す (目的レベルが低すぎることに繋がる) 6. ユースケースには意味のあるアクションの集合を含める(トランザクションのようにとらえる) 7. チェックするではなく、正しいことを確認するなどIfのどちらかを主成功シナリオにする 8. 必要ならタイミングを記述する 特に 5 については、「インターフェース詳細記述」と呼んでる。 長い記述は読みにくく、維持にかかるコストも高くつく。 書かれた対話は要求ではなく書き手が想像するユーザーインターフェースになってる。 システムの設計に少しでも変更が入ると意味がなくなってしまう。 例えば、「OKボタンを押す」というのはインターフェース詳細記述になってる。 インターフェースはインターフェース設計者の仕事であり、要求さえ決まってればデザインが決まりきってなくても開発に入れることを指す。 ## 拡張シナリオ 正常系ではないようなシナリオを拡張シナリオと呼ぶ。 大体の場合には、失敗パターンのような雨の日シナリオを指す。 拡張シナリオは一般に4パターンある。 - 処理が終わると元のステップが成功した状態になる(継続) - 元のステップの最初に戻る(再開) - ユースケース全体が終了する - 異なる筋道を通って成功する(代替フロー) 拡張シナリオは簡潔に書くのが難しいので、低いレベルにならないように気を付ける。 例えばアプリケーションの関心ごとにもよるが、「ファイルがすでに存在してたら」、「ディレクトリが存在しない」などは影響が同じなのであれば読み手への簡潔さのためにまとめてしまうなどがある。 また結果として同じようなシチューエンションになるものの、技術的なバリエーションがある場合には列挙をしておくのも重要である。 例えば、「返品に対して顧客に返金する」という拡張シナリオに対しては、以下の3つのバリエーションがある - 小切手で返金する - EFTで返金する - 金券で返金する これらをシナリオの本体としてではなく、バリエーションがあることを明記しておく。 # 感想 ユースケース駆動な開発を意識してて、ユースケースを書くのだが、段々チームの人数が多くなるなかでユースケースが複雑で技術詳細に寄ったものになるようになってきた。 この本の中で、「簡潔に、目的レベルを低くしすぎない」という2点がユースケースについての整理に大いに役にたった。 また、[Steve Adolph](https://steveadolph.com/) が述べてる > ユースケースを使うのは要求をドキュメントに記述するというよりむしろ要求を発見するためである というのは自分がユースケースを整理する進め方のいいところだと思ってる。