﻿在庫管理システム刷新 要件定義書
研修用に作った架空の会社と架空の文書です。実在の会社、人物、案件とは関係ありません。
項目 | 内容
発注者 | サンプルマート株式会社
文書の版 | 第0.9版（社内レビュー用）
作成日 | 2026年11月30日
作成 | 受託者 在庫管理システム刷新プロジェクト（PM 鈴木）
発注者の窓口 | 情報システム部 佐藤部長


1 本書の位置づけ
1.1 目的
本書は、サンプルマート株式会社（以下「発注者」）が進める在庫管理システムの刷新について、受託者が発注者の各部への聞き取りをもとに要件を取りまとめたものである。発注者が本書を承認したあと、受託者は本書をもとに基本設計を行う。本書の対象は在庫管理の業務とシステムに限り、組織の変更や店舗の業務の手順の見直しは、発注者が別に進める。
第0.9版は、発注者へ提出する前に受託者の社内でレビューするための版である。社内レビューの指摘を反映した第1.0版を、2026年12月18日に発注者へ提出する。
1.2 対象範囲
対象は、全48店舗と本部（商品部、物流部、店舗運営部、情報システム部）で行う在庫管理の業務と、それを支えるシステムである。会計システム、人事システム、ネット通販のシステムは対象外とする。POSシステムも対象外とし、本システムとの連携部分だけを扱う。
1.3 用語の定義
用語 | 意味
在庫数 | 店舗にある商品の数量。単位は商品ごとの販売単位（個、本、袋など）とする。
商品コード | 発注者が商品ごとに付けている8桁の番号。商品マスタの主キーとする。
発注候補数量 | 本システムが算出する、発注の候補となる数量。店舗担当者が確認して発注数量を確定する。
店舗担当者 | 各店舗で在庫と発注の業務を受け持つ従業員。1店舗あたり2〜4名いる。
棚卸 | 店舗にある商品を数え、本システム上の在庫数と照らし合わせる作業。
ハンディ端末 | 店舗担当者が売場とバックヤードで使う携帯型の端末。商品のバーコードを読み取れる。


1.4 関係する文書
受託者は、本書のほかに、現行システムの画面一覧（2026年9月版）と、物流センターのシステムの連携仕様書（2026年8月版）を発注者から受け取っている。
1.5 日程
工程 | 期間
要件定義 | 2026年10月〜2027年1月（本書の承認は2027年1月22日の予定）
基本設計 | 2027年2月〜3月
詳細設計と製造 | 2027年4月〜7月
結合試験と受入試験 | 2027年8月〜9月
本番稼働 | 2027年10月4日


2 現状と課題
2.1 業務の現状
発注者は、首都圏で食品と日用品を扱うスーパーマーケットを４８店運営している。各店舗の営業時間は9時から22時で、年中無休である。取り扱う商品は約3万品目で、1日の売上明細は平常時で約30万行になる。年末（12月20日から31日まで）と年4回の大型セールの期間は、売上明細が平常時の約3倍になる。
店舗担当者は毎朝、紙の在庫表と前日の売上を見て発注数量を決め、店舗のパソコンから発注を入力している。在庫数は、POSシステムの売上を夜間にまとめて差し引いて計算しており、日中の在庫数は分からない。店舗担当者は1店舗あたり2〜4名で、発注の作業に1日あたり約1時間をかけている。
商品は、発注者の物流センター2か所から各店舗へ毎日1回配送している。店舗に届くのは、前日の10時までに確定した発注の分である。
本部では、商品部が全店舗の在庫数を週に1回、表計算ソフトで集計している。集計には2日かかるため、本部が見る在庫数は常に2日以上前のものになる。
2.2 現行システムの課題
(1) 在庫数が前日の夜の時点のものしか分からず、売場で欠品に気づくのが遅れる。
(2) 発注数量を店舗担当者の経験で決めており、店舗ごとに欠品と廃棄の量がばらついている。
(3) 棚卸は年2回、紙の集計表で行っている。現行の運用では、在庫数と数えた数の差異が5%を超えた品目を、店舗が紙で本部の商品部へ報告している。
(4) 現行システムは稼働から12年がたち、保守の期限が2027年12月に切れる。
(5) 店舗間で在庫を移動するときは、電話で相手の店舗に連絡し、紙の伝票で記録している。移動は月に約400件あり、商品部が伝票の集計に月に3日かけている。
2.3 刷新の目標
(1) 店舗担当者が、日中の在庫数を売場で確認できるようにする。
(2) 発注候補数量を本システムが算出し、発注にかかる時間を1店舗あたり1日30分減らす。
(3) 本部が、全店舗の在庫数を毎日確認できるようにする。
(4) 店舗間の在庫の移動を本システムで記録し、電話と紙の伝票をなくす。

