# 受発注管理システム ユーザーストーリー仕様書（サンプル） ## このドキュメントについて 本ドキュメントは、中堅卸売業を想定した「受発注管理システム」の **業務上の振る舞い** を、非エンジニア（経営者・事業責任者・現場リーダー）が読んで仕様確認できる形で記述したサンプルです。実プロジェクトでこの形式を真似て書き、開発会社との認識合わせに使ってください。 - **目的**: 各ユースケースで「誰が」「何の目的で」「どの画面で」「どう操作したら」「どうなる」のか、業務観点で合意を取る - **想定読者**: 非エンジニア。実装上の技術用語は使用しない - **粒度**: 画面と操作と結果のみ。実装手段（DB設計・API・フレームワーク）は記述しない - **使い方**: 各章末の「確認チェック」を読み、現場運用に照らして「この通りでよい／この点を変えたい」を書き込んでもらう - **記法**: シナリオは **EARS（Easy Approach to Requirements Syntax）** で記述する。各要求は1文で「いつ／どういう時／どういう状態の時／どういう機能オプションの時、システムは何をすること」を述べる。下記「EARS記法について」を参照 ## 用語 | 用語 | 説明 | |---|---| | 営業担当者 | 顧客から注文を受け付け、システムに登録する社内ユーザー | | 在庫担当者 | 入荷検品・在庫引当・出荷準備を行う倉庫の社内ユーザー | | 顧客 | 当社から商品を仕入れる取引先（法人）。システムには直接ログインしない | | 商品マスタ | 取り扱う商品の単価・JANコード・安全在庫数などの基本情報の集合 | | 顧客マスタ | 取引先企業の社名・与信限度額・支払条件などの基本情報の集合 | | 注文 | 顧客から受けた1回分の発注内容。複数明細（商品×数量）を持つ | | 引当 | 注文に対して在庫を確保し、出荷予定として状態を変えること | | 安全在庫 | これを下回ると発注検討が必要になる、商品ごとの最低在庫数 | ## アクター | アクター | できること | 利用画面 | |---|---|---| | 営業担当者 | 顧客マスタを登録する／注文を新規登録・修正する／注文一覧を確認する | 営業画面 | | 在庫担当者 | 入荷を登録する／注文に対して在庫を引き当てる／在庫一覧を確認する | 在庫画面 | | システム | 安全在庫を割り込んだ商品を検出して担当者に通知する／日次の注文サマリを生成する | （画面なし。メール通知や状態変化として表れる） | ## 画面構成（全体マップ） - **営業画面**: ダッシュボード、顧客一覧、顧客詳細・編集、注文一覧、注文新規登録、注文詳細・編集、商品一覧 - **在庫画面**: ダッシュボード、入荷一覧、入荷登録、引当待ち注文一覧、引当作業画面、在庫一覧 - **共通**: ログイン、パスワード再設定、プロフィール ## EARS記法について EARSは要求文を5種類の定型パターンで書く記法です。曖昧さを減らし、テスト可能性と合意形成のしやすさを高めます。 | 種別 | 形式 | 用途 | 例 | |---|---|---|---| | **常時（Ubiquitous）** | システムは〈応答〉すること | 常に成立する基本要求 | システムは画面右上にログイン中のユーザー名を表示すること | | **イベント駆動（Event-driven）** | 〈トリガー〉した時、システムは〈応答〉すること | 利用者操作・外部イベント駆動 | 営業担当者が「注文確定」ボタンを押した時、システムは在庫担当者に引当依頼の通知を送信すること | | **状態駆動（State-driven）** | 〈状態〉の間、システムは〈応答〉すること | 状態依存の挙動 | 顧客の与信限度額を超過している間、システムは新規注文の確定ボタンを無効化すること | | **オプション（Optional feature）** | 〈機能を含む構成〉の場合、システムは〈応答〉すること | プラン依存・機能フラグ | 自動発注機能が有効である場合、システムは安全在庫を下回った商品の発注書を仕入先へ自動送信すること | | **異常系（Unwanted behavior）** | 〈条件〉の場合、システムは〈応答〉すること | 失敗・拒否・誤操作 | 注文数量が在庫数を超える場合、システムは確定を拒否し「在庫不足のため確定できません」と表示すること | ### 要求IDの付け方 各要求文には一意のIDを付けます。本書のシナリオセクション内では以下の形式とします。 ``` REQ-{ユースケースID}-{連番3桁} ``` 例： - `REQ-SA-1-001`：SA-1の1番目の要求 - `REQ-WH-1-101`：WH-1の101番目（異常系）の要求 - `REQ-SY-1-201`：SY-1の201番目（境界値）の要求 連番は「正常系=001番台」「異常系=101番台」「境界値=201番台」を慣例とし、後から要求が追加されても末尾に追加できる構造とします。 ### 各要求文の付帯情報 各要求文には以下を併記します： - **種別**: 上記5種類のどれか - **優先度**: 必須 / 推奨 / 任意 - **由来**: 元仕様の章番号、ヒアリング議事録の項番、運用要望のいずれか（追跡可能性の確保） 書式例： ```markdown - **REQ-SA-1-001**（イベント駆動・必須・由来:SA-1元仕様） 営業担当者が注文新規登録画面で顧客・商品・数量を入力し「確認画面へ」ボタンを押した時、 システムは注文確認画面に遷移し、入力内容と合計金額を一覧表示すること。 ``` ## ドキュメントの章構成 各ユースケース章は以下の定型で記述します： - **概要**: そのユースケースで何が達成されるか（1〜3文） - **登場人物**: 主役と関係者 - **ビジネス価値**: なぜ提供するのか - **前提**: 操作開始時に何が成立しているか - **シナリオ（要求文 / EARS形式）**: - **正常系**: 想定通りに進む典型ケース（イベント駆動・状態駆動・常時）3件以上 - **異常系**: 失敗・拒否・誤操作（異常系パターン）3件以上 - **境界値**: 数や期間や文字数の境目（イベント駆動 + 数値条件）必要に応じて - **画面で見えるもの**: ボタン・項目・表示内容（用語確認用） - **メール／通知**: 発火条件と本文の要点（必要な場合のみ） - **確認チェック**: 非エンジニアが「この仕様でOK」と判定するためのチェックリスト ## 部構成 - **第1部**: 営業担当者ユースケース [SA-1〜SA-2] - **第2部**: 在庫担当者ユースケース [WH-1] - **第3部**: システム／自動処理ユースケース [SY-1] 合計4ユースケース。実プロジェクトでは20〜70ユースケースになることが一般的です。 --- # 第1部 — 営業担当者ユースケース 営業担当者は、顧客からの注文を受け付け、システムに登録する社内ユーザーです。本部では注文登録と顧客マスタ管理を扱います。 --- ## SA-1. 注文の新規登録 ### 概要 営業担当者が顧客からの注文を、画面で「顧客 → 商品 → 数量 → 確認 → 確定」の順で登録する業務フローです。確認画面で内容と合計金額を見直してから確定できるため、入力ミスが顧客に届く前に発見できます。 ### 登場人物 - **主役**: 営業担当者 - **関係者**: 在庫担当者（注文確定を受けて引当作業を行う）、顧客（注文内容の発注元） ### ビジネス価値 - 営業にとっての価値: 紙の注文書を手書きで処理していた工程をシステム化することで、転記ミスがなくなり、確定まで数分で完了する。 - 在庫部門にとっての価値: 注文確定と同時に引当依頼が自動で届くため、紙のFAXを待たずに即座に出荷準備に入れる。 - 経営にとっての価値: 受注履歴がデジタル化され、月次の売上集計が自動化される。 ### 前提 - 営業担当者はログイン済みである - 注文対象の顧客が顧客マスタに登録済みである - 注文対象の商品が商品マスタに登録済みである ### シナリオ 各要求文はEARS形式で記述します。`REQ-SA-1-XXX` は本章内の要求IDです。 #### 正常系 - **REQ-SA-1-001**（イベント駆動・必須・由来:SA-1元仕様） 営業担当者が注文新規登録画面で顧客・商品・数量を入力し「確認画面へ」ボタンを押した時、システムは注文確認画面に遷移し、入力内容と合計金額（税抜・税込）を一覧表示すること。 - **REQ-SA-1-002**（イベント駆動・必須・由来:SA-1元仕様） 営業担当者が確認画面で「確定」ボタンを押した時、システムは注文を確定状態として保存し、画面に注文番号と「確定しました」メッセージを表示すること。 - **REQ-SA-1-003**（イベント駆動・必須・由来:SA-1元仕様） 注文が確定された時、システムは在庫担当者の引当待ち一覧に当該注文を追加し、在庫担当者に通知を送信すること。 - **REQ-SA-1-004**（イベント駆動・推奨・由来:SA-1元仕様） 営業担当者が確認画面で「戻る」ボタンを押した時、システムは入力画面に戻り、直前に入力した顧客・商品・数量の値をすべて保持して再表示すること。 - **REQ-SA-1-005**（常時・必須・由来:SA-1元仕様） システムは注文新規登録画面で、商品を選択した時点で当該商品の現在庫数と単価を即座に表示すること。 #### 異常系 - **REQ-SA-1-101**（異常系・必須・由来:SA-1元仕様） 注文数量が現在庫数を超える場合、システムは確定を拒否し「在庫不足のため確定できません。在庫担当者に補充を依頼してください」と赤字で表示すること。 - **REQ-SA-1-102**（異常系・必須・由来:SA-1元仕様） 顧客の与信限度額を超過する金額の注文を確定しようとした場合、システムは確定を拒否し「与信限度額を超過します。経理部に確認してください」と表示すること。 - **REQ-SA-1-103**（異常系・必須・由来:SA-1元仕様） 「確定」ボタンが処理中の間、システムは同ボタンを再度押せない状態にし、二重登録を防止すること。 - **REQ-SA-1-104**（異常系・推奨・由来:SA-1元仕様） 通信が一時的に不安定で「確定」ボタン押下に対する応答が10秒以上得られない場合、システムは「ネットワークエラーが発生しました。再度お試しください」と表示し、利用者の再操作で再試行できるようにすること。 #### 境界値 - **REQ-SA-1-201**（イベント駆動・必須・由来:SA-1元仕様） 注文数量が現在庫数とちょうど同数の時、システムは確定を許可し、当該商品の現在庫数を0として更新すること。 - **REQ-SA-1-202**（異常系・必須・由来:SA-1元仕様） 注文数量が0または負の数の場合、システムは確認画面に進めず「数量は1以上を入力してください」と表示すること。 ### 画面で見えるもの | 要素 | 内容 | |---|---| | ページタイトル | 「注文 新規登録」 | | 入力欄 | 顧客（プルダウン検索）、商品行（商品プルダウン×数量、複数行追加可） | | 表示項目 | 商品単価、現在庫数、明細小計、合計（税抜／税込） | | ボタン | 「明細を追加」「確認画面へ」「戻る」「確定」 | | エラー表示 | 該当欄の下に赤字で表示 | ### メール／通知 - 注文確定時：在庫担当者宛に「新しい引当依頼があります（注文番号: ○○）」を画面通知＋メール送信 ### 確認チェック - [ ] 営業担当者は1つの注文に複数商品を含めて登録できる - [ ] 確認画面で合計金額（税抜・税込）が確認できる - [ ] 在庫不足の注文は確定できず、画面でその理由が分かる - [ ] 与信限度額を超過する注文は確定できず、画面でその理由が分かる - [ ] 確定すると在庫担当者に自動的に通知が届く - [ ] 「戻る」ボタンで入力値が消えない --- ## SA-2. 顧客マスタの登録 ### 概要 営業担当者が新しい取引先（法人顧客）を顧客マスタに登録する業務フローです。社名・所在地・担当者・与信限度額・支払条件などを登録し、以降の注文登録で選択できるようにします。 ### 登場人物 - **主役**: 営業担当者 - **関係者**: 経理部（与信限度額の最終承認者） ### ビジネス価値 - 営業にとっての価値: 顧客情報が一元管理され、注文時に毎回入力する必要がなくなる。 - 経理にとっての価値: 与信限度額がシステムで強制されるため、限度額超過の取引を未然に防止できる。 ### 前提 - 営業担当者はログイン済みである - 経理部から与信限度額の事前承認を口頭または書面で得ている ### シナリオ #### 正常系 - **REQ-SA-2-001**（イベント駆動・必須・由来:SA-2元仕様） 営業担当者が顧客新規登録画面で必須項目（社名、社名カナ、郵便番号、住所、代表者名、担当者名、担当者メール、支払条件）を入力し「登録」ボタンを押した時、システムは顧客マスタに新規レコードを作成し、顧客一覧画面に遷移して登録結果を一覧の先頭に表示すること。 - **REQ-SA-2-002**（イベント駆動・推奨・由来:SA-2元仕様） 営業担当者が郵便番号を入力した時、システムは住所欄に該当する都道府県・市区町村までを自動入力し、番地以降の入力欄にフォーカスを移すこと。 #### 異常系 - **REQ-SA-2-101**（異常系・必須・由来:SA-2元仕様） 入力された担当者メールアドレスが既存の顧客マスタに登録済みの場合、システムは登録を拒否し「同じメールアドレスの顧客が既に登録されています（顧客番号: ○○）」と表示すること。 - **REQ-SA-2-102**（異常系・必須・由来:SA-2元仕様） 与信限度額が事前設定された上限値（例: 1,000万円）を超える金額で入力された場合、システムは登録を拒否し「与信限度額は経理部の追加承認が必要です」と表示し、経理部承認フラグの入力を促すこと。 #### 境界値 - **REQ-SA-2-201**（異常系・必須・由来:SA-2元仕様） 社名カナにカタカナ以外（ひらがな・漢字・英字）が含まれる場合、システムは登録を拒否し「社名カナはカタカナで入力してください」と表示すること。 ### 画面で見えるもの | 要素 | 内容 | |---|---| | ページタイトル | 「顧客 新規登録」 | | 入力欄（必須） | 社名、社名カナ、郵便番号、住所、代表者名、担当者名、担当者メール、支払条件（プルダウン） | | 入力欄（任意） | 与信限度額、電話番号、FAX、備考 | | ボタン | 「登録」「キャンセル」 | | エラー表示 | 入力欄の下に赤字で表示 | ### 確認チェック - [ ] 必須項目をすべて入力すれば登録できる - [ ] 郵便番号入力で住所が自動入力される - [ ] 同じメールの顧客を二重登録できない - [ ] 与信限度額の上限を超える場合は経理部承認フラグが必要 --- # 第2部 — 在庫担当者ユースケース 在庫担当者は、入荷検品と注文への引当作業を行う倉庫の社内ユーザーです。 --- ## WH-1. 入荷登録と在庫引当 ### 概要 在庫担当者が仕入先からの入荷を登録し、引当待ちの注文に対して在庫を引き当てる一連の業務フローです。 ### 登場人物 - **主役**: 在庫担当者 - **関係者**: 営業担当者（引当完了の通知を受け取る） ### ビジネス価値 - 在庫部門にとっての価値: 紙の入荷伝票と注文書を突き合わせる作業がなくなり、引当作業が画面上で完結する。 - 営業部門にとっての価値: 引当が完了した瞬間に通知が届き、顧客に出荷予定日を即答できる。 ### 前提 - 在庫担当者はログイン済みである - 仕入先からの入荷品が物理的に倉庫に届いている - 引当待ちの注文が1件以上存在する ### シナリオ #### 正常系 - **REQ-WH-1-001**（イベント駆動・必須・由来:WH-1元仕様） 在庫担当者が入荷登録画面でJANコードをスキャンし数量を入力し「登録」ボタンを押した時、システムは商品マスタから該当商品を特定し、当該商品の在庫数を入力数量分加算すること。 - **REQ-WH-1-002**（イベント駆動・必須・由来:WH-1元仕様） 在庫担当者が引当待ち一覧から注文を選び「引当実行」ボタンを押した時、システムは注文明細の各商品について在庫数を必要数分減算し、注文を「引当済み」状態に変更すること。 - **REQ-WH-1-003**（イベント駆動・必須・由来:WH-1元仕様） 注文が「引当済み」状態に変わった時、システムは当該注文を担当した営業担当者に「引当が完了しました（注文番号: ○○）」を画面通知＋メールで送信すること。 - **REQ-WH-1-004**（状態駆動・必須・由来:WH-1元仕様） ある商品の在庫数が安全在庫数を下回っている間、システムは在庫一覧画面で当該商品行に警告アイコン（橙色の三角）を表示すること。 #### 異常系 - **REQ-WH-1-101**（異常系・必須・由来:WH-1元仕様） スキャンされたJANコードが商品マスタに登録されていない場合、システムは入荷登録を拒否し「未登録の商品です。商品マスタに先に登録してください」と表示し、エラー音を鳴らすこと。 - **REQ-WH-1-102**（異常系・必須・由来:WH-1元仕様） 引当実行時に注文明細のいずれかの商品で在庫数が必要数に満たない場合、システムは引当を実行せず「○○の在庫が△個不足しています」と一覧で表示し、どの注文で詰まっているか分かるようにすること。 - **REQ-WH-1-103**（異常系・必須・由来:WH-1元仕様） 入荷数量に0または負の数が入力された場合、システムは登録を拒否し「数量は1以上を入力してください」と表示すること。 #### 境界値 - **REQ-WH-1-201**（イベント駆動・必須・由来:WH-1元仕様） 引当実行後の在庫数がちょうど0になる時、システムは引当を許可し、当該商品を在庫一覧で「在庫切れ」表示にすること。 ### 画面で見えるもの | 要素 | 内容 | |---|---| | ページタイトル | 「入荷登録」「引当作業」 | | 入力欄 | JANコード（スキャン入力対応）、数量 | | 表示項目 | 引当待ち注文一覧（注文番号、顧客、明細、合計）、在庫一覧（商品、現在庫、安全在庫、状態） | | ボタン | 「登録」「引当実行」「キャンセル」 | | 警告アイコン | 安全在庫を下回る商品行に橙色の三角アイコン | ### メール／通知 - 引当完了時：営業担当者宛に「引当完了（注文番号: ○○）」を画面通知＋メール送信 ### 確認チェック - [ ] JANコードのスキャンで商品が自動特定される - [ ] 引当が完了すると営業担当者に通知が届く - [ ] 在庫不足時は引当できず、不足商品と数量が画面に表示される - [ ] 安全在庫を下回る商品が一覧で視覚的に分かる --- # 第3部 — システム／自動処理ユースケース 人手を介さず、システムが時間トリガーや状態トリガーで自動実行する処理です。 --- ## SY-1. 安全在庫アラートの自動送信 ### 概要 商品の在庫数が安全在庫を下回った時、システムが自動的に在庫担当者と仕入担当者にアラートメールを送信する処理です。発注タイミングの遅れによる欠品を防ぎます。 ### 登場人物 - **主役**: システム（自動処理） - **関係者**: 在庫担当者、仕入担当者 ### ビジネス価値 - 在庫部門にとっての価値: 毎朝の在庫チェックを忘れていても、安全在庫を割った瞬間に通知が来るため、欠品リスクが下がる。 - 経営にとっての価値: 欠品による販売機会損失と、過剰発注による在庫コスト増の双方を抑えられる。 ### 前提 - 商品マスタに各商品の安全在庫数が設定されている - 在庫担当者と仕入担当者のメールアドレスが利用者マスタに登録されている ### シナリオ #### 正常系 - **REQ-SY-1-001**（イベント駆動・必須・由来:SY-1元仕様） ある商品の在庫数が安全在庫数を下回った時、システムは在庫担当者と仕入担当者にメールを送信すること。本文には「商品名」「現在庫数」「安全在庫数」「直近30日の出荷数」を含めること。 - **REQ-SY-1-002**（オプション・推奨・由来:SY-1元仕様） 自動発注機能が有効である場合、システムは安全在庫を下回った商品の発注書（PDF）を仕入先メールアドレスに自動送信すること。 - **REQ-SY-1-003**（状態駆動・必須・由来:SY-1元仕様） ある商品の在庫数が安全在庫数を下回っている間、システムはダッシュボードに「要発注検討」セクションで当該商品を一覧表示すること。 #### 異常系 - **REQ-SY-1-101**（異常系・必須・由来:SY-1元仕様） メール送信に失敗した場合、システムは1分間隔で最大3回まで再送を試みること。 - **REQ-SY-1-102**（異常系・必須・由来:SY-1元仕様） 3回再送しても送信できない場合、システムは管理者画面のエラーログに記録し、ダッシュボード上で「未配信アラート あり」を表示すること。 - **REQ-SY-1-103**（異常系・推奨・由来:SY-1元仕様） 同一商品について同日中に既にアラートを送信済みの場合、システムは重複送信を抑止すること。 ### メール／通知 - アラート送信時：件名「【要発注検討】○○（現在庫: △個）」、宛先は在庫担当者と仕入担当者 - 自動発注送信時（オプション有効時）：件名「【自動発注】○○ × △個」、宛先は仕入先 ### 確認チェック - [ ] 安全在庫を割ると自動でメールが届く - [ ] メールに必要な情報（商品名・現在庫・安全在庫・出荷数）が含まれている - [ ] 同じ日に同じ商品で何度もメールが届くことはない - [ ] メール送信失敗時に管理者が気付ける仕組みがある --- ## このサンプルの活用方法 1. **写経して書き換え**: 章構成と書式を真似て、自社のユースケースに置き換えて書いてください 2. **EARSで書く練習**: 既存の機能要望をEARSの5パターンに分類し直すと、抜け漏れが見えてきます 3. **スコープ管理ツールに取り込む**: 弊社が提供する「要件定義支援ツール」のスコープ管理機能で、本書の各要求文を「作る／後回し／作らない」に振り分けて優先度を可視化できます 4. **開発会社との合意に使う**: 各章末の「確認チェック」を一緒に読み合わせることで、要件定義のレビューが効率化します ご質問や個別のサンプル作成のご相談は、無料相談からお気軽にお問い合わせください。