WMS Requirements That Don’t Backfire: Functional vs. Non-Functional (With Real Examples)

Written By Justin Ide

Most WMS projects fail before kickoff because the requirements are junk—either vendor boilerplate or IT-only wish lists. You need operator-written requirements that describe how work must flow, plus non-functional guardrails that keep the system fast, usable, and supportable when volume spikes.


Use this as your playbook to write requirements the market can actually deliver.


Quick definitions (plain English)

  • Functional requirements: What the system must do at each step of the warehouse flow (receive → putaway → pick → pack → ship → returns, etc.).

  • Non-functional requirements (NFRs): How the system must behave under real-world conditions (speed, uptime, devices, labels, integration, security, support).


Write what, not how. Vendors own the “how.”


Ground rules before you write a word

  1. Stabilize basic process first (slotting, pick path, staging). A WMS won’t rescue bad flow.

  2. Use real volumes (lines/day, peak/hour, SKUs, units per order).

  3. Tie each requirement to an acceptance test you can run during UAT.

  4. Prioritize: Must / Should / Could (and be ruthless).

  5. Limit customizations. If three vendors can’t meet a Must without code, you’re asking for the wrong thing—or your process is the outlier.


Functional requirements by workflow (with acceptance criteria)

Receiving & ASN

  • FR-R1 (Must): Accept EDI/portal ASNs; auto-create inbound loads with pallet/carton counts.

    Acceptance: Import sample ASNs from 3 carriers; system creates loads with correct counts and flags mismatches.

  • FR-R2 (Must): Blind receipt option for suppliers without ASN; variance captured at item and pallet.

    Acceptance: Blind receive 20 mixed-SKU pallets; discrepancies show on an exceptions dashboard.


Putaway

  • FR-P1 (Must): System suggests putaway locations by rules: temperature, hazmat, velocity, unit of measure, available space.

    Acceptance: For 50 receipts across 4 classes (fast/slow, reefer/ambient), 90% suggestions match rules without overrides.

  • FR-P2 (Should): Consolidate to existing LPN/location if same lot/UOM.

    Acceptance: Mixed receipt of identical SKU/lot merges into existing location with one scan.


Replenishment

  • FR-Re1 (Must): Min/Max triggers for forward pick with time-based look-ahead (e.g., next 4 hours of demand).

    Acceptance: Simulate peak orders; tasks drop before stockout; zero reactive stockouts in top 50 SKUs.

  • FR-Re2 (Should): Wave-aware replen that sequences before pick release.

    Acceptance: Replens complete 10 minutes before wave start in 95% of tests.


Picking

  • FR-Pk1 (Must): Support discrete, cluster, batch, and zone picking; choose by order profile.

    Acceptance: Run 3 profiles; confirm pick path minimizes backtracking; scans validate item/UOM/location.

  • FR-Pk2 (Must): Real-time shortage handling with substitute/partial rules by customer.

    Acceptance: Short a line mid-pick; system enforces customer rule (partial allowed vs. backorder).

  • FR-Pk3 (Should): Cart/bin optimization by cube/weight; prevents overflow.

    Acceptance: 95% of orders fit in suggested containers without repack.


Packing, QC, & Shipping

  • FR-Pa1 (Must): Print customer-specific labels and BOLs; integrate with carrier/TMS rate shop.

    Acceptance: Print all docs for 5 customers with different label specs; transmit manifest to carrier sandbox.

  • FR-Pa2 (Should): Photo capture for damages/overages tied to order/LPN.

    Acceptance: Photos visible in order history and exportable.


Inventory control

  • FR-I1 (Must): Cycle count programs: ABC, location-based, and triggered (variance, high-value, recount).

    Acceptance: Run each program; inventory accuracy baseline ≥ 98% after completion.

  • FR-I2 (Should): Support lot/expiry/serial and catch-weight where applicable.

    Acceptance: Receive, move, pick, and ship each control type without losing traceability.


Value-Added Services (VAS) / Kitting

  • FR-V1 (Should): Simple work orders with components, labor capture, and yields.

    Acceptance: Build 3 kits; variances and labor show on cost report.


