# Requirements gathering meetings: what to ask a client and how to write it up

> For freelance developers and technical consultants running requirements calls with clients on Google Meet or Microsoft Teams: questions grouped by area, from users and data to rules and non-functional needs, how to capture the client's exact wording, an ambiguities list, and how to turn the notes into a spec draft the client corrects. Ends with how TrackHeros helps you find what was said.

Canonical: https://trackheros.com/blog/requirements-gathering-meeting/  
Author: Sami Kanafani  
Updated: 2026-10-22

**In short:** In a requirements gathering meeting, cover users, data, workflows, business rules, integrations and non-functional needs one area at a time, and ask for a real example of each rule. Write the client's exact words, keep a list of ambiguities, and send a spec draft for correction within two days. TrackHeros records Google Meet and Microsoft Teams requirements calls and answers questions about them with citations.

A requirements gathering meeting is a structured call where you find out exactly what a piece of software has to do: who uses it, what it keeps, what rules it follows and how it has to behave. This guide is for freelance developers and technical consultants running those calls with clients on Google Meet or Microsoft Teams. It gives the questions to ask, area by area, how to record the client's exact wording, what goes on an ambiguities list, and how to turn the call into a first spec draft.

## How is a requirements meeting different from a discovery call?

A discovery call decides whether there is a project; a requirements meeting decides precisely what it is. The first is about problems and budgets. The second is about rules, examples, numbers and exceptions, and it usually takes several sessions.

The [discovery call guide](/blog/discovery-call-notes-solo-developer/) covers the first conversation and the [kickoff agenda](/blog/client-kickoff-meeting-agenda/) covers agreeing how the engagement runs. Requirements sessions come after both, or alongside the first sprint. Plan sixty to ninety minutes per session and one or two areas per session. Trying to cover a whole system in one call produces a list of features, not requirements.

## Which questions should you ask a client about software requirements?

Go area by area, and ask for a real example every time. A rule described in the abstract hides its exceptions; a rule applied to last Tuesday's order shows them.

| Area                 | Questions that work                                                                                                                                                 |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Users and roles      | "Who will use this, and what is each of them trying to get done?" "Who must not see what?"                                                                          |
| Data                 | "What does the system keep track of? Can you show me a real one?" "Where does that live today, and who owns it?" "How many are there, and how fast does that grow?" |
| Workflows            | "Walk me through the last time you did this, step by step." "What happens when it goes wrong?"                                                                      |
| Business rules       | "When is an order counted as late?" "Are there exceptions, and who decides them?"                                                                                   |
| Integrations         | "Which other systems does this talk to?" "Who can get me their documentation and a test account?"                                                                   |
| Reports and outputs  | "What does someone need to see on Monday morning?" "Can you show me the spreadsheet you use now?"                                                                   |
| Non-functional needs | "How many people use it at once?" "What happens if it is down for an hour?" "Are there rules about where the data is stored?"                                       |
| Acceptance           | "How will you check this works? What would you try first?"                                                                                                          |

The workflow question is the most productive in the list. "Walk me through the last time" gets you a real case with real exceptions. "How does the process work?" gets you the version in the procedures manual.

Ask the screen-share question too: "Can you show me?" Five minutes watching someone use the current spreadsheet tells you more than twenty minutes of description.

## How do you record the client's exact wording?

Put the client's words in quotation marks with their name, and keep your interpretation on a separate line. The words carry the rule. "Late" might mean "after five the next day" to operations and "after the promised date" to customer service, and only the exact wording shows you that there are two rules.

Four habits help:

- **Quote, then interpret.** `Tom: "anything not out the door by five the next day is late."` Then, on its own line: `My reading: shipped after 17:00 on the working day after payment.`
- **Read it back.** "So an order is late if it hasn't shipped by 17:00 on the working day after it was paid. Is that right?" Corrections here are free.
- **Note who said it.** Two stakeholders will describe the same rule differently. You need to know which version came from whom.
- **Build a glossary as you go.** Every term the client uses that you would not use yourself goes into a list with their definition. If the call is held in German, keep the German term next to your English one: the spec should use the word the client's team will search for.

If you cannot type fast enough while running the session, type only quotes and numbers. The rest can be filled in afterwards, from memory or from a recording if the client agreed to one.

## What goes on the ambiguities list?

Every word that sounds like a requirement and is not one yet. Vague words are the usual source, and each has a question that turns it into something testable.

| What the client said   | The question to ask                                              |
| ---------------------- | ---------------------------------------------------------------- |
| "It should be fast"    | "Fast compared to what? How long is too long, in seconds?"       |
| "All users can see it" | "Including the warehouse temps? Including former staff?"         |
| "In real time"         | "If it is a minute old, is that a problem? Five minutes?"        |
| "The usual exceptions" | "Which ones? Can you list them, or show me the last three?"      |
| "And so on" / "etc."   | "What else is in that list?"                                     |
| "Simple"               | "What is the one screen or step you want to avoid?"              |
| "Nice to have"         | "If it is not in the first release, does anything stop working?" |

Add conflicts between stakeholders and anything you assumed but nobody said. Each item gets a question, the person who answers it, and a date. Send the list with the spec draft. An ambiguity you fail to write down does not go away; it becomes a [change request](/blog/scope-creep-starts-in-meetings/) six weeks later.

## How do you turn the call into a written spec draft?

Within two days, while the wording is fresh on both sides. A plain structure is enough:

1. Purpose, in the client's words.
2. Users and roles.
3. Glossary.
4. Workflows, as numbered steps, with named exceptions.
5. Business rules, numbered, each with its source.
6. Data and integrations.
7. Non-functional requirements, with numbers.
8. Out of scope.
9. Open questions: the ambiguities list.

Write each business rule with its source, an example and anything still open:

```text
BR-4  Late orders
Rule:    An order is late if it has not shipped by 17:00, warehouse
         time, on the working day after payment.
Source:  Tom (operations), requirements call 20 October:
         "anything not out the door by five the next day is late".
Example: Paid Friday 14:00 → late if not shipped by Monday 17:00.
Open:    Do public holidays count as working days? Tom, by 23 October.
```

Send it as a draft, and say what you need: "Everything under Open questions needs an answer before I can estimate. Corrections to anything else are welcome." The corrections are the point. Each one is a misunderstanding caught before it reached the code.

## How does TrackHeros help with requirements calls?

TrackHeros is an AI meeting notetaker that joins requirements calls on Google Meet and Microsoft Teams as a visible participant and records them. The transcript is made in two passes: the platform's captions first, for real speaker names, then an audio pass over the recording. A line that cannot be attributed reads "Unknown" rather than being given to the likeliest person, which matters when a spec cites who said a rule.

Afterwards, open the client and ask "what did Tom say counts as a late order?" The answer comes from that client's meetings only, cited to who said it and when, and the citation plays the recording from that moment, so a rule's source line can point at the exact sentence. The notes list decisions and action items, such as "Tom to confirm public holidays by Friday", each with the owner as heard and the due date as said.

Client vocabulary is handled with correction rules on that client's Rules page: a vocabulary rule for a term the transcript gets wrong, or an instruction rule with free-text guidance. Rules apply to every meeting summarised from then on. To fix a past meeting, ask the assistant in that client's chat to apply your vocabulary rules to it or to rewrite its notes; both wait for your approval. A call held in German is transcribed and rendered into English line by line, and on paid plans ([pricing](/pricing/)) the notes can be written in German or any other of the nine notes languages listed on [/languages/](/languages/). More at [ask your meetings](/features/ask-your-meetings/) and [correction rules](/features/correction-rules/).

## Frequently asked

**How long should a requirements gathering meeting be?**

Sixty to ninety minutes, covering one or two areas, not the whole system. Attention drops after that and answers get vaguer. A typical freelance project needs two to four sessions, with a spec draft in between so each call starts from what was written, not from memory.

**Should I write the spec or ask the client to?**

Write it yourself and send it as a draft for correction. Clients describe what they want far better than they write it, and correcting a draft is a task they will actually do. Their corrections are the most valuable part of the process, because each one is a misunderstanding caught before it is built.

**What if two people on the client's side disagree about a requirement?**

Write both versions down with each person's name, and do not choose between them yourself. Put it on the ambiguities list with the name of whoever decides and a date. A requirement two stakeholders read differently will be built wrong for one of them.

**Can I record a requirements call?**

Ask first. A recording is the best way to check exact wording later, but rules on recording differ by country and by contract, so check yours and tell the client what the recording is for and how long you keep it.

---

TrackHeros is in early access: https://trackheros.com/#early-access