Downloaded 22 times
More Related Content
![[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用](https://cdn.slidesharecdn.com/ss_thumbnails/withesmsmartphoneapplicationandcyclonecodename1000-111207215903-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
いまさらユースケース
- 1.
- 2. はじめに ここでは要求分析の作業のうち、「要求を伝 える」事を取り上げます ウォーターフォールモデルのいわゆる「要件 定義」ということではありません UML（Unified Modeling Language : 統一モデ リング言語）の一つであるユースケース図の 話もありますがソフトウェアエンジニアリン グの話ではありません 2
- 3.
- 4. こんなこと経験ありません こんな経験ありませんか？ か？ 「アンケー トでユー ザーの不満 「完璧だよ を調べた」 ね！いつ頃 「・・・よ できる？」 くわからな いからとり あえず×2倍 「何が必要 にしておこ とされてい う・・・」 るかも考え た」 開発者 「ビジネス インパクト も十分検討 曖昧なストーリー、 した」 曖昧な説明 4
- 5.
- 6. なぜそのような不幸が起こるの こんな経験ありませんか？ か？ 要求仕様は関係者に正確 に伝わっていましたか？ 6
- 7. こんな経験ありませんか？ プロジェクトの計画には要求仕様の策定が必 要 要求仕様の策定 要求 要求 シナリオ 規模の 期間に 見積も り 変換 計画 要求 要求 シナリオ 大変な思いをするプロジェクトは この部分の精度が悪かったり共有 できていなかったりする 7
- 8. こんな経験ありませんか？ 要求仕様を決める3つの活動 要求を収集する 行動観察 アンケート インタビュー など 要求を分析する 会議体 プロトタイプ ビジネスフロー など 要求を伝える フローチャート ユースケース 画面遷移 など 8
- 9. こんな経験ありませんか？ 実際に発生した問題 トップダウン式の曖昧な要求仕様では計画作り が困難です コミットメントされたスケジュールの中では、 後から気づいたシナリオを納期に合わせるため 開発サイドにしわ寄せがいきます これらが常態化すると開発サイドは「自衛」の ためスケジュールに多くのバッファを取るよう になります 9
- 10. このような問題を解決するた めの開発手法の提言は色々あ る。 ですが今回取り上げたい のはその前段の話 10
- 11. こんな経験ありませんか？ 経験して感じたこと どんな開発手法も要求分析は必要 仕様変更に柔軟なことと、要求仕様を曖昧なま まにしておいて良いということは意味が違う 「要求仕様書」を作ることを目的とすると余 計負担が増える 「要求仕様を伝えること」を目的とするのが 正解 11
- 12.
- 13. いつ誰がどのように？ いつやる？ 要求は常 に発生す 要求が発生したとき るものと 考えサイ クルには 企画する 組み込ま 設計／実 ない 計画 装 要求仕様を決め る テスト／ 要求分析 リリース 評価 ・要求を収集する ・要求を分析する ・要求を伝える 13
- 14. いつ誰がどのように？ 誰がやる？ 企画をリードする人、作る人、ビジネス上の 判断ができる人が一緒に行うのが効果的 ビジネス オーナー デベロッ マーケ パー ター 14
- 15. いつ誰がどのように？ どのようにやる？ 例えばレビュー時に要求をホワイトボードに書 き出す 決まったフォーマット、成果物は無い 綺麗に文書化するためのリソースは必要ない 手書きのレベルで十分 最低限何を満たしたいのか？（ゴールはどこ か？）を明確にする ゴールを満たすためのもっと手軽な代替手段はある かもしれない 15
- 16.
- 17.
- 18.
- 19. いまさら？ 19
- 20. 本気？ 20
- 21. 本気です 21
- 22. 超本気 22
- 23.
- 24.
- 25. ユースケースとは 要はシステム要件を洗い出すこと X販売システム 顧客はXを購入します 新規顧客の場合、顧客情報を登録します 決済手続きをします クレジット支払いが選べます 携帯支払いが選べます PayPal支払いが選べます
- 26. ユースケースとは UMLに従いモデル化すると理解が早い X販売システム クレジット 決済手続き カード <<include>> 携帯支払い Xを購入する 顧客 <<extend>> PayPal 新規顧客情 報を登録す る 26
- 27. ユースケースとは モデル化する目的は？ 要件の理解・共有が容易 登場人物（人に限らず）とその関係性を示せ ること（主語が明確になる） ビジネスサイド、開発サイドの双方で共通の 認識が持てる 27
- 28.
- 29. ユースケースとは ユーザーストーリーにも展開しやすい 3千円以上の購入で送料を無料にする 携帯支払いで支払う クレジットで支払う 決済手続き PayPalで支払う 購入後は決済番号をメールで通知する ・・・・・・ ・・・・・・ 29
- 30. ユースケースとは 気をつけるポイントは3つ そのユースケースでシナリオは立てられます か？ ユースケースから立てたシナリオは言葉で説 明できますか？ 適切に見積もりできる単位ですか？（大雑把 すぎず細かすぎない） 30
- 31.
- 32. ユースケース図の書き方 先ほどの図を例に X販売システム クレジット 決済手続き カード <<include>> 携帯支払い Xを購入する 顧客 <<extend>> PayPal 新規顧客情 報を登録す る 32
- 33. ユースケース図の書き方 サブジェクト X販売システム 開発対象であるシステム 33
- 34. ユースケース図の書き方 アクター ユーザーや連携する外部シス テムなど 顧客 34
- 35. ユースケース図の書き方 ユースケース システムの振る舞い Xを購入する 35
- 36. ユースケース図の書き方 汎化 クレジット 決済手続き カード 携帯支払い PayPal 抽象的な要素を具体的に表す 36
- 37. ユースケース図の書き方 include（包含） 決済手続き <<include>> Xを購入する 依存関係 例：Xを購入するには決済手 続きが必要 37
- 38. ユースケース図の書き方 extend（拡張） 拡張 条件によって行われる 例：新規ユーザーの場合は顧 客情報を登録する Xを購入する <<extend>> 新規顧客情 報を登録す る 38
- 39. ユースケース図の書き方 アドバイス 「ユーザーの行動」ではなく「行動したこと で得られること」=「システムが何をしてく れるか」を考えると書きやすい 例： 「氏名を入力」ではなく「ユーザー登 録」 登場人物は人に限らない 39
- 40. ユースケース図の書き方 悪いユースケース 開発者は細かくなりすぎ そうでないひとは簡単すぎ 40
- 41.
- 42. 最後に 42
- 43. ユースケース図を書くことを目的とし 最後に ない 多少UMLから外れても気にしない include とかextendとかは、大きいユース ケースを分割するテクニック。無理に使わな くていい 必要が無いならやらないことも大事 例えばプロジェクトの規模や難度によって判断 するなどの柔軟性をもたせる 43
- 44.