ユースケース分析

「要求を記述しろなんて言われても漠然としすぎていて書けない」という方に お勧めするのが、「ユースケース分析」と呼ばれる手法です。ユースケースと は「使われ方」のことです。このシステムを誰がどんな時にどうやって使うか を列挙するのがユースケース分析のやり方です。

ユースケース分析では、まずそのシステムを使う人の「立場」を列挙します。 例えば「お客さん」「システム管理者」「社長」「バイトの店員」などです。 これらを「アクター」と呼びます。そして、次にその人達がシステムを使って 何をするのかを列挙します。この「すること」を「ユースケース」と呼びます。 そしてそれぞれのユースケースについて制約条件や関連を記述します。

楽曲データベースでは、アクターとして次の人が考えられます。

アクターの説明には「何をしたくてシステムに向かう人か」を記述します。 「何をする人か」は厳密に書く必要はありません。それはこれから明らかにし ていく事ですから。

同じ人が複数の立場を兼ねる事もあります。例えば上の例では「管理者」が 「情報提供者」であることもあります。しかしこの場合でも、使う人は立場を はっきりさせた上でシステムに向かいます。いくらその人に管理者権限があっ ても、その人が情報提供者としてシステムにログインした場合には、管理者と しての機能は提供しなくていいのです。

それができたら、次にそれぞれのアクターについてどんな事をするかを記述し ます。例えば楽曲データベースシステムでは次のような表になります。

このような表を作ってみると、いろいろな疑問点や注文が浮かんでくるはずで す。例えば、「他人が書いた情報の間違いも訂正できるようにしたい」とある が本当にいいのでしょうか？セキュリティの問題と運営ポリシーに関わる問題 です。これをどうするかというのは「後で決めればいいこと」ではなく「今決 めなくてはならない問題」です。なぜならこれをどうしたいかは顧客しだいな ので技術者からは何も言える事はないからです。^[1] ここでは、情報提供者は個人的な知り合い同 士であって、もし何かトラブルが起きたら当事者同士で解決することにしてお きます。

このユースケース表ができたら、それぞれの項目について数量や頻度、程度を 追加します。例えば「楽曲のエントリは何項目くらいあるのか」「情報提供者 は何人くらいか」「どのくらいの頻度で情報が更新されるか」といったことで す。数字はだいたいでかまいません。上限の数を書くことができればなお結 構です。

それぞれのアクターについてもコメントが必要です。「情報提供者」のコンピュー タスキルはどうなのか、という情報は、「情報をXMLに書いてメール添付」な んて方法が取れるのかそれとも専用のインターフェースを作らなければいけな いのかといった実現方法に関わってきます。管理者が自分だけなら、データベー スの復旧も特にインターフェースとして持たせる必要はないかもしれません。

この段階ではどんなタイプのシステムなのかは全く考えられていないことに注 意して下さい。楽曲リストを見るのはWeb上なのか、あるいは専用のビューア を使うのか、はたまたFAXで配信するのか、それは今考えるべきことではあり ません。実際のところ、Web上で表示させるのもFAXで配信するのも設計として はたいした違いはありません。それより(上で書いた)セキュリティの問題や運 用ルールなどの方がずっと重要な問題なのです。