How to Write a Business Automation Requirements Document

By Team Nevara | Published 2 October 2026

Many automation projects begin with a sentence such as “connect our forms to the CRM” or “use AI to process these documents.” That describes an idea, not a buildable requirement. The delivery team still needs to know who uses the process, what starts it, which rules apply, what happens when information is missing and how the business will decide that the result works.

A business automation requirements document turns process knowledge into an agreed plan. It should be detailed enough to estimate, design and test the workflow, while remaining clear enough for the process owner to review without technical translation.

Prepare this document after you map the current process and before committing to a full build. If the investment is still uncertain, use the scope and baseline to calculate the expected automation ROI.

Start with the problem, not the requested technology

Open with a short problem statement. Describe what happens today, who is affected and why change is needed. Include evidence such as processing time, waiting work, duplicate entry, missed follow-ups, error types or customer delays. Do not prescribe a chatbot, mobile app or AI model before the problem and users are understood.

The GOV.UK Service Standard advises teams to understand users and their needs in context so the service can meet those needs simply and cost effectively. For business automation, speak with the people who perform, approve and receive the work. Management may know the policy, while frontline staff know the exceptions and workarounds.

Define the outcome and success measures

State what should be different after implementation. A useful outcome is observable: valid enquiries create one complete record, reach the correct owner and receive a response within the agreed time. “Save time” is too vague unless the baseline, target and measurement method are defined.

GOV.UK guidance on setting service performance metrics recommends choosing measures from the needs and hypotheses the service is meant to address. Record the baseline, target, data source, review frequency and owner for each important measure.

Set clear scope boundaries

List what the first release will and will not do. Name the business units, users, locations, channels, data types and process stages included. A lead-handling release might cover website enquiries, validation, CRM creation and assignment while excluding quotation, contracts and payment collection.

Separate must-have requirements from later improvements. Priorities should reflect business need, risk and dependency rather than which feature sounds most advanced. This protects the core outcome when time or budget changes.

Describe users, roles and permissions

For each role, state what the person needs to see, create, edit, approve, export and delete. Include external users, administrators, reviewers, managers and support staff. Avoid a generic “admin” role that gives everyone broad access because detailed permissions were postponed.

Identify who owns the business process, approves changes, reviews exceptions and supports the automation. A technical team can maintain software, but it should not silently become responsible for commercial rules or client-facing decisions.

Write the workflow from trigger to confirmed completion

Document the trigger, required inputs, validation, decisions, actions, approvals, notifications and final status. State where each piece of information comes from and where the result must be recorded. A successful API response is not a completed business process unless the intended record, owner and customer outcome are confirmed.

Use numbered steps and plain conditional rules. For example: if the customer email is missing, place the item in the incomplete queue and notify the intake owner. If a matching CRM record exists, attach the enquiry instead of creating a duplicate. Each rule should produce a result that can be tested.

Capture exceptions before the happy path is approved

List missing data, duplicate requests, conflicting rules, unavailable systems, expired credentials, unsupported formats, late approvals and cases requiring judgment. For each exception, define whether the workflow retries, pauses, creates a review task, alerts someone or returns to the manual process.

Name the owner and response target for each important exception. A queue without ownership is not error handling. It is delayed failure.

Specify integrations and data responsibilities

For every connected system, record its purpose, owner, authentication method, available test environment, usage limits, expected availability and the fields exchanged. Confirm whether the organisation controls the account and whether the provider permits the intended use.

Create a field list showing the source, format, required status, destination and retention need. Mark personal, financial, confidential and regulated information. Define which system is the source of truth when two systems disagree.

Add security and privacy requirements early

The NIST Secure Software Development Framework recommends integrating secure practices throughout development and expressing security requirements to suppliers. The requirements document should cover access control, authentication, audit records, encryption, secrets, backups, dependency updates, vulnerability handling and incident response where relevant.

The OWASP Application Security Verification Standard provides requirements that can support security verification for web applications. Select controls appropriate to the system and risk instead of adding a vague line saying the solution must be secure.

Document the lawful purpose for personal data, who can access it, where it is stored, how long it is kept and how correction or deletion requests are handled. Security and privacy decisions made after development are usually more expensive and may change the design.

Define AI-assisted steps separately

If the workflow uses AI for extraction, classification, scoring, drafting or recommendations, state the purpose, approved inputs, prohibited data, expected output, reviewer, correction method and actions the system may not take automatically. Describe which errors are tolerable and which must stop the workflow.

Require version tracking and a test set representative of normal work, incomplete inputs, known exceptions and high-impact cases. A few successful demonstrations are not acceptance evidence.

Write measurable acceptance criteria

Acceptance criteria describe what must be true for a requirement to be approved. They should be specific, observable and connected to the business outcome. Examples include: every valid submission creates exactly one record; incomplete cases enter a named review queue; unauthorised roles cannot view restricted fields; failed integrations produce an actionable alert; and a reviewer can correct a suggestion without losing the original input.

Use these criteria to test the automation pilot before full rollout. Assign an approver to each group of criteria so the project does not depend on one person informally declaring the whole system complete.

Include operational requirements

Describe expected volume, peak periods, response time, availability, alerting, logs, backups, recovery, data export, support hours and manual fallback. Name who can pause the automation and what happens to work already in progress.

Also define ownership at handover: repository, hosting, domains, vendor accounts, documentation, credentials, analytics and third-party licences. The business should know which assets it controls and which require continuing supplier access.

Control changes without freezing learning

Requirements will change as the team learns. Keep a decision log recording the request, reason, impact on scope, cost and timeline, approver and date. Update acceptance criteria when a decision changes behaviour. Do not let important requirements live only in calls, chat messages or a developer’s memory.

Illustrative example: document approval automation

Consider a fictional consulting company that wants to automate incoming document checks and approval routing. This is an illustrative example, not a Nevara client result. The requirements identify submitters, reviewers and finance approvers; define required file types and fields; map the approval sequence; and specify where the approved record is stored.

The exception section covers unreadable files, missing references, duplicate submissions, rejected approvals and an unavailable storage service. The security section limits access by role and requires audit records. Acceptance criteria confirm that valid documents reach the correct approver, rejected items return with a reason, restricted files remain protected and failed transfers create a review task.

Frequently asked questions

How detailed should automation requirements be?

They should be detailed enough for the team to estimate, design and test the workflow without guessing important business rules. Focus on observable behaviour and decisions rather than prescribing low-level technical implementation unless the business has a genuine constraint.

Who should approve the document?

The process owner should approve the business workflow. Operational users should verify real cases and exceptions. Technical, security, privacy and finance owners should approve the requirements relevant to them. One signature should not replace specialist review.

Can the requirements document change during development?

Yes. Learning is expected, but changes should be recorded, assessed and approved. A controlled change log protects the budget and timeline while preserving useful discoveries.

Turn process knowledge into a buildable plan

Nevara Solutions plans and builds web, app, SaaS and automation systems around real business workflows. If your team has an automation idea but the scope is still spread across conversations and documents, share the process with us. We can help turn it into clear requirements, a controlled pilot and a measurable implementation plan.