このブログのアクセスログを見ると、どうもユースケース記述のアクセス数が常に上位にあるようです。
ユースケース記述(図じゃなくて)に関心がある方が多いのでしょうか。あなたは、どうですか?
ユースケース記述について、より理解を深めていただくために、ちょっと違う視点で説明してみたいと思います。
前回は、一般的なユースケース記述の書き方について、サンプルケースを使って、チュートリアルっぽく説明しました。
そこで、今回は重要なポイントに的を絞ってお話しします。
コンテンツ
ユースケース記述の目的
ですので、ユーザにわからない用語は、使用すべきではありません。
ユーザは、普通ビジネスドメインについてはエキスパートですので、ビジネス上の専門用語を使用するのは、構いません。
ユースケース記述の必須事項
ただ、実際には仕様を明確にするために、「どうしてもこれだけは書くべき」と考えられるものが、いくつかあります。
それは、以下の5つです。
- 名前
ユースケース図のどのユースケースのシナリオなのかわかるように、同じ名前をつけるべきです。
中には、IDで対応づけを管理しているプロジェクトもあるようです。(ID?うえーっ) - サービスを受けるアクタ
シナリオを理解するうえで、誰のためのものなのかは、非常に重要なポイントです。
なぜ重要かは、次の概要/目的と同じです。 - 概要(または目的)
アプリケーションが、目的もなく動作するなんてことは、まずありません。
たとえユーザが、自分は目的がないつもりでアプリケーションにインタラクトしようとしている場合でも、アプリケーション側は無目的ではありません。
必ず、なんらかのサービスをユーザに提供することを目的にして、動いています。
ユースケース記述は、そんなアプリケーションの目的ごとに、作成します。
ここで記述する目的とは、どんなサービスを提供するかということにつきます。
これが明確でないと、もう何を書きたくてわざわざ書かれたものなのか、わからなくなります。 - 事前条件
これは、本編であるシナリオがブレてしまうことを防ぐために、必要な記述です。
たとえば、ショッピングサイトで「カートを見る」というユースケースが書きたいのに、「ユーザ登録」からハナシをはじめるのは、避けたいですよね。
「カートを見る」ユースケースの前提条件には、きっと「ユーザ登録が済んでいる」とか、あるいは「ログインが済んでいる」とかいう前提条件が含まれるはずです。(この例の場合は、代替シナリオ「ユーザが未登録だった場合」を記述するというテも、あるわけですが) - イベントフロー(シナリオ)
これが、待ちに待ったユースケース記述の本編ですね。
大切なのは- 5W1Hに気をつけて、できる限り明確に書く
- 本筋(基本シナリオ)をブラさない
本筋をブラさないためには、枝道と考えられる筋はすべて、「代替シナリオ」や「例外シナリオ」に追い出すことが必要です。
シナリオを書く際、「書き漏れ」を探すことは、たいていの人がするのですが、枝道の「追い出し漏れ」を探すことは、意外と忘れている人がいるのではないでしょうか。
「足りないもの(書き漏れ)」を探すという行為は、必要なことではありますが、消極的な行動です。
良いものを書くには、逆に「書きすぎ(追い出し漏れ)」を探すことが重要です。
でも、結局は
なので、近頃使用されているフォーマットには、そういう事が書ける場所が用意されているのが普通です。
もしなかったら、自分で場所を作ってください。
結局のところ、ユースケース記述はフリーフォーマットなんですから。
前節で書いた「必須の項目」だって、あれはあくまで僕がそう感じてるだけのことで、誰かの論文や公式見解が根拠になっているわけではありません。
人によって、必須と思う項目は違ってくるでしょう。
あなたも、自分なりの必須項目を考えてみてください。
それと、フリーフォーマットの弊害(?)として、前節で書いたようなユースケースの各項の名称などは、イマイチ統一されていません。
人やプロジェクトによって、同じものを違う名前で呼んでいることがよくありますので、気をつけてください。
0 件のコメント:
コメントを投稿