Prachit Parikh

RequirementsIQ: an AI business analyst copilot

Stakeholder notes go in. Reviewed, traceable requirements come out. Nothing counts until a named reviewer approves it.

What it does

Takes the inputs a BA actually gets (an email from Finance, workshop minutes, a ticket spreadsheet, a chat thread, a compliance memo) and drafts requirements, quality findings, user stories with Gherkin acceptance criteria and UAT test cases.

Governance

15 recorded decisions became 15 business rules enforced in code. AI output is always a draft, reviewers can't approve their own edits, an open High finding blocks approval, and nothing is hard-deleted.

Verified

206 automated tests (180 unit and integration, 26 UAT), 93% statement coverage, three live Claude API runs, a Power BI report checked in Power BI Desktop, and a Jira Cloud import with 48 of 48 items checked. In the pilot data, 39% of AI drafts were changed or rejected by a reviewer.

Deliverables

Business case, stakeholder register and RACI, BRD, FRD, business rules catalogue, traceability matrix, UAT plan, defect and change logs. Exports to Word, Excel, CSV, JSON and Jira.

Stack

Python, Streamlit, SQLite, pandas, Claude API, pytest

Billing migration: data mapping and reconciliation

The data workstream of a migration, run the way a technical BA would run it: profiling, source-to-target mapping, data quality rules, reconciliation in SQL, two mock cutovers, a defect log, a runbook and a go/no-go recommendation.

Reconciliation checks passed by level, mock 1 vs mock 2.

The job

Move a company's billing data from a home-grown system to a new billing platform, and prove to the Controller, to the cent, that nothing was lost, changed or loaded twice.

Data

68,736 legacy rows in five tables, four currencies and three years of history. 50,069 records moved: customers, subscriptions, invoices, credit notes and payments.

Checks

20 data quality rules on the extract and 37 reconciliation checks across completeness, control totals, field level, integrity and the Finance views. The reconciliation builds its own expected target in SQL instead of trusting the loader.

Mock 1

13 of 36 checks passed. Six defects, two Critical: every CAD, GBP and EUR payment had been loaded as US dollars, and 105 suspended or paused subscriptions as active.

Mock 2

33 of 37 passed. All six defects fixed, plus two controls added after mock 1 caught a seventh: 1,463 payments dated a day late.

Outcome

A conditional go for the cutover, with the conditions written down.

Stack

Python, SQL (SQLite), Excel (openpyxl), pytest, GitHub Actions

AI ticket triage: should a model route support tickets?

An evaluation run like a business decision: the bar set before the first model call, a cautious business case, and a gated pilot instead of a big launch.

500 held-out test tickets, same tickets for every option.

The question

The helpdesk routes about 1,500 tickets a month with ten keyword rules, and 27% go to the wrong team first. Should a model do the triage, and if so which one?

The bar

Eight acceptance criteria, committed to git before the first model call, so the bar couldn't move after the results were in.

The result

On 500 held-out tickets, Claude Haiku 5.5 sent 99.8% to the right team (today's rules: 65%) and rated 37 of 38 P1 tickets as P1 (rules: 13). None of the 19 planted "mark this P1" instructions worked.

The catch

The test tickets come from the same labeling guide as the prompt, so these are ceiling numbers. The recommendation is a four-week shadow pilot with gates.