Contents
- Start with the problem, with an observable outcome
- Describe the users and permissions
- Document the normal workflow and exceptions
- Inventory data and systems
- Assign a priority to each requirement
- Write the acceptance criteria before the quote
- Provide for the decisions and deliverables of the scoping phase
- A template to copy into your document
- Sources and method
The specifications for a custom application should allow a team to understand the work to be done, the data handled, and how to verify the delivery. It does not need to lock in each screen. Its main purpose is to make visible the decisions that affect scope, cost, and risk.
In brief
- Start from a real process and its exceptions, then identify the users.
- Describe the data, permissions, and connections before the visual details.
- Prepare acceptance criteria that the operations team can verify.
Start with the problem, with an observable outcome
"We want a portal" describes a form of solution. "Our clients call to know the status of their order because three teams each have part of the information" describes a problem. The second formulation allows for examining several options: a portal, an integration, a process change, or a combination.
Record the current workflow, the people involved, the approximate volume, and situations that require intervention. Distinguish what you observed from what you assume. If lost time has never been measured, indicate it: a short observation of the work can be more useful than a seemingly precise estimate.
The expected result might be that a client sees a reliable status, that an employee no longer re-enters an order, or that a manager spots blocked files. Also write down what the first project does not intend to change. This boundary protects the budget when useful ideas appear during workshops.
Describe the users and permissions
The same record can serve multiple roles without granting the same rights. The client views their file; the representative corrects commercial information; accounting validates a payment condition. List who can view, create, modify, approve, and export each category of information.
Include replacements and departures. Who retrieves the files of an absent employee? How are accesses removed? A shared account seems convenient, but it makes actions difficult to attribute. The specifications must allow the technical team to design permissions based on actual responsibilities.
OWASP highlights authorization risks in APIs. For your framework, this means that a person authorized to view one order does not necessarily have access to all customer orders. Require boundary-check scenarios, not just a login page.
Document the normal workflow and exceptions
For each priority process, write the trigger, steps, inputs, outputs, and the person who confirms the result. Add at least one successful example and one exception example. A complete order may be simple; an order canceled after invoicing reveals the decisions the application needs to handle.
TableDocument the normal workflow and exceptions · shareable block
| Vague wording | Actionable wording | |
|---|---|---|
| Result | Simplify operations | Display files without a responsible party and allow their assignment |
| User | Employees | The supervisor assigns; the technician updates only their own files |
| Exception | Handle errors | Keep an interrupted request and indicate the next action |
| Integration | Connect the CRM | Import the customer number and sync the status according to a defined rule |
| Acceptance | The application works | Verify a set of representative files with business managers |
This grid illustrates a scoping method, not a universal scope. You can use it in a simple document. Five clearly described processes are better than a catalog of one hundred features without priority or success criteria.
Inventory data and systems
List the sources: spreadsheets, accounting tool, CRM, forms, documents, and email inboxes. For each, identify the owner, update frequency, identifiers, and known issues. Two columns named "client" do not necessarily refer to the same thing.
Specify the reference for each important piece of data. Does the price come from accounting or the catalog? Does the shipping status come from the carrier or an internal entry? Without this decision, synchronization can replace correct information with an old value.
Also describe the need for historical records. A team may need to review past invoices without modifying them. This does not always require rebuilding all functions of the old system. Providing an accessible archive can reduce the scope, provided that access and retention are defined with the responsible parties.
Assign a priority to each requirement
Classify the requirements into three groups: necessary to execute the first process, useful after the first batch has been validated, and to be explored. For each necessary requirement, ask what happens if it is missing. A concrete answer helps distinguish an operational requirement from a preference.
Fictitious illustration: a service company may launch a first batch that creates the interventions, assigns them, and tracks their status. The complete financial table may come later if the existing accounting system continues to play that role. The objective of the first batch is to complete a usable workflow rather than partially building all modules.
Before opting for custom development, reread decision framework between application and SaaS. The specifications can also be used to configure existing software or to build only the missing integration.
Write the acceptance criteria before the quote
An acceptance criterion describes an observation. For example: after adding a file, the supervisor finds it in their queue, assigns it to a technician, and the client only sees their own file. Prepare the test data and name the person who will decide if this behavior meets the requirement.
Add the operational criteria: restoration from a backup, visibility of a synchronization failure, and removal of access. For performance, specify the workflow, the volume, and the measurement conditions; "fast" does not constitute a reproducible test.
Accessibility must be integrated into planning, as recommended by the W3C. Define the workflows to verify via keyboard, the readability of errors, and the profiles to consult. A demonstration on the developer's laptop does not represent all users nor all usage conditions.
Provide for the decisions and deliverables of the scoping phase
The final file must include the priority processes, the data map, integrations, roles, acceptance criteria, and remaining unknowns. Add a list of decisions with their responsible person and deadline. A team cannot confirm a reliable estimate if access to an API or the quality of data remains hypothetical.
Request that the quote separates assumptions from the firm scope. Data cleaning, training, and deployment must be visible. Our custom web application service can then be discussed from a common file and a first measurable delivery.
A template to copy into your document
This template proposed by Daillac can fit on a few pages. Replace each element in brackets and attach an anonymized example. Leave the unknowns visible: they will serve to prepare the scoping workshop rather than being silently transformed into estimate assumptions.
- Current problem: [process], [people involved], [frequency], and [observed consequence].
- Expected result: [feasible action], [measurable criterion], [responsible person approving the delivery].
- Users: [role], [data viewable], [authorized actions], [prohibited actions].
- Priority workflow: [trigger], [steps], [expected output], [two exceptions].
- Data: [source], [fields], [volumes], [known quality], [retention rule to specify].
- Interfaces: [system], [direction of exchange], [acceptable delay], [behavior on failure].
- First version: [essential], [deferrable], [explicitly excluded].
- Acceptance: [set of files], [expected result], [evidence to keep].
- Exploitation: [hosting], [responsible person], [support], [access and documentation to provide].
- Open questions: [question], [decision-maker], [decision date].
Filled example: a small field service business
The following case is fictitious. A company with twelve technicians receives its requests by email; the coordination transcribes them into a spreadsheet. The goal of the first version is that an approved request becomes an assigned work order, then a complete file ready to invoice. The number of people is used to size the roles; it does not predict the price or duration of the project.
TableFilled example: a small field service business · shareable block
| First version decision | Acceptance criterion | |
|---|---|---|
| Coordination | Create and assign an intervention | The work order has a stable number and a technician |
| Technician | See their interventions and attach a report | Technician A does not see Technician B’s files |
| Invoicing | Receive completed interventions | An incomplete intervention is not transmitted |
| Data | Import active clients from the spreadsheet | Each line is imported or listed in a rejection report |
| Exception | Client absent or address incomplete | The request remains pending with a visible reason |
| Out of scope | Automatic route optimization | No estimation of this module is included in the MVP |
An actionable acceptance-test scenario: the coordination creates a request for the fictitious client CLIENT-042; they assign it to Technician A; the latter attaches the report; invoicing retrieves the file with its documents. Then replay the scenario without a required document and with Technician B’s account. Acceptance testing requires the success of the complete process and the rejection of the two forbidden situations. "The form works" does not cover these conditions.
In this example, offline functionality remains an open question. The provider must specify whether they offer a local draft, simple offline reading, or no support. This distinction affects the quote. A vague phrase like "mobile application" does not allow one to decide between these behaviors.
Frequently Asked Questions
Is it necessary to design all screens before consulting an agency?+
No. A few sketches can clarify a workflow, but processes, data, and permissions are more important at this stage. Screens will need to be adjusted with users. Avoid turning a sketch into a final requirement too early.
Can we request a quote with just a simple spreadsheet?+
Yes, if the spreadsheet describes the needs, priorities, examples, and open questions. The format of the document matters less than the quality of the information. Attachments must be anonymized if they contain sensitive data.
What level of detail is needed for integrations?+
Identify the systems, data exchanged, frequency, synchronization direction, and exceptions. The team can then verify access, limits, and rights. Do not assume that an available connector covers all your processes.
How to limit changes during development?+
Define a first complete workflow and a list of deferred needs. For each new request, evaluate its value, dependencies, and effect on the budget. Document the decision to replace, postpone, or add a feature.
Sources and method
W3C WAI — Planning and managing accessibility · OWASP — API Security Top 10, 2023 edition. Sources consulted on October 1, 2026; the grids and decision examples are an editorial analysis by Daillac.
Moving from your need to an initial scope
Present us with a real process, a sample document, and the main exceptions. We will be able to scope a first delivery and the points to clarify before the quote.
D
