App requirements before the project: how to describe them

Quick facts

• A requirement must be testable: it has to state a condition and the expected result.
• Scope is described through process boundaries, roles and the events that start and end the process.
• Acceptance criteria reduce disputes, and a risk register stabilises the schedule and cost.

Describing requirements effectively before a project is possible without mockups, provided the document separates needs from solutions and gives them an unambiguous, verifiable form. The biggest quality gain comes from working with three mechanisms:

• normalising terms (a glossary, definitions of fields and states) and eliminating synonyms used incorrectly across the organisation,
• modelling behaviour in scenarios and exceptions (alternative paths, errors, limits),
• a quality contract (acceptance criteria, SLA levels, security and compliance thresholds).

Introduction

Describing requirements at the pre-project stage should give business and delivery teams a shared language that lets them judge whether the initiative makes sense, reduce uncertainty and plan the delivery of features in iterations. The biggest threat at this stage is mixing needs with ideas for a screen or a technology, which makes estimation and testing harder. Effective requirements material is not a monolith; it usually takes the form of a set of short artefacts: a description of the goal, scope, roles, process, data, integrations, constraints and acceptance criteria. In practice, the level of detail needs to be enough to answer these questions: what is supposed to happen, who is the actor, what data is needed, what exceptions are possible, what is out of scope and how fulfilment of the conditions will be confirmed. This structure makes it possible to discuss priorities without producing a graphic design.

What a “requirement” means in an app and how to tell it from a solution

A requirement describes the expected outcome and the conditions for meeting it, not how a screen looks or which technology is chosen. It reads most clearly when each need has an identifier, a business rule and a test condition.

In practice, requirements are divided into functional (what the system does) and non-functional (how it should do it: performance, security, availability, compliance). The mistake appears when the description slips into design decisions, such as naming libraries, button layouts or implementation details that are not needed to validate the need. An effective way to tell them apart is to check whether the sentence can be tested without referring to appearance: “the user can regain access” is testable through a scenario, whereas “there should be a button in the top right corner” is not a requirement but a UI proposal.

It is worth keeping three layers of description: the need (why), the rule (what) and the acceptance criterion (how to confirm it). This structure also makes it easier to catch contradictions, for example a requirement for a short login process set against a condition of multi-step authorisation. If the words “screen”, “button” or “colour” appear in the description, the material is usually drifting towards design.

If a requirement has a measurable or auditable outcome, the most likely result is that it will be correctly distinguished from implementation decisions.

How to gather business context: goal, users, processes and events

A good requirements description starts with context: the business goal, the actors and the process the app is meant to support. Without this layer, feature details become a wish list with no priorities.

The goal should have a metric, even if approximate: shorter case-handling time, fewer errors, higher conversion, lower operating cost. Next, working personas are described as process roles, not marketing profiles: who initiates the event, who approves and who only reads. The next step is a process map: the starting event, the steps, the decisions, the end state and the exception paths. At the pre-project stage you do not need BPMN notation; a description of steps and states in the language of the domain is enough.

It is worth adding a definition of the system boundary: what belongs to the app and what stays in external systems or manual activities. This part limits later disputes over “small additions”. Extra stability comes from adding recurring events (for example synchronisations and reports) as well as rare but critical ones (for example complaints, returns and corrections). The material is often supported by analysing similar implementations, for example in the area of apps and platforms, where requirements are based on the process, not on graphics.

If a process has a clearly defined starting event and end state, the consequence is that scope and priorities are agreed faster.

A requirements template: user stories, use cases, acceptance criteria

The most stable set of artefacts before a project is a combination of process events with user stories or use cases and acceptance criteria. This kind of record lets you estimate work and plan tests without mockups.

A user story works well in iterative work: role, need, benefit. A use case better describes complex scenarios with alternatives: actor, preconditions, steps, exceptions, result. Whichever format you use, acceptance criteria should state the entry conditions, validation rules and the final result. Gherkin or an equivalent notation is good practice, without imposing tools: “given… when… then…”. The criteria must also cover errors and limits, for example a lockout after a set number of attempts, required fields and tolerance for integration delays.

In many projects it is useful to attach examples of input and output data, especially for forms or imports. You do need to make sure the examples do not turn into a UI design; it is enough to describe the fields, types, constraints and error messages. In product development, working with a backlog can also help, since features there have priorities and dependencies, which makes the release plan easier.

With acceptance criteria, writing down the condition and the expected result lets you tell a finished feature from a partly working one without increasing the risk of errors.

Data, integrations and constraints: what to describe without technical documentation

Describing data and integrations before a project should state what information is needed, where it comes from and which constraints affect how the app works, without going into implementation. The level needed is one that lets you identify risk and the cost of obtaining the information.

Data is described through a dictionary: field name, business meaning, type, validations, source, retention and sensitivity. Personal and financial data are especially important, because they impose legal and security requirements. Integrations are described through: the external system, the direction of flow, frequency, criticality, the expected response time and the fallback mode when the system is unavailable. At this stage there is no need to describe endpoints; what matters is whether the integration is synchronous or asynchronous and which events trigger it.

