Requirements gathering for an enterprise MVP: what to ask, what to write down
How I run discovery for an enterprise MVP: mapping stakeholders, running process workshops, writing user stories with testable acceptance criteria, and pinning down the non-functional requirements that decide the architecture.
Series · Part 2 of 7Enterprise MVP, end to end
- Enterprise MVP, end to end: from the first workshop to production
- Requirements gathering for an enterprise MVP: what to ask, what to write down
- Architecture design for an enterprise MVP: C4 diagrams, a modular monolith and the seams that matter
- Database design for an enterprise MVP: from domain model to the first PostgreSQL migration
- Developing an enterprise MVP with Flask and React: structure, workflow and tests
- CI/CD for an enterprise MVP: GitHub to Cloud Build to Cloud Deploy
- GKE or Cloud Run? Choosing where an enterprise MVP runs, and the go-live checklist
On this page · 6 sections
Requirements gathering for an enterprise MVP isn’t about collecting wishes. It’s about finding the smallest set of things that, if built, makes the client say “yes, keep going”, and the set of constraints that, if ignored, makes their security team say “no, this can’t go live”.
This is part 2 of a series following one illustrative project, a supplier onboarding portal for a manufacturer, from requirements to production. Part 1 has the map of the whole journey.
Who are the stakeholders in an enterprise MVP?
The person who commissions the system is rarely the only person who can stop it. In the first two days I build a stakeholder map, and I keep it in the scope document:
| Stakeholder | What they want | What they can block |
|---|---|---|
| Head of procurement (sponsor) | Faster onboarding, visibility | Budget, priorities |
| Procurement officers | Less chasing, fewer emails | Adoption |
| Compliance reviewers | Complete documents, clear evidence | Approval workflow design |
| Finance | Verified bank details before the first payment | Go-live, if bank checks are weak |
| Suppliers (external) | A form they can finish in one sitting | Adoption, data quality |
| IT security | SSO, data protection, pen-test sign-off | Go-live |
| IT operations | Something they can run and monitor | Go-live, hosting |
| Internal audit | Who approved what, and when | Go-live, in regulated industries |
| ERP team | No duplicate or malformed vendor records | The integration |
The last four rows are the ones teams forget. They didn’t ask for the system, they won’t attend your demos, and they can each delay launch by a month. I book a 45-minute session with each of them in week one.
How do you run discovery workshops?
Two kinds of workshop, in this order.
Process walkthroughs. I ask a procurement officer to onboard a real (or recent) supplier while I watch, screen-shared. Not “describe the process”, but do it. People describe the process they think they follow; watching shows the spreadsheet they keep on the side, the three emails they copy-paste, and the folder where rejected documents go to die.
Story-mapping sessions. With the sponsor, two officers, a reviewer and finance in one room, we lay the supplier’s journey left to right (invite, register, fill in details, upload documents, review, approve, sync to ERP) and hang user stories under each step. Then we draw a line: everything above the line is the MVP.
The output of the walkthroughs becomes the state model of the application, which is worth drawing early because it settles arguments fast:
Notice what the diagram forced us to decide: there is a changes requested loop (not just approve or reject), approval needs both compliance and finance, and ERP sync can fail independently of approval. Each of those is a conversation that would otherwise happen in week seven.
How should user stories be written for an enterprise MVP?
In the standard shape, but with acceptance criteria precise enough that a tester can verify them without asking me:
As a compliance reviewer, I want to request changes on a specific document with a comment, so that the supplier knows exactly what to fix.
Acceptance criteria:
- Given an application In review, when I mark a document as Changes requested and enter a comment of at least 10 characters, the application moves to Changes requested.
- The supplier receives an email within 5 minutes containing the comment and a link to the document.
- The audit log records reviewer, document, comment and timestamp.
- I cannot request changes on an application that is already Approved.
The fourth criterion is the one that matters. Negative cases are where enterprise MVPs fail user acceptance testing.
What are non-functional requirements, and why do they matter so much?
Functional requirements decide what the system does. Non-functional requirements (NFRs) decide what it is: its architecture, its database, where it runs and what it costs. They’re also the requirements clients are worst at stating, so I bring a checklist and ask for numbers.
| Area | Requirement for this project | What it later drives |
|---|---|---|
| Authentication | SSO with the client’s identity provider (OIDC); suppliers use email magic links | Auth design, session model |
| Authorisation | Roles: procurement, compliance, finance, admin, supplier; suppliers see only their own data | API checks, row-level filtering |
| Audit | Every state change and document action recorded; retained 7 years | Audit table design, storage cost |
| Availability | 99.5% during business hours (IST); planned maintenance allowed at weekends | Single region, managed services, no multi-region |
| Performance | p95 page load < 2 s; document upload up to 20 MB | Signed upload URLs, CDN |
| Scale | ~500 suppliers a year, ~50 internal users, peaks at quarter end | Cloud Run over GKE, small database tier |
| Data residency | All data stored in India | Region asia-south1 |
| Security | OWASP ASVS level 2, annual pen test, encryption at rest and in transit | Managed services, secret handling, review gates |
| Integration | ERP vendor master updated within 15 minutes of approval | Async queue with retries, not a synchronous call |
| Recovery | RPO 1 hour, RTO 4 hours | Cloud SQL automated backups and point-in-time recovery |
Look at the right-hand column. “500 suppliers a year and 50 internal users” is why part 7 of this series ends up recommending a serverless runtime. “ERP updated within 15 minutes” rather than “instantly” is why the integration can be asynchronous and resilient. A single number captured in week one removes weeks of over-engineering later.
How do you decide what’s in the MVP?
MoSCoW (Must, Should, Could, Won’t), applied ruthlessly, with the Won’t list written down:
- Must: supplier registration and application form, document upload, review workflow with changes-requested loop, SSO for internal users, roles, audit log, ERP sync, email notifications.
- Should: reviewer dashboard with ageing, bulk invite from CSV.
- Could: supplier self-service updates after approval, analytics.
- Won’t (this phase): supplier risk scoring, contract management, multi-language UI, mobile app.
The Won’t list is the most valuable part of the scope document. It turns “can we also…” in week six into a pointer to a page everyone signed.
What does discovery hand over?
One scope document, versioned, with:
- Problem statement and success measures (e.g. median onboarding time from 4 weeks to 1 week).
- Stakeholder map.
- Process maps, current and future, and the state diagram.
- User stories with acceptance criteria, prioritised.
- Non-functional requirements as numbers.
- Out-of-scope list.
- Assumptions and open questions, each with an owner.
It’s signed by the sponsor, security and IT operations. That signature is what lets the architecture phase start from facts instead of guesses.
Next: Architecture design, turning these requirements into C4 diagrams and decisions.
Requirements you don’t write down as numbers will be written down later as incidents.