Consultative Discovery and Requirements Gathering Questions

Direct answer

A functional requirement says what the system does: a behaviour you can demo, such as "a user can send a message to another user". A non-functional requirement (NFR) says how well it must do it: speed, reliability, capacity, security. "The app must be reliable" is the second kind, and as written nobody can build or test it, because it has no number, no situation and no measurement point. The stakeholder (anyone with a stake in the outcome, such as the sponsor or a user) holds the missing half in their head, so you draw it out by asking what failure looks like to a user, then turn each answer into a measurable sentence.

The difference in plain terms

Think of a restaurant. Functional: the kitchen cooks and serves the dish you ordered. Non-functional: it arrives hot, within about 15 minutes, even on a Friday night. Both matter, but they are tested differently.

Getting the missing half out of a stakeholder (five questions, in order)

1. "Tell me about the last time a chat app let you down. What happened?" A story beats a definition. It reveals which kind of "reliable" they mean: lost messages, slowness, or outages.
2. "After I tap send, how long before it feels broken?" Probe the vague answer: "Two seconds? Measured from the tap to the message appearing on their screen? For most messages or every single one?" This yields a latency target with a percentile. The 95th percentile (p95) means 95 of every 100 messages are at least that fast.
3. "Can a message ever be lost, arrive twice, or arrive out of order? Which is worst?" This sets the delivery promise (the guarantee about each message: never lost, delivered at most once, delivered in order).
4. "How many people use it at once on the busiest day, and how soon could that double?" This sets capacity. Example: "About 20,000 at once on a Friday evening, maybe 40,000 after the next campaign" becomes "sustain 40,000 concurrent users with p95 under 2 seconds".
5. "If the service is down, how long can people tolerate it, and what must still be true afterwards?" This sets availability and recovery (getting back to a working state after a failure). Example: "Down at most 30 minutes, and we can lose at most a minute of messages" becomes "service restored within 30 minutes of an outage, losing no more than 1 minute of messages".

Worked example: turning "reliable" into testable sentences

Each sentence below is an acceptance criterion (a pass or fail condition the team agrees on to call a requirement done). The numbers are illustrative: the stakeholder's real answers set the real ones.

• Availability: "The send-and-receive service is available 99.9% of each calendar month, measured by a test message sent every minute." A 30-day month has 30 x 24 x 60 = 43,200 minutes, so 0.1% allows 43.2 minutes of downtime. Ask: "Is 43 minutes of downtime a month acceptable?" At 99.99% the allowance falls to 4.32 minutes, which costs more to achieve. Putting the minutes in front of the stakeholder is what makes them choose.
• Latency: "p95 of online-to-online messages appear within 2 seconds of tapping send."
• Delivery: "A message the app shows as sent is never silently dropped. If the recipient is offline, it is delivered when they reconnect."

Trade-offs and pitfalls

• Asking "do you want it fast?" always gets "yes". Ask for the failure story and the trade-off ("what would you give up for another nine of availability?"). Availability is quoted in nines: 99.9% is three nines, 99.99% four nines, 99.999% five nines. Each extra nine cuts the allowed downtime tenfold: 43.2 minutes a month, then 4.32 minutes, then about 26 seconds (25.9 exactly).
• If a stakeholder cannot give a number, record it as an assumption to confirm, not as a fact.
• Each tighter NFR costs money and time, so unpriced NFRs get over-specified.
• The line blurs: "search works" is functional, "search returns in under 1 second" is non-functional. Check that every functional line has its "how well" partner.

Direct answer

Do not reply with a plan yet. Reply with a short message that asks a handful of sharp questions (or take a ten-minute call), because the email bundles three different asks with different deadlines and one of them is hedged ("if possible"). The goal is to learn which decision the board is making, when the numbers are really due, and what each ask must show. If the sender cannot be reached in time, send the staged delivery shown below, built on stated assumptions, rather than waiting or guessing silently.

Questions, in order, with what each answer changes

1. Decision and audience: "What decision will the board make with this, and who is presenting? Which slide or page of the board pack (the bundle of reports prepared for the meeting) does this go in?" If the board (the senior group that decides company direction and funding) is deciding whether to invest more in the EU, the EU deep-dive (a detailed analysis, as opposed to a headline number) is the core and the weekly view is background. If it is a routine update, the weekly table is the core.
2. Real deadline: "Tomorrow at what time: the pack's submission deadline or the meeting itself? Is there a review step before the pack is locked?" A deadline at 9am versus 3pm decides what is feasible.
3. Definitions: "By revenue do you mean booked, invoiced or recognised revenue? Which week boundaries? Which countries are in EU, and in which currency?" Gloss: booked is signed, invoiced is billed, recognised is counted as earned when control of the goods or services passes to the customer, following the company's accounting rules (under IFRS 15 and ASC 606), and they give different numbers for the same week. A wrong definition means a board slide that contradicts finance.
4. Depth of the EU ask: "Performance against what: last year, plan, other regions? If you could say one sentence after seeing it, what would it be?" This turns "deep-dive" into one or two named comparisons.
5. Attribution: "What would channel attribution let you decide, and is it needed tomorrow?" Channel attribution means crediting each sale to the marketing or sales channel that produced it (for example, paid search versus email versus a partner), so the board can see which channels are worth funding. The "if possible" signals nice-to-have. Attribution also needs trustworthy tracking data, so check whether it exists before promising it.

