Learning Objectives

After completing this lecture, you will be able to:

• Understand the key concepts of writing ai requirements in rfps and sows in a government context
• Participate in structured workshop activities with real-world scenarios
• Use downloadable templates for immediate workplace application
• Identify next steps for applying these concepts in your role

Key Topics Covered

-
Specifying AI capabilities, performance requirements, fairness standards, monitoring obligations

-
Sample language library

-
Government context for writing ai requirements in rfps and sows

-
Practical applications and next steps

Why This Matters for Government

Overview

Government agencies face unique challenges when it comes to AI adoption. This lecture addresses these challenges head-on by providing senior managers, procurement officers, program directors with the knowledge and frameworks needed to navigate AI in the public sector responsibly and effectively.

As part of the L3 (AI Strategist) 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 writing ai requirements in rfps and sows is essential for responsible, effective government AI adoption.

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

TRANSCRIPT: Writing AI Requirements in RFPs and SOWs

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

What you will learn: Writing clear AI requirements; performance specifications; fairness and transparency criteria; data requirements; testing and validation requirements.

The quality of your RFP directly determines the quality of proposals you receive. Poor requirements lead to poor solutions. Vague requirements lead to disputes. This lecture teaches you how to write clear, specific AI requirements that vendors can understand and bid confidently.

At the L3 level, you're responsible for translating government policy and program needs into procurement language that guides vendor behavior.

Why AI Requirements Are Different

Traditional software requirements focus on functionality: "The system shall process 1,000 transactions per second." AI requirements add layers of complexity:

• Transparency Requirements: Can the system explain its decisions?
• Fairness Requirements: Does the system treat different groups equitably?
• Data Requirements: What data is used? How is it validated?
• Testing Requirements: How is accuracy verified? How is bias tested?
• Monitoring Requirements: How will we know if performance degrades?

Writing effective AI requirements means being specific about all of these.

Requirement Structure

Each requirement should follow this structure:

Requirement Number: [REQ-AI-001]

Category: [Functionality / Performance / Fairness / Data / Testing / Monitoring]

Statement: [Clear, specific requirement]

