Learning Objectives

After completing this lecture, you will be able to:

• Understand the key concepts of requirements gathering for ai in a government context
• Participate in structured workshop activities with real-world scenarios
• Connect requirements gathering for ai to your agency's AI initiatives
• Identify next steps for applying these concepts in your role

Key Topics Covered

-
What to ask stakeholders

-
Defining success criteria for AI

-
The AI requirements template

-
Avoiding scope creep

Why This Matters for Government

Government agencies face unique challenges when it comes to AI adoption. This lecture addresses these challenges head-on by providing analysts, project leads, team supervisors with the knowledge and frameworks needed to navigate AI in the public sector responsibly and effectively.

As part of the L2 (AI Practitioner) curriculum, this lecture builds on the foundational principle that every AI system in government ultimately serves citizens. Whether you are working with AI tools daily or setting strategy for your agency, understanding requirements gathering for ai is essential for responsible, effective government AI adoption.

======================================================================

TRANSCRIPT: Requirements Gathering for AI

======================================================================

Chapter: 4 -- AI Project Management

What you will learn:

• How requirements gathering for AI differs from traditional IT
• What questions to ask stakeholders about AI projects
• How to define success criteria for AI systems
• How to capture AI-specific requirements (data, validation, fairness)
• How to use an AI requirements template effectively
• Common requirements mistakes and how to avoid them

Requirements gathering is where AI projects get derailed. Unlike traditional software projects where you can write detailed specifications upfront and then implement to spec, AI projects require a different approach to requirements.

You might walk into a requirements meeting hearing something like: "We want to use AI to detect fraud in our tax filings" or "We need AI to improve our hiring process." These statements sound like requirements, but they're actually just problem statements. A real requirement answers much tougher questions: What counts as fraud that the system should catch? What does "improve" actually mean--more diversity, faster processing, better accuracy? Who decides if the system is working? What happens when the AI system gets it wrong?

This lecture teaches you how to ask the right questions in requirements gathering so that you can actually define what success looks like for an AI system. We'll work through the kinds of questions that unlock the information you need, and we'll use a structured template to capture AI-specific requirements that traditional IT requirements don't cover.

PURPOSE STATEMENT

Requirements gathering is the critical bridge between "we have a business problem" and "we know what to build." For AI projects specifically, it's even more crucial because the requirements will shape everything about how you validate the system, define success, and maintain it after deployment. Weak requirements lead to misaligned expectations, failed projects, and governance failures.

WHY THIS MATTERS FOR GOVERNMENT

In government, weak AI requirements create particular problems. A poorly-defined benefits eligibility system might be deployed, used for months, and then discovered to be unfair to a particular demographic group--leading to policy failures, public backlash, and crisis management. A hiring AI with unclear success criteria might optimize for the wrong outcomes, creating workforce problems. Requirements gathering isn't just project management--it's a critical governance control that prevents harms.

Additionally, government agencies operate with multiple stakeholders. You have the business team that wants the system built, the legal team that needs to understand compliance implications, the civil rights team that needs to assess fairness, the IT team that needs to understand data and systems architecture, and often the public that will be affected by the system. Requirements that don't capture all these perspectives will miss critical constraints and create conflict later.

AI REQUIREMENTS ARE DIFFERENT FROM IT REQUIREMENTS

Traditional IT requirements typically specify:

• What the system will do (features and functions)
• How it will perform (speed, capacity, uptime)
• What it will integrate with (data sources, other systems)
• What it will cost

AI requirements need to also specify:

• What success actually looks like (accuracy, fairness, equity outcomes)
• What data the system needs and where it comes from
• What the system cannot be expected to do (limitations and failure modes)
• How we'll validate that the system is working (testing methodology)
• How we'll monitor it in production (monitoring and alerting)
• What happens when the system fails or needs to be overridden
• Fairness and bias considerations specific to the domain
• How the system will be updated and maintained as conditions change

The key insight: AI requirements need to spend substantial effort defining success criteria because success for an AI system is much fuzzier than success for a traditional system.

THE FIVE CRITICAL REQUIREMENTS QUESTIONS

Overview

When gathering requirements for an AI system, you need to ask five critical questions. These questions should guide your entire requirements conversation with stakeholders.

QUESTION 1

Don't accept "we want to use AI" as a problem statement. Dig deeper.

