What are business requirements and how do they differ from specifications?
Business requirements are a description of what the business wants to achieve from the system. At the level of "what needs to be done," rather than "how to technically implement it."
The technical specification is a more detailed document that already contains technical solutions: architecture, integrations, data formats. The technical specification is created based on business requirements.
For most accounting system implementation projects, the optimal approach is to create a combined document: business requirements with technical details where critical (integrations, security, performance).
Structure of a Quality Business Requirements Document
A good document contains 8 mandatory sections. Let's consider each one.
Chapter 1: General Information about the Project
What we include: client name, project goal (1-2 sentences), tasks that the system should address, expected results, budget (range), expected timelines.
Example: "The goal of the project is to implement an accounting system for the automation of accounting, tax, personnel records, and payroll calculation for LLC X. Expected result: reduction of month-end closing time from 14 to 5 days, automatic generation of reports for the State Tax Service, a single database instead of 4 different programs."
Chapter 2: Description of the Current State (As Is)
What we include: what programs are currently used, how accounting is conducted, which processes are automated, which are performed manually, the main pains and problems.
This section is important because it gives the contractor an understanding of the context. Without it, they will propose a "theoretical solution" rather than what actually fits into your business.
Chapter 3: Description of the Desired State (How It Should Be)
What we include: how accounting should work after implementation, which processes are automated, how data flows, which reports are available automatically.
Process diagrams often help here — BPMN diagrams or simple block diagrams. Visuals are better than a text description on a page.
Chapter 4: Functional Requirements
This is the heart of the document. A list of specific functions that the system must implement. Format: "User [role] can [action] in order to [goal]."
Examples: "The accountant can import bank statements with one click to speed up payment processing." "The manager can obtain a sales report by manager for any period."
Each requirement must be verifiable. Avoid phrases like "user-friendly interface," "fast," "reliable" — they do not provide clear criteria.
Chapter 5: Non-functional Requirements
This is the quality requirements for the system, not its functions. We include: the number of simultaneous users, expected response time, availability (for example, 99.5% of the time), security requirements (backups, encryption), compatibility with devices, language versions.
Often this section is ignored — and then people are surprised that the system "lags" with 50 users. The contractor could have taken this into account if the requirement had been documented.
Chapter 6: Integrations
List of systems that the accounting system must integrate with: bank-client, M.E.Doc, website, marketplaces, CRM, warehouse, others. For each — exchange format (API, files), frequency, what data is transmitted.
Chapter 7: Data Migration
From which systems are we transferring data, which specific ones (reference books, balances, history), and in what volume? Who is preparing the data for transfer on your side?
This section is often overlooked — and then it turns out that migration was not included in the scope of work. Additional payment of 50-100 thousand UAH.
Chapter 8: Acceptance Criteria for Work
The most important section for avoiding conflicts. What exactly needs to be done for you to consider the work accepted. Format: checklist, where each item can be marked as "completed / not completed".
Example: "All functional requirements from section 4 have been implemented," "The testing period of 2 weeks has been completed without critical errors," "5 key employees have completed training," "Documentation has been provided in PDF format."
Business Requirements Template: What Needs to be Adapted
If you want to use the template — the structure above is universal. What to adapt for your business:
Sections 4 and 5 - completely rewrite them according to your functions and non-functional requirements. This is the largest part of the work.
Chapter 6 — the list of integrations depends on your system landscape.
Chapter 7 — completely yours, depending on current programs.
The rest of the sections change only at the level of facts.
How much time does it take to formulate requirements
It depends on the scale. For small businesses with typical processes — 1-2 weeks. For medium-sized companies — 3-5 weeks. For large projects with customization — 1-2 months.
If the processes are already described, the time is halved. If not, the requirements formation actually includes the description of the processes, so it takes longer.
Can business requirements be created independently?
Technically — yes. Practically — it rarely works out. Without experience, the documents end up either too general ("we want a normal system") or too detailed in unnecessary places.
It is optimal to involve a business analyst. They will bring methodology, an objective perspective, and experience from other projects. Your role is to provide information during the interview. SPOC has a separate service for forming business requirements specifically for this purpose.
Need help with formulating business requirements?
Leave a request for a free consultation — we will discuss your project and offer the optimal approach.