# A Requirements Gathering Process for Shopify Projects > A requirements gathering process for Shopify projects: how to gather requirements from real clients and turn them into a buildable spec. _Published: 2026-10-21 ยท CommerceCopilot_ ## The gap between what clients say and what developers need A client says "we want customers to find products faster." A developer needs to know whether that means predictive search, collection filtering, a mega menu, or a quiz, and which apps, templates, and budget constraints apply. A requirements gathering process is how an agency crosses that gap on purpose instead of by accident, and most Shopify agencies do not have one. They have a kickoff call, a notes document someone wrote on the call, and a quote that commits the team to whatever the notes happened to capture. The cost of getting this wrong is well documented. [PMI's Pulse of the Profession research on requirements management](https://www.pmi.org/learning/thought-leadership/pulse/core-competency-project-program-success) found that 47 percent of unsuccessful projects fail to meet their goals because of inaccurate requirements management, and that organizations waste 5.1 percent of every project dollar on poor requirements practices. Those numbers come from large-company surveys, but the mechanism is identical at a six-person agency: a requirement that was never pinned down comes back as a change request, a rework cycle, or an awkward call about why the thing the client "obviously meant" is not in the build. This post lays out a requirements gathering process built for agency Shopify work: what to collect, how to collect it from real clients, and how to turn the output into something a developer can build from. ## What requirements gathering covers, and how it differs from discovery The two terms get used interchangeably, and the overlap is real, but they are not the same activity. Discovery is the broad phase where you work out what the client actually needs, including the parts they have not articulated; we cover running it in [how to run client discovery for Shopify projects](/blog/shopify-agency-client-discovery-process). Requirements gathering is the part of discovery that produces the record: eliciting specific, confirmable statements about what the solution must do, and writing them down in a form someone can build and test against. The [BABOK Guide](https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/), the business analysis profession's reference text, classifies requirements into four types, and the classification maps cleanly onto agency work even if you never use the vocabulary with a client: - **Business requirements**: why the project exists. "Mobile conversion is 40 percent below desktop and we need it up by Q2." - **Stakeholder requirements**: what specific people need from it. The marketing lead needs to edit the campaign banner without a developer; the ops manager needs orders to keep flowing into the ERP. - **Solution requirements**: what the build must do, functionally ("the filter updates results without a page reload") and non-functionally ("product pages stay under a 2-second load on 4G"). - **Transition requirements**: what is needed to get from here to there, and only until launch. Data migration, redirects, staff training on the new theme editor sections. You do not need the taxonomy. You need what it protects against: projects where everyone gathered solution requirements ("build a quiz") and nobody gathered the business requirement that would have revealed the quiz was the wrong solution, or the transition requirement that doubles the timeline because 80,000 customer records have to move with their order history intact. ## How to gather requirements from real clients "Just ask the client what they want" fails because clients answer in solutions, not requirements, and because the people in the kickoff call are rarely the only people with requirements. A workable elicitation kit for agency projects has four techniques. **Structured conversation.** Interviews are still the core technique, but the structure does the work: outcome first, constraints second, specifics last. Ask why before how. When a client requests a feature, the follow-up is "what happens today, and what should happen instead," which surfaces the requirement underneath the request. Prepared question lists help here; we keep a working set in [discovery questions for Shopify agency projects](/blog/shopify-agency-discovery-questions). **Reading what already exists.** The client's store is a requirements document nobody wrote. The theme and its customizations, the installed app list, the navigation structure, the order and catalog data: an hour reading these answers questions the client cannot, and surfaces constraints they forgot to mention. The app nobody remembers installing that injects script into the cart page is a requirement, whether or not anyone states it. **Watching the workflow.** When the project touches the merchant's operations (fulfillment, merchandising, content updates), a short screen-share of how the team works today beats any description of it. People describe their process as it should be; the recording shows the workaround in cell B14 that the new build has to replace. **Written follow-up.** After every session, send back what you heard as a list of statements the client confirms or corrects. This is the cheapest validation step that exists, and it converts "I'm sure we discussed this" disputes into a timestamped record. ## The requirements gathering process, step by step Techniques only help inside a sequence. This is the process in five steps, each with an output. ### 1. Collect the facts before the first session Platform and plan, tech stack, app dependencies, budget range, hard deadlines, and who makes decisions. Gather these by form or email so the live sessions spend zero minutes on facts and all their time on ambiguity. ### 2. Elicit in stages Run the techniques above, staged from outcome to constraints to specifics. For anything beyond a small build, split sessions rather than running one marathon call, and make sure a technical voice is in the room before anything resembling a commitment is made. ### 3. Sort every statement into confirmed, assumed, or open This is the step that separates a requirements gathering process from a notes folder. Every requirement gets a status: confirmed by a stakeholder, assumed by you, or an open question. The assumed and open lists are the project's risk register in embryo. Most scope disputes trace back to an assumption that was never promoted to a question. ### 4. Validate with the people who were not in the room Circulate the confirmed list and the open questions to stakeholders beyond your main contact. The warehouse manager who was never invited to a call is the classic source of the week-nine surprise requirement, and one email in week one is cheaper than a change order in week nine. ### 5. Translate into tickets with acceptance criteria A requirements document is not a spec until it becomes sequenced tickets with checkable acceptance criteria. This translation step is where requirements gathering usually dies at agencies: the senior person who ran the sessions becomes the bottleneck, and the handoff happens as a narrative summary instead. The ticket formats in [how to write development tickets](/blog/how-to-write-development-tickets) and [writing acceptance criteria for Shopify tickets](/blog/writing-acceptance-criteria-shopify-tickets) are the target output; a requirement is gathered when it exists as a line a developer can build and a reviewer can check. ## Shopify requirements that change the whole project Some requirements are worth forcing into the open early because the answer changes the architecture or the price, not just the backlog. On Shopify projects, four come up constantly: - **Checkout.** Customizing the information, shipping, and payment steps with [checkout UI extensions](https://shopify.dev/docs/api/checkout-extensions) requires Shopify Plus; on standard plans, extensions are limited to the thank-you and order status pages. A client on a Basic plan asking for a customized checkout is a plan-upgrade conversation, not a ticket. - **Apps versus custom.** Every "can it do X" requirement needs an answer to "is X an app, a theme customization, or a custom app," because the three have different costs, maintenance profiles, and failure modes. - **Data.** If the project is a migration or replatform, the volume and shape of products, customers, and order history is a requirement that dominates the timeline, and it is almost never in the brief. - **Markets and languages.** Multi-currency, multi-language, and regional catalogs multiply testing scope on every template they touch. One question in week one, or a 40 percent surprise at QA time. ## Where CommerceCopilot fits The process above has a structural weakness: it depends on someone doing the unglamorous parts (logging statements, tracking what is confirmed versus assumed, chasing open questions, translating findings into tickets) consistently, on every project, including the weeks when the agency is slammed. At most agencies that someone is a founder or lead developer doing it between other jobs, which is the gap we wrote about in [does your Shopify agency need a business analyst](/blog/business-analyst-digital-agency). CommerceCopilot's Business Analyst agent runs this process continuously. It listens where requirements actually form (meeting calls, connected Slack channels, notes, and pasted emails) and maintains a living model of the project: the outcome, what is confirmed, what is assumed, and what is still an open question. When something is unclear it raises the question instead of inventing an answer, and once findings are accepted it proposes sequenced tickets with acceptance criteria, with a human reviewing everything before it reaches the tracker. The [discovery project walkthrough](/docs/your-first-discovery-project) shows the full loop from first call to accepted tickets. ## FAQ ### What is the difference between requirements gathering and scoping? Requirements gathering establishes what the solution must do, in confirmable statements. Scoping decides which of those requirements this project will deliver, for what price, on what timeline. Scoping built on ungathered requirements is a guess wearing a number; the two meet in [Shopify project scoping](/blog/shopify-project-scoping). ### How long should requirements gathering take on a Shopify project? Match it to what the answers change. A storefront refresh might need one structured session plus a store review. A replatform with an ERP integration and 80,000 customers justifies weeks, because the expensive requirements (data, integrations, checkout) each need their own investigation. The test is coverage, not calendar time: can you state the business requirement, the constraints, and the risky unknowns with a status on each? ### Who should do requirements gathering at a small agency? Whoever can hold both conversations: business questions early, technical verification before the quote. In practice that means a senior person, which is exactly why the work gets squeezed. The fix is either protecting that person's time, hiring for the role once volume justifies it, or delegating the continuous capture and translation work to tooling and keeping the judgment calls human. ### What format should gathered requirements live in? Whatever your team will actually keep current, with two non-negotiables: every requirement carries a confirmed, assumed, or open status, and the document feeds directly into tickets rather than being filed after kickoff. A requirements document nobody reopens after the quote is a transcript, not a model. --- Canonical page: https://www.commercecopilot.ai/blog/requirements-gathering-shopify-projects