Back to case studies Business Analysis · Case Study

Online Shopping Platform

A retailer taking orders manually through social-media DMs is losing track of stock and orders as demand grows. This case study frames the business problem, maps the as-is and to-be ordering processes, and documents the requirements for a proper online shopping platform.

Requirements BPMN / Process User Stories Use Cases KPIs

01Business Problem & Objectives

Orders currently arrive via social-media comments and DMs, tracked manually in notebooks and chat threads. As order volume grows, this causes overselling of out-of-stock items, missed orders, and no reliable record of sales for the owner to review.

  • Objective 1: Let customers browse products and place orders directly through a website.
  • Objective 2: Prevent overselling by tracking stock levels in real time.
  • Objective 3: Reduce cart abandonment with a simple, trustworthy checkout flow.
  • Objective 4: Give the owner a single dashboard to track orders, stock, and dispatch status.

02As-Is vs To-Be Process

As-Is: Customer comments or messages interest → owner manually checks remaining stock from memory or a notebook → owner confirms availability and price over chat → payment arranged informally → order noted down by hand, with no stock deduction until later — the root cause of overselling.

To-Be: Customer browses the catalogue online → adds items to cart, with stock validated live → customer checks out and pays online → system deducts stock immediately and creates an order record → owner sees the new order on a dashboard ready for dispatch.

03Functional Requirements

  • FR1: Customers can browse products by category and view stock availability.
  • FR2: Customers can add items to a cart and adjust quantities before checkout.
  • FR3: System prevents checkout if requested quantity exceeds available stock.
  • FR4: Customers can pay online and receive an order confirmation with a reference number.
  • FR5: System automatically deducts ordered quantities from stock on order confirmation.
  • FR6: Owner can view, update, and mark orders as dispatched from an admin dashboard.

04Non-Functional Requirements

CategoryRequirement
PerformanceProduct catalogue and cart pages load in under 2 seconds.
SecurityPayments processed via a PCI-compliant gateway; no card data stored locally.
AvailabilityStorefront available 99.5% of the time, including outside business hours.
UsabilityCheckout completable on mobile in 4 steps or fewer.
ScalabilitySupports peak sales-event traffic (3× average daily orders) without degradation.

05User Story & Acceptance Criteria

As a customer, I want to place an order online and know my item is reserved, so that I don't pay for something that turns out to be out of stock.

  • Given a product has available stock, when a customer adds it to their cart and completes payment, then the order is confirmed and stock is deducted immediately.
  • Given a product is out of stock, when a customer tries to add it to their cart, then the system prevents it and shows it as unavailable.
  • Given an order is confirmed, when payment completes, then the customer receives an email with an order reference within 1 minute.

06Use Case: Place an Order

ActorCustomer
PreconditionCustomer has added one or more available items to their cart.
Main flow1. Customer reviews cart. 2. System validates stock for each item. 3. Customer enters delivery and payment details. 4. Customer confirms payment. 5. System deducts stock and confirms the order.
Alternate flowIf an item goes out of stock before payment completes, system removes it from the cart and asks the customer to review before continuing.
PostconditionOrder is recorded, stock updated, and confirmation email sent.

Want to see more BA work?

Explore the other case studies and projects on the main portfolio.

Back to case studies