Government AI Procurement and Requirements Specification

10 min

Turning a use case into something you can accept (1): function and workflow

Translating an AI use case into a procurement requirement means breaking "what this system should do" into concrete categories, each of which must be verifiable, not just an adjective like "deploy a smart AI system" that can never actually be accepted.

• Functional requirements: what concrete tasks the system must complete, mapping to Module 1's use case.
• Workflow requirements: how step order, routing, and human gates operate, mapping to Module 2's workflow canvas.
• Data and knowledge requirements: what data sources are needed, how the knowledge base is built and updated, mapping to Module 3's context & data canvas.

Key takeaway: Functional and workflow requirements directly carry forward the output of Modules 1-2: break the use case card and workflow canvas into acceptable line items, rather than reinventing a set of adjectives.

12 min

Turning a use case into something you can accept (2): model, permission, operations

• Model and tool requirements: which model is used, which systems it must connect to, mapping to Module 4's tool & permission matrix.
• Permission and security requirements: Read/Write scope, access control, security requirements, mapping to the governance design from Modules 4-5.
• Logging and performance requirements: log retention, response time, reliability metrics, mapping to Module 6's test and evaluation results.
• Operations and versioning requirements: who operates it, how model/system updates are handled, portability considerations, which affect whether the system stays acceptable over the long run.
• Maintainability: whether the system can be diagnosed and fixed in time when something goes wrong, rather than requiring a full rebuild.

Key takeaway: The five categories, model, permission, logging, performance, and operations, turn the governance and test design from Modules 4-6 into concrete clauses a procurement document can check.

12 min

Conceptual considerations: cloud, third parties, and ownership

Key takeaway: Conceptual-level considerations are not legal advice, they are a reminder to ask before signing: where does the data live, who can get it back, and what happens if the vendor changes.

12 min

Deliverables and acceptance evidence

If a requirement cannot be matched to a Deliverable and Acceptance Evidence, it usually means the requirement is not concrete enough yet. A deliverable is "what the vendor must hand over"; acceptance evidence is "what the agency uses to confirm the deliverable actually meets the requirement."

• Deliverable examples: system source code or license, an operations manual, test reports, knowledge-base build documentation, permission-configuration documentation.
• Acceptance evidence examples: test-case results from Module 6, log samples, permission-configuration screenshots or files, a regression-test report.
• Every requirement should be able to answer: what is the verification method, who performs it, and what counts as passing.

Key takeaway: Every requirement must be able to answer both "what is delivered" and "how is it proven," missing either one means the requirement is not ready for acceptance.

14 min

Practice: From Use Case to Procurement Requirement

Activity 7 translates one workflow requirement from Module 2 into a concrete procurement requirement, filling in the Government AI Procurement Requirements Sheet, preparing the requirement basis Module 8's acceptance decision needs.

1. 1Pick a workflow requirement
   Reuse the workflow design from Module 2.
2. 2Write it as a concrete requirement
   Avoid unverifiable adjectives like "smart" or "intelligent."
3. 3Define a verification method
   How will you confirm this requirement is met?
4. 4Define the acceptance criterion and required evidence
   What condition counts as passing? What evidence is required?

• Government AI Procurement Requirements Sheet minimum schema: Requirement ID, Category, Requirement, Rationale, Priority, Risk, Verification Method, Acceptance Criterion, Required Evidence, Owner, Supplier Responsibility, Agency Responsibility, Change / Version Rule.

• Go to the practice page: Activity 7 From Use Case to Procurement Requirement

Key takeaway: This Requirements Sheet turns every judgment from Modules 1-6 into something Module 8's acceptance can check item by item; if you can't write a verifiable requirement, you can't write an acceptable system.