• What is failing in the current process?
• How do you know it's failing? (what metrics show the problem?)
• What would success look like? (how would we know we've fixed the problem?)
• Who experiences the current failure? (staff, citizens, other agencies?)
• What have you tried to fix it already?

Example: Instead of "We want AI to improve our hiring," ask: "We're getting complaints that hiring decisions take too long and candidates from certain universities are rarely selected. We want to reduce time-to-hire from 90 days to 30 days and increase diversity in our selection."

QUESTION 2

This is where you define concrete success criteria. Not "the AI works well" but specific, measurable outcomes.

• What metrics will we use to measure success?
• What is the baseline (current performance without AI)?
• What improvement are we actually trying to achieve?
• Who defines success? (this matters--technical teams and business teams often have different success criteria)
• How will we know if success is being achieved?

Success criteria for AI should be specific and measurable. Examples:

• "Reduce fraud detection time from 40 hours of analyst review to 10 hours per case"
• "Identify 85% of high-risk maintenance items with a false positive rate below 5%"
• "Achieve demographic parity in approval rates across protected classes within 2% tolerance"
• "Reduce decision variance for similar cases from 15% to less than 5%"

QUESTION 3

Data determines what's possible in AI systems. This is non-negotiable.

• What data sources are available?
• How complete is the data? (missing values, coverage gaps?)
• How recent is the data? (is it stale if we're using historical data?)
• Is the data representative of the population we're applying the system to?
• Are there protected class fields in the data? (demographic data, disability status, etc.)
• What biases or problems exist in the historical data?
• Who owns this data and can we actually use it for this purpose?
• What data cleaning or preparation is needed?
• What data governance constraints apply? (privacy regulations, data protection requirements)

This is critical because: The AI system can only be as good as the data it learns from. Bad data = bad system, no matter how good the AI algorithm is.

QUESTION 4

This determines the governance model for the system.

• Will this be a fully automated system or will humans review decisions?
• If humans review, what percentage of decisions will they review? (100%? 10%? Sampling?)
• What will trigger human review? (all decisions above a confidence threshold? all adverse decisions? random sampling?)
• How much time do reviewers have to review each decision?
• What training will reviewers need?
• Can reviewers override the AI recommendation? (they should be able to)
• How will you monitor whether reviewers are actually providing value?

Different governance models:

• Full automation: System makes final decisions with no human review. Very limited use in government, only appropriate for low-stakes decisions
• High-risk human review: Humans review all decisions, especially adverse decisions. Appropriate for rights-impacting systems
• Sampling review: Humans review a random sample of decisions to check quality. Useful for monitoring but inadequate for full validation
• Alert-based review: System flags potentially problematic decisions for human review. Appropriate for fraud detection, outlier identification
• Assistance model: System provides recommendations that humans use to inform their own decisions. Appropriate for many government processes

QUESTION 5

Every system has limitations. Understanding them upfront prevents deployment failures.

• What is the system not expected to do?
• What would constitute a failure of this system?
• What happens if the system is wrong? (what's the cost of false positives vs. false negatives?)
• Are there certain populations or cases where the system will inevitably perform worse?
• What are the operational constraints? (speed requirements, availability requirements, cost constraints?)
• What happens if the system can't process something? (does it escalate? does it default to accept or reject?)
• How often will the system need to be updated as the environment changes?

THE AI REQUIREMENTS TEMPLATE

Here's a structured template for capturing AI-specific requirements:

• BUSINESS CONTEXT
• Name of system:
• Target users/stakeholders:
• Current process (before AI):
• Why AI is being considered:
• PROBLEM STATEMENT
• What specific problem are we solving?
• How is the problem measured? (current metrics/baseline)
• Who experiences the problem?
• What have we already tried?
• SUCCESS CRITERIA
• Performance metrics (accuracy, speed, etc.):
• Business outcome metrics:
• Fairness/equity metrics (if applicable):
• Acceptable performance ranges:
• How will we measure success in production?
• SCOPE AND SCALE
• How many decisions/cases per month?
• Which departments/offices will use it?
• Which populations will be affected?
• Will scope expand? (plan for this)
• DATA REQUIREMENTS
• Data sources available:
• Data completeness and quality issues:
• Data recency and staleness concerns:
• Demographic composition (does it match the population we're serving?):
• Protected class fields and fairness concerns:
• Data governance/privacy constraints:
• SYSTEM FUNCTIONALITY
• What inputs will the system receive?
• What outputs will it produce?
• What is the confidence level needed to act on recommendations?
• What are edge cases or special scenarios?
• What situations should trigger human escalation?
• VALIDATION AND TESTING
• How will we test for accuracy?
• How will we test for fairness and bias?
• What edge cases must we test?
• Who validates the system before deployment?
• What validation documentation is required?
• HUMAN OVERSIGHT DESIGN
• Will decisions be fully automated or human-reviewed?
• If human review: what percentage, which decisions, what's the process?
• Can reviewers override AI decisions? (yes, they must)
• What training do reviewers need?
• How will you monitor reviewer performance?
• MONITORING AND MAINTENANCE
• What metrics will we monitor in production?
• How often will we review system performance?
• What triggers require escalation or investigation?
• How often will we retrain the model?
• How will we handle performance degradation?
• RISKS AND CONSTRAINTS
• What could cause the system to fail?
• What populations might be affected differently?
• What are the privacy/security considerations?
• What operational constraints exist? (speed, cost, availability)
• What is the contingency if the system doesn't work?
• GOVERNANCE AND COMPLIANCE
• What policies apply to this system? (civil rights, federal acquisition, etc.)
• Who needs to approve this system?
• What documentation is required?
• How will we handle incidents or failures?
• What training will stakeholders need?

STAKEHOLDER MAPPING AND REQUIREMENT SYNTHESIS

AI requirements aren't gathered from one person--they come from multiple stakeholders with different perspectives.

Typical stakeholders in government AI projects:

• Business sponsor (wants business value: efficiency, accuracy, cost savings)
• End users (actually use the system: concerns about usability, time impact, reliability)
• Compliance/legal team (concerns about policy compliance and legal exposure)
• Civil rights/EEO team (concerns about discrimination and fairness)
• IT/security team (concerns about data handling, security, system architecture)
• Audit/oversight team (concerns about documentation and traceability)
• Affected communities (concerns about fairness, accuracy, impacts)

Each group has legitimate concerns that should inform requirements. The challenge is that these concerns sometimes conflict. Business teams want fast systems; civil rights teams want careful validation. IT teams want simple data pipelines; fairness teams want detailed demographic data tracking.

Your job as requirements lead is to:

• Gather requirements from all stakeholders
• Make conflicts explicit (don't hide them)
• Help teams negotiate and prioritize
• Document what you committed to and for whom
• Make clear when requirements represent tradeoffs

Example: "To meet business timeline requirements (3-month deployment), we're accepting demographic performance gaps up to 5% rather than pursuing perfect parity. Legal team and civil rights team have signed off on this tradeoff. This will require enhanced monitoring in production."

REQUIREMENTS VALIDATION AND SIGN-OFF

Overview

Don't just gather requirements and move on. Validate them.

Validation questions:

• Do all stakeholders understand the success criteria the same way?
• Are success criteria actually measurable with the data we have?
• Are there conflicting requirements that need to be negotiated?
• Have we identified the real constraints? (sometimes constraints hide assumptions)
• Is the scope realistic for the timeline and budget?
• Have we identified what the system is NOT expected to do?
• Do we have commitment from data owners to provide required data?
• Do we have commitment from business to implement human oversight as designed?
• Have we addressed fairness and bias concerns?

Get formal sign-off from:

• Business sponsor (agrees this solves the business problem)
• Legal/compliance (agrees this can be done legally)
• Civil rights (agrees fairness approach is appropriate)
• Data owner (can provide necessary data)
• IT (can build and maintain this technically)
• Each signer should initial against specific requirements they're committing to

Document: "Requirements finalized on [date]. Signed off by [names]. Any changes require written amendment."

ANTI-PATTERNS

ANTI-PATTERN 1: Vague Success Criteria

Requirements state "the system should improve decision quality" or "the system should work well" without defining metrics. Teams discover only during testing or deployment that they disagree about whether the system is successful.

How to avoid it: Every success criterion must be testable and measurable. "Improve" is not a criterion. "Reduce false positive rate to below 3%" is a criterion. Make people commit to numbers.

ANTI-PATTERN 2: Ignoring Data Quality

Requirements focus on what the AI should do but don't adequately assess whether the data is good enough to do it. The system is built, tested with good data, deployed, and then fails because production data is different.

How to avoid it: Spend significant effort on data quality assessment during requirements. Ask: "Is this data good enough for what we're asking the system to do?" Get data owners involved in requirements gathering.

ANTI-PATTERN 3: Unrealistic Timelines and Scope

Requirements are gathered in a compressed timeframe with limited stakeholder input. Teams discover only later that requirements are incomplete or unrealistic. Scope expands during development, timeline slips, team stress increases.

How to avoid it: Allocate sufficient time for requirements gathering. Involve all stakeholders. Document assumptions about scope and timeline. Build in discovery time--don't lock requirements too early.

ANTI-PATTERN 4: Fairness as an Afterthought

Requirements focus on accuracy and business outcomes. Fairness considerations are tacked on late in development. By then, the system architecture isn't designed for fairness monitoring.

How to avoid it: Make fairness and bias assessment part of core requirements conversation from the beginning. Ask: "Who could be harmed if this system is unfair? What fairness metrics matter?" Require fairness validation in success criteria.

ANTI-PATTERN 5: Missing Failure Modes

Requirements don't articulate what happens if the system fails, breaks, or makes a bad decision. No contingency plan. When something goes wrong in production, teams have to improvise responses.

How to avoid it: Explicitly ask about failure modes. "What's the worst-case scenario?" "What would we do if the system had to be turned off?" Document fallback procedures and override processes.

PRACTICE PROMPTS

EXERCISE 1: Requirements Template Application

Take a government AI system you know or one from your agency. Apply the AI Requirements Template:

• Complete each section as if you were gathering requirements for this system
• Identify which sections have complete information and which have gaps
• Note what additional stakeholder conversations would be needed to fill gaps

EXERCISE 2: Stakeholder Perspective Mapping

Choose a hypothetical government AI system (e.g., predictive maintenance for federal buildings, benefits eligibility screening, hiring assistance). List the likely stakeholders and their perspective:

• What does each stakeholder care about?
• Where might their interests conflict?
• How would you negotiate these conflicts?
• What would each stakeholder sign off on?

EXERCISE 3: Success Criteria Definition

Write detailed success criteria for one of these systems:

A. An AI system that flags suspicious purchases in federal procurement

B. An AI system that assists in staffing decisions for federal offices

C. An AI system that predicts infrastructure maintenance needs

For each system, define:

• Performance metrics
• Business outcome metrics
• Fairness metrics
• Acceptable ranges and how you'll measure them

KEY TAKEAWAYS

• Requirements gathering for AI is more complex than for traditional IT. You must define not just what the system will do, but how you'll know it's working, what it can't do, and how you'll handle failure.
• Success criteria must be measurable, specific, and agreed upon by stakeholders. Vague success criteria lead to project failure. Make people commit to testable numbers.
• Data quality assessment is a requirements activity, not just a technical activity. You must understand whether the available data is actually suitable for what you're asking the system to do.
• Fairness and bias concerns belong in requirements, not in testing. Consider fairness from the beginning. Design systems with fairness validation in mind.
• Multiple stakeholders bring legitimate but sometimes conflicting requirements. Your job is to make conflicts explicit, help teams negotiate, and document tradeoffs.
• Document what the system is NOT expected to do. Articulate limitations and failure modes. Plan for contingencies.
• Get formal sign-off from all stakeholders on final requirements. Written commitment prevents later disputes about what was promised.
• Use a structured requirements template. Templates ensure you ask the right questions and capture AI-specific considerations that traditional IT templates miss.

GLOSSARY

Requirements: Specifications of what a system must do, including functional requirements (what it does), performance requirements (how well it does it), and constraints (what it can't do or limitations on how it operates).

Success Criteria: Measurable, specific standards by which the success or failure of a system will be evaluated, including performance metrics, fairness metrics, and business outcome metrics.

Stakeholder: Any person or group who has an interest in or will be affected by an AI system, including business sponsors, end users, compliance teams, and affected populations.

Fairness Metric: Measurable standard for assessing whether an AI system treats different populations equitably, such as demographic parity, equalized odds, or calibration.

Data Quality Assessment: Evaluation of whether available data is suitable for the intended AI application, considering completeness, recency, representativeness, and bias.

Requirements gathering is where you establish the foundation for the entire AI project. Bad requirements lead to failed projects, governance failures, and wasted resources. Good requirements lead to systems that actually solve problems and earn trust.

The key to good requirements in government is recognizing that AI systems are not just technical systems--they're governance systems. They affect people's access to services, their opportunities, their treatment by government. Requirements gathering is where you understand and encode those impacts.

As you move into the implementation phases, you'll refer back to these requirements repeatedly. During testing, you'll check that the system meets the success criteria you defined. During deployment, you'll implement the human oversight model you designed. During monitoring, you'll track the fairness metrics you included. Requirements discipline early prevents chaos later.

Reflect on a complex government process you're familiar with. What would it take to use AI to improve it? What would you need to know about the people affected by decisions? What would you need to measure to know if the AI was actually helping? What could go wrong? Use this reflection to develop intuition for the depth of requirements work needed for AI projects.

You've learned the framework for gathering requirements in government AI projects. The next lecture focuses on agile and iterative development for AI--how to structure your project delivery when requirements evolve and you're learning as you go. Requirements and iterative development work together: solid requirements give you direction while iterative development gives you flexibility to learn and adjust.

See you in the next lecture.

Government AI CLUB Certification Program

Level 2: AI Ready | Requirements Gathering for AI | Lecture 2.4.2

A GOVT.CLUB initiative

Visit: https://govt.club/learn/lectures/l2/242-requirements-gathering.html

======================================================================

<- 2.4.1 How AI Projects Differ from Traditional IT
2.4.3 Working with AI Vendors and Contractors ->

Start Your CLUB Certification

This lecture is part of L2: AI Practitioner -- 40 hours of comprehensive government AI training.

Explore CLUB Certification

Related Lectures

L2
2.4.1 -- How AI Projects Differ from Traditional IT
60 min - Video + Comparison

L2
2.4.3 -- Working with AI Vendors and Contractors
60 min - Video + Checklist

L2
2.4.4 -- Testing and Validating AI Systems
60 min - Video + Lab