要件定義と振る舞いの設計｜ユースケース・DFD・活動図・シーケンスを使い分ける

画面の順番は合っているのに、予約が二重に入る。データの流れは描けても、入力エラーの後に何を表示するかが決まらない。設計図は、それぞれ別の問いへ答える道具です。一つの業務要求を複数のモデルで表し、同じ条件と結果を扱っているかを確認します。

この記事で理解すること

• 機能・非機能要件と受入条件を、利用者の目的から具体化する。

• ユースケース、DFD、活動図、シーケンス、画面遷移の表す内容を区別する。

• 入力・データ・処理順・エラー・画面の間で同じ要求を満たすか検証する。

架空の会議室予約サービスを例にします。利用者は予約と自分の予約取消を行い、管理者は会議室情報を管理します。会議室IDや予約IDは整数です。予約時間は開始以上・終了未満の半開区間とし、同じ会議室の有効な予約の重なりを禁止します。特定製品の画面や運用を前提にしません。

要求から要件へ：何を満たすかを確認できる形にする

要求は関係者が求めること、要件はシステムや業務が満たす条件として具体化したものです。機能要件は予約登録や取消等の振る舞いです。非機能要件は応答性能、利用できる時間、運用やセキュリティ等の条件で、数値や対象範囲がなければ評価がぶれます。

たとえば性能の受入条件なら、要求の種類・データ量・負荷・測定区間を定めて応答時間を評価します。「速い」という言葉だけでは合否を決められません。指標と計算の詳しい意味は性能設計の記事にまとめます。計画の範囲と変更承認も別記事です。

モデルを選ぶ：同じ図へ全部を詰め込まない

画面遷移は利用者が見る画面と、操作や結果による移動を表します。データモデルは保存する対象と関係を表します。図の矢印がデータ、処理順、メッセージ、画面の移動のどれなのかを確認し、同じ意味だと決め付けないようにします。

ユースケース：利用者の役割と達成する目的

アクターはシステムとやり取りする役割で、人の名前や画面の部品ではありません。利用者、管理者、外部システムなどが対象です。ユースケースは、アクターがシステムを使って得る価値のある結果を表します。「予約する」「予約を取り消す」がこの例の目的です。

一般的なユースケース図は、楕円で目的を、アクターとの線で関連を示します。システムの境界と外部の役割を区別します。線は通信の時系列や画面の表示順ではありません。includeは組み込む共通の振る舞い、extendは条件付きで追加する振る舞いという違いがあり、単なる前後順として使いません。

図だけでなく、開始条件、基本の流れ、代替の流れ、成功時と失敗時の結果を書きます。予約では、条件を選ぶ、サーバが検証する、重複がなければ登録する、予約IDを返す流れです。重複時は登録せず修正へ戻る代替経路であり、DB接続失敗等の技術的な例外とも区別します。

図：利用者と管理者の役割、システムの境界、目的を対応付けます。

DFD：どのデータが、どの処理と保存先を通るか

DFDは外部実体、処理、データストア、データフローでデータの流れを表します。この例の利用者が外部実体、予約を登録する機能が処理、予約記録がデータストア、予約内容や登録結果がデータフローです。処理はデータを受けて変換等を行います。

この表はDFDの対応を文章で示したものです。正式な図は図法に従う処理・保存先・外部実体の記号と、データ名を付けた矢印で表します。利用者から保存先へ直接線を引くのではなく、データを検証・処理する箇所を介します。

DFDの矢印を「はい」「いいえ」の分岐や、時間の順序として読みません。判断や実行順は活動図等で表します。処理を詳細へ分解するときは、上位で出入りするデータが下位の処理でも対応するようにし、根拠のないデータを突然出力させないようにします。

図：予約内容、結果、新しい予約情報、既存の予約時間というデータの流れを示します。

活動図：処理の分岐と並行を表す

活動図は動作と制御の流れ、条件分岐や並行する処理を表します。判断には条件を付け、どの経路へ進むかを明示します。合流は選ばれた代替経路をまとめ、フォークとジョインは並行経路を分けて同期するための要素です。分岐と並行開始を混同しません。

「検証OK？」が真になる条件を説明できるようにします。開始が終了より前、会議室が有効、権限がある、既存予約と重ならない等です。図に一つの判断を置いただけで、並行要求の間でも正しく登録できるとは限りません。

シーケンス：参加者のやり取りを時系列で確認する

シーケンス図は参加者のライフラインと、やり取りするメッセージの順を表します。この教材では上から下へ進みます。同期呼出しは結果を待つ呼出し、非同期通知は相手へ通知して継続できる方式などとして区別します。実装でどちらを使うかは応答待ちと失敗処理に影響します。