If a vague answer comes back ("just the usual numbers"), probe: "Which last-quarter board slide should I match?"

What I would send (assuming I could not reach them)

"Happy to help. To hit tomorrow, here is what I can commit to: (1) weekly revenue by region as one table, using invoiced revenue and Monday to Sunday weeks, ready by 2pm tomorrow. (2) A one-slide EU headline against last quarter's plan, by end of day today. (3) Channel attribution and the full EU deep-dive after the meeting, with a date once I know the decision they feed. If any of my assumptions on definitions, the deadline or the comparison are wrong, tell me before noon tomorrow, and if the pack locks before 2pm tell me and I will bring item (1) forward."

The reply states its assumptions openly: invoiced revenue, Monday to Sunday weeks, a 2pm deadline tomorrow and last quarter's plan as the comparison. The deadline and comparison are exactly the points questions 2 and 4 ask about, so each is easy for the sender to correct in one line.

Worked reasoning for the split

In the reply above, items (1) and (2) serve a decision tomorrow and use data that likely exists already. Item (3) bundles two things that should not put tomorrow's deliverable at risk: channel attribution, which the email marked "if possible" and which needs tracking data of unknown quality, and the full EU deep-dive, which is too large for one day. The one-slide EU headline in (2) covers the board's immediate need, and the follow-up date in (3) is set once the decision they feed is known.

Pitfalls

• Saying yes to all three and delivering a rushed, unchecked deep-dive.
• Replying with a long list of questions that makes the requester do your work. Offer assumptions they can simply confirm.
• Skipping definitions, which is how two correct numbers contradict each other in front of the board.

Direct answer

I turn the target into a timed chain. I define when the clock starts and stops, measure how long each stage takes today, give each stage a share of the one-hour budget, and write each share as a requirement with a measurement point. I also ask which decision gets better with an hour, so the target serves an outcome and not only a number.

Step 1: define time-to-insight

"Day to hour" is ambiguous. Ask: does the clock start when the business event happens or when data reaches the warehouse? Does it stop when the dashboard updates or when someone acts on it? I agree: event time to the insight visible to the decision maker. The whole 60 minutes runs from event to insight. The dashboard itself should show the data earlier, once the first three stages are done (45 minutes), which leaves the last 15 minutes for the person to reach an answer.

Step 2: the current chain (illustrative breakdown of 24 hours)

Step 3: budget the 60 minutes

What replaces the 10-hour wait: instead of one nightly extract, the pipeline loads only new and changed rows every 10 minutes, so there is no nightly window to wait for. That is why ingest can fit in 15 minutes: a change waits at most 10 minutes for the next run, and a run of new rows takes about 5 minutes (to confirm on a prototype), so the worst case is 10 + 5 = 15. Loading every 15 minutes would not fit, because the wait for the next run would add to the run time and exceed the 15-minute budget. Transform fits in 20 minutes only if it processes just those new rows instead of rebuilding everything, which I would confirm by timing a prototype. The 15/20/10/15 split is a first proposal (illustrative): transform gets the largest share because it takes the most processing today, and I revise each share once I measure the real stages.

Requirements that follow

• Freshness: 95% of days, data is visible in the dashboard within 45 minutes of the source event (the first three stages), so the user keeps the last 15 minutes of the 60 to reach an answer. Measured as lag: the current time minus the timestamp of the newest event in the dashboard's table. If the newest loaded event happened at 10:42 and it is now 11:07, the lag is 25 minutes, inside the 45.
• Pipeline success rate and rerun time (a failed run must not eat the budget).
• Reconciliation (checking that the warehouse agrees with the source system): totals match within an agreed tolerance. For example, the source shows 10,000 orders for the day and the warehouse 9,990, a 0.1% gap, inside a 0.5% tolerance.
• Pre-built answers for the top recurring questions, so the last stage in the budget (the self-service answer) takes minutes instead of the analyst's four hours today.

What I measure to show it was met

Freshness lag over time, pipeline failures, and an outcome check: did the decision that needed speed change (for example, how fast was a stock or campaign problem acted on) compared with before.

Other business targets: decomposition and proof

Every target gets the same treatment: define it precisely, break it into parts, name the data that proves it.

For client-stated key performance indicators (KPIs) I drop the vendor jargon and restate each as an event, a table and a target.

