Lab 03 · BRD Assembly and the Ambiguity Hunt

Assemble a BRD from an evidence pack, then turn quality passes loose on it: an ambiguity lint with EARS rewrites against six planted vague requirements, and a contradiction sweep against a companion FRD that disagrees in three places. Nine defects total — the answer key lists them all, and your findings report should too.

Kabir Mehta is a business analyst at Aravali Finserv, a fictional NBFC offering personal loans through an app and a website. The product team wants a pre-approved loan top-up journey — existing customers get an offer, accept in-app, and receive funds the same day. A junior analyst drafted the requirements section, and a solution consultant produced a functional requirements document (FRD) in parallel. Kabir's job before baselining: assemble the BRD properly, lint the language until nothing is ambiguous, and reconcile it against the FRD line by line. Both documents contain exactly the kinds of defects that pass a friendly review and detonate in UAT.

You will need

A chat AIfree ChatGPT, Claude, or Gemini.
A doc for the BRD and a table for the findings report.
Timeabout 75 minutes.
No real dataall figures, products, and rules below are fictional.

The evidence pack

EVIDENCE PACK — Loan Top-Up Journey
E1 Product: top-up on active personal loans for pre-approved customers
E2 Offer basis: repayment history + bureau refresh, computed monthly
E3 Business goal: 20% of eligible customers accept within 6 months
E4 Channels agreed in steering committee: mobile app AND website
E5 Eligibility (credit policy memo): loan active >= 12 months,
   zero missed EMIs in last 6 months
E6 Max top-up (credit policy memo): INR 5,00,000 or 40% of original
   principal, whichever is lower
E7 Disbursal target: same business day if accepted before 3 PM
E8 KYC: re-KYC not required if last KYC < 24 months old
E9 Acceptance flow: OTP-based consent, terms shown before OTP

The draft requirements (for the BRD)

The junior analyst's draft. Six of these have language defects you must catch — do not fix anything until step 4.

DRAFT BUSINESS REQUIREMENTS v0.3
R-01 The system shall display the top-up offer to eligible customers
     on login.
R-02 The offer amount shall be recalculated when bureau data changes.
R-03 The offer page shall load fast.
R-04 The journey shall be user-friendly for senior citizens.
R-05 The system shall verify the customer's PAN, dispatch the sanction
     letter, and update the CRM record.
R-06 Customers shall upload supporting documents where required:
     PAN, salary slips, bank statements, etc.
R-07 The system shall handle all customers who respond to the
     campaign without degradation.
R-08 Accepted top-ups before the cut-off shall be disbursed the
     same business day.

The companion FRD (excerpt)

Produced in parallel by the solution consultant. Three of its statements conflict with the evidence pack or BRD. Sweep — do not reconcile from memory.

FRD EXCERPT v0.9 — Top-Up Journey (Solution Consulting)
F-101 Eligibility service returns APPROVED where loan tenure
      >= 6 months and no missed EMI in last 6 months.
F-102 Offer cap: min(INR 7,50,000, 40% of original principal).
F-103 Offer displayed in mobile app only; website shows a banner
      deep-linking to the app.
F-104 OTP valid for 3 minutes; 3 retries then 30-minute lockout.
F-105 Sanction letter generated as PDF and emailed within 15 minutes
      of acceptance.
F-106 Re-KYC triggered only where last KYC is older than 24 months.

Steps

