概要
ダイアグラム別UML徹底活用で、ユースケース記述について学んだことを書いていこうと思います。
特にユースケース記述の章では、開発するシステムについて、適切に相手に説明するためにはどのようなことが重要かが書かれていました。
自分に欠けていることだと思ったので、今後の役に立てたいと思います。
ユースケース記述とは
ユースケース図とは、主にシステム開発の初期段階で作成されるものでユースケース図と一緒に扱われます。ユースケース図１つにつき、1つのユースケース記述が作成されます。そのユースケースが具体的にどのように振る舞うかを説明したものがユースケース記述です。ユースケース記述はシステムの開発者担当でない人、システム内部に詳しくない人やエンドユーザーでも理解できるような書き方が望ましいです。
ユースケース記述の項目
| 項目 | 説明 |
|---|---|
| ユースケース名 | ユースケース図についている名前。ユースケース図に書かれている名前と揃える。 |
| 目的(ゴール) | ユースケースの目的を実行することで達成される結果 |
| アクター | ユースケースに関係するアクター |
| 開始条件(起動トリガー) | ユースケースが開始される条件 |
| 事前条件 | このユースケースが開始されるときに整っていなければいけない条件 |
| 事後条件 | ユースケースの実行後に期待されている条件。アクターにどのような影響を与えたかなど |
| メインフロー | イベントフローの一つ。ユースケースの実行に伴って起きるアクターとシステムとの間のやり取りのうち、想定通りのもの。この時、事後条件は満たされる。 |
| 代替フロー | イベントフローの一つ。メインフローの代わりとなる手順。代替フローを実行しても、事後条件は満たされる。 |
| 例外フロー | イベントフローの一つ。ユースケースの実行が中断せざるを得ないもの。この時、事後条件が満たされない。 |
| 備考 | 上記の項目に収まらないような記述や詳細な説明。 |
| シナリオリスト | イベントフローの具体例としてよくあるものをリストアップする。 |
| シナリオ記述 | シナリオリストに書かれたそれぞれのシナリオを記述する。 |
ユースケース記述を書くメリット
開発者やエンドユーザーがユースケース記述を通してシステムのイメージを共有できる事が大きなメリットです。システムのイメージを明確化することで「システムや機能の対象範囲」や「何を作って、何を作らないか」が決まります。開発の内容が具体的に定義されていると全体像が理解しやすくなります。
また、実際に開発に入るときは小さな単位で小分けして行うことになるでしょう。ユースケースを一つひとつ実装していき、全てが実現できた時にシステムの完成ということにるので、ユースケース一つひとつをマイルストーンとした開発を行うことも出来ます。（ユースケース駆動開発）
ユースケース記述作成時の注意点
厳密に書く
ユースケース記述は、読んだ人が間違った解釈をしないように厳密な記述をしなければなりません。「適切な」「適当な」「ある程度」などの曖昧な書き方は、読み手に推測をさせることになります。同様に、読み手に文脈から推測させるようなこともするべきではありません。特に「開始条件」「事前条件」「事後条件」はそれぞれの条件を満たしているかどうかをシステム側で定量的に評価しなければならないため、曖昧なままだと開発の工程で解釈の違いが生まれてしまいます。
細かく書きすぎない
ユースケース記述の作成者が技術者であると、システム内部の振る舞いまで書いてしまうことがよくあります。上記で述べたようにユースケース記述は、システムの設計開発の関係者はもちろん、そのシステムの内部に詳しくない人、またエンドユーザーでも読んで理解出来るものにする必要があります。「データベース」「テーブル」「クエリ」「入力フォーム」などが出てきたり、画面遷移について記述がされているとなると、記述が細かくなりすぎている可能性があります。
空欄を作らない
ユースケース記述のフォーマットは項目が多く、なおかつ具体的に記述する必要があります。そのため、内容が決まっていないという理由で記述できない場合がよくあります。そんなときは空欄にせず、T.B.D(To Be Determindの略)と記入するようにしましょう。項目について検討した結果、書くことがない場合は「なし」と記載します。項目を空欄のままにしてしまうと現在検討中なのか、それとも検討の結果「なし」となったのかがわかりません。空欄のままにしてしまうことは避けましょう。
いつまでも書き続けない
ユースケース記述を明確に記述しようとするあまり、あらゆる事象の検討を網羅したり、T.B.Dがユースケース記述がなくなるまで次の工程に進まないというプロジェクトの進め方はよくありません。なぜなら、システムは実際に動かしてから課題が表面化することがあるからです。すべてを書き終わるまで次の工程に進まないのではなく、次の作業に着手出来るまでまとまったら、その段階で決まっていない部分はT.B.Dとして次の作業をすすめることも必要です。