Web application specification: the sections to include

A web application specification describes what the application must allow people to do, for whom and under which constraints, before a provider proposes a solution. It is used to consult providers, to frame the contract, then to run acceptance testing. This guide explains how it differs from a technical specification, the sections to include, how to write verifiable requirements and the mistakes that prove costly later.

It is written for managing directors, CIOs and product managers preparing the custom development of a web application: a customer portal, a business tool, a platform. A showcase site needs a lighter document; the principles remain the same.

What is a web application specification?

A web application specification is the document in which a company states its need before having an application developed: the users, what they must be able to do, the constraints to respect and the criteria that will show whether the result is right. It comes before the choice of a solution and serves as the reference throughout the project.

The NF EN 16271 standard, published by AFNOR in 2013 to replace the French standard NF X50-151, defines the functional specification as the expression of a need in terms of service functions and constraints. For each function, it calls for assessment criteria, with an expected level and its flexibility: what is negotiable and what is not.

The document is used three times: to consult providers on a common basis and compare their answers, to frame the contract, then for acceptance testing, that is, checking at delivery that what was asked for is really there.

Functional or technical specification: what is the difference?

The functional specification says what the application must do; the technical specification says how it will do it. The first belongs to whoever expresses the need, the second to those who design the solution.

Mixing the two is the most common mistake: imposing a language or a tool in the functional specification shuts out better solutions and blurs the comparison of offers. A real constraint, such as integration with your ERP or imposed hosting, belongs there; a preference with no reason does not.

Which sections should a web application specification include?

A web application specification comes down to ten sections, from the reason for the project to the arrangements after delivery. They do not all need the same length; none should be missing.

• Context and objectives. The company, the problem to solve, what exists today, and the measurable objectives of the project.
• Scope. What the application covers, and what it does not: the list of what is out of scope prevents as many misunderstandings as the rest.
• Users and their roles. Who uses the application (customers, internal teams, partners, administrators) and what each of them may see and do.
• Journeys and functions. What each user must be able to do, journey by journey, with the business rules that apply.
• Data. The information the application creates, receives or displays, where it comes from, how long it is kept, and the migration of existing data.
• Exchanges with other tools. ERP, CRM, payment, authentication, internal tools: what is exchanged, in which direction and how often.
• Non-functional requirements. Expected performance, availability, security, accessibility, browsers and devices, languages.
• Constraints. Technical (existing systems, imposed hosting), regulatory, budgetary and scheduling, each with its reason.
• Priorities and acceptance. What is essential for the first version, what can follow, and how each function will be checked at delivery.
• Consultation and after delivery. What the provider’s answer must contain, code ownership, documentation, maintenance and reversibility.

The last sections are often the shortest and the most forgotten. Yet they decide what happens after delivery: who owns the code, who maintains it, and how you change provider. Our guide to the application maintenance contract details these clauses.

How do you write the functional requirements of a web application?

A well-written functional requirement states who does what, for what purpose, and how you will know it has been met. The ISO/IEC/IEEE 29148 standard, dedicated to requirements engineering, notably requires a requirement to be unambiguous and verifiable.

In web projects, the most widespread form is the user story, followed by its acceptance criteria and its priority:

Three rules avoid most unusable requirements: one requirement per sentence; no word that cannot be measured (“fast”, “intuitive”, “modern”) without saying how it is measured; a priority for each. The MoSCoW method, which classifies each requirement as must have, should have, could have or won’t have this time, is a simple reference.

What should you plan for data, security and accessibility?

Personal data, security and accessibility belong in the specification because they cost far more to add afterwards. For personal data, it is an obligation: Article 25 of the GDPR requires data protection by design and by default.

• Personal data. Which data is collected, why, how long it is kept, who can access it, and how a person exercises their rights. Test environments count too: see our article on test data and the GDPR.
• Security. Authentication, roles and permissions, a record of sensitive actions, backups, and what happens when a vulnerability is discovered.
• Accessibility. The target level and the journeys concerned. For certain online services, including e-commerce, the European Accessibility Act has made it an obligation since 28 June 2025: our European Accessibility Act checklist explains who is concerned.
• Migration of existing data. Where the data to migrate comes from, what state it is in, and who validates it before go-live.

Which mistakes should you avoid in a specification?

The costliest mistakes in a specification are the ones that only show at delivery: a need described as a solution, a scope with no limits, a requirement that cannot be verified.

• Describing a solution instead of a need. “A drop-down menu”, “a MySQL database”: without saying what it is for, the provider cannot propose anything better.
• Leaving the scope open. Whatever is not written as out of scope will end up being argued over, at the worst moment.
• Giving everything the same priority. The provider can no longer propose a realistic first version.
• Writing without the users. The real business rules lie with those who do the work every day.
• Forgetting what comes after. Without code ownership, documentation and maintenance planned, an application quickly turns into technical debt, and its takeover by another provider is costly.
• Freezing the document. A specification is updated when the need changes, with a dated version.

Frequently asked questions

Specification: start from the need, not the solution

A good web application specification does not foresee everything: it says what matters, for whom, how it will be checked, and what will happen after delivery. The rest is built with the chosen provider.

The iones team develops custom web applications nearshore from Tunisia, for French and European companies, and can start with an audit of your existing system or your need. You can also write to us for an initial discussion.