Requirements Documents in App Development: Defining What Your App Must Do

Anyone who commissions an app without defining the requirements properly pays twice: first for the misunderstandings, then for the rework. A good requirements document is the cheapest risk management an entire project will ever buy. This article shows what belongs in a requirements document for app development, how to phrase requirements precisely and why all of this works in agile projects too.

Here is an example that plays out again and again in some form. A mid-sized energy utility wants a service app for its customers, with meter reading capture, an invoice overview and tariff switching. The enquiry sent to three agencies consists of two paragraphs of email. The proposals come back: 30,000 euros, 95,000 euros, 180,000 euros. The spread does not come from wildly different rate cards. It comes from every supplier offering something different. The first plans a lean MVP with a web interface inside an app shell. The second a cross-platform app connected to the existing billing software. The third two native apps plus a new backend and an admin portal. All three proposals are serious; not one of them is comparable to the others. A requirements document is what solves exactly this problem.

Why no proposal is comparable without a requirements document

A requirements document describes the totality of the client’s demands regarding the deliverables and services of the contractor. That definition comes from the German project management standard DIN 69901-5, which is where the widely used term Lastenheft originates; the international counterpart for software is ISO/IEC/IEEE 29148. What matters more than the standard is the allocation of roles: the requirements document is written by the client. Third parties may contribute to it, in individual cases even the eventual contractor, but responsibility for its content stays with the client.

In the project timeline the requirements document sits right at the beginning, before development proper. It serves three functions at once. First, it is the basis for the tender and for comparing proposals: only when every supplier answers the same catalogue of requirements can proposals be laid side by side. Second, it is a contractual basis; scope of work and acceptance criteria can only be enforced later if they were documented beforehand. Third, it is an instrument of communication: working on the document forces the parties inside your own organisation to agree on what the app is actually supposed to do. Many contradictions between the business unit, IT and management surface here for the first time, at the cheapest possible moment to resolve them. That clarifying effect also works inwards: having to put requirements in precise writing means thinking them through, discovering gaps and tacit assumptions in your own picture of the app, and ending up understanding your own project far better than two paragraphs of email would ever compel.

Requirements document and functional specification: the what and the how

The two documents are often conflated, yet the distinction is simple. The requirements document answers “what” and “what for” from the client’s point of view. The functional specification, known in German-speaking practice as the Pflichtenheft, answers “how” and “with what”: it contains the realization specifications worked out by the contractor on the basis of the requirements document, and it should be signed off by the client before implementation starts. In software development the IEEE 830 specification (Software Requirements Specification) was the long-established reference, although it does not separate the two documents; its successor is ISO/IEC/IEEE 29148, currently in its 2018 edition.

From that separation follows the single most important rule for your requirements document: describe requirements, not solutions. Detailed specifications for the technical implementation narrow the solution space before the search for a solution has even begun. “The app must be built with React Native” is a solution mandate. The actual requirement behind it usually reads: “The app has to ship on iOS and Android, and both budget and team only allow for a single shared codebase.” Phrased that way, a supplier can propose React Native, Flutter or Kotlin Multiplatform and justify the choice on the merits. Whether a technology mandate still makes sense, for instance because your own team is meant to take over development later, is a deliberate decision; it then belongs, with its rationale, in the guidelines for technology decisions, not hidden inside a feature description.

What belongs in a requirements document for app development

As a skeleton, the outline proposed by Helmut Balzert has proven itself, because it concentrates on the essentials: objectives, product deployment, product functions, product data, product performance, quality requirements and supplements. For an app project that translates as follows:

Objectives: which measurable goals should the app achieve? For the fictional energy utility, for example: after twelve months, 30 percent of meter readings are submitted through the app, with calls to the service centre falling accordingly. Goals like these later decide which features go into the MVP and which can wait.

Product deployment and target groups: who uses the app, in what context, on which devices? This is where the target platforms belong (iOS, Android, possibly tablet or web) along with the oldest operating system versions to be supported; both have a direct effect on effort and architecture.

Product functions: the core functions from the user’s point of view, without going into detail. Registration and login, meter reading capture with the camera, invoice archive, push notifications, tariff switching. Secondary functions and edge cases do not belong here; they emerge later in the detailed specification. If the app is also meant to offer its functions to voice assistants and system-level AI, our article on App Intents is worth a look.

Product data: which data has to be stored persistently, and where? Customer records, contracts and meter readings usually live in the backend, not on the device. Personal data should already be flagged as such here; it saves weeks in the later data protection review.

Product performance: requirements on time, data volume and accuracy for individual main functions, for example the response times of interfaces or a capacity model such as 50,000 registered users and 5,000 concurrent sessions at the end of the month when the bills go out.

Quality requirements and supplements: reliability, usability, efficiency, plus stipulations such as corporate design, existing style guides or mockups.

App projects add points that classic templates from the desktop software era do not cover. The first is the system landscape: which existing systems does the app have to connect to, through which interfaces, and who is responsible for adapting them? In practice this point decides budget and timeline more often than the app itself does. The second is operations: hosting, maintenance, monitoring and the process for updates, because an app is not finished after launch, it has only just reached the market. The third is store reality: Apple and Google review every submission against their guidelines, and their rules, on login methods or on in-app purchases for digital goods for example, should not come as a surprise at release time. And the fourth is the project framework: timeline with milestones, budget envelope, points of contact, test procedures and acceptance criteria.

Non-functional requirements: the underrated part

Most requirements documents describe functions at length and qualities not at all. Yet it is the non-functional requirements that determine whether the app feels good and whether it can be operated in compliance with the law. Four areas deserve particular attention.

Performance and offline capability: does the app have to be usable without a network connection, and if so, which functions? Capturing a meter reading in a basement without reception is a realistic scenario. Retrofitting offline capability is expensive, because it reaches into the data architecture.

Security and data protection: the GDPR requires data minimisation and clear responsibilities. The requirements document should state the desired hosting location, requirements for encryption and authentication, and which data is particularly sensitive.

Accessibility: the European Accessibility Act obliges, among others, apps used in e-commerce, so shops, booking functions, banking services and passenger transport apps, to be accessible; for services, only micro-enterprises with fewer than ten employees and at most two million euros in annual turnover are exempt. National implementations set the dates, in Germany the Barrierefreiheitsstärkungsgesetz (BFSG), which has applied since 28 June 2025. In practice the Web Content Accessibility Guidelines (WCAG) serve as the technical reference. Discovering this requirement only after release means an expensive rebuild; in the requirements document it costs a paragraph.

Scalability and maintainability: will the user base grow predictably or in spikes? Should your own team be able to continue development later? Both influence architecture decisions that are hard to reverse afterwards.

Writing requirements that hold up

A requirements document is only as good as its individual requirements. Three rules of craft make the difference.

First: measurable instead of vague. Every requirement should be phrased so that whether it has been met can be checked objectively.

Vague:      "The app must start quickly."
Measurable: "A cold start to a usable home screen takes at most two seconds
             on a three-year-old mid-range device."

Second: prioritise. Not every requirement carries the same weight, and a requirements document in which everything is a “must” is no requirements document at all. The MoSCoW distinction (must have, should have, could have, won’t have) has proven itself. It creates the basis for a sensible MVP and stops nice-to-have features from eating the budget of the core functions.

Third: traceable. Give every requirement a unique ID. That traceability pays off twice over: in the proposal, a supplier can state effort and approach per requirement, and in testing, every acceptance can be traced back to a requirement. Acceptance criteria can be phrased precisely as scenarios for this purpose, for instance in Gherkin format:

Scenario: Capture a meter reading without a network connection
  Given the user has no internet connection
  When they save a meter reading
  Then the value is stored locally
  And transmitted automatically on the next connection

Part of this is a controlled way of handling change: new requirements are documented, assessed and then deliberately accepted or rejected. Without that process the project scope grows unnoticed; the phenomenon known as scope creep is one of the most common reasons budgets blow up.

Six steps to a requirements document

A six-step approach has proven itself for putting the document together:

1. Gather stakeholders: get everyone involved around one table: the business unit, IT, support, marketing, data protection. Collect requirements unfiltered at first.
2. Structure: sort the collection along an outline, the one after Balzert described above for example, extended by the app-specific points.
3. Prioritise: separate must-haves from nice-to-haves before anyone talks about budgets.
4. Phrase precisely: measurable criteria, unique IDs, clear language without open-to-interpretation terms such as “user-friendly” or “performant”.
5. Review: have the document checked and approved by all stakeholders. An external development partner can reflect feasibility and completeness back to you at this stage already.
6. Let it live: treat the requirements document as a living document with version history and a change log, not as a stone tablet decided once and for all.

On length, an honest word: for a typical business app, ten to twenty concentrated pages are worth more than a hundred nobody reads. Wireframes and sketches in the appendix replace many pages of prose, because people argue over a picture faster and reach agreement over it faster than over a paragraph.

Creating a requirements document with AI

AI assistants can support the work meaningfully too, if you use them the right way. Three usage patterns have proven themselves. For brainstorming, have requirements, user roles and edge cases suggested for your app idea that your team has not thought of yet; the results are raw material for step 1, not finished requirements. For quality checking, feed in your draft and have it criticised deliberately: which requirements are vague or not measurable, where are solution mandates hiding, which points contradict each other? And in the supplier role, you can simulate the questions a development partner would ask about your document; each of those questions marks a gap in it. Two rules come with this: for confidential project content, use only services whose data protection and confidentiality commitments your company has vetted, and treat every AI suggestion as a draft to be assessed on the merits by a human. Responsibility for the requirements document stays with the client.

Requirements documents and agile development: not a contradiction

The common objection to the requirements document is that it comes from the waterfall world: the document is finished, the signatures are dry, and the solution still fails to match the actual needs in the end. The objection deserves to be taken seriously. In dynamic project environments, fully pre-specified requirement catalogues run into their limits; changes then lead to delays, extra cost or products that miss the need. Agile approaches therefore rely on requirements that emerge iteratively and incrementally over the course of the project and are refined as user stories.

What follows from that is not that you should do without a requirements document; only that its cut changes. An agile project, too, needs answers to the stable questions before the first sprint: which goals does the app pursue, for whom, with which must-have functions, on which platforms, in which system landscape, with what budget envelope and which legal requirements? A lean requirements document answers exactly these questions and leaves the how open. Its prioritised requirements become the initial product backlog: must-have requirements become epics, epics are refined into user stories sprint by sprint. The document remains the stable frame against which changes can be measured: whatever serves the goal goes into the backlog; whatever shifts the goal is a deliberate decision by the client and not silent drift. Only for strongly exploratory products, whose target picture is still searching for itself, would a detailed requirements document be premature; there a vision, some guardrails and a budget for validating experiments will do.

Conclusion

The requirements document is not a bureaucratic artefact from the past, it is the cheapest risk management an app project knows. It makes proposals comparable, contracts enforceable and internal conflicts of interest visible before they cost money. Anyone unable to describe their own requirements delegates the most important product decisions to the supplier’s interpretation; when in doubt, to the cheapest supplier’s. Ten precise pages with measurable, prioritised and traceable requirements are enough for that, and they work as a foundation for classic and agile projects alike.

Planning an app and want to put your requirements on a solid foundation? Johnny Bytes builds apps, web applications and backends from a single source and supports you from the requirements phase onwards: from structuring your requirements document through technical feasibility assessment to a prioritised backlog. Get in touch.

Sources

• Lastenheft: Anforderungen in der Softwareentwicklung richtig definieren (entwickler.de, Dr. Veikko Krypczyk, in German)
• Lastenheft für App Entwicklung (deineseite.at, in German)
• Lastenheft, with the DIN 69901-5 definition (Wikipedia, in German)
• Pflichtenheft (Wikipedia, in German)
• Von Lastenheft zur User Story: Requirements Engineering im Wandel (Rexult, in German)
• European Accessibility Act (European Commission)
• ISO/IEC/IEEE 29148:2018 Requirements Engineering (iso.org)