How to write requirements for a business application

Start with one situation you want to change

“We need a business management system” leaves almost every decision open. A more useful starting point is: “The office books a service visit, but the technician has to call for the address, fault description and photos. We want to hand over a complete job in one place.” This is an illustrative example, not a client project.

Describe how often it happens, who is affected and what improvement would look like. In this example, a useful check is whether the technician can open a complete job without searching messages for attachments. Avoid promising a percentage saving when the current work has not been measured.

That short description is enough for an initial enquiry. A fuller brief will help compare proposals later; it should not stop you from starting a conversation.

Follow the work from start to finish

Walk through one ordinary case. Identify its trigger, required information, the people involved and what counts as completion. Note the tool used at each step: a spreadsheet, email, existing program or paper form.

Separate roles even if one person currently performs several of them. “The office receives a request” and “the technician records completed work” describe different needs. They help establish who can see a price, change a deadline or remove an attachment. Saying that there will be five users does not answer those questions.

Include working conditions. Will someone use a phone, wear gloves or share a device? Is an internet connection always available? Describe the expected behaviour. Working offline needs its own scope assessment; it is not an automatic consequence of a website opening on a phone.

Describe data and rules, not just screens

List the information needed for a job: reference, customer, location, date, description and attachments. For each item, identify its source and when it becomes mandatory. An address may be unnecessary during the first enquiry but essential before a technician leaves.

Write rules in ordinary language: “The office can assign the visit after providing a location and fault description.” Explain what the person sees when something is missing. A generic error message gives little help with completing the task.

Useful sample materials include an empty form, an anonymised job and a few spreadsheet rows. Remove details that are unnecessary for understanding the work. An initial enquiry does not need your complete customer database or passwords for current systems.

Turn broad features into acceptance checks

Scroll the table sideways to read the full comparison.

These are examples to adapt, not a standard package of features. Writing requirements this way exposes decisions that might otherwise only emerge during final testing.

Include the exceptions that actually happen

Choose a few common or costly exceptions. A customer reschedules, the office changes the technician, a photo is attached to the wrong job or a visit cannot be completed. Explain who decides what happens next and what information needs to remain available.

Mark unanswered questions explicitly. “We have not decided who may cancel a job once work starts” is useful information. A developer can help design the handling of that situation, but should not accidentally decide who has authority in your business.

Separate the first version from later ideas

Create three groups: essential for the selected task, temporarily manageable outside the application, and deferred. Every essential item should have a reason: someone cannot complete the work without it, or the result cannot be checked.

For the service example, the first version could record requests, assign technicians and capture completed work. Route optimisation, a customer portal and invoicing could be separate projects. Write exclusions clearly. Keeping invoices in the accounting system is a useful boundary; “accounting integration later” leaves the responsibility unclear.

A brief you can reuse

Copy these questions into a document and answer with short paragraphs:

1. Problem: what keeps happening, and what are the consequences?
2. Users: who starts, receives and completes the work?
3. Steps: how does an ordinary case move through the current tools?
4. Information: what is needed, where does it come from and who changes it?
5. Exceptions: what happens after a change, cancellation or missing detail?
6. First version: what must work initially and what is excluded?
7. Acceptance: which tasks will staff perform to check the result?
8. Constraints: who decides, what budget is available and what drives the deadline?

A budget limit or unavailable data is not something to hide. It helps determine whether the scope should be smaller or another approach would fit. Compare off-the-shelf and custom software before assuming that development is the answer.

What should be clarified before a quote

The next discussion should identify dependencies: access to existing systems, moving data, permissions, testing and responsibility for launch. Two proposals with different assumptions are not directly comparable just because both have a total price. The application cost guide explains the main items to separate.

At brigdev, detailed solution planning is a separate stage covering the work, alternatives, first-version scope and acceptance. You can start with a short description. You do not need to design the complete application yourself before finding out whether it is a suitable project.