雀の日記スマートフォン用の表示で見る雀の日記この広告は、90日以上更新していないブログに表示しています。2017-04-30ユースケースOOAでは機能要求を「ユースケース図」に記述する。「ユースケース図」にはユースケースの説明文として以下のような「ユースケース記述」が付与される。主処理フローはメインフローに記述されるがケースにより代替フロー、例外フローも記述される。フロー開始時の条件は事前条件、終了時の条件は事後条件、ビジネスルールなどは事前事後に適用される不変条件として記述する。ユースケース図の各要素(特にフローと条件)はイテレーティブに記述が追記・変更されることが前提である。【ユースケース名】商品を購入する【概要】本ユースケースは、Web上および店頭で商品を購入する際に呼び出される。エンタープライズ参照ユースケースはユースケース名を決めた時点で粒度が決まるが、その粒度を小さくしすぎて機能数が増大してしまう落とし穴がある。これを回避するため「ユーザの認識できる言葉」でユースケース名をきめていく必要がある。機能単位をユースケースにするなユースケースの単位を、機能分割の感覚で作ってしまいます。そのようなユースケースは、ユーザーの視点から見ると時系列を伴うものが多く、時系列を表すすべがないユースケース図には不適切であり、また、ユースケースの個数が膨大になってしまいます。DBが変わったりFWやPGLがかわってもユースケースには影響しない。データベースがどこにあるかなどは問題ではないよくある誤解が、例えば「商品を登録する」というユースケースの中にデータベースが存在すると勘違いしてしまうことです。この勘違いから、「商品を参照する」というユースケースに関連を持つアクターからも「商品を登録する」に関連を引いてしまいます。エンタープライズ参照ユースケースには変更されやすいホットスポット、変更されにくいコールドスポットがある。コールドスポットがあるユースケースにはBRが含まれることが多い。逆にBRがないユースケースはホットスポットとなりやすい。優先順位が高いのは前者だ。ロバストネス分析でBRの数を数えればそれが開発優先順位の指標となる。数が多い方が優先順位が高い。変わりにくい、またはビジネスにとって重要なユースケースから始めるのだ。最後に洗い出されたユースケース全体を眺めて粒度をそろえる。神がシステム開発を変える神がシステム開発を変える神がシステム開発を変えるユースケースの推敲ユースケース月別アーカイブはてなブログをはじめよう!chungzeeさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。