Success Criteria: [How will we know it's met?]

Verification Method: [How will we test it?]

Example:

REQ-AI-001

Category: Fairness

Statement: The system shall achieve at least 92% accuracy across all demographic groups.

Success Criteria: Accuracy tested separately for each demographic group defined in the data specification. All groups achieve at least 92% accuracy.

Verification Method: Vendor provides fairness testing results comparing accuracy across demographic groups. Government independently validates on hold-out test set.

Functional Requirements

Be specific about what the system must do:

Good: "The system shall classify incoming permit applications into one of five categories: Building, Environmental, Safety, Zoning, Other. Classification shall be correct at least 95% of the time."

Poor: "The system shall classify applications correctly."

Better: "The system shall classify permit applications into the following categories: Building Permits, Environmental Review, Safety Compliance, Zoning Variance, Other. The system shall:

• Accept applications in PDF, Word, and plain text formats
• Extract key information (applicant name, property address, application type, requested action)
• Classify applications into correct category with at least 95% accuracy based on content and metadata
• Provide confidence scores for each classification
• Route applications to appropriate department based on classification
• Support human override if classification is incorrect"

Performance Requirements

Specify accuracy, precision, recall, latency:

"The system shall achieve the following performance metrics:

• Overall accuracy: >= 95% (percentage of correct classifications)
• Precision for each category: >= 90% (of predicted positives, how many are actually correct)
• Recall for each category: >= 85% (of actual instances of each category, how many does the system find)
• Latency: = X% (defined by category/demographic group if applicable)

PR-2: Latency = X%

...

Fair-1: System shall achieve within X% accuracy across all demographic groups

Fair-2: System shall provide explanations for individual decisions

Fair-3: System shall document known limitations

...

DR-1: Data sources: [List approved sources]

DR-2: Data quality standards: [Specific checks]

DR-3: Data retention: [How long will data be kept?]

...

TR-1: Accuracy testing methodology: [Describe]

TR-2: Fairness testing: [Which metrics? Which groups?]

TR-3: Robustness testing: [Edge cases to test]

...

MR-1: Performance metrics to be reported: [List]

MR-2: Reporting frequency: [Monthly? Daily?]

MR-3: Alert thresholds: [When should vendor alert agency?]

...

SEC-1: Cybersecurity standards: [NIST, ISO, etc.]

SEC-2: Access controls: [Who can modify the model?]

SEC-3: Incident response: [Notification timeline?]

...

Anti-Patterns and Misuse Risks

Anti-Pattern 1: Requirements Too Vague

Risk: "The system shall classify documents accurately." Vendors interpret this differently. Some propose 85% accuracy, some propose 95%. Disputes arise.

How to Avoid: Be specific. Define accuracy by category, by demographic group, by use case. Define test procedures.

Anti-Pattern 2: Requirements Without Verification Methods

Risk: Vendor commits to something, but you have no way to test if they delivered it. Later disputes arise.

How to Avoid: For every requirement, specify how you'll verify it. Will you test independently? Will you audit their testing?

Anti-Pattern 3: Fairness Requirements Without Specificity

Risk: "The system shall be fair." Fairness means different things to different people. Vendor implements one fairness metric, you expected another.

How to Avoid: Specify exactly which fairness metrics matter. Specify demographic groups. Specify acceptable thresholds.

Anti-Pattern 4: One-Size-Fits-All Requirements

Risk: Same requirements for a low-risk system (internal tool) and high-risk system (affects citizen benefits). Vendors over-invest in low-risk systems.

How to Avoid: Scale requirements with risk. High-risk systems need more stringent testing and monitoring. Low-risk systems can be simpler.

Anti-Pattern 5: Requirements Changed During Performance

Risk: You specify one performance metric (accuracy), vendor optimizes for it and meets it. You then discover you actually needed different metrics (fairness, latency).

How to Avoid: Get requirements right upfront. Consult with end users, compliance, security. Finalize requirements before issuing RFP.

Reflection Prompts

• What are the most important requirements for your specific AI system? Are they functional? Performance? Fairness?
• How would you specify fairness requirements for your system? Which demographic groups are relevant? Which fairness metrics matter?
• What testing would prove to you that a vendor's system is ready for deployment?
• What performance metrics would you monitor in production?
• How specific can you be about your requirements given current uncertainty about the problem?

Key Takeaways

• AI requirements must be more specific than traditional IT requirements, covering functionality, performance, fairness, data, testing, and monitoring.
• Every requirement needs a verification method. If you can't test it, you can't enforce it.
• Use a structured template (requirement number, category, statement, success criteria, verification method).
• Scale requirements with risk. High-risk systems need more stringent requirements.
• Be specific about fairness. Vague fairness requirements lead to disputes.
• Specify testing and monitoring upfront. Vendors will design systems to meet your specified metrics.
• Involve end users, compliance, and security in requirement development. Requirements are easier to change before RFP than after award.

Terms and Glossary Items

• Requirement: Specific statement of what system must do or achieve
• Functional Requirement: Requirement about what system does
• Performance Requirement: Requirement about how well system performs
• Fairness Requirement: Requirement about equitable treatment across groups
• Verification Method: Procedure for testing whether requirement is met
• Success Criteria: Specific measure of whether requirement is satisfied
• Acceptance Testing: Testing to verify system meets requirements before delivery

Your requirements are the contract between you and the vendor. Clear, specific, measurable requirements lead to better proposals and fewer disputes. Vague requirements lead to misunderstandings and conflicts.

Take time upfront to develop comprehensive requirements. Consult with stakeholders. Test your requirements by having vendors explain how they would meet them. Finalize before issuing the RFP.

Good requirements make everything downstream easier: proposal evaluation, contract negotiation, performance monitoring, and dispute resolution.

Develop Requirements for Your System:

• Identify Key Requirements: What matters most for your specific system? Accuracy? Fairness? Speed? Security?
• Define Metrics: How will you measure success for each requirement?
• Specify Testing: How will you verify vendors meet the requirements?
• Identify Risks: What could go wrong if requirements aren't met?
• Create Template: Draft 5-10 requirements using the provided template.

Your requirements shape what vendors will build. Poor requirements lead to poor systems. Excellent requirements guide vendors toward excellent systems. Invest time in requirement development. It pays dividends throughout the procurement and performance lifecycle.

Government AI CLUB Certification Program

Level 3: AI Practitioner | Writing AI Requirements in RFPs and SOWs | Lecture 3.3.2

A GOVT.CLUB initiative.

<- 3.3.2 AI Vendor Evaluation Methodology
3.3.4 Evaluating AI Vendor Claims ->

Start Your CLUB Certification

This lecture is part of L3: AI Strategist -- 80 hours of comprehensive government AI training.

Explore CLUB Certification

Related Lectures

L3
3.3.1 -- Federal Acquisition of AI: FAR/DFARS
120 min - Lecture + Workshop

L3
3.3.2 -- AI Vendor Evaluation Methodology
90 min - Workshop + Scorecard

L3
3.3.4 -- Evaluating AI Vendor Claims
60 min - Workshop + Checklist