From Meeting Notes to Requirements Docs: A Five-Step Method with AI Assistance

Every requirements review meeting ends, and you're left holding tens of thousands of words of transcripts, a pile of slides, and an email thread—with no idea where to start. The raw material does contain requirements, but they almost never show up in "requirement" format. This article presents a five-step method you can run with a spreadsheet and a highlighter. AI can speed up most of the steps, but there's one iron rule: every AI-generated requirement must be traced back to the source material and verified line by line.

Why Raw Meeting Materials Are Unreliable

Meeting materials are dense with information, but extracting the useful parts costs even more. Common problems include:

• Requirements hide inside stories. "Last winter a technician had no signal in the basement and lost a whole day's forms"—that's actually a requirement for offline work, just disguised as a complaint.
• Solutions run ahead of problems. "We need a dashboard" is a solution. What should be recorded is the requirement behind it: supervisors need to see which visits are overdue before 10 a.m.
• Decisions get buried. "We're keeping the existing scheduling system" is a constraint that affects every subsequent decision, yet it often appears on a single line of the transcript.
• Sources contradict each other. The sales deck promises same-day reports, while the operations lead says weekly is fine. Both statements end up in your notes.
• The volume is overwhelming. A one-hour call produces thousands of words of transcript. A few calls plus a few decks, and nobody is going to re-read any of it.

The goal is not to summarize the material, but to extract the parts that "someone will build and test," and to explicitly mark everything else as open questions.

Step 1: Collect and Tag Your Sources

Before reading closely, put every source into a register and give each one a short tag. The tag format can be "type letter + number," e.g., T1 for the first call transcript, D1 for the first slide deck, E1 for an email thread. The register should record: tag, source content, date, and participants.

The tags pay off later—every requirement you write carries one or more tags, so anyone can trace the origin and the person who said it. Make sure to record who took part in each conversation, because a sentence from the budget approver and a casual remark from a bystander carry completely different weight.

If a source is a recording with no transcript, transcribe it first. Reconstructing a call from memory is the main source of "invented requirements."

Step 2: Extract Statements, Decisions, and Questions

Read through each source and mark three kinds of lines, copying them into a worksheet with the source tag and a short quote:

• Requirements: what users or the business must be able to do, or what quality attributes must be present. "Supervisors need to see which visits are overdue."
• Decisions and constraints: things already settled or non-negotiable. "Keep the existing scheduling system." "Data must stay in the EU." "Launch before summer."
• Questions and concerns: anything unclear, disputed, or assumed. "Do subcontractors use this app too?" "Are weekly reports enough, or must it be same-day?"

Don't rewrite anything at this step—keep the speaker's exact words. Here you're after coverage, not polish, and the quotes will settle later arguments ("the operations lead said X on March 3").

When two sources disagree, record both and add a new question. Don't quietly make the choice for someone.

Step 3: Rewrite into Testable Requirements

Now rewrite each requirement into a form a tester can judge as pass or fail. A good requirement line is short, covers one thing, and states an observable outcome. The ISO/IEC/IEEE 29148 standard lists quality attributes such as necessary, singular, unambiguous, and verifiable; in practice, the question "can someone check this?" catches most problems.

A simple sentence pattern comes from the EARS method developed at Rolls-Royce: When [trigger], [system] shall [response].

Raw note (source)	Rewritten requirement
"No signal in the basement, lost a day's forms" (T1)	The technician app shall allow technicians to record visits without a network connection and sync once connectivity returns.
"Supervisor learned about the refusal by phone, too late" (T2)	When a technician refuses a visit, the scheduling board shall show that visit as unassigned with the refusal reason within one minute.
"Keep the existing scheduling system" (T1, E1)	Constraint: visits shall be created and closed through the existing scheduling system's API.
"The customer denied we were there" (T2)	The app shall capture a customer signature and attach it to the closed visit record.

(The examples above are fictional, for illustration only.)

Then add the administrative fields: type (functional/non-functional/constraint), priority (MoSCoW, agreed with the sponsor rather than guessed), acceptance criteria (one to three checks), source tags, and the business goal it supports.

