Gathering requirements for AI projects fails when teams apply traditional requirements practices without adaptation. The statement “the system shall detect fraud” is not a requirement; it is a wish. AI requirements must specify what counts as fraud, what accuracy is acceptable, what data is available, and what happens when the system is wrong. This guide covers the practical steps for eliciting, documenting, and managing requirements for AI projects.

Start with the Business Problem

Before discussing models or data, clarify the business problem. Use structured interviews with stakeholders to answer:

  • What decision is being made today, and by whom?
  • How is that decision currently made (manually, rules-based, not at all)?
  • What is the cost of a wrong decision (false positive vs false negative)?
  • What is the expected volume of decisions per day/hour/second?
  • What is the acceptable latency between input and decision?

These questions surface the real requirements. A stakeholder who says “we want AI to classify customer complaints” actually needs a system that routes complaints to the correct department within 30 seconds of receipt, with at least 90% routing accuracy, because misrouted complaints cost $15 each in rework.

Define Measurable Acceptance Criteria

Every AI requirement needs a measurable acceptance criterion. Use this template:

“Given [input description], the system shall [action] with [metric] of at least [threshold], measured on [evaluation dataset], under [conditions].”

Example: “Given a customer support email in English under 500 words, the system shall classify it into one of 12 predefined categories with at least 88% accuracy, measured on a monthly holdout set of 500 labeled emails, during normal business hours with p95 latency under 200ms.”

Each element prevents ambiguity:

  • Input description bounds what the system is expected to handle
  • Metric and threshold define success quantitatively
  • Evaluation dataset specifies how success is measured
  • Conditions set the operational context

Document Data Requirements

Data requirements are first-class requirements for AI projects. For each data source, document:

Availability - Is the data accessible? What APIs, databases, or files provide it? Are there access control or privacy restrictions?

Volume - How much data exists? Is it enough for the intended approach? A deep learning model may need millions of examples; a gradient-boosted tree may need thousands.

Quality - What is the completeness, accuracy, and consistency of the data? Conduct a data quality assessment before committing to requirements that depend on the data.

Labeling - For supervised learning, do labels exist? If not, what is the labeling strategy and cost? A requirement that assumes labeled data exists when it does not is dead on arrival.

Freshness - How current is the data? A fraud detection model trained on data that is six months old may miss new fraud patterns.

Handle Requirements Uncertainty

AI requirements evolve as the team learns what is feasible. Manage this uncertainty explicitly:

Phase requirements by confidence. High-confidence requirements (clear business need, data available, known feasibility) go into the committed backlog. Low-confidence requirements (uncertain feasibility, data quality unknown) go into a research backlog with timeboxed exploration.

Use feasibility spikes. Before committing to a requirement, allocate 1-2 weeks for a data scientist to assess whether the data supports the requirement and estimate achievable performance. The spike output is a feasibility report that either confirms the requirement (with realistic thresholds) or recommends revision.

Version requirements. Track requirements versions as understanding evolves. Version 1 might specify 85% accuracy; after the feasibility spike, Version 2 might revise this to 90% accuracy with a reduced scope (English only, under 500 words). Maintain the version history so stakeholders understand how and why requirements changed.

Manage Conflicting Requirements

AI projects often face requirement conflicts that do not exist in traditional software:

Accuracy vs latency - A more complex model may be more accurate but too slow. Document both the accuracy threshold and the latency SLA, and let the team find the Pareto-optimal solution.

Precision vs recall - Business stakeholders rarely use these terms, but they have strong preferences. “We cannot miss any fraud” implies high recall. “We cannot block legitimate transactions” implies high precision. Surface this trade-off early and get stakeholder agreement on the balance.

Fairness vs performance - Optimizing for overall accuracy may produce a model that performs well on majority groups and poorly on minority groups. If fairness is a requirement (and it should be), document the fairness criteria and the acceptable performance trade-off.

Requirements Traceability

Maintain traceability from business requirements to model metrics to test cases. A traceability matrix maps each business requirement to the model metric that measures it, the test dataset that evaluates it, and the monitoring dashboard that tracks it in production. This matrix becomes the backbone of model validation and post-deployment monitoring, ensuring that the team is always testing and monitoring what the business actually cares about.