Consultative Discovery and Requirements Gathering Questions
Drawing out what needs to be built from stakeholders, customers, and subject-matter experts through structured questioning. Covers turning a vague request into a scoped problem with clarifying questions, preparing and running discovery meetings and workshops, active listening and probing for unstated needs, interviewing stakeholders and subject-matter experts, extracting tacit knowledge and undocumented rules, translating business goals into measurable requirements and non-functional targets, pressing vague quantitative demands (such as '99% accuracy' or 'make it faster') until they are measurable, separating functional from non-functional requirements, eliciting compliance and regulatory constraints as testable requirements, agreeing on definitions and success measures for vague metrics and goals (such as what counts as an active user), recording assumptions and open questions and deciding which unknowns to validate, reconciling conflicting inputs between stakeholders, mapping the people who hold unwritten requirements or veto power, surfacing hidden goals and undocumented dependencies, guarding against cognitive bias, adapting discovery to remote or hard-to-reach stakeholders and to different organization sizes, knowing when to stop asking and start proposing, and synthesizing findings into a shared understanding tailored to each audience. Focused on the inbound half of communication where you gather and validate information to define what to deliver. Excludes sales qualification and deal advancement, formal research study design, writing requirement documents and acceptance-criteria templates, prioritization frameworks, keeping stakeholders aligned through delivery, and governing scope changes.
A business sponsor describes the features they want for a new customer portal and says nothing about how it must perform or be protected. What do you ask to surface the non-functional requirements, and what evidence would you request for each answer?
Sample Answer
Direct answer
Features describe what the portal does. Non-functional requirements (NFRs) describe how well it must do it and under what constraints: speed, availability, security, privacy, accessibility, growth and supportability. A sponsor rarely mentions them, so I ask by category, and for each answer I request evidence that turns an opinion into a number.
Questions by category (six), the evidence to request, and a resulting requirement (illustrative)
| Category | What I ask | Evidence I request | Example requirement |
|---|---|---|---|
| Performance and load | How many customers use it, when are peaks, how fast must pages load? | Analytics from the current site, campaign calendar | Pages load in 2 s or less for 95% of views at 500 concurrent users (500 people active at the same moment, not 500 per day) |
| Availability and recovery | When must it be up? What does an hour of downtime cost? | Past outage impact, support-hours policy | Available 99.9% monthly (about 43 minutes of downtime in a 30-day month); recovery time objective (RTO) of 4 hours and recovery point objective (RPO) of 15 minutes, meaning at most 15 minutes of recent data may be lost |
| Security | What data is in it? Who may see what? | Data classification (labels such as public, internal, confidential), past audit findings | Role-based access (what a user may see follows their job role, such as support agents seeing tickets but not billing); encryption in transit (scrambled while crossing the network) and at rest (scrambled on disk) |
| Privacy and compliance | Where are the customers? What rules apply? | Legal or compliance review, contracts | Data kept only for the retention period, deletion on request |
| Accessibility and devices | Who must be able to use it, on which devices and browsers? | Customer demographics, contract or legal clauses | Meets the agreed WCAG level (Web Content Accessibility Guidelines, which define conformance levels A, AA and AAA, each stricter than the last; the requirement must name one) on current mobile and desktop browsers |
| Growth and supportability | How many users in 12 months? Who runs it afterwards? | Sales forecast, support staffing | Handles twice the launch load; alerts reach an on-call owner |
I also ask "Is there a past incident or complaint that taught you what matters here?" Real stories surface requirements that questionnaires miss.
Worked example: "the API should be more secure"
I would ask three groups of questions.
- Technical: who calls the API (internal, partners, public)? What would a breach expose? Is there a past attack?
- Legal: which rules or contracts apply, for example data protection law, payment standards, or customer security clauses? Is breach notification required?
- User-facing: how much friction is acceptable (multi-factor sign-in, session timeouts)?
A minimal control set for a first release, in priority order:
- First: authentication using a standard protocol such as OpenID Connect (a sign-in layer built on OAuth 2.0, which is itself a delegated-authorization standard: it lets an app act for a user with limited access without ever holding the user's password; OAuth 2.0 alone grants access and does not prove who the user is), a permission check on every resource (stops one customer reading another's records), and encryption in transit using TLS (scrambles traffic so it cannot be read on the way).
- Next: input validation (rejecting malformed or malicious input), rate limiting (capping calls per client per minute, which blunts password guessing and overload), and audit logs (a record of who did what and when, used to investigate incidents).
- Before launch: secrets (passwords and keys) kept out of code, and a security test.
Check that the targets agree with each other
An availability figure and a recovery time must be consistent. A 99.9% monthly target allows about 43 minutes of downtime (43,200 minutes x 0.001 = 43.2), but a recovery time objective of 4 hours is 240 minutes, so a single incident that used the full 4 hours would use up the monthly allowance about five and a half times over (240 / 43.2). The two numbers in the table are illustrative and must be reconciled with the sponsor: either the 4 hours applies only to a rare disaster and the availability target excludes it, or a 4-hour recovery is acceptable and the honest availability target is about 99.4% (240 / 43,200 is 0.56% downtime), or the recovery time must shrink to well under an hour. Asking the sponsor which of these is true is exactly the kind of question that surfaces a real requirement.
What I write down
Each requirement with a number, a measurement or verification method, an owner, and anything still unknown flagged as an open question. For the security and privacy rows in the table the "number" is a checkable condition rather than a figure, for example every endpoint refuses plain HTTP, or deletion requests are completed within an agreed number of days, and an owner and a verification method (a scan, an audit, a test) are added to each row before it counts as written down.
Pitfalls
- Accepting "secure" or "scalable" as written.
- Asking only IT, when legal and support hold the other half.
- Promising numbers before baseline data exists.
A client wants to 'cut time-to-insight from a day to an hour.' How do you turn that business target into concrete requirements for the system, and what would you measure to show it was met?
Sample Answer
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)
| Stage | Hours today |
|---|---|
| Waiting for the nightly extract window | 10 |
| Extract and load | 2 |
| Transformations | 6 |
| Dashboard refresh and caching | 2 |
| Analyst finding or building the answer | 4 |
| Total | 24 |
Step 3: budget the 60 minutes
| Stage | Budget (minutes) |
|---|---|
| Ingest (source change visible in the warehouse) | 15 |
| Transform | 20 |
| Dashboard refresh | 10 |
| Self-service answer for the user | 15 |
| Total | 60 |
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.
| Target | Decomposition | Data and proof |
|---|---|---|
| Trial-to-paid conversion | Trial started, plan chosen, payment succeeded | Events such as trial_started and payment_succeeded joined to a subscriptions table; funnel (the count of users reaching each step in order, showing where they drop off) by cohort (group of users who started in the same week) |
| Cut checkout drop-off by 20% | Ask: 20% relative or in percentage points? If 600 of 1,000 shoppers who start checkout leave today (60%), a 20% relative cut gives 60% x 0.8 = 48%, which is 12 points; a 20-point cut would mean 40% | Discovery questions: at which step, why (payment errors, shipping cost), verified with session data, then an A/B test (show half of users the change and half the old version, then compare) |
| Improve retention | Retention by cohort, with a guardrail (a metric that must not worsen, such as support tickets) | Cohort tables plus the guardrail trend |
| Grow annual recurring revenue (ARR) by 5% | New plus expansion (existing customers paying more) minus churn (revenue lost to cancellations). Illustrative: on $10M ARR, 5% is $500k, for example $600k new + $300k expansion - $400k churn | One experiment per driver, each with a named metric |
| "Improve onboarding" | Testable hypothesis (a specific guess that data can prove wrong): cutting setup from 7 steps to 4 raises the share completing a first project within 7 days | Instrument each step, run an A/B test |
| ML project (machine learning) | Business level (fewer churned customers), product level (offers sent to the riskiest users), model level (precision and recall at a threshold, response time). At a threshold means the model flags users whose risk score is above a cutoff. Precision is the share of flagged users who really would churn; recall is the share of all churners that got flagged. Illustrative: 100 users flagged and 40 of them churn gives precision 40%; if 200 users churn in total, recall is 40/200 = 20% | A chain showing how a model gain lifts product action and then the business goal |
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.
You accept an ambiguous request and cannot get answers right now. How do you keep track of what you are assuming, and how do you stop assumptions from quietly turning into requirements?
Sample Answer
Direct answer
I keep a written assumptions register that the stakeholders can see, give every assumption an owner, a way to test it and a review date, and label everything I deliver with the assumptions it rests on. An assumption becomes a requirement only through explicit confirmation by a named person, never through silence or because I built on it.
The register (one row per assumption)
| Field | Purpose |
|---|---|
| ID | So code, documents and emails can refer to it |
| Assumption | One plain sentence |
| Why I assumed it | Source or reasoning |
| Confidence | High, medium or low |
| Impact if wrong | Cost of being wrong |
| How to test | The cheapest check |
| Owner and test-by date | Who confirms, and when |
| Status | Open, confirmed, rejected or expired |
Worked example: weekly revenue ETL (extract, transform, load: moving and reshaping data on a schedule)
| ID | Assumption | Confidence | Impact if wrong | Test | Owner and test-by date |
|---|---|---|---|---|---|
| A1 | "Revenue" means net of refunds | Low | High: totals differ from finance | Ask finance for the written definition | Finance lead, Wednesday |
| A2 | The week runs Monday to Sunday in UTC | Medium | Medium: boundary orders shift week | Compare with the finance calendar | Finance analyst, Thursday |
| A3 | Foreign currency uses the rate on the order date | Low | Medium | Ask finance; recompute one week | Finance lead, Wednesday |
| A4 | Late orders are restated into the original week (an order placed on Sunday but recorded on Monday is counted in the week it was placed, which changes a total already published) | Medium | Medium | Ask the report owner | Report owner, Friday |
| A5 | Missing marketing spend is spread evenly over days until invoices arrive | Low | Low: only the estimate label and back-fill change | Compare with the first invoices | Marketing ops, next invoice date |
Ordering rule: attack low confidence and high impact first. Marketing spend data missing? I state an assumption (A5 above: spend is spread evenly over days until invoices arrive), label the output "estimate", and plan to back-fill actuals (replace the estimate with the real figures once invoices arrive) and publish a difference report (a short table of estimate versus actual for each week, so readers see how far off the estimate was).
How I stop assumptions turning into requirements
- Every deliverable carries the line "based on assumptions A1 to A5, unconfirmed".
- Confirmation is recorded with a name and a date in the register.
- Each row has an expiry date: unconfirmed by then means it is escalated, not forgotten.
- In code or config I tag the assumption ID, so it can be found when it is replaced. For example, a comment above the SQL:
-- A1 (unconfirmed): revenue = gross amount minus refunds. - I use the register in negotiation: "Delivery by Friday is possible if A1 and A3 are confirmed today. Otherwise I deliver on stated assumptions and the risk is yours to accept in writing."
Techniques to surface hidden assumptions
| Technique | Finds |
|---|---|
| Ask "what would have to be true for this to work?" | Preconditions |
| Walk the data from source to report | Missing steps |
| Look for words like all, every, always, never | Unchecked absolutes |
| Ask "what happens when this is missing?" | Edge cases |
| Inspect a real sample | Data that disagrees with the story |
Turning interviews into a ranked list: collect every assumption heard, rate confidence and impact, and test the low-confidence, high-impact ones first.
Business stakeholders cannot talk in terms of latency or recovery objectives, yet you need numbers. How do you draw those numbers out of them, with examples or analogies, and what do you do when they simply cannot give any?
Sample Answer
Direct answer
I stop asking for numbers and ask about consequences, stories and choices, then I turn what I hear into a number myself and ask them to confirm it. Business people can answer "what happens if this is unavailable on Monday at 9am?" even when they cannot answer "what is your recovery time objective?". If they truly cannot give any numbers, I propose labelled assumptions with options and prices, get a named owner to accept one, and schedule a point at which we validate it with real data.
Terms in plain language
- Disaster recovery (DR): restoring the service after a major failure, such as losing a data centre.
- Latency: how long a user waits for a response (page loads, report refreshes).
- RTO (recovery time objective): how long the business can be without the service after a failure.
- RPO (recovery point objective): how much recent data the business can afford to lose, measured as time (re-keying the last 4 hours of work).
- SLA (service-level agreement): the promise made to users, such as uptime or refresh deadlines.
Techniques to draw numbers out
- Ask for a story: "Tell me about the last time this system was down. What did people do? When did it start to hurt?" The point where it hurt is the RTO.
- Use an analogy: "If the shop is closed, how long before customers go elsewhere? RPO is how many hours of till receipts you can afford to re-enter by hand."
- Use a deadline: "When must the finance report be ready, and what happens if it is late by an hour?" That gives a refresh window.
- Offer a menu with a price tag: "Restoring from last night's backup is cheap and takes hours. Keeping a warm copy (a scaled-down running copy of the system in a second location) is dearer and takes minutes. Which fits?" People choose between options better than they invent figures.
- Ask about peaks: month-end close (the days when the finance team finalises the books), campaign launches, payroll day.
How answers map to designs (multi-region recovery)
AWS's disaster recovery guidance lists four strategies, from cheapest and slowest to costliest and fastest: backup and restore, pilot light (data replicated, application servers switched off), warm standby (a scaled-down working copy always running), and multi-site active/active (several regions serving traffic). A tolerance of hours for both RTO and RPO points to backup and restore. Minutes of tolerance points to pilot light or warm standby. Near-zero tolerance points to active/active, with its cost and complexity, and I make sure the stakeholder sees that price. As a rough working rule (illustrative, to be confirmed with real costs): about 4 hours or more is the "hours" band, somewhere between a few minutes and an hour is the "minutes" band, and anything under a few minutes is the active/active band. Between about 1 and 4 hours is a grey zone where either an automated, rehearsed restore from backup or a pilot light can fit, so I ask what the extra hours are worth and show the price of both. The four strategy names are worth knowing; interviewers rarely expect exact prices.
Artifact: translation table (illustrative targets)
How one row is reached: the stakeholder says "it can't go down". I ask what a 4-hour outage costs at month-end versus a Sunday. Suppose they answer: "At month-end finance cannot close the books; on a Sunday nobody notices until Monday." Then the month-end close job takes, say, 3 hours to rerun inside a 5-hour window, so only 2 hours of outage can be absorbed, and I propose a 1-hour RTO in that window to keep a margin, with 4 hours the rest of the time. A 1-hour RTO points to warm standby rather than backup and restore, and I show the extra cost before they sign.
| What they said | My probe | Resulting target |
|---|---|---|
| "Reports must be fresh" | Fresh for whom, by when? | Dashboard data refreshed by 07:00 on business days |
| "Finance KPI can't be wrong" | What if a load fails halfway? | Failed ETL (extract-transform-load) run rolls back; last good figures stay visible and are labelled with their timestamp |
| "It can't go down" | What is the cost of a 4-hour outage at month-end vs a Sunday? | RTO 4 hours (24x7), tightened to 1 hour in the close window |
| "Incidents must be communicated" | Who needs to know, and how fast? | Status notice to report owners within 30 minutes of an outage |
Owners and measurement points for the table above (illustrative): refresh by 07:00 is owned by the data platform lead and measured as the timestamp of the last successful load, checked each business day at 07:00; the rollback behaviour is owned by the ETL owner and measured by a test that forces a mid-run failure and checks that the last good figures and their timestamp stay visible; the RTO targets are owned by the service owner who accepted the price, and measured in a recovery drill with a stopwatch from declared outage to service restored; the 30-minute notice is owned by the incident lead and measured from the alert time to the sent-notice time in the incident log.
Multi-tenant analytics platform (one platform serving several customers)
A tenant is one customer organisation using the shared platform. Ask: how isolated must each tenant's data be (shared tables with row filters, meaning one table where every row carries a tenant ID and every query is filtered to the caller's tenant, or separate databases)? Who pays for what (cost allocation by tenant, meaning splitting the cloud bill among customers using tags, labels on resources that say which tenant they serve)? What growth in tenants and data volume is expected in a year?
Example (illustrative). Stakeholder: "Two bank customers will not accept shared tables, the rest do not mind." Resulting assumptions list:
- The two regulated tenants get separate databases; the other tenants share tables with row filters.
- Isolation test: query as tenant X and expect zero rows belonging to tenant Y.
- Every resource carries a tenant tag, and the monthly bill is split by tag.
- Assume 20 tenants now and 60 in a year; revisit the design at 40.
If they cannot give any numbers
Offer a default, say "I am assuming RTO 4 hours and RPO 1 hour until you tell me otherwise", show the cost of the tier above and below, and get a named person to accept it. Validate against evidence: past incident logs, support tickets from the last outage, actual usage by hour. Revisit when we have a measured baseline.
Pitfalls
- Leading with jargon, or accepting "as fast as possible".
- Writing the target without an owner or a measurement point.
- Assuming the stakeholder's silence means no requirement.
A compliance expert carries rules in their head that determine how a report must be built, and none of it is written down. How do you get that knowledge out and confirm you have it right?
Sample Answer
Direct answer
People rarely recall unwritten rules when asked "what are the rules?", because the rules have become habit. I would get them out by working from real cases: ask the expert to walk through the last report they built, ask where it went wrong or got rejected, and test my understanding with examples. I confirm by predicting outcomes on cases the expert has not seen, and by checking against a written source or a second person.
Steps
- Prepare. Read what exists: the regulation text, past reports, audit findings. Ask for a past report and its review comments.
- Walk a real case, thinking aloud. "Show me how you built the March report. What did you check first? What do you do when a number looks wrong?" Watching beats asking.
- Ask about exceptions and failures. "When was a report last sent back? What was wrong?" Failures reveal the rules that are not written down.
- Use scenario questions. "If an account was closed on the 29th, does it appear?" and "What would make you reject this row?"
- Write each rule as a testable statement (a rule precise enough that a sample record clearly passes or fails it) and read it back.
- Validate with examples. Give the expert 8 to 10 sample records, ask them to predict whether each is included, then run my draft logic and compare. A mismatch means I missed a rule.
- Cross-check. Compare to the policy text or ask a second person (an auditor or another analyst) the same cases.
- Get sign-off on the rule list, with a named owner for changes.
Worked example (illustrative)
Rule as first stated: "Exclude closed accounts." After walking the last report, the expert reveals: "Unless closed less than 30 days ago, or the account is under dispute." Rewritten as a testable rule, reading "closed less than 30 days ago" literally: "Exclude accounts closed 30 or more days before the reporting date, unless the account carries a dispute flag." Test case: account closed 12 days ago, no dispute: included. Closed 45 days ago, no dispute: excluded. Closed 45 days ago, under dispute: included. The expert confirms two of the three and corrects the third (dispute accounts are included only until the dispute closes). So far the rules are: (1) exclude accounts closed 30 or more days before the reporting date (my first draft, revised by rule 4 below); (2) a dispute flag overrides that exclusion; (3) the override lasts only until the dispute closes. A fourth rule emerged only because I tested a boundary case: an account closed exactly 30 days before the reporting date, no dispute. My draft excluded it. The expert said it stays in, because the cut-off is "more than 30 days", counted in calendar days from the closure date. Rule 4: an account closed exactly 30 days ago is still included, and exclusion starts at 31 days, so rule 1 now reads: exclude accounts closed more than 30 days before the reporting date. Tracing it again: closed 30 days ago, no dispute, included; closed 31 days ago, no dispute, excluded.
Probing a vague answer
"It depends" is the signal. Reply: "Depends on what? Give me the last time it went each way."
Trade-offs and pitfalls
- One interview rarely suffices. Plan two or three short sessions.
- Do not lead: "Is it 30 days?" gets a polite yes. Ask "What is the cut-off, and how do you know?"
- The expert may be wrong or out of date. That is why the second source matters.
- Without sign-off, a rule is a guess. Keep a log of rules with the date confirmed and by whom.
- Dependence on one person is a risk in itself. Part of the output is a written rule book for everyone.
Unlock Full Question Bank
Get access to all 16 Consultative Discovery and Requirements Gathering interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.