eCommerce Requirements Gathering

Here are three keys to successful eCommerce requirements gathering, as well as a couple of free tools that can help you in the process.

Understand the Difference between Business, Functional, and Technical Requirements

Business Requirements

These are for the business, and typically include the justification for the requirement from the business’ perspective. Some business requirements include:

    • Pricing rules, because b2b accounts have negotiated discounts and terms.
      • These rules are set via account status in ERP.
    • Shipping rules, because some products have exclusions or requirements such as palletization or shipping via freight.
      • These rules are set via product attribute in ERP and their rates are provided via ShippingCo.
    • Order fulfillment workflow, because some products are drop-shipped.
      • Products are usually tagged as DropShip in ERP.
    • Legal / regulatory requirements, because dealing with legal issues is the last thing you want to do

Functional Requirements

These are for the user, and should reflect conversion and performance goals around the customer’s’ experience. Examples of functional requirements are:

  • Product reviews to increase conversion rates and differentiate from competition.
    • Whether reviews will be moderated or unmoderated.
    • Whether anonymous/guest reviews will or will not be accepted.
  • Product tours (photos/videos/etc.)to increase user engagement and differentiate from competition.
  • A shipping calculator to set expectations and decrease cart abandonment.
    • Drop-shipped products follow a different workflow.
  • Saved carts or printable quotes, because shoppers often require a manager’s permission or a purchase order prior to checkout.
    • Saved carts / quotes expire in 14 days
    • Account creation (with email and phone number) required for quote

Technical Requirements

These are for the developer, and should prevent the developers from having to make any assumptions. Examples of technical requirements include:

  • Make sure user accounts adhere to password policy. One possible flow for this is:
    • On submit
      • AccountNumber and password
        • If successful
          • Log login activity
        • If login is successful and AccountStatus is “disabled”
          • Do not login
          • Display friendly message to contact Customer Service if in error
        • If IsExcludedOfPasswordChangePolicy is false and LastPasswordChange is older than [SystemSettings] DaysToChangePassword
          • Redirect to Force Password Change
        • Else Redirect to MyAccount

In an ideal world where we know everything in advance, stating requirements from multiple perspectives should result in a duplicate or triplicate set of identical requirements. In reality, working through requirements via multiple personas always identifies new and previously unconsidered issues and opportunities. Sometimes there are requirements that are in conflict (such as a “one-step checkout” that conflicts with “no guest checkout—ERP requires account creation”), and sometimes there are requirements represented in one category but not another.

Security Should Be Addressed First, not Last

In fact, your security posture should be assessed as part of the initial scope conversations and then continuously throughout the project as changes occur. I’ve seen several projects start outside of PCI Compliance scope, but somehow end up there as various stakeholders inject new requirements.

eCommerce can actually be much safer for your customers than brick-and-mortar retail if you approach it correctly. Just know that adding SSL to make your site “https” isn’t going to cut it.

For more information on what your platform could be at risk for and how to check for problems, take a look at our blog post “Your Magento eCommerce Platform is on Fire. Here’s How to Fix It”.

Understand Your Mobile Users

“Make it responsive” is not the best way to address the needs of your mobile users. In many settings we find that mobile users have entirely different goals and behaviors than desktop users, and in fact sometimes they vary between device types (e.g. smartphone vs tablet).

Two example scenarios come to mind:

  1. Due to the rise in tablet-based point of sale systems, some B2B’s who have traditionally done inventory replenishment and order management via desktop have moved to using the readily-available tablets to perform subsets of the same tasks. However, most of these are situation-specific—a user is checking specific orders or specific sku’s in response to a customer or colleague inquiry. Reporting and analytics are saved for “office time,” and thus the investment into making those features tablet-friendly isn’t justified at this time.
  2. For an industrial/manufacturing supply company, all orders come through established accounts and generally via desktop browsing sessions. However, part availability and compatibility needs to be checked while on the shop floor—meaning a mobile phone optimized experience for the technicians should focus on providing product information and a simple way to send/share part info, rather than focus on driving transactions on the device.


You’ve made it this far, or you took the “TL; DR” route and jumped straight to the bottom. Either way, here’s your reward:

Here’s a user-friendly “checklist” you can use to discover if you’ve at least touched on the most important requirements groups. Print and share with your team to facilitate conversation.
Download PDF


If you’re ready for a more thorough exploration of e-commerce requirements, here’s a spreadsheet with roughly 350 questions spanning the above three types of requirements, common types of third party integrations, and more. Don’t worry if some of your answers are “unknown” or “not applicable” – it’s intended to focus future requirements gathering sessions on any areas where gaps exist.
Download XLSX


Credits : atlanticBT

Leave a Reply

Your email address will not be published. Required fields are marked *