はじめての設計をやり抜くための本 第2版 概念モデリングからアプリケーション、データベース、アーキテクチャ設計、アジャイル開発まで

095

導

入

編

1

設

計

編

ア

キ

テ

ク

チ

ャ

編

2

3

4

5

6

7

3

ユースケース 分 析

　次に、ユースケース分析に話を進めます。

ユースケースとは

　ユースケース分析は、要件定義として行われることが一般的です。もしか

したら、皆さんが設計者として開発プロジェクトに携わる時には、すでに作

成済みかもしれません。その場合は、ここから先の説明は読み飛ばしていた

だいてもかまいません。ただ、ユースケースから画面や外部システムI/Fな

どの外部仕様を導き出すので、「ユースケースとは何で、どのようなものか」

というユースケースの概要くらいは知っておく必要があります。

　ユースケース分析が要件定義の中で行われる場合は、ユースケースを記述

するのはシステム開発のユーザー企業側かもしれません（図3-2）。

　従来は、要件定義書といっても、Wordなどを使って文章で書かれたもの

でした。そこには標準的な規約も基準もありません。設計者の考えた章立て

や構成で、設計者の頭の中の要件が文章で書かれているだけです。時には、

記述の粒度もレベルも関係なく、ただ箇条書きになっているだけのものもあ

ります。まさに、雲のようなモヤモヤしたものなのです。システム開発側

は、その要件定義書から不明事項を質問したり行間を読んでみたり、四苦八

苦しながら検討して開発の見積りを行います。そのため、SE（システムエ

ンジニア）と呼ばれる顧客の業務に詳しい人が、提案や見積り段階から参加

して要件定義書の曖昧さを埋めるのです。しかし、ユースケースを使うこと

で要件の粒度や表記方法に統一感ができ、その後の開発が行いやすくなりま ...