ユースケース駆動開発実践_要件定義

前回ユースケース駆動開発の流れを掴めたので実際に開発を進めてみたいと思います。以下のECサイトの機能要求からドメインモデリングユースケースを行いたいと思います。

 - ユーザはログイン画面でユーザ名、パスワードを入力してログイン認証が行えます。
 - ユーザはショッピングカートに商品を入れることができる
 - ユーザはショッピングカートに入れた商品の品目を参照できる。
 - ユーザはショッピングカートに入れた商品の品目を更新できる。
 - ユーザはショッピングカートに入れた商品を購入できます。
 - ECサイト管理者は商品カタログの登録が行えます。
 - 商品カタログ上の商品が購入対象になります。
 - ショッピングカートに商品を入れた後に商品の金額に変更がある場合、ユーザに通知のみ行いカートに入れたままにします。
 - 商品の支払方法としてクレジットカードと銀行支払いがあります
 - ECサイト管理者は1回限り利用できるクーポンコードの発行を行えます。
 - ユーザは商品の購入手続き時にクーポンコードを入力できます。
 - 商品の購入手続き後3日以内に入金が行われないと
 - 支払い手続き完了後商品が発送されます
 - 商品の発送および在庫管理は外部のシステムと連携します
 - 発注先の住所は個人情報から選択、または手入力が行えます。
 - 商品の発送前であればキャンセルが行えます。入金後のキャンセルでは払い戻しが行われます。
 - 購入時の合計金額が3000円未満であれば、一律で200円の発送料金がかかります。
 - ユーザは購入履歴を確認できます    
 - 他システムとスムーズに連携を行えるようにします。

機能要求の一覧があったらまず一つ一つの要求に疑問がないかを見直してみます。例えば以下のような疑問が出てくるかと思います。

  • ユーザはログイン画面でユーザ名、パスワードを入力してログイン認証が行えます。
     → 機能要求の一覧についてユーザ登録の内容は含まれていなかったが、ユーザIDやパスワードにバリデーションチェックはあるか
  • ユーザはショッピングカートに商品を入れることができる
     → 商品を見つけるまでにどのような導線があるか
  • ユーザはショッピングカートに入れた商品の品目を参照できる。
     → 具体的に何が見えれば良いのか
  • ECサイト管理者は商品カタログの登録が行えます。
     → ECサイト管理者はどのようにログインするのか?
    ECサイト管理者向けサイトにはアクセス制限があるのか? 商品カタログとは何、どんな情報を持っているのか?
    例えば商品の取り扱い開始日の設定などあるのか?

このように機能要求を具体化していく上でうまれる疑問点は最初のうちに割り出して顧客に投げるようにする。

疑問が落ち着いたら機能要求の一覧についてドメインに対する要求かシステムに対する要求かを分けて、ドメインに対する要求についてはポイントとなる単語を抽出します。

先に挙げた機能要求の一覧の中では 他システムとスムーズに連携を行えるようにします。 がシステムに対する要求になりましてドメインとは別でのアーキテクチャ側での対応が必要になります。

ドメインモデリング

それから、ドメインに対する要求について単語を抽出すると以下のようになります。
ショッピングカート 商品 品目 支払い方法 クレジットカード 銀行支払い クーポン 商品カタログ 発送 在庫管理 個人情報 発送料金 購入履歴 発送

次に用語間の関係を図示化する。 f:id:steavevaivai:20180430221438p:plain それぞれのオブジェクトに対して扱う内容に対してコメントをつけたり、コミュニケーションを取ることでチーム内での認識を合わせます。例えば 個人情報 のオブジェクトでは住所などの個人情報を扱うや、品目では対象の商品と数量、それからショッピングカートに入れた時点の金額と現在の金額に差がないか判断するためにその時点の金額を扱うなど。

ユースケースモデリング

次にユースケースモデリングを行います。ユースケースモデリングではアクターとシステム間とのやり取りを明確化します。 ユーザはログイン画面でユーザ名、パスワードを入力してログイン認証が行えます。

→ ユーザはログイン画面でユーザ名とパスワードを入力しログインボタンをクリックする。
  システムはユーザ名から対象のユーザアカウントを探してパスワードが一致しているかチェックする。
  パスワードの一致が確認できたらセッションにユーザアカウントの情報を保存し、TOP画面を表示する。
このようにアクターとシステムのやり取りを具体化していく。具体化する上でも新しく疑問点が出てくる、例えばログイン直後の画面に何を出すかなど出てくるので、疑問点はまとめて質問できるようにしておく。

以下のように関連する機能要求についてはまとめてしまった方が分かりやすいかもしれない
ユーザはショッピングカートに入れた商品を購入できます。
ショッピングカートに商品を入れた後に商品の金額に変更がある場合、ユーザに通知のみ行いカートに入れたままにします。
商品の支払方法としてクレジットカードと銀行支払いがあります
ユーザは商品の購入手続き時にクーポンコードを入力できます。
購入時の合計金額が3000円未満であれば、一律で200円の発送料金がかかります。
発注先の住所は個人情報から選択、または手入力が行えます。

 → ユーザはショッピングカートボタンをクリックする。
  システムは品目の一覧、それから合計金額が表示されたショッピングカート画面を表示する。商品の金額に変更があった場合はその旨を伝えるメッセージを表示する。
  ユーザはショッピングカート画面の購入手続きへボタンをクリックする。
  システムは支払い方法、配送先、クーポンコード入力項目がある購入手続き画面を表示する。この時システムはユーザに登録された住所とクレジットカードを選択の候補として選べるようにする。
  ユーザは支払い方法と配送先、クーポンコードを入力して注文内容確認ボタンをクリックする。
  システムは支払い方法、配送先、クーポンコードのバリデーションチェックを行う。それから合計金額を計算し3000円未満であれば配送料の200円を追加料金に加えた上で注文確認画面を表示する。
  ユーザは注文確定ボタンをクリックする。
  システムは注文の確定処理を行う、具体的に以下の処理を行なった上で注文確定画面を表示する。

  - 支払い方法がクレジットカードの場合は、外部システムのクレジットカードの決済処理を呼び出す。
  - 支払い方法が銀行振込の場合は、外部システムで振込用のワンタイム口座を作成して注文確定画面に口座の情報、支払い期限を表示する
  - 注文確定の時点で支払いが確定していたら外部システムにより発注の対象に追加する

このように具体的な内容になるようにしておく。

要求レビュー

元々あった機能要求に対して具体的にどんなものなのかの解釈を加えることでユースケースモデリングを行なったが、要求レビューではその方向性が間違っていないかを顧客やマネージャーを踏まえて確認する。 そのためにも簡単なモックの画像を用意するや、ドメインモデル中のオブジェクトを使った文章によりユーザとシステムの振る舞いで問題領域のカバーが行えるかを確認する。