A good business application specification document must turn an operational problem into a project that can be estimated: objectives, KPIs, scope, users, permissions, processes, business rules, MVP, data, interfaces, technical constraints, deliverables, and acceptance criteria. There is no single legal format in France, but leaving out these sections quickly increases the budget, timeline, and risk of poor adoption.
How do you define the project context, objectives, and KPIs?
The specification document for a business application starts with a simple answer: what concrete problem do you want to eliminate? Reduce re-entry, make data more reliable, speed up an approval, better track a field team, centralize documents, automate a calculation. If the need remains forulated as “modernize our tools,” the estimate will be fragile.
The context must describe the current organization, the tools being used, the pain points, and the business consequences. For example: three Excel files circulate by email, salespeople re-enter information into an ERP (management software), and errors block invoicing. This level of detail is what allows an agency or vendor to understand the true cost of the problem.
The objectives must then become measurable. A few realistic KPIs for a business application: reduce file processing time by 30 %, cut manual re-entry by 50 %, handle 95 % of requests within the planned timeframe, keep the error rate below 2 %, achieve 80 % adoption three months after launch. At this stage, five well-chosen indicators are better than a decorative bord decorative chart.
On the projects we lead, we often see confusion between a feature and an objective. “Create a notification module” is not an objective. “Reduce missed follow-ups by 40 % thanks to useful notifications” is one. If your project includes alerts, the scoping can also rely on best practices related to push notifications and their acceptance by users.
How do you define the included and excluded scope?
The scope is the project's anti-scope-creep insurance. It specifies what will be delivered, what will not, and what may be the subject of a later phase. Without this boundary, every meeting adds one idea, then another. The budget rarely follows.
A business application specification document must distinguish between functional scope, user scope, and technical scope. Functional: request management, bord, exports, validation workflow. User: administrators, managers, field teams, external partners. Technical: web, mobile iOS/Android, API (connector between software systems), hosting, authentication.
The common trap: wanting to replace the entire information system in the first version. Honestly, this approach is only justified if the old tool is blocking, costly to maintain, or dangerous for the data. In many SMEs, it is better to gradually connect the new application to the existing environment, then replace the weakest components.
To decide between custom development and existing software, a look at the criteria for choosing between custom business software and SaaS helps avoid a costly mistake. A custom application is mainly justified when your rules, integrations, confidentiality constraints, or business calculations do not fit cleanly into a standard tool.
How do you describe users, roles, and permissions?
A business application rarely fails because a button is badly coded. It fails because people misunderstood who does what, with what responsibilities. The specification document must therefore describe user profiles, their tasks, their access rights, and their limits.
For each role, document at minimum: role name, population concerned, authorized actions, prohibited actions, approval rights, data visibility, and escalation rules. It is also a security issue. The GDPR, applicable since 2018, requires limiting access to personal data to people who truly need it.
| Role | Access rights | Validation | Business threshold | Data visibility |
|---|---|---|---|---|
| Contributor | Create and edit requests | No final approval | Request up to €1,000 | Only their files |
| Manager | View requests from their team | Approve or reject | Approval up to €10,000 | Data within their scope |
| Management | View bord dashboards | Exceptional arbitration | Beyond €10,000 | Consolidated view |
| Director | Configure accounts and reference data | No business approval | Not applicable | Technical data and accounts |
This table is not an administrative detail. It avoids, for example, a provider developing a rights management system that is too simplistic, only to have to thoroughly rework it during acceptance testing. Depending on the providers and the complexity, this type of rework can represent anywhere from several days to several weeks of work.
How to formalize processes and business rules?
A process describes the sequence of actions: creation, review, approval, notification, export, archiving. A business rule describes what must happen in a specific case: thresholds, exceptions, calculations, required checks, deadlines, audit logs, error messages. Both are necessary.
The right level of formalization is not necessarily a complex diagram. A clear user journey, step by step, is often enough to bring out the blind spots. What happens if an attachment is missing? If the approver is absent? If the amount exceeds the threshold? If the ERP API does not respond? A single question of this kind can save a costly rework.
On the agency side, the reflex is to transform these rules into verifiable criteria. For example: “if the amount exceeds €10,000, the request automatically goes to the Management role and the action is recorded in the audit log”. That is much more actionable than a sentence like “provide advanced approval”.
When the project involves sensitive data or remote access, the specifications must also include security requirements: strong authentication, logging, backups, retention period, role segregation. The issues often overlap with those of securing remote digital access, especially for mobile teams or partner extranets.
How should MVP features be priorized?
The MVP, or Minimum Viable Product, is the first usable version that achieves the main objective. It is not a rushed version. It is a version deliberately focused on what creates value quickly.
The MoSCoW method, documented by the Agile Business Consortium, remains practical for classifying needs: Must Have, Should Have, Could Have, Won’t Have this time. The “Must Have” items are essential to the product’s goal. The “Won’t Have this time” items are deliberate exclusions for the current version, which protects the budget as much as the schedule.
- Must Have: create a request, approve it, historize actions, notify the people concerned.
- Should Have: filter files, export to CSV, display simple statistics.
- Could Have: customize the interface, add comment templates, provide a dark mode.
- Won’t Have this time: native mobile application, recommendation AI, full integration with all historical tools.
With a constrained budget, it is better to deliver a short, reliable, and adopted scope than a broad application of which half the screens remain unused. In the French market, a simple web business application often starts at around a few tens of thousands of euros, while a complex tool with workflows, APIs, granular permissions, and mobile can exceed €80,000 to €150,000 depending on the providers. The figures vary greatly, but the order of magnitude helps priorize.
If AI is part of the scope, keep the same discipline. The price of code is changing with development assistants, but the cost of planning, testing, security, and integration remains. The topic is well summarized in the analysis on what the drop in the price of code really changes for SMEs.
What data, interfaces, and technical constraints should be documented?
Data is often the real challenge. The specifications document should inventorier the objects being handled: customers, orders, files, contracts, interventions, documents, tickets, invoices. For each one, indicate the current volumes, the historory to migrate, the expected annual growth, the data owner, its sensitivity, its retention period, and the access rules.
Interfaces must be described with the same precision: source system, target system, API type, authentication, exchange frequency, data format, error handling. A REST API (standard web exchange) with OAuth 2.0 authentication is not handled the same way as a CSV export deposited every night on a server. The cost is not the same. Neither is the risk.
An example of a useful record fits in just a few lines: “Customer files: 120,000 records, five years of historory to migrate, annual growth 12 %, personal data, ten-year retention, ERP source, business application target, daily synchronization, alert in case of failure”. This level of detail avoids surprises when taking over data.
Technical constraints also cover hosting, performance, mobile compatibility, RGAA (digital accessibility), GDPR, backups, and monitoring. OVHcloud, Scaleway, AWS, Microsoft Azure, or Cloudflare may be involved depending on hosting, CDN (content acceleration), or protection needs. If the application is highly mobile, the choices differ encore ; thinking about the business application development makes it possible to define web, mobile, and API trade-offs from the start.
What deliverables and acceptance criteria should be planned?
Acceptance testing is the phase where it is verified that the delivered application corresponds to the need. It must be planned from the specifications stage, not improvised at the end. Each important feature should have an acceptance criterion: a measurable condition that makes it possible to say “it is compliant” or “it is not conforme”.
Expected deliverables may include: UX/UI mockups, functional backlog, technical architecture, business rules, data model, test plan, acceptance environment, administrator documentation, user guide, deployment procedures, maintenance plan. For a mobile application distributed outorside the storres, the terms change; the subject of direct distribution of Android applications then deserves to be framed early.
The SLA, or service commitment, must specify expectations after production go-live. IT documents use, for example, an initial response time of one business hour for critical infrastructure, or two business hours for an unavailable application. Your specifications document can adapt these thresholds: blocking incident, major incident, minor anomaly, change request.
Last point: plan for a downloadable or shared template, but adapt it. Public templates, including those oriented toward websites listed by France Num, provide a good framework; they are not always enough for a business application with roles, calculations, audit, APIs, and data migration. A solid outline includes at minimum the following sections: context, objectives, KPI, users, rights, processes, business rules, MVP, data, interfaces, security, schedule, budget, deliverables, acceptance, and support.
Defining this type of project upfront avoids most unpleasant surprises: unclear scope, underestimated permissions, poorly anticipated data migration, acceptance testing that is too subjective. This is often where an outside perspective saves time, especially for transforming business uses into usable journeys, backlog, architecture, and validation criteria.
FAQ on the specifications document for a business application
Who should write the specifications document for a business application?
The business side must carry the requirement, because it knows the uses and exceptions. A project manager, an IT department, or an agency can then structure the document to make it estimable and testable.
How long does it take to prepare a specifications document?
For a simple SMB application, it often takes one to three weeks of scoping. A project with several services, APIs, and data migration may require four to eight weeks before any serious cost estimate can be made.
Should everything be specified before developing in agile?
No, but the objectives, MVP scope, roles, data, and constraints must be clear. Agile allows adjustments, not compensation for a poorly defined need.
What budget should you plan for a business application?
Depending on the scope, French projects often range from a few tens of thousands of euros to more than €100,000. Workflows, fine-grained permissions, APIs, security, and data migration quickly drive up the budget.