3 業務要求
発注者の各部への聞き取りをもとに、業務要求を次の10件にまとめた。4章の機能要件は、「対応する要求」の列で要求番号を参照する。
要求番号 | 業務要求 | 要求元
R-01 | 店舗担当者が、自店の在庫数を日中も最新の状態で確認できるようにする。 | 店舗運営部
R-02 | 売上の実績をもとに、発注候補数量を自動で算出できるようにする。 | 商品部
R-03 | 店舗担当者が、ハンディ端末で売場から発注を入力できるようにする。 | 店舗運営部
R-04 | 本部が、全店舗の在庫数を一覧で確認できるようにする。 | 商品部
R-05 | 物流センターからの入荷予定を、店舗で確認できるようにする。 | 物流部
R-06 | 棚卸の結果をハンディ端末で入力し、在庫数を補正できるようにする。 | 店舗運営部
R-07 | 店舗間で在庫を移動できるようにし、移動の記録を残す。 | 店舗運営部
R-08 | 賞味期限が近い商品を、店舗担当者に知らせる。 | 商品部
R-09 | 利用者ごとに、使える機能と表示できる店舗を制限する。 | 情報システム部
R-10 | 在庫と発注の実績を月次で集計し、本部に報告する。 | 商品部


要求元の部は、要求の中身を変えるときの相談先とする。2.3の目標に直接つながるR-01、R-02、R-03を、最も優先する要求とする。

4 機能要件
3章の業務要求を実現する機能を、次の12件とする。画面と帳票の細部は基本設計で決める。
機能番号 | 機能名 | 内容 | 対応する要求
F-01 | 在庫照会 | 店舗担当者が、ハンディ端末か店舗のパソコンで、自店の在庫数を商品コードか商品名で検索して表示する。 | R-01
F-02 | 売上の取り込み | POSシステムから受け取った売上データを、在庫数から差し引く。取り込みの間隔は15分とする。 | R-01
F-03 | 全店舗の在庫一覧 | 本部の利用者が、店舗ごとの在庫量を商品単位で一覧表示する。一覧はCSVでも出力する。 | R-04
F-04 | 発注候補の算出 | 毎朝6時に、店舗と商品ごとの発注候補数量を算出する。発注候補数量は、手持ち数と過去4週間の販売数と入荷予定から求める。 | R-02
F-05 | 発注入力 | 店舗担当者は、ハンディ端末か店舗のパソコンで発注候補数量を確認し、数量を変える場合は変えてから発注数量を確定する。確定した発注は、毎日10時に物流センターへ送る。 | R-03
F-06 | 入荷予定の表示 | 物流センターの出荷データをもとに、店舗ごとの入荷予定を翌日分まで表示すること。 | R-05
F-07 | 棚卸 | 店舗担当者がハンディ端末で数えた数を入力し、在庫数を補正する。棚卸で差異が大きい品目は、本部の商品部へ自動で通知する。 | R-06
F-08 | 賞味期限の通知 | 賞味期限まで3日以内の商品を、毎朝7時に店舗のハンディ端末へ通知する。 | R-08
F-09 | 利用者と権限の管理 | 利用者ごとに、使える機能と表示できる店舗を設定する。設定は発注者の情報システム部が行う。 | R-09
F-10 | 月次の集計 | 毎月1日に、前月の在庫と発注の実績を店舗別に集計し、本部向けの帳票に出力する。 | R-10
F-11 | 操作の記録 | 利用者のログインと、在庫数の補正と、発注の確定を記録する。記録は1年間保管する。 | R-12
F-12 | マスタの取り込み | 商品マスタと店舗マスタを、発注者の基幹システムから毎日5時に取り込む。 | R-02、R-04


