Requirements Gathering
On day one, Meera Iyer tells you: "We need AI to read our carrier invoices." It sounds like a requirement. It is really a solution someone has already picked. The actual requirement is hiding in how Farhan's five clerks spend their day, and you will only find it by looking.
The rule
Study the work, not the wish: ask about the last real case.
- Requests arrive as solutions. "AI to read invoices", "a dashboard", "an alert". Trace each one back to the problem and to the outcome that matters: paying carriers the right amount with less manual effort.
- Ask about real past events. People are poor at predicting what they would use and good at describing what they just did. "Walk me through the last invoice you disputed" beats "What features would help you?"
- Watch the work. Sit beside a clerk for an hour. You will see what no interview reveals: a personal spreadsheet of carrier quirks, three TMS tabs open at once, a phone call to the depot to confirm when a truck was unloaded.
- Collect the constraints too. Some requirements are about how, not what. Invoice data must stay in Harbourline's own cloud account. Carriers must be paid within 30 days. Every approval needs a record of who approved it. These are non-functional requirements, and they shape the design as much as the features do.
Write each requirement so it names who needs it, what happens today, and how success will be measured.
The shortcut
Turn every request into one sentence: "so that ___, measured by ___." If you cannot fill both blanks, you have not found the requirement yet. Keep asking about real cases.
The ask
Meera: "We need AI to read our carrier invoices."
Notice that "AI" disappeared. It may still be part of the solution, but the requirement is about catching wrong charges quickly.
The trap is the leading question. "Would a dashboard help?" gets a yes from almost everyone and teaches you nothing.
Drills
Answer fast — trust the rule.
Which question will give you the most reliable information?
Meera says, "We need a dashboard." What is the best first response?
While watching a clerk, you notice she keeps a personal spreadsheet of each carrier's billing quirks. What is it?
Which of these is a non-functional requirement?
Which requirement is written best?
Remember
- Study the work, not the wish: ask about the last real case.
- Shortcut: rewrite each request as "so that ___, measured by ___".
- Trap: leading questions, and treating a requested solution as the requirement.
