<プロジェクト名>
ユースケース仕様書: <ユースケース名>
バージョン <1.0>
[メモ: 次のテンプレートは、Rational Unified Process で使用することを目的に提供されたものです。 大括弧で囲まれた青色のテキスト (style=InfoBlue) は、 作成者に対する説明用ですので、本文書を公開する前に削除してください。 このスタイルの後に入力した段落は自動的に通常の形式 (style=Body Text) に設定されます。]
改訂履歴
日付 |
バージョン |
説明 |
作成者 |
<yy/mm/dd> |
<x.x> |
<詳細> |
<名前> |
|
|
|
|
|
|
|
|
|
|
|
|
目次
ユースケース仕様書: <ユースケース名>
[以下のテンプレートは、「ユースケース仕様書」の作成用に用意されているもので、 ユースケースのテキスト・プロパティーが記載されています。 この文書は、 Rational RequisitePro などの要求管理ツールと併用して、ユースケースのプロパティーに該当する要求を明確にし、特定することをその目的としています。
ユースケース図は、Rational Rose のようなビジュアル・モデリング・ツールを使用して作成できます。 ユースケース・レポート (および全プロパティー) は、Rational SoDA で作成できます。 詳しくは Rational Unified Process のツール・メンターを参照してください。]
[ユースケースの目的を簡潔に記述します。1 段落にまとめるようにしてください。]
[このユースケースは、アクターが何かアクションを行うと開始されます。 ユースケースを開始するのは常にアクターです。 ユースケースでは、アクターが行うアクションの内容と、それに対するシステムの応答を記述します。ユースケースの表現は、アクターとシステムの対話形式にする必要があります。
ユースケースは、システム内で何が行われるかを記述するもので、それがどのように、なぜ行われるかという内容を記述するものではありません。 情報が交換される場合は、どのような情報がやりとりされるかを具体的に指定します。 例えば、アクターが顧客情報を入力する、という表現はあまり明確ではありません。 アクターが顧客の住所と氏名を入力する、という表現の方が適切です。 一般に、用語集を作成すると、複雑なユースケースの管理に役立ちます。 顧客情報などの用語を用語集に定義しておけば、ユースケースを細部まで明快に表現できます。
代替フローがあってもそれが単純な場合は、ユースケースの本文中に入れることができます。代替フローがある場合の内容をほんの数行で記述できる場合は、別立てせずに直接「イベント・フロー」セクションに記述します。代替フローが複雑な場合は、独立したセクションに記述します。 例えば、「代替フロー 」サブセクションを設けて、より複雑な代替フローの記述をどのようにするか、その方法を説明します。
明確で単純な文章は何にも代えがたいですが、時には図のほうが、長々とした説明よりもわかりやすい場合があります。図で説明したほうがわかりやすい場合は、ユーザー・インターフェース、プロセス・フロー、その他の説明図をユースケースに自由に貼り付けてください。フローチャートを利用したほうが、複雑な決定プロセスを表すのに便利と思われるならば、迷わずに使ってください。 同様に、状態に依存する振る舞いを表現する場合も、多くの場合、状態遷移図を使用したほうが、文章を何ページも書き連ねるより、システムの振る舞いを明確に表現できます。問題に応じた適切な表現媒体を使用する一方で、対象読者が理解できないような専門用語、概念、図などを使用しないように注意します。目的は、あくまでわかりやすい表現で、わかりにくくすることではありません。]
[複雑な代替フローについては、「イベント・フロー」セクションのサブセクション「基本フロー」から参照される形で独立したセクションに記述します。この「代替フロー 」サブセクションは、代替的な振る舞いと考えてください。各代替フローは、通常、メイン・フローでの例外発生による代替的な振る舞いを表しています。このサブセクションの長さは、この代替的な振る舞いに関連するイベントを説明するのに必要な長さをとってかまいません。 代替フローが終了した時点で、メイン・フローのイベントが再開されます。]
[代替フローは、さらにサブセクションに分割したほうがわかりやすければ、そのようにすることができます。]
[多くの場合、1 つのユースケースには、複数の代替フローがあります。 各代替フローは、わかりやすくするため個別に記述します。このように代替フローを使用することにより、ユースケースの読みやすさが向上します。 また、代替フローには、1 つのユースケースの中が複数のユースケースの階層に分解されることがないようにする働きもあります。ユースケースは言葉による記述にすぎず、その主な目的は、システムの振る舞いを 明確に、簡潔に、わかりやすい方法で表現することであることを忘れないでください。]
[特殊要件は、通常、ユースケースに固有の機能外要求ですが、 ユースケースのイベント・フロー内のテキストでは簡単にまた自然な形では記述できません。特殊要件の例としては、 法規制の要件、アプリケーション規格、作成するシステムの品質属性 (使いやすさ、信頼性、性能、 サポートのしやすさの要求など) があります。また、オペレーティング・システムとオペレーティング環境、 互換性の要件、設計上の制約など、その他の要件もこのセクションに明示する必要があります。]
[ユースケースの事前条件は、ユースケースの実行前にあらかじめ整っていなければならないシステムの状態です。]
[ユースケースの事後条件は、ユースケース終了直後におけるシステムの可能な状態の一覧です。]
[ユースケースの拡張点]
[イベント・フロー内での拡張点の位置をここに定義します。]