スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ユースケースメモ

ユースケース重要!(not 図、but 記述) - An Agile Way [ITmedia オルタナティブ・ブログ]

このページ何でメモったか忘れた。多分、要約レベル、ユーザ目的レベ ル、ユーザ機能レベル、サブ機能レベルのレベルに反応した?それと、 JUDEにユースケース記述の機能があること?


@IT:The Rational Edge Dr.ユースケースの “ユースケース人生相談”

ユースケースとファンクションポイントの関連性について。

そもそも、ファンクションポイントとは、システムの物理的レイアウ ト(例えば、テーブルやフィールドの数など)に大きく依存しており、 大部分はデータ駆動型になっています。
ということのよう。
参考「ユースケースポイント法:」(http://www.objectclub.jp/download/technicaldoc/else)


スポンサーサイト

ユースケースをどう設計書に反映するか

ユースケースを設計書に記述するためにどのように記述するかを考えた。
そもそも、ユースケース記述だけだと文字ばかりになってしまい、読む人に敬 遠されがちのため。
■機能との関係は

機能構成は、表を使って一覧で表現するのは必須->カタログスペック。

■カタログとして

設計書において、ユースケース図は、機能構成を俯瞰できるように使用 する。ユースケース記述は、ユースケース図をカタログとしてその説明 に1個1個書くようにする。

■図の網羅度は

ユースケース図は注目システムとアクターに関するもののみを書いた方 がいいのかもしれない。
注目システムとその背後にあるシステムのユースケースやより低レベル なユースケースを全て一緒に描こうとすると、関連がややこしくなる。 よって、図を見ても把握し難くなる。

分析から設計の過程において、ユースケースが詳細化(高度レベルを低 く)される。この詳細化の追跡と各レベル間のユースケースの関連をカタ ログ的に示すのにユースケース図が適しているということだと思ってま す。この各レベルのユースケースの関連は、ユースケース図の包含、拡 張、派生などの関連で表される。
しかし、この図を描こうとするといつも困っている。なぜなら、各ユー スケース間の関連を示す線が多過ぎて、わけがわかんなくなるから。ツ リー構造みたいになれば良いんだけれども、大抵そうはならない。
なんでかなぁ、以前からこの問題ですっきりしない...。
ユースケースと機能が、ごっちゃになっていているから?

ユースケース図は1つではない。
いっぱい書く。
いっぱい書いた場合、その図をどのように文書内に配置する?
概要として大枠なのが1つは必要と思われ。

■設計書への適用は

現在、最適と考えているのは、
以下の図の振り分けで業務フローとか運用フローとかへ記述する。
また、各図に対応したユースケース記述を加える。

  • 境界間の振舞いはシーケンス図
  • 境界内部の振舞いはアクティビティ図

機能とユースケース

機能とユースケースは1対1に対応するだろうか。恐らくしないでしょう。1対1に無理に対応させようと奮闘するよりも最初から別物として扱う方がいい気がする。

要求分析結果とか基本仕様とかで最初の最も高レベルなユースケースを抽出し、より低レベルのユースケースに詳細化してゆく。その過程でカタログスペックのような機能一覧の機能はどれかのユースケースに含まれるのではないか?だとすると、ユースケースの追跡性を記述しユースケースと機能の対応というか追跡は可能かなぁ。あれ...

ケーススタディ

ユースケースの例を参考にしたい場合に使えるサイトを集める。

ユースケース

UseCase.Org

Alistair Cockburnさんのサイト内ユースケース関連サイト。
テンプレートがある!

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。