If a number in the acceptance criteria comes from no source, mark it "proposed" and get someone to confirm it—don't quietly adopt it.

On the MoSCoW method: MoSCoW is a widely used requirements prioritization technique proposed by Dai Clegg in 1994. It divides requirements into four categories: Must have, Should have, Could have, and Won't have (not this time). Must means core requirements whose absence causes the project to fail; Should means important but with a workaround if missing in the short term; Could means nice-to-have, done when resources allow; Won't explicitly marks scope out of this cycle to avoid scope creep. The article stresses "agreed with the sponsor rather than guessed" precisely because priority is fundamentally a business decision, not a technical judgment by the requirements analyst.

On the EARS method: EARS (Easy Approach to Requirements Syntax) was proposed by Mavin et al. at Rolls-Royce to reduce requirement ambiguity using controlled natural language. Its basic patterns include: ubiquitous (the system shall…), event-driven (when [trigger], the system shall…), state-driven (while [state], the system shall…), optional-feature (if [feature], the system shall…), and unwanted-behavior (if [exception], the system shall…). The value of EARS is that it forces trigger conditions and system responses apart, so that every requirement lets a tester design a clear pass/fail judgment—consistent with the article's "can someone check this?" test.

On ISO/IEC/IEEE 29148: This standard is the international standard for requirements engineering in systems and software engineering, replacing the earlier IEEE 830. It defines the quality attributes a requirements specification should have, including necessary, implementation-free, unambiguous, complete, singular, feasible, verifiable, correct, and conformant. The article cites the standard to show that "testable" is not a subjective feeling but rests on an industry consensus; in practice, the plain question "can this be checked?" operationalizes those attributes.

Step 4: Record What's Still Unknown

Much of the value of this process lies precisely in what you can't write down. Every question from Step 2 and every guessed requirement goes into an open-questions log. Each entry records: a one-line question, why it matters (which requirement or estimate it affects), who can answer it, the deadline, and what is assumed until then.

Example: "Do subcontractors use the app? Affects login, permissions, and license count. Ask: operations lead. Until answered: assume employees only."

Assumptions made to keep moving should be visible in the same place. An estimate built on "employees only" has to be thrown out if the answer turns out to be "plus 40 subcontractors."

Finally, re-read your requirements list against the sources: find items that appear in the transcripts but not in the requirements, and requirements with no source tag. The latter are often ideas that surfaced while writing—possibly fine, but they should be confirmed rather than smuggled in.

What AI Can Help With, and What You Must Check

AI is good at the slowest parts of Steps 2 and 3: reading long transcripts, finding sentences that state requirements, merging similar points, and producing first-draft wording. It's also effective as a second pass ("what statements did I miss in this transcript?").

It fails in a few predictable ways:

• Fabricated details. Models may add numbers, names, or thresholds nobody mentioned. Verify every number against the source.
• Goals written as requirements. "Reduce missed visits by 30%" is a goal, and the model may rewrite it as a requirement the system itself can't satisfy.
• Lost disagreements. Summaries tend to pick one version when two sources conflict. You need both, plus a question.
• Missed constraints. Brief remarks about budget, regulation, or existing systems are easy to drop, and costly to discover late.
• Overly confident tone. A beautifully worded requirement reads like consensus, even when it's only a guess.

Take Discovery Phase AI as an example (a tool built by the author of the original article—disclosure noted): you upload transcripts, slides, documents, or images, and it analyzes them in memory without storing them; the AI drafts stakeholders, goals, users, journeys, and requirements for human review. It is instructed to draft requirements only when the source explicitly states them, never to invent acceptance criteria or numbers, and to leave fields blank rather than guess. Every draft item is checked by a human before being saved. Even so, Steps 1 and 4 remain human work: figuring out who said what, and writing down the questions nobody answered.

Where the Five-Step Method Fits

This method suits the early stage of requirements discovery, especially salvaging clues from unstructured material. It does not replace user interviews or a formal requirements review. AI accelerates reading and first drafts; judgment and decisions stay with people.

One practical habit is worth keeping: if you can't point to which sentence in which source a requirement came from within thirty seconds, it doesn't belong in the requirements document.