Pitfalls

• Optimising the stage that is easy rather than the biggest one.
• Not asking what the faster insight is for.
• Hitting freshness while accuracy silently drops.

Direct answer

I do not pick a winner or average the three. I find the decision behind each metric, arrange them as a chain from the user's first action to business value, choose one primary metric that sits near the real outcome, and turn the other two teams' concerns into guardrails (limits that must not be crossed) and a lagging check (a metric that only moves long after the change, such as revenue per user at 90 days). The sponsor who owns the launch confirms it, and I write it down as a precise metric definition.

Steps

1. Ask each team what decision or pain sits behind its metric. Marketing needs to know acquisition works, support protects workload, finance protects return.
2. Lay the metrics on one chain: signups, then completed onboarding, then support tickets, then revenue per user. Signups alone can be inflated by sign-ups that never use the product.
3. Pick one primary metric close to value but measurable at launch: share of new signups completing onboarding within 7 days (the 7 is illustrative; I choose the window by looking at how long successful users historically took to finish). It sits nearer to value than signups because a signup is only intent, while finishing onboarding shows someone actually got started.
4. Make the others guardrails: support tickets per 1,000 new users must not rise above an agreed level. Revenue per user is a lagging indicator reviewed at 90 days, not a launch gate.
5. Get the sponsor to confirm and record it. If teams still disagree, the sponsor decides using the trade-off analysis (the side-by-side comparison in the next section).

Analysis that exposes the trade-off (illustrative numbers)

Marketing's metric favours A. Onboarding and tickets favour B. Showing this table in the room makes the choice about value, not about whose number wins.

The metric definition contract

Name, plain-language definition, formula, data source, owner, cadence, grain (the level of detail, for example per day per feature). One definition, one owner.

Other conflicts: clicks, cost versus incidents, adoption, bookings, cadence

• Clicks versus revenue: clicks are cheap and gameable (easy to inflate without creating value), so use purchases per session as primary and keep clicks as a diagnostic (a metric watched to explain movements, not to judge success).
• Registrations versus completed onboarding: the table above.
• 20% cost reduction versus 40% fewer incidents: put both in one unit by asking what an incident costs (engineer hours, refunds), or treat the cost target as primary and incidents as a guardrail. Illustrative: on a $400,000 quarterly bill a 20% cut is worth $80,000; with 40 incidents a quarter at about $4,000 each, 40% fewer is 16 fewer incidents, worth $64,000. In one unit the cost target is larger, so it is primary and incidents are the guardrail.
• Adoption versus revenue attribution: adoption means the share of eligible users who use the feature. Attribution (deciding which feature gets credit for a revenue change) needs agreed rules, or better a holdout group (users who do not get the feature) to estimate the extra revenue.
• Gross bookings versus net revenue: gross bookings are the total value of orders placed before cancellations and refunds. Net revenue is what the company keeps after refunds and discounts. Keep both under separate names, never one word "revenue" for both, with one canonical written definition.
• Product versus finance cadence and granularity: publish daily numbers labelled provisional (subject to revision), reconcile (compare and explain differences against) finance's monthly closed figures with a stated tolerance (for example, within 1%), one underlying definition.

Pitfalls

• Splitting the difference (a blended score nobody understands).
• Letting the loudest team's metric win.
• Skipping the sponsor's sign-off, so the dispute returns after launch.

Direct answer

A functional requirement says what the system does: a behaviour or capability. A non-functional requirement says how well it must do it or under what limits: speed, reliability, security, usability and similar qualities. As I listen to a stakeholder (anyone with a stake in the result) I split each sentence into the thing being done and the qualifiers attached to it. After the first conversation I produce a short written summary with both lists, the vague words that still need numbers, assumptions and open questions.

How I split while listening

• Test one: the verb (approve, download, search) is functional. The adjectives and adverbs (quickly, securely, always, on a phone) are non-functional.
• Test two: if it fails, does the system do the wrong thing (functional) or the right thing too slowly, unsafely or unreliably (non-functional)?
• Some items sit on the edge: access control can be written either way. I record it once, label it, and do not argue about the label.

Worked example (illustrative)

A stakeholder says: "Managers need to approve expense reports from their phone, even on slow hotel wifi, and we must never lose an approval."

Vague words such as "slow" and "never" become open questions: "What counts as slow wifi?" and "Is never zero lost in a year, or recoverable from a backup?"

What I produce after the first conversation

1. A one-page summary in two columns: what the system does, and how well it must do it.
2. A list of vague words with the question needed to pin each one down.
3. Assumptions and open questions, each with an owner.
4. A read-back sent within a day, asking the stakeholder to correct it.

Pitfalls

• Treating the NFR half as an afterthought: it often drives the architecture.
• Writing "fast" or "secure" into the list as if they were requirements.
• Spending the meeting arguing about classification instead of capturing both.