F-01、F-05、F-07は、ハンディ端末と店舗のパソコンのどちらからも使えるようにする。F-03とF-10は、本部のパソコンからだけ使う。

5 非機能要件
非機能要件は、性能、可用性、セキュリティ、運用、拡張性の5つに分けて定める。
番号 | 区分 | 要件
N-01 | 性能 | 全店舗の在庫一覧（F-03）は、本部の利用者が操作に不満を感じない速さで表示されること。
N-02 | 性能 | 年末やセール期間などの繁忙期においても、平常時と変わらない性能を保つこと。
N-03 | 性能 | 発注候補の算出（F-04）は毎朝6時に開始し、7時30分までに全店舗分を終えること。
N-04 | 可用性 | システムは高い可用性を確保し、店舗の営業に支障を与えないこと。
N-05 | 可用性 | バックアップは毎日1回、営業時間外に取得し、30日分を保管する。
N-06 | セキュリティ | 利用者はIDとパスワードでログインする。パスワードは10文字以上とし、5回続けて誤った場合はその利用者のIDをロックする。
N-07 | セキュリティ | 店舗の利用者は、自店のデータだけを表示できる。本部の利用者は、全店舗のデータを表示できる。
N-08 | 運用 | 受託者は、7時から23時まで本システムの稼働を監視する。監視で異常を見つけた場合は、発注者の情報システム部へ30分以内に連絡する。
N-09 | 拡張性 | 店舗は5年後に60店舗まで増える計画がある。60店舗になった場合も、N-03の処理時間を守ること。


非機能要件の値は、受入試験で合否を判定するときの基準とする。試験の手順は、結合試験を始めるまでに受託者が作り、発注者が確認する。

6 外部連携とデータ移行
6.1 POSシステムとの連携
POSシステムから売上データを15分ごとに受け取り、在庫数に反映する。売上データは、品番と販売数と販売日時を1行とする。POSシステムは、発注者が別の会社に保守を委託している。
6.2 物流センターとの連携
確定した発注データは毎日10時に物流センターのシステムへ送り、出荷データは毎日17時に受け取る。ファイルの形式と送り方は、発注者の物流部と受託者が基本設計で決める。物流センターのシステムは、発注者の物流部が管理している。
6.3 基幹システムとの連携
商品マスタと店舗マスタは、発注者の基幹システムから毎日5時にファイルで受け取る（F-12）。ファイルの形式は、現行システムで使っているものをそのまま使う。
6.4 データ移行
現行システムのデータは、本番稼働の前週に新システムへ移行する。移行の対象は、商品マスタと店舗マスタと在庫数と、過去2年分の発注実績とする。
7 前提条件と役割分担
7.1 前提条件
(1) 各店舗から本部のネットワークへは、発注者が契約している回線で接続できる。
(2) 店舗で使うハンディ端末は、全店で計120台を新たに導入する。
(3) 本システムは、受託者が用意するクラウドの環境で動かす。環境の利用料は、本番稼働後の保守費に含める。
(4) 店舗と本部のパソコンは、現行のものを使い続ける。
(5) 本システムの利用者は、店舗担当者が約150名、本部の利用者が約30名である。
7.2 役割分担
作業 | 発注者 | 受託者
要件の決定と本書の承認 | 行う（情報システム部 佐藤部長が承認する） | 支援する
要件の取りまとめと本書の作成 | 確認する | 行う
基本設計から結合試験まで | 確認する | 行う
受入試験 | 行う | 支援する
利用者への教育 | 行う（店舗運営部） | 教材を作る
本番稼働後の保守 | 問い合わせる | 行う


7.3 会議の進め方
発注者と受託者は、毎週水曜日に定例会を開き、進み具合と課題を確かめる。定例会の議事録は受託者が作り、翌営業日までに発注者へ送る。課題は課題一覧で管理し、期限を過ぎた課題は情報システム部の佐藤部長に報告する。
7.4 本書の承認
発注者は、2027年1月22日までに本書を承認する。承認のあとに要件を変える場合は、発注者と受託者が変更の内容と費用を協議して決める。
