設計のおおまかな流れ

要件定義系

• ここでのアウトプットが果たす目標としては、非開発部門とのコミュニケーションにおいて共通認識を合わせる助けとなるもの。
• それ単体で全てが説明されていることはなく、対面での説明ありきで考えてよい。

業務分析

• システム化の対象となる業務を観察・ヒアリングし業務フロー図に起こす。
• 業務フロー図ではレーン上にアクターを配置し、業務の流れに沿ってアクタ間の関係を記述する。
• 多数のアクターが存在して複雑な場合に、システム担当者と業務担当者の認識を合わせるのに役立つ。

ユースケース分析

• ユースケースとは「ある目的を達成するためのアクターからシステムへの操作と、それに対するシステムの振る舞いの関係」を表したもの。
• なぜユースケース分析を行うのかというと、その後の画面やIFを作成するのに必要な情報となるため。
• ユースケース分析のアウトプットとしては ユースケースシナリオであり、ある目的を達成するためのユーザー操作とそれに対するシステムの振る舞いを文章として記述する。
• システム実装の詳細までは踏み込まない。

ユースケースシナリオ

• 各ユースケースの構成要素としては以下のようになる。

構成要素	説明
ユースケース名	アクターがシステムで達成したい業務の概要を簡潔に表す
シナリオ	ユースケースでメインの構成要素であり、アクターの操作とシステムの振る舞いを1つずつ業務の流れに沿って文章化している。シナリオは実行順に番号が振られ、アクターの操作とシステムの反応が交互に書かれることが多い。
アクター	文字通り業務を実行するためにシステムを操作する人。基本的には主アクターと
拡張シナリオ	あるシナリオが正常に実行されなかった場合を記載する。
事前条件	ユースケース実行前に保証されていること。
事後条件	ユースケース実行後に保証されているもの。ユースケースが成功した場合に保証される内容と失敗しても保証されている内容がある
トリガー	ユースケースを実行するイベント。

ユースケース図

• ユースケース図ではアクターとシステムの相互作用を表す。
• 最近は書かない現場も多いらしいが、ユースケースシナリオが表やリストで書かれているため全体が見えにくいという弱点をカバーすることはできる。
• ただし、ユースケース図固有のルールが共有されていることが前提となっており、その知識レベルに格差があると書き手と受け手の間で誤解が生じやすいデメリットがある。