Point an AI at a business requirements document and it will happily summarize what is there. This playbook does the opposite: the AI interrogates what is missing — the NFRs, implicit assumptions, and conflicting constraints a senior architect would probe for — and you, the architect, own every answer.
Tier: Foundation · Hands-on time: ~20 minutes
Requirements gaps are the cheapest defects to fix and the most expensive to discover late. Documentation-shaped AI assistance is already the most common architect use of LLMs, and adversarial review of a BRD is its lowest-risk, highest-leverage form: the model generates questions, not facts, so there is nothing to hallucinate into your design. The discipline that makes it safe is simple — the AI never answers its own questions.
Skip AI when the requirements are three lines on a whiteboard — go interview the stakeholders first; there is nothing yet for the model to interrogate.
Strip and stage the input. Paste the requirements text, not the whole PDF with boilerplate. Remove client-identifying details if your MSA requires it. Twenty pages of legal preamble dilutes the model's attention on the ten paragraphs that matter.
Prompt for interrogation, not summary. Tell the model its job is to find what is absent, ambiguous, or contradictory — and forbid it from inventing answers.
You are reviewing requirements as a principal architect with 15 years of
experience. Your ONLY job is to generate the questions a senior architect
would ask before designing. Do not answer any question yourself. Do not
summarize the document.
Context: I am Rajesh, principal architect at an IT services firm. This is
the discovery input for the "Meridian Retail" engagement — a US retailer
wants a customer-support copilot and an order-status agent. The BRD text
follows after ###.
Produce:
1. Missing NFRs — for each of: availability, latency, throughput,
RTO/RPO, data residency, security, compliance, operability, cost —
state what the document says (quote it) or "SILENT", then the
question I must ask the client.
2. Implicit assumptions — statements that presume something unstated
(e.g., "real-time" without a number). Quote each one.
3. Conflicts — pairs of statements that cannot both be true.
4. Scope ambiguities that will bite estimation later.
Format as a table: #, category, quote-or-SILENT, question, why it
matters for the architecture.
###
[paste BRD text]
Triage the question list yourself. Expect 25–40 questions. Kill duplicates and the generic filler ("what is the budget?" asked five ways), and mark each survivor as answer-now (you know it), ask-client, or ask-internal. This triage is the architect's judgment — a model cannot know that Meridian's order database is a 15-year-old AS/400, which turns a routine integration question into the engagement's biggest risk.
Push a second, meaner pass. In the same conversation: "Assume the answers to all of the above are favorable. What questions would a skeptical reviewer still ask? Focus on the AI-specific requirements: hallucination tolerance, escalation-to-human paths, prompt-injection exposure, eval criteria, token-cost ceilings." For any 2026 engagement with a GenAI scope, this second pass is where the questions nobody has asked yet live.
Answer in your own words, in a separate document. Copy the surviving questions into your requirements register and write the answers from stakeholder interviews and your own knowledge. Never ask the model to "fill in likely answers" — a plausible invented NFR ("99.99% availability is typical for retail") entering your design unlabeled is exactly the failure this track trains you to prevent.
Close the loop with a coverage check. Paste your completed register back: "Which of my answers are vague enough that two engineers would interpret them differently? Quote the vague phrase." Rewrite those. Then file the register with the BRD as the engagement's requirements baseline.
Client BRDs and RFPs are usually MSA-governed documents. Before pasting anything: run the constraint check (does the MSA restrict processing client material with external AI tools? — if you have not extracted that constraint yet, that is pb-03). If external tools are prohibited, either redact the document to structure-only (replace client name, systems, and figures with placeholders — the interrogation technique works identically on [CLIENT] and [ORDER-SYSTEM]), use an approved client-tenancy endpoint (Bedrock or Azure OpenAI inside the client's own subscription), or run a local model via Ollama for the question-generation pass. The question list is generic; the answers — which never touch the AI — are where the client specifics live.
The model's product is questions; your product is answers. The moment an AI-suggested answer enters your requirements register unlabeled, you have shipped a hallucination into a contract.