Understanding what a customer really needs is not always as straightforward as listening to what they say. Customers often describe requirements in terms of what they are currently experiencing rather than the outcome they want. They leave out details they assume are understood. They use words like "simple" or "professional" without defining them.
This checklist gives you a structured approach to requirements conversations — from preparation through to documentation and confirmation. Use it as a reference before and after customer meetings, not as a script during them.
What This Checklist Is For
This checklist is for any situation where you need to understand what a customer or stakeholder needs before you can begin work — whether that is a service engagement, a project, a purchase decision, or a change to an existing arrangement. It applies to conversations with external customers and with internal stakeholders (team members, managers, other departments).
Before the Conversation — Preparation
- Review any previous communications with this customer to understand their history and any existing expectations.
- Write down what you already know about their situation, and what you do not know but need to find out.
- Prepare three to five open questions focused on outcomes — not features or deliverables, but what success looks like from their perspective.
- Identify any constraints you need to ask about: timing, budget, technical limitations, regulatory requirements.
- Decide how you will document the conversation — notes during the meeting, a written summary afterwards, or both.
During the Conversation — Questions to Ask
Focus on outcomes and context before moving to specifics. Useful questions include:
- What is the problem you are trying to solve, or the outcome you are hoping to achieve?
- What does success look like for you in this engagement?
- What have you already tried, and why did it not fully work?
- Are there any constraints I should know about — timing, budget, technical or regulatory requirements?
- Who else is involved in this decision, and are their requirements the same as yours?
- How will you decide whether the final result has met your needs?
- Is there anything you particularly want to avoid?
When you hear an ambiguous word or phrase, ask for a concrete example. "What would that look like in practice?" or "Can you give me an example of what you mean?" are reliable ways to move from vague to specific.
What to Document
After the conversation, document the following before beginning any work:
- The outcome the customer is trying to achieve, in their own words where possible.
- Any specific requirements that were stated explicitly — what the output must include, must exclude, or must achieve.
- Constraints: timing, budget range, technical limitations, regulatory considerations.
- Assumptions you are making — things that were not stated but that you are treating as understood. List these explicitly so they can be confirmed.
- Open questions — things you still need to clarify before work can begin.
- Who confirmed the requirements and when.
After the Conversation — Confirmation
- Send a written summary of what you understood — requirements, constraints and any assumptions — to the customer within one working day.
- Ask them to confirm that the summary is correct, or to correct anything that is not.
- Resolve any open questions before beginning work.
- Keep the confirmed requirements accessible for the duration of the engagement — they are the reference point for evaluating success.
- If requirements change during the engagement, document the change and re-confirm in writing.
After Gathering Requirements — What to Do Next
Once you have a confirmed set of requirements, you have the foundation for the rest of the engagement. Use the requirements to define the scope of work, to make decisions when options arise during the work, and to evaluate the output before delivery.
If at any point during the work you encounter something that would require departing from the agreed requirements, raise it with the customer before making the change rather than after. This keeps the customer informed and gives them the opportunity to adjust the requirement rather than receiving a surprise at the end.
Requirements gathered well at the start reduce the amount of back-and-forth during an engagement. They do not eliminate all changes — but they make changes manageable, because you have a clear baseline to measure changes against.