別の要求が同時に進むと、空き確認から登録までの間に状況が変わります。「空き」と判断した結果を画面で保持するだけでは、R2を満たせません。サーバ・DBで、競合しても重複を確定して防ぐ処理が必要です。トランザクションや排他の詳細は別記事の範囲です。

alt等の組合せフラグメントを使う図では条件付きの代替経路を、loopでは繰返しを示します。正常系の図にAPIへの要求があっても、失敗時の戻り値と画面処理が別に必要です。予約IDを返す前に登録が確定しているか、失敗なのに完了画面へ進む矛盾がないかを点検します。

画面遷移と入力検証：修正・取消・再送を決める

画面側の検証は早く修正を促すために有用ですが、サーバ側の検証の代わりではありません。入力値の型・範囲・開始と終了の関係・会議室の存在・操作権限をサーバで確かめます。取消する予約IDを入力できても、他人の予約を取り消す権限があるとはいえません。

重複時間は、既存の開始 < 新しい終了、かつ新しい開始 < 既存の終了で判定できます。半開区間なので、既存10時～11時と新規11時～12時は重なりません。条件の境界を画面とサーバで一致させます。SQLiやXSS等の対策はWeb攻撃の記事へ分け、入力検証だけで全攻撃を防ぐとは説明しません。

二度押しや通信失敗後の再送でも、同じ要求を二重に登録しない条件を決めます。画面ボタンを無効にするだけでは、再送や別の呼出しを防げません。結果が不明なときに、登録済みか確認できる識別と応答の仕組みも含めて設計します。

モデル間の整合：同じ要件から結果へつながるか

R2なら、ユースケースの重複時の代替経路、DFDの既存予約データ、活動図の判断、シーケンスのDB処理、画面の拒否理由が対応します。一つのモデルでだけ重複を検査し、別のモデルでは無条件に登録するなら矛盾があります。

要件IDを、モデルの処理、入力条件、データ、確認項目へ対応付ける追跡可能性を持たせます。要件が変わったとき、どこを修正・再確認するかが分かります。図を増やすこと自体を目的にせず、未定の条件と例外を見つけるために使います。

演習1：目的の粒度

条件：利用者は会議室を予約したい。画面には入力ボタンがある。

問い：ユースケースの目的には何を置くか。

解答例：会議室を予約する。利用者が得る業務上の結果を表す。

根拠と誤答の確認：ボタンを押すという部品操作だけでは目的を十分に表しません。

演習2：DFDの矢印

条件：利用者から予約登録処理へ予約内容を送る。

問い：矢印は何を表し、何を表さないか。

解答例：予約内容というデータの流れを表す。真偽の分岐や時系列の全てを表すものではない。

根拠と誤答の確認：図の種類ごとの矢印の意味を区別します。

演習3：重複時間

条件：既存は10時～11時、新規は11時～12時。半開区間とする。

問い：時間が重なるか。

解答例：重ならない。新しい開始11時が既存の終了11時より小さい条件を満たさない。

根拠と誤答の確認：終了時刻を含む区間と混同しません。

演習4：同時登録

条件：二要求がどちらも空きを確認してから、別々に登録する。

問い：何を要件として補うか。

解答例：競合しても同じ部屋の重複時間を登録しないよう、確認と登録を一貫して実施する。

根拠と誤答の確認：空き確認を一度行ったことだけでは競合を防げません。

演習5：画面だけの検証

条件：ブラウザで他人の予約IDを選べないようにした。

問い：取消の認可として十分か。

解答例：十分ではない。サーバで対象予約と利用者の権限を検証する必要がある。

根拠と誤答の確認：画面の選択制限はサーバへの直接要求を防ぐ保証ではありません。

演習6：例外と表示

条件：登録が失敗したのに、画面が完了へ進み予約IDを表示しない。

問い：どの整合を確認するか。

解答例：APIの成功・失敗応答と画面遷移、ユースケースの結果を対応付ける。

根拠と誤答の確認：正常系の表示だけを作り、失敗時も同じ遷移にしません。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。公式・教育機関の資料で仕組みを確認し、特定年度の問題本文を前提にせず学べる構成にしています。

IBM ユースケース

IBM 活動図等のモデル

IBM DFDの要素と目的

IBM シーケンス図

IPA APシラバス

関連テーマを続けて学ぶ

状態とイベント｜状態遷移・タイマー・割込み・メッセージの順序を追う

E-R図とキー

Web攻撃と対策

性能設計と評価

プロジェクト計画と変更管理

記述式の設問と本文根拠の読み方