Requirements, specification and design: the difference, and who each one is for
The three terms get mixed up in vendor conversations, so it helps to separate them by the question each deliverable answers and by who is supposed to read it.
| Deliverable | Answers | Who reads it | When it's enough |
|---|---|---|---|
| Requirements document | What the product must enable, for whom, and what counts as success | Business owner, product owner, the vendor pricing it | For first quotes and deciding whether to proceed to a full spec |
| Specification | How every screen, flow, field and exception behaves | Designer, developer, tester | Before development; usually written together with the chosen vendor |
| UX/UI design | How it looks and feels, and the order of actions on screen | Developer, product manager, test users | After requirements and flows are settled |
The example product: a field-service app
A (fictional) service company wants to move ticket intake, technician scheduling, status updates and visit summaries into one system. Today these happen over phone calls, messages and separate files. The goal of version one: every ticket has an owner and a clear status, with nobody chasing anyone.
Proposed product measures
Measures go into the document so you can later tell whether the product did its job — not to promise an outcome. In the example: share of tickets that get scheduled, time to first update, share of visits with a complete summary, and the number of updates still happening outside the system. There is no baseline and no improvement claim here — those are measured only after launch.
Users and permissions
This table is usually the section with the biggest effect on the quote: every additional role brings screens, permissions, tests and sometimes a separate app.
| Role | What they need | Access in version one |
|---|---|---|
| Service manager | See workload, assign work, review closures | All company tickets, scheduling and basic reports |
| Coordinator | Open and coordinate tickets | Create, update visit details, schedule within their permission |
| Technician | Know where to go and report what was done | Only tickets assigned to them; status updates and summaries |
| System admin | Manage users and settings | Users, roles and system values |
The main flow
- A coordinator opens a ticket with customer, service address, fault type and description.
- The service manager assigns a technician and a visit window.
- The technician sees their ticket list and confirms they received the job.
- The technician opens the ticket, updates its status and documents the work.
- The technician submits a summary with the outcome and any follow-up.
- The service manager reviews and closes, or sends it back for completion.
Ticket states
new → scheduled → accepted → in_progress → pending_review → closed. Exceptional states: cancelled, and waiting_parts when a part is missing. Transitions depend on role: a technician does not close a ticket, a coordinator does not approve a summary. Cancelling never deletes history. This state list is what the developer turns into a data model, notifications and reports — which is why it's worth more than ten lines of "the system shall allow".
Scope of version one
- Sign-in, access recovery and user management in a way that fits the chosen infrastructure.
- Ticket list with search by ticket number and filters by status, technician and date.
- Create and edit a ticket, with required fields separated from optional ones.
- Assign a technician and a visit date.
- A mobile view for the technician with the job details and only the actions allowed to them.
- Status updates, work notes and visit photos — where needed and permitted.
- Completion summary and send-back for completion.
- An operational history of key changes (who, what, when).
- Notification on assignment and on significant changes, through one agreed channel.
- A basic admin screen and data export for authorised users.
Out of initial scope
Billing and payments, a full inventory system, automatic routing, a call centre, an end-customer app, full offline operation, AI-based diagnosis, automatic integration with every ERP. Each needs its own decision and pricing. The exclusions section is often the most useful one in the document: it prevents three quotes from pricing three different products.
Example screens — including empty and failure states
A screen described only in its "everything works" state is half a screen. In practice most development and testing time goes to empty states, errors and missing permissions — so they appear here from the start.
| Screen | Main content | Actions | Empty or failure state |
|---|---|---|---|
| My tickets (technician) | Number, general location, visit window and status | Open, filter, limited update | No jobs; loading failed with retry |
| Ticket details | Needed service info, contact details by permission | Confirm receipt, start work, summarise | No permission; ticket reassigned while viewing |
| Visit summary | Outcome, work done, follow-up needed | Save draft, submit for review | Missing required field; upload failure without losing the text |
| Ticket management (manager) | List, scheduling and status | Open, assign, approve closure | Filter with no results; conflicting updates by two users |
A complete requirement: REQ-01 submit visit summary
This is what one requirement looks like when it is written all the way through. Notice that most lines deal with what happens when things don't go to plan — that is exactly what separates a realistic quote from one that grows mid-project.
“As a technician assigned to a ticket, I want to submit a visit summary so that the service manager can approve closure.”
— REQ-01 — the requirement statement
Preconditions: the user is signed in, the ticket is assigned to them, and the state allows reporting. The summary includes an outcome and work notes; a photo is a field conditional on the spec decision, not automatically required.
Acceptance criteria
- After a successful save the data exists on the server and the ticket moves to pending_review.
- Double-tapping "submit" does not create two summaries or two notifications.
- If the network fails there is no success message, and the entered text stays in the form for a retry.
- Another technician cannot submit or read the summary by changing an id in the URL or the request.
- If the assignment changed while the form was open, the server re-checks permission and returns a clear explanation.
- The service manager sees who submitted and when, can approve or send back, and the event is recorded in the history.
- No summary text, customer address or contact details appear in analytics events.
REQ-02 reassignment (in brief)
A service manager can replace the technician before closure. The change is recorded with user and time. The previous technician loses active access and the new one receives the job according to the defined policy. A screen left open by the previous user does not grant them permission on the next request.
Boundaries that must be written down
Network and data
This version requires a network connection for server actions. A local draft can be kept, but full offline operation must not be promised without designing sync, conflicts, expiry and protection on shared devices. Every file has allowed types and sizes, access permissions and a retention policy. Personal data is not written to general logs and not sent to analytics tools.
Integrations and dependencies
Before pricing, find out: is there a CRM or ERP, do interfaces and documentation exist, is there a test environment, who holds the credentials, what is the quality of customer data, and who approves changes. In version one you can choose manual entry or a defined import, and leave continuous integration for a later phase. Third-party services and connection details are not considered available until verified.
The delivery package
Code and credentials per the agreement, setup instructions, role documentation, dependency list, test scenarios, release process, backup and restore, and a list of items left for later. Define who pays for infrastructure and accounts, who operates them, and what maintenance covers after launch.
Questions left open for the specification
A good requirements document doesn't pretend everything is known. It marks what still needs deciding — which is exactly what lets a vendor price with visible assumptions instead of guessing.
- How many companies or operating units are included, and is data separation required between them?
- Is a store app required, or can we start with a mobile-friendly web interface?
- Which devices and network conditions do technicians actually work in?
- Which summary fields are really needed, who approves, and what is the correction process?
- What data exists today and how is it migrated?
- What support is required and how are emergencies handled?
How to use the document to get comparable quotes
- Fill in the goal, the users and the exclusions first. These three sections move the quote the most, and need no technical knowledge.
- Write the main flow as a numbered list and the states as a list. If you're unsure about a state, write an open question instead of guessing.
- For every screen add one line on its empty state and one on its failure state. That's enough for a serious vendor to price correctly.
- Write one requirement all the way through, like REQ-01, and ask every vendor to respond to it. The difference in answers will tell you more than the price.
- Send the same document to every vendor and ask each quote to state what's included, what isn't, and which assumptions were made about the open questions.
What this document does not do: it does not replace a full specification with a designer and developer, it does not decide architecture, and it does not price itself. Once the quotes are in, the next step is usually UX specification and interface design with the chosen vendor — where requirements become screens, flows and a spec you can build from. What our specification and design phase includes
And if your next question is what this should cost — our app development cost guide breaks the cost drivers down along exactly these sections: number of roles, backend, integrations, testing and uncertainty. How much app development costs in Israel in 2026