How to set an AI project scope
Aranv’s guidance on AI project requirements: describe the task, its inputs and the systems involved, then define a correct output with real examples, the accuracy you need, where a person reviews or approves, what the AI must never do, and the volume and response time it has to handle.
Start narrow. Scope one task for one group of users. ‘Answer warranty questions for the service desk from the current warranty terms’ is buildable; ‘an assistant for the whole company’ is not. The AI implementation roadmap explains how to pick that first task.
Describe the systems. List each application the AI reads or updates, the access method (API, export or database) and the account it will run under. Estimates often go wrong on integration detail, and LLM integration work depends on getting it right.
Parts of an AI requirements document
What a buildable brief contains
- 01 Task and users Who uses it, for which job, and what happens to the result.
- 02 Inputs and systems Documents, fields and applications the AI reads from or writes to.
- 03 Quality and limits Accuracy targets, review points and the actions the AI must refuse.
- 04 Examples and acceptance Real cases with expected outputs and the pass mark for launch.
AI requirements need examples, because a written description alone leaves too much open to interpretation.
Four requirements AI projects often skip
Normal software requirements still apply. These four are specific to AI and are often missing from a first draft.
Expected outputs by example
A set of real inputs paired with the answer your team would give turns the word accurate into something a tester can check.
Confidence and fallback
What the AI should do when unsure: ask a question, hand off to a named person or decline. Write it down per type of case.
Data and model limits
Where data may be processed, which model providers are acceptable, retention rules, and whether prompts may ever be used for training.
Change and retest rules
How prompt, model or data changes are approved, and which tests must pass before each one reaches users.
Writing acceptance criteria for AI output
Acceptance criteria turn opinions into a test. Pick measures that match the task, such as correct category, fields extracted without error or replies approved without edits, set a pass mark on the example set, and name the person who signs off.
What we do
- Measures matched to the task
- Pass mark on the example set
- Separate marks for risky cases
- Named sign-off person
- Retest rule for later changes
Requirements for what the AI must not do
Limits deserve the same detail as features. List the topics the AI must decline, the records it may never change, the actions that always need approval, and the data it must never reveal. Each limit should have a test case that proves it holds.
What we do
- Topics the AI declines
- Records that stay read-only
- Actions needing human approval
- Data never shown to users
- One test case per limit
How we approach a project
Write the non-functional needs. Response time, volume, languages, hours of operation, logging, retention and accessibility. A chat window on your website should meet the same accessibility standard as the rest of the site, and the W3C’s overview of WCAG 2.2 explains the success criteria that version added.
Agree acceptance before the build. State the pass mark on the example set and who signs off. If several firms will quote, our guides to a software development RFP and the software discovery phase cover what comes next, or ask for a 30-minute conversation about your draft brief through the Contact page.
How we work
- Examples over adjectives
- Measurable acceptance criteria
- Limits written as clearly as features
Our Process
-
Interview the people doing the task
Record how they handle routine cases and exceptions today, in their own words.
-
Collect real examples
Gather inputs with the correct outputs, including the awkward cases staff still remember.
-
Draft the requirements document
Cover task, users, inputs, systems, quality targets, limits, non-functional needs and acceptance.
-
Review and freeze version one
Walk the draft through with users and IT, close the gaps, then fix the version firms will quote on.
How Aranv works from requirements
Examples drive the build
We turn your example cases into an evaluation set at the start of the build and report results against it at every review.
Gaps raised early
When a requirement is unclear or clashes with how a connected system behaves, we raise it in writing instead of building around a guess.
Requirements you can reuse
Documents from our discovery phase are written so another team could build from them, and we recommend contract terms that make them yours.
Limits tested like features
Each refusal rule and approval step gets its own test, and those tests run again whenever prompts, data or models change.
Ready to act on this guide?
Ask our team in a 30-minute conversation.
Or see how we build it: Explore all services
AI requirements document FAQs
-
What should an AI requirements document include?
The task and users, inputs and data sources, systems to read or update, expected outputs shown by example, accuracy targets, review and approval points, actions the AI must refuse, needs such as response time and logging, and acceptance criteria.
-
How are AI requirements different from normal software requirements?
AI output varies, so requirements describe acceptable results and test sets rather than one exact answer. They also cover what happens when the AI is unsure, how prompt or model changes are tested, and the data terms agreed with model providers.
-
How do we set an accuracy target?
Start from the cost of a mistake. Drafts that a person reviews can begin with a lower bar than actions that change records. Measure your staff’s current accuracy on the same examples, since that is the fair comparison.
-
How detailed should the AI project scope be?
Detailed enough that two firms would quote on the same thing: named systems, example cases and acceptance tests. Leave model choice and technical design to discovery unless you have a firm constraint, such as an approved provider.
-
Can a vendor help write the requirements?
Yes. A paid discovery phase often produces the requirements document. Make sure the contract says the document belongs to you, so you can use it with any firm you choose.
Let’s talk about your next step
Contact Aranv to discuss your workflow, current tools, and goals. Meet with our team or send an inquiry.
Book a meeting with our team
Choose an available date and time for a 30-minute conversation about your project.
Tell us about your project
Share a few details so we can discuss a useful next step.
Prefer email? sales@aranv.com