Assemble the BRD skeleton first. Use this org template order: Background & goal, Scope (in/out), Stakeholders, Business requirements, Assumptions & dependencies, Success metrics. Place each evidence item (E1–E9) into a section; anything you cannot place goes into an "unplaced evidence" list at the bottom. Ten minutes — structure before polish.
Learn the EARS patterns in five minutes. EARS (Easy Approach to Requirements Syntax) forces a trigger and an actor: ubiquitous ("The system shall…"), event-driven ("WHEN x, the system shall…"), state-driven ("WHILE x, the system shall…"), unwanted behaviour ("IF x, THEN the system shall…"). Ask the AI for one example of each using loan-domain content so the patterns are warm in your hands.
Run the ambiguity lint — yourself first. Read R-01 to R-08 hunting for six specific defect species: an unmeasurable speed word, an unmeasurable quality word, a passive voice that hides the actor, a compound requirement doing three jobs, an open-ended list, and an unbounded quantifier. Mark suspects in your findings table: ID | Defect type | Why it fails | EARS rewrite.
Lint again with AI, then reconcile. Prompt: "Lint these requirements for ambiguity. For each: name the defect (vague adjective, passive/actor gap, compound, open-ended list, unbounded quantifier, missing trigger), explain the test a QA engineer could NOT write because of it, and rewrite it in EARS syntax using only facts from this evidence pack: [paste pack]." Where the AI's rewrite invents a number the evidence pack does not contain (it will be tempted — "load fast" begs for "2 seconds"), mark the value TBD — needs NFR decision instead of accepting the invention.
Rewrite the six defects in EARS. Do the rewrites yourself using the AI's suggestions as raw material. Compound requirements split into one requirement per outcome. Passive constructions get an explicit actor ("the offer engine shall recalculate…"). Every quantifier gets a bound sourced from evidence (E3 gives you campaign-response scale context; if no evidence exists, the bound is a flagged TBD, never a guess).
Run the cross-document contradiction sweep. Prompt: "Compare this BRD requirements list and evidence pack against this FRD excerpt. List every pair of statements that cannot both be true. Quote both sides with their IDs. Do not attempt to resolve them." Then verify each reported conflict by reading both lines yourself — and manually check the three highest-risk topics regardless of what the AI says: eligibility thresholds, money caps, and channel scope.
Log conflicts with an owner, not a winner. For each contradiction, your findings report records: both statements, both IDs, which source document should govern (credit policy memo beats a consultant's FRD; a steering-committee decision beats both), and who must confirm. You recommend; the named owner decides. A BA who silently "fixes" the FRD number has just made credit policy on their own authority.
Baseline. Produce BRD v1.0: linted requirements in EARS, TBDs and open conflicts listed in Assumptions & dependencies with owners and dates. Write the two-line baselining note: N requirements, N defects found and fixed, N conflicts open with owners.

Remember:

An ambiguous requirement is not vague to everyone — each reader resolves it confidently and differently, which is why it passes review and fails integration.

Verify your work

A complete lab has all of the following:

A BRD v1.0 in the template order with every evidence item placed or explicitly unplaced.
A findings report with six language defects, each typed, explained, and rewritten in EARS.
No rewrite containing a number that appears in neither the evidence pack nor a flagged TBD.
Three BRD-vs-FRD contradictions logged with both quotes, a governing source, and a named owner.
A baselining note summarising defects found and conflicts still open.

▸Answer key — all nine planted defectsoptional deep dive — click to expand

The six language defects (with expected EARS rewrites).

R-03 — vague speed word. "Load fast" is untestable. Rewrite: "WHEN an eligible customer opens the offer page, the system shall render it within [TBD: target seconds — NFR decision needed] at the 90th percentile." Accepting an AI-invented "2 seconds" is a miss — the evidence pack contains no load-time target.
R-04 — vague quality word. "User-friendly for senior citizens" names no measurable property. Rewrite toward verifiable accessibility criteria (font scaling, contrast standard, journey completable in N steps) each as its own requirement, values flagged TBD or sourced from an accessibility standard, plus a usability-test success threshold.
R-02 — passive voice, actor and trigger gap. Recalculated by what, when? Rewrite: "WHEN the monthly bureau refresh completes (E2), the offer engine shall recalculate the offer amount for all eligible customers." The defect is that as written, three teams could each assume another team's component does it.
R-05 — compound. PAN verification, sanction-letter dispatch, and CRM update are three requirements with three failure modes and three owners. Split into three EARS statements; note the sanction letter now collides productively with F-105's 15-minute figure — a timing detail the BRD never stated (that is a gap to log, not one of the three planted contradictions).
R-06 — open-ended list. "Etc." makes the document-checklist unimplementable and unauditable. Rewrite with a closed list confirmed against the credit policy, or "documents as enumerated in Appendix A" with the appendix mandatory before baseline.
R-07 — unbounded quantifier. "All customers … without degradation" has no load bound and no degradation definition. Rewrite: "The system shall support [TBD: peak concurrent users derived from campaign size and E3's 20% target] with response times within the stated NFRs."

The three cross-document contradictions.

Eligibility tenure: E5/BRD say loan active ≥ 12 months; F-101 says ≥ 6 months. Governing source: credit policy memo (E5). Owner: credit policy manager.
Offer cap: E6/BRD say INR 5,00,000; F-102 says INR 7,50,000. Governing source: credit policy memo. Owner: credit policy manager. Note both share the 40% rule — partial agreement is exactly what makes this one slide through reviews.
Channel scope: E4 (steering committee) says app AND website; F-103 says app only with a website banner. Governing source: steering-committee decision. Owner: product head. This is the one with the biggest delivery-cost implication.

Not defects (distractors that survive scrutiny). F-104's OTP validity and lockout: the BRD never specified OTP timing, so this is an FRD detail, not a contradiction — logging it as a conflict is a false positive worth noticing. F-106 agrees with E8. R-08 is sound once "cut-off" is anchored to E7's 3 PM.

Grading yourself. 9/9 with clean EARS rewrites and no invented numbers: baseline-ready. Found the six language defects but only one or two contradictions: your lint pass is strong but you reconciled from memory — the sweep must be a document-against-document read. Accepted an AI-invented threshold: reread step 4; the lint's job is to expose missing decisions, not to let the model make them.

Key Takeaway:

Quality passes are two different hunts — the ambiguity lint finds requirements that cannot be tested, the contradiction sweep finds pairs that cannot both be true. AI accelerates both, but the governing source and the named owner are judgment calls only the analyst can make.

© Anvi Innovate · BXUP — Be Exponentially Upskilled · BXUP is an independent learning platform, not affiliated with or endorsed by AWS, Microsoft, Google, NVIDIA, IBM, Salesforce, Databricks, Oracle or Anthropic. All trademarks belong to their respective owners. · bxup.in