Returns

  • FR-Rt1 (Must): RMA intake with reason codes; quarantine and disposition flow.

    Acceptance: 20 RMAs processed; time-to-disposition KPI produced.



Non-Functional requirements (set your guardrails)


Performance & scale

  • NFR-Perf1: 95th percentile screen response ≤ 700 ms for scan-to-next action at 300 scans/minute per site.

  • NFR-Perf2: Support peak of X orders/day, Y lines/hour, Z concurrent users without throttling.



Availability & recovery

  • NFR-Avail1: 99.9% uptime monthly; planned maintenance outside business hours with 7-day notice.

  • NFR-DR: RPO ≤ 5 minutes; RTO ≤ 30 minutes.



Devices & UX

  • NFR-UX1: RF handhelds (Android), forklifts tablets, and web; dark theme RF; one-hand scan → confirm.

  • NFR-UX2: Offline queue for intermittent Wi-Fi (retries with duplication protections).



Labels & documents

  • NFR-Lbl: Native ZPL printing; GS1 barcodes; templates version-controlled per customer.



Integrations

  • NFR-Int: Standard adapters/APIs for: ERP (orders, items), TMS (rates/manifests), EDI (850/940, 856, 945), YMS, carrier portals.

  • NFR-Logs: All interface events logged with replay capability.



Security & roles

  • NFR-Sec: Role-based access; audit trails for inventory adjustments and overrides.



Config vs. custom

  • NFR-Cfg: 90% of behavior via config/rules; custom code isolated and upgrade-safe.



Implementation & support

  • NFR-Imp: Vendor provides test scripts matching your flows; UAT must pass against volumes you specify.

  • NFR-Sup: 24×7 Severity-1 support; response ≤ 30 minutes.




Prioritization matrix (be ruthless)

  • Must: Safety, compliance, core flow (receive/putaway/replen/pick/pack/ship), labels, integrations you already use.

  • Should: Nice-to-have modes that lift productivity (voice, advanced slotting, cart optimizer).

  • Could: Reports you can export to BI later, advanced analytics, ML add-ons.


Rule: If a “Should” delays the go-live by >2 weeks, push it to Phase 2.



Readiness checklist (operators own this)

  • Item master clean: UOM, weights, dims, lot/serial flags

  • Location schema finalized and labeled (aisle-bay-level format)

  • Slotting rules defined (A/B/C, temp, hazmat)

  • Baseline KPIs recorded: inventory accuracy, pick productivity, dock-to-stock

  • Devices chosen & procured (Android RF, printers, scanners)

  • Test data sets built: 30 days of real orders, edge cases

  • Training plan: leads first, then associates

  • Cutover plan: freeze window, rollback, hypercare


If you can’t check half this list, you’re not ready for WMS. Fix the warehouse first; then buy software.



Vendor demo script (make them “walk your day”)

Give each vendor the same script and data. Make them run it live:


  1. Receiving: ASN + blind receipt. Mixed lot/UOM.

  2. Putaway: Reefer + hazmat + fast-mover rules.

  3. Replen: Time-based triggers ahead of a wave.

  4. Picking: Two profiles (cluster + discrete). Force a shortage mid-pick.

  5. Packing/Docs: Customer A needs GS1 labels; Customer B needs special BOL.

  6. Returns: RMA with photo capture and quarantine.

  7. Performance: 50 concurrent users hammering RF scans—show response time.


Score against your Must/Should list and the NFRs above, not a glossy feature matrix.



Success metrics post-go-live

  • Dock-to-Stock: ↓ 30–50%

  • Pick productivity (lines/hr): ↑ 15–30%

  • Inventory accuracy: ≥ 98–99%

  • Shortages on A-SKUs: near zero

  • Overtime hours: ↓ 10–20%

  • Order cycle time: ↓ 10–25%



If your vendor can’t commit to tracking these, wrong vendor.


Want a requirements pack that vendors can’t dodge?


My 2–3 day assessment produces (1) operator-written FR/NFR set, (2) demo script + UAT tests, and (3) a readiness roadmap so you don’t buy software to formalize today’s problems.


Book a 20-minute fit call to see if it’s worth doing at your site.

Justin Ide
Next

Warehouse Assessment Checklist: What to Prep Before Day 1