Analyze AI-Assisted Requirements & Research
AI-assisted requirements gathering, research synthesis, feasibility analysis, and stakeholder alignment. Surface insights before you write a single line of code.
What is the Analyze Phase?
The Analyze phase is the foundation of any successful project. Before design, before code, before anything else - you need to understand what you're building and why.
Traditionally, this phase involved countless meetings, manual document reviews, and trying to synthesize information from disparate sources. AI transforms this by acting as a tireless research assistant that can process vast amounts of information quickly - and research agents can now pull directly from your own docs, tickets, and codebase through MCP connections, not just what you paste into a chat.
In the Analyze phase, AI helps you:
- Extract requirements from stakeholder conversations and documents
- Synthesize research across multiple sources
- Identify gaps and potential risks early
- Generate clarifying questions you might have missed
- Create structured analysis documents
Quick Reference
Research Assistant
Requirements docs, analysis reports
Claude, ChatGPT, Perplexity, Gemini Notebook
Product owner, with the tech lead
Requirements Brief signed off
Inputs and Outputs
Every phase in AIDLC is defined by what it takes in and what it must hand over. Analyze is the only phase that starts from the outside world: people, documents, and the evidence a running system produces.
What it receives
- Stakeholder conversations: meeting transcripts, emails, interview notes, and chat threads.
- Existing material: product docs, tickets, support history, and the relevant parts of the codebase, reached through governed connectors rather than pasted into a prompt.
- Backlog items sent back by the Curate phase: incidents, escaped defects, and what monitoring revealed.
- Constraints from outside the team: budget, deadlines, compliance duties, and the data classification of what the feature will touch.
What it hands off
- A Requirements Brief, the single artifact Ideate receives.
- Problem statement: what is wrong today, for whom, and why it matters now.
- Users and acceptance criteria written in Given/When/Then form, so each one can later become a test.
- Constraints, open questions with named owners, and a risk list.
The brief is the contract with the next phase
Ideate may treat only what is in the signed-off brief as settled. A claim that lives in a chat log, a meeting recording, or a model summary is not a requirement yet. Writing it down in this shape is also the first draft of the ticket contract that later phases depend on.
Key Activities
Requirements Extraction
Feed AI transcripts of stakeholder meetings, emails, and existing documents. AI identifies explicit requirements, implicit needs, and potential conflicts.
Research Synthesis
AI processes technical documentation, competitor analysis, and market research to provide summarized insights relevant to your project.
Risk Identification
AI identifies potential risks, dependencies, and blockers based on requirements and technical constraints.
Gap Analysis
AI identifies what's missing from requirements, what questions need answering, and what assumptions need validation.
Example Workflow
Gather Raw Input
Collect meeting transcripts, emails, existing documentation, and stakeholder notes. Check the data classification of each source before it reaches a tool.
AI Processing
Feed documents to AI with prompts to extract requirements, identify risks, and generate questions. Ask it to quote the source line for every requirement it reports.
Human Review
Review AI output, validate accuracy, and add domain knowledge AI may have missed. Strike anything the sources do not support.
Stakeholder Validation
Present synthesized requirements back to stakeholders for confirmation and refinement. Resolve conflicts between stakeholders as a decision, not as a summary.
Write the Requirements Brief
Assemble the problem statement, users, Given/When/Then acceptance criteria, constraints, open questions, and risk list into one document. The product owner signs it off.
Move to Ideate
With validated requirements - the spec that steers every downstream agent - proceed to the Ideate phase. See Context & Spec-Driven Development.
Who Owns It
The product owner is accountable for the brief: what is in scope, what is not, and which stakeholder wins when two disagree. The tech lead is accountable for the feasibility notes and the risk list. A model can be fast and thorough at the reading, but it holds no accountability for the answer.
What the AI drafts
- Extract candidate requirements from transcripts and documents, with the source line quoted.
- Group, de-duplicate, and flag statements that conflict.
- Draft clarifying questions and a first pass of Given/When/Then criteria.
- Propose risks and dependencies from the stated constraints and the codebase.
What humans decide
- Which requirements are real, and which are noise or wishful thinking.
- Priority, scope, and the call between conflicting stakeholders.
- Whether a risk is acceptable, mitigated, or a reason to stop.
- Sign-off on the brief. Nothing leaves Analyze without a named human approving it.
Humans own decisions and merges in every phase; Analyze is where that habit starts. For the rules on which data may reach a tool at all, see the usage policy outline and Governance Before Scale.
Entry and Exit Criteria
Entry criteria
Start the phase when all of these are true.
- A named product owner exists for the request.
- The request is a real problem or a backlog item sent back from Curate, not a solution in disguise.
- The source material has been classified, and the tool in use is approved for that data tier.
- A baseline for the metrics this work will affect has been captured, or its absence is noted.
Exit criteria
Leave the phase only when all of these are true.
- The Requirements Brief has all six parts: problem, users, acceptance criteria, constraints, open questions, risks.
- Every acceptance criterion is testable as Given/When/Then.
- Every open question has an owner, or has been answered and recorded.
- The tech lead has reviewed the risk list and feasibility notes.
- Stakeholders have confirmed the brief, and the product owner has signed it off.
Best Practices
Quote the source for every requirement
Ask the model to attach the exact line it drew each requirement from. A requirement with no quote is a guess and goes on the open-questions list instead.
Ask for conflicts and gaps, not just a summary
A model asked to summarize will smooth over disagreement. Ask it explicitly to list contradictions, missing actors, and unstated assumptions.
Write acceptance criteria as Given/When/Then
Criteria in that form become the tests that Ideate, Develop, and Launch check against. Prose criteria get reinterpreted at every step.
Use governed connectors for internal data
Let research agents read docs, tickets, and code through approved MCP connections. Do not paste restricted data into a chat window.
Do not treat a fluent answer as a verified one
AI output reads as confident whether or not it is right. Every claim a decision rests on needs a human to confirm it against the source.
Anti-Patterns
These are the ways Analyze most often goes wrong. The named patterns are catalogued on Twelve Ways AI Adoption Fails.
Summaries mistaken for requirements
A tidy model summary of a meeting gets filed as the requirements. Nobody checked it against the people in the room, and the first wrong inference ships as a feature.
Governance After the Incident
Sensitive material is pasted into a tool before any policy says it may be. The fix is the usage policy first; see the failure pattern of the same name.
One-Size-Fits-All Adoption
Every request gets the same depth of analysis, whether it is a copy change or a payments rewrite. Match the rigor of the brief to the risk of the work.
Measuring Without Baselines
Nobody records how long this kind of work took before AI, so every later claim of improvement is a story. Capture the baseline here, before the work starts.
What to Measure
Analyze rarely moves a metric directly, but it sets up the ones that tell you whether the whole loop is working. Pick from the list on Measuring Impact.
Cycle time, ticket to production
Requirements churn shows up here first. If the median is fine but the 85th percentile is long, look for briefs that were reopened after Develop began.
Bug escape rate
Count the escaped defects that trace back to a missed or ambiguous requirement. A high share means the brief is not catching enough.
Developer survey
Ask whether the briefs were clear enough to build from. It is a cheap signal that catches vague acceptance criteria early.
The baseline itself
Record the current numbers for the workflow before the first AI-assisted change. Without it, no later number in any phase means anything.
Report each number against its baseline, not on its own.
Go Deeper
Frequently Asked Questions
The Analyze phase involves AI-assisted requirements gathering, research synthesis, feasibility analysis, and stakeholder alignment. AI helps surface insights from documentation, past projects, and domain knowledge.
AI can analyze existing documentation, identify gaps in requirements, suggest clarifying questions, and synthesize research from multiple sources to provide comprehensive context for development decisions.
A Requirements Brief is the one document the Analyze phase hands to Ideate. It holds the problem statement, the users, acceptance criteria written as Given/When/Then, constraints, open questions, and a risk list. A product owner signs it off, so every later phase works from the same written agreement instead of a chat history.