Requirements gathering meeting notes that become a BRD

Write five fields, not a narrative

For each need the room agrees on, capture five fields before you move on. If any field is blank, that item is an open question, not a requirement.

• Problem: the pain, in the stakeholder's words, before anyone names a screen or a system.
• Requirement: one behavior or rule. "The warehouse lead can see which orders missed the cutoff" is a requirement. "Better visibility" is not.
• Owner: the person who will accept it, not the person who will build it.
• Acceptance: the check that proves it is done. A number, a state, or a sentence a tester can fail.
• Priority: must, should, or could. If everything is a must, the meeting did not prioritize.

Run the meeting so those fields get filled

Forty-five minutes is enough for one problem and a handful of requirements. Spend the time in this order, and stop when the clock says so rather than starting a second problem.

• First 10 minutes: the problem. Who feels it, how often, and what they do today when it happens. Park solution ideas on a side list.
• Next 20 minutes: requirements. One at a time. Read each one back in the five-field shape and let the owner correct it.
• Next 10 minutes: priority and conflicts. Two musts that cannot both ship this release get named as a conflict, not smoothed over.
• Last 5 minutes: read the open questions aloud and assign a person and a date to each. Unowned questions do not leave the room as "we'll figure it out."

Separate the BRD from the transcript

The transcript is the evidence. The BRD is the decision. After the meeting, the document a builder can use has four sections and almost no dialogue.

• Problem statement, a few sentences, with who is affected.
• Functional requirements, each with owner, acceptance, and priority.
• Non-functional requirements that are testable: "the cutoff list loads in under 3 seconds for 500 open orders," not "the page should be fast."
• Open questions, risks, and decisions, each with an owner. This is the RAID log. A risk without an owner is a worry, not a log entry.

If you only have time for one pass after the call, write the requirements and the open questions. A polished narrative can wait. A missing owner cannot.

Where a live analyst fits

The hard part is asking for the blank field while the person who knows the answer is still in the room. A note-taker writes down "better visibility" and leaves you to translate it later. A BA meeting assistant should stop and ask who owns it and what done looks like.

Ava's Requirements Lead runs that agenda in the meeting, or in a typed session, and drafts the BRD from what people confirmed. The Business Analyst persona does the same job with a lighter touch when you want her asking follow-ups rather than driving the whole session. If you already have notes and only need the document, the free BRD generator turns a paste into a first draft.