RequirementsMethodBusiness softwareSMEsPrototype
How to write a software requirements document for an internal business application
10 min read
To write a requirements document for an internal application, describe the problem before the solution: measurable goals, users and their permissions, the current process, business rules, data, the systems to connect, security constraints and acceptance criteria. Keep it short, prioritise every requirement, then check the whole thing against a visual prototype before asking for quotes.
Most templates online are built for large software teams: a full IEEE style software requirements specification (SRS) with dozens of sections. For an internal tool commissioned by a small or mid-sized company, that format costs weeks and protects little. This guide covers the sections that matter, what to write in each, what to leave to the vendor, and a checklist to run before you send the document.
What the document is really for
A requirements document is not a writing exercise. For an internal application it has three jobs, and they are the only test of whether it works.
- Getting a quote. A vendor must be able to estimate the work without guessing what you have in mind.
- Comparing quotes. Two proposals answering the same document must describe the same application, or their prices mean nothing side by side.
- Accepting the delivery. At handover, each requirement must be checkable with a yes or a no.
A document that piles up pages without serving these three uses costs time to write and time to read, and it protects nobody.
The template in nine sections
| Section | The question it answers | Example |
|---|---|---|
| Context and goals | Why this project, and how will you know it worked? | "Stop re-typing job sheets that technicians fill in on paper each day" |
| Scope | What is in, and above all, what is out? | "Invoicing stays in the current accounting software" |
| Users and permissions | Who uses the tool, and who can do what? | Technician: enters. Area manager: approves. Accounts: read only |
| Current process | How is the work really done today? | The life of a job sheet, from site visit to archive, detours included |
| Business rules | Which conditions, calculations and exceptions? | "A job over 4 hours needs manager approval" |
| Data | Which information, where it comes from, what is the source | Customers, sites, jobs, parts, time spent |
| Integrations | Which systems must the application exchange data with? | ERP, accounting software, company directory (single sign-on) |
| Constraints | Security, data protection, hosting, mobile, accessibility | "Data entry must work offline and sync when the signal returns" |
| Acceptance and support | How do you accept it, and who maintains it afterwards? | Testable criteria, milestones, maintenance and change requests |
Order matters. Goals and scope shape everything else. A business rule only makes sense when it is tied to a goal, and an integration is only justified if data really has to move.
Business rules: the heart of the document
This is the most useful section and the one most often rushed. Screens are quick to sketch; rules do the work, and they drive the price. A well written rule fits in one sentence of the form "when this happens, the system does that", followed by its exceptions.
- Usable: "When a job exceeds 4 hours, it moves to the status 'awaiting approval' and the area manager is notified. Exception: jobs under an annual maintenance contract are approved automatically."
- Useless: "The system handles approvals."
Look for rules where they hide: in spreadsheet formulas, in "notes" columns, in cells someone colours by hand, in the "we always do it this way" of each team. If your process lives in an Excel file today, that file is already a large part of your requirements, as we explain in replacing Excel with a custom application.
Testable requirements, not intentions
Each requirement must be testable. Adjectives are not.
| Vague wording | Testable wording |
|---|---|
| The application must be fast | Today's job list loads in under 2 seconds on a phone over 4G |
| The tool must be easy to use | A technician completes a job sheet unaided after a 15 minute demo |
| Data must be secure | Every user signs in with a named account, and every change is logged |
| It must be possible to export | Monthly CSV export with the columns listed in the appendix |
The thresholds in the right column are examples. Set your own, based on what your teams actually live with. What matters is that they exist, because they become your acceptance criteria. Our user acceptance testing checklist shows how they are used at delivery.
Prioritise: not everything is essential
A document where everything is mandatory leaves no room on price or deadline. The MoSCoW method, popularised by the DSDM agile framework, sorts each requirement into four levels:
- Must have: without it, the tool is pointless;
- Should have: important, but a first version can live without it;
- Could have: welcome if the budget allows;
- Won't have (this time): left out of this version, and written down as such.
The last category is the most valuable. Writing down what is not requested stops a vendor from pricing it in "just in case", and stops a user from demanding it during acceptance testing.
What to leave out
- An imposed technical solution with no in-house expertise behind it. The language, database and hosting provider are the vendor's choices, and the vendor must justify them. You set the constraints (hosting in the EU, sign-in through the company directory), not the architecture.
- Pixel-perfect mockups drawn in a slide tool. They freeze design choices before anyone has tested the journey.
- "Just in case" features. Each one has a development cost, then a maintenance cost for the whole life of the application.
Constraints: security and data protection from day one
An internal application almost always handles personal data: staff names, customer contact details, sometimes more sensitive information. The GDPR requires data protection by design (Article 25) and a written contract with any vendor that processes data on your behalf (Article 28). The UK GDPR carries the same obligations. The requirements document is the right place to state:
- which personal data the tool holds, and why;
- who can access it, by role;
- how long it is kept;
- where the application is hosted.
These four lines cost little to write and avoid expensive rework once the application is built. Our GDPR checklist for a business application goes further.
A condensed example
Here, for illustration, is the core of a requirements document for a field job tracking tool:
Goal: stop re-typing job sheets and shorten the time to invoice. Users: twelve field technicians, two area managers, one person in accounts. Rules: a job over 4 hours needs approval; parts used are deducted from stock. Data: customers and sites from the ERP, parts from the catalogue. Integration: approved jobs flow back into the ERP for invoicing. Constraints: offline data entry, named accounts, hosting in the EU. Out of scope: invoicing itself.
Ten lines, and a serious vendor already knows which questions to ask. The flow back into the ERP alone deserves a proper conversation; we cover it in integrating a custom application with an existing ERP.
From document to prototype
Even well written, a requirements document is text, and text can be read in several ways. "The manager approves the job" does not say whether approval happens on a phone, in batches or one by one, or what the manager sees before approving. These questions often surface only during acceptance testing, when answering them costs the most.
A visual prototype closes those gaps: real screens, real journeys and realistic data that your team can comment on before any code is written. The document says what must be done; the prototype shows how it will be done. They work together, and the validated prototype often becomes the reference for the quote, as we explain in see your software before you pay for it.
Checklist before you send it
- Goals are measurable, and each says how you will know it is met.
- The scope also lists what is excluded.
- Every user role has its permissions described.
- Business rules are written as "when... then...", with their exceptions.
- Every piece of data has one named source, and only one.
- The systems to connect are named, with a contact person for each.
- Every requirement can be checked with a yes or a no.
- Requirements are prioritised, including what is left out for now.
- Personal data, retention periods and hosting are specified.
- Life after launch is planned: who maintains the tool, and how changes are requested. Our article on business application maintenance explains what that budget line covers.
A document that passes this list can be quoted seriously. It also helps you pick the right contract model, which we compare in fixed price vs time and materials, and understand what will drive the cost of the application.
No time to write it?
That is common, and it is not a blocker. At LPR Studio, one first conversation is enough: you describe the problem, share the files and documents that carry it today, and within 5 working days we present a free visual prototype on a video call. If the project goes ahead, it serves as the requirements baseline, and you choose the model that suits you: fixed price, a subscription with no upfront development cost, or a SaaS product we publish and run.