Constraints also include the operating environment (browsers, devices), accessibility requirements, languages, regulations, and the budget and timeframe as boundary conditions. It is worth supplementing the material with a list of assumptions and dependencies, because these often become a source of delays; examples are a lack of access to test data or delayed decisions on the part of the process owner.

If an integration has a defined fallback mode and response time, the consequence is fewer blockers in acceptance testing.

Priorities, MVP scope and change control before the project starts

Setting priorities and MVP boundaries lets you describe requirements in a way that allows delivery in stages, without scope creep along the way. The most reliable approach is a split into “must have”, “should have”, “could have” and “won’t have now”.

Priority is not an assessment of how attractive a feature is, but of its impact on the goal and its dependencies. A low-value feature that blocks the process may have a high priority. It is good practice to add to each backlog item its business value, risk, cost and dependencies on data or integrations. The MVP should cover a complete run of the process in its minimal form, not a set of random screens. For this reason, an MVP description often contains conditions that limit variants: only one payment channel, only one user type, no automatic recommendations in the first release.

Change control before the project starts means setting a procedure: who can raise a change, how it is described, how its impact on cost and schedule is assessed and where the decision is made. Without such a procedure, requirements start to drift apart and the team delivers different interpretations. Formalising a change log is sometimes more important than a perfect requirements document.

If a change comes with a description of its impact on cost and schedule, the consequence is fewer disputes over responsibility and priorities.

How much detail is enough before a project: the “testable and estimable” rule

The level of detail before a project is sufficient when requirements are testable and estimable and the risks are out in the open. This boundary limits over-investment in analysis and speeds up the start of work.

Testability means that fulfilment of a condition can be confirmed unambiguously; in practice a requirement must have a measurable result or an observable change of state. Estimability means that the scope is closed enough to estimate the work without guessing: the roles, data, exceptions, constraints and integrations are known. It is worth checking whether most items can be described as an “input–processing–output” scenario with a list of exceptions. The gaps that most often block estimation are undescribed reference data, undefined permissions and hidden legal requirements.

The minimum set before a project usually contains: goals and metrics, process scope, a list of features with priorities, acceptance criteria, non-functional requirements, a list of integrations, risks and assumptions. That is enough to start work on solutions without producing full technical documentation. In areas where requirements depend heavily on the process, examples of delivered apps and systems show that the advantage comes from the precision of the criteria, not the length of the document.

Where there are no criteria for exceptions, the most likely result is that testing and integration work is underestimated.

Which sources of information about requirements are better: workshops or analysis of existing data?

The better choice depends on the source selection criteria: formats, verifiability and trust signals. Workshops deliver knowledge in spoken form and require decisions to be recorded, whereas data analysis relies on artefacts that can be reproduced and compared over time.

Workshops are less verifiable if there are no minutes, decision list or versioning; their trust signal is the participation of process owners and alignment with the organisation’s policies. Analysis of existing data (logs, tickets, reports) can be more verifiable, because it has a provenance trail and can be audited, but the sources may be incomplete or affected by classification errors. The highest quality comes from combining the two: the data identifies facts and frequencies, while workshops clarify intentions and exceptions that leave no trace in the systems.

A requirements matrix before design

A project with similar process logic is described in the Tarnów City Office training platform case study, where roles, permissions and data completeness in the flows are key.

In the area of mobile apps, a similar emphasis on scenarios and exceptions appears in projects such as Tacho App, where the requirements must account for the constraints of the environment and the boundary conditions of operation.

In e-commerce projects with heightened formal requirements, inspiration can come from AlimPay – legal e-commerce, where acceptance criteria and process compliance directly affect the MVP scope.

Questions and answers

What should a requirements description for an app include before design?

The description should contain goals, roles and the process, a list of features with priorities, and acceptance criteria. Constraints, integrations and non-functional requirements are also essential, to make estimation and testing possible.

How should requirements be written so they are unambiguous?

Requirements should be testable and measurable, with the entry condition and the expected result described. A glossary and consistent use of domain terms across the whole material help.

Can UX be described in requirements without mockups?

You can describe behaviour and interaction rules, such as process steps, validations and error messages, without drawing screens. Mockups are part of the design, and requirements should focus on the outcome and the scenarios.

How do you define the MVP so that the scope does not grow along the way?

The MVP should cover a minimal but complete run of the process, with unambiguous exclusions. Effective change control requires a clear procedure for assessing the impact on cost and schedule.

What often causes wrong estimates at the requirements stage?

Most often the description of exceptions, permissions and reference data is missing, which increases the risk of integration and testing work. Hidden legal or organisational dependencies that were not recorded as constraints are a problem too.

Sources

• ISO/IEC/IEEE 29148: Systems and software engineering — Life cycle processes — Requirements engineering (2018)
• ISO/IEC 25010: Systems and software engineering — System and software quality models (2011)
• PMI: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute (2017)
• IEEE: Guide to Writing Requirements Specifications, IEEE (periodic updates)

Summary

Describing requirements before a project works best when it separates needs from solutions and gives the record a testable form. Business context, scenarios with exceptions and acceptance criteria stabilise the scope and make estimation easier. Organising data, integrations and constraints early reduces the risk of delays in implementation and testing.