# Requirements Elicitation Checklist

**Initiative:** _______________  **Analyst:** _______________  **Date:** _______

## 1. Before the session

- [ ] The business problem stated in one sentence — and it is a problem, not a solution
- [ ] Stakeholders identified: who **does** the work, who **owns** it, who **pays** for it
- [ ] **Someone who actually performs the task is in the room**, not only their manager
- [ ] Existing documentation read first — do not spend a stakeholder's hour on what is written down
- [ ] Current process observed, or a walkthrough arranged
- [ ] Sample of real data or real documents obtained
- [ ] Questions prepared, but not read from

🔴 Requirements gathered only from managers describe the process as it is supposed to work.
Requirements gathered from the people doing it describe the process as it actually works,
including the workarounds — and the workarounds are usually the requirement.

## 2. Questions that surface the real process

- [ ] "Walk me through the last time you did this" — a specific instance, not the general case
- [ ] "What do you do when it goes wrong?"
- [ ] "What is the most annoying part?"
- [ ] "What do you keep in a spreadsheet outside the system, and why?"
- [ ] "How often does the exception happen?" — then check whether the answer is measured or felt
- [ ] "Who else touches this?"
- [ ] "What would you not want to lose from how it works today?"

The spreadsheet question is the highest-yield question in business analysis. Shadow systems mark
exactly where the official system fails.

## 3. Watch for solutions disguised as needs

- [ ] Any request phrased as a screen, field or report captured — then traced back to the need
- [ ] Asked "what decision does that help you make?" or "what would you do with it?"
- [ ] Distinguished what they **want** from what they **need** from what the business **requires**
- [ ] Recorded the requested solution too, so nobody feels unheard

Someone asking for a dashboard is telling you they cannot see something. The dashboard may still
be right; the requirement is the visibility.

## 4. Coverage

- [ ] Happy path captured
- [ ] **Exceptions captured** — with rough frequency
- [ ] Volumes: how many per day, peak, largest single case
- [ ] Timing: deadlines, cut-offs, period-end behaviour
- [ ] Rules: eligibility, calculation, approval thresholds — including who can override
- [ ] Data: what is captured, what is mandatory, what is validated, what is retained
- [ ] Permissions: who may see and do what
- [ ] Integrations: what else needs this, and what does this need
- [ ] Non-functional: performance, availability, accessibility, audit

## 5. Conflicts

- [ ] Contradictions between stakeholders recorded rather than resolved on the spot
- [ ] Escalation path for genuine business conflicts identified
- [ ] Nobody's requirement was quietly dropped because they were less senior

Conflicting requirements are information about competing priorities. Resolving them privately in
favour of whoever spoke last is how a project delivers something nobody agreed to.

## 6. After the session

- [ ] Notes written up within 24 hours, while context survives
- [ ] **Sent back to participants for confirmation** — "have I understood this correctly?"
- [ ] Requirements written testable, one behaviour each
- [ ] Assumptions listed separately, each with someone who can confirm it
- [ ] Open questions listed with owners and dates
- [ ] Out-of-scope list updated with anything explicitly excluded

## 7. Quality check on what you produced

- [ ] Every requirement provable in one sentence
- [ ] No *user-friendly*, *robust*, *intuitive*, *appropriate*
- [ ] No requirement contains "and" doing the work of two
- [ ] Each traces to the business problem
- [ ] Someone who was not there could read it and understand what is needed

**Requirements that are really assumptions:** _______________

## Sign-off

| | Name | Date |
|---|---|---|
| Analyst | | |
| Participants confirmed notes | | |
| Business owner | | |