Technical and Business Requirement Discovery Questions
Ability to dig beneath surface requirements to understand true business problems, technical constraints, and success criteria. Asking insightful questions that help customers clarify their own thinking. Discovering hidden objectives and constraints that affect deal strategy.
MediumTechnical
78 practiced
Customer goal: 'reduce fraud'. Walk through how you would decompose this objective into measurable business outcomes, required data sources and signals, short-term vs long-term discovery experiments, and initial success criteria that can be validated within a sales cycle.
Sample Answer
High-level decomposition- Business objective → measurable outcomes → signals/data → experiments (short vs long) → success criteria validated in a sales cycle.Measurable business outcomes (examples, tied to revenue/ops):- Reduce fraud losses: % decrease in fraudulent chargebacks or reimbursed amount (target e.g., −30%).- Improve detection quality: increase precision at top-k (precision@100) or true positive rate (TPR) at fixed false positive rate (FPR).- Reduce operational cost: % drop in manual review volume and time per case (target e.g., −40% reviewers).- Minimize customer friction: false positive rate or customer repudiation rate below threshold.- Time-to-detect: median detection latency (minutes/hours).Required data sources & signals- Internal: transaction logs, payment authorization results, chargeback/ dispute outcomes (labels), customer account history, device fingerprints, session logs, IP/geolocation, order velocity, refund/return patterns.- Identity: KYC/ID verification results, email/phone verification status.- Behavioral: mouse/touch patterns, session timing, browsing patterns.- Platform/network: proxy/VPN indicators, ASN, browser headers.- Third-party: fraud scoring providers, sanctions/AML lists, payment network signals (AVS/CVV results), credit bureau.- Derived signals: velocity features, device churn, graph features (shared devices/emails), risk scores.- Engineering: fresh timestamps, streaming event bus (Kafka), raw + enriched data lakes, event retention & labeling pipeline.Short-term (discovery) experiments (fast to run during sales/pilot)- Rule-based pilot and shadow mode: implement conservative, explainable rules (velocity, blacklist) in parallel (shadow) to measure potential catches without blocking. Duration: 2–4 weeks.- Feature-flagged A/B on low-risk traffic: block vs monitor to measure lift and FP rate.- Lightweight classifier using existing features (logistic regression) trained on historical labeled chargebacks; deploy in shadow to estimate precision/recall. Duration: 3–6 weeks.- Metrics: compare predicted fraudulent amount, recall on known chargebacks, manual-review reduction potential.Long-term experiments / investments- Graph-based link analysis to detect rings/organized fraud (iterative; 2–6 months).- Behavioral biometrics and device fingerprinting improvements (integration + ML models).- Online learning / streaming scoring with real-time feature stores to reduce latency.- Ensemble/ML ops: retraining cadence, feedback loops from dispute outcomes, model explainability.Initial success criteria (validated within a sales cycle, e.g., 30–60 days)- Data readiness: ≥ X months of labeled chargeback history ingested and queryable; streaming latency < Y seconds for real-time signals.- Shadow-mode lift: predicted fraud amount caught in shadow >= 20% of historical fraud in pilot subset with FP rate < predefined business tolerance.- Manual-review reduction: model+rules can auto-decline or auto-accept a segment reducing manual reviews by ≥ 25% while maintaining dispute win rate.- Precision@k / ROC: precision@top 500 > baseline + 15% OR TPR at fixed 1% FPR increases by ≥ 20%.- Business ROI: projected monthly prevented fraud $ > cost of solution within N months (payback within sales cycle projection).Validation methodology (practical, sales-oriented)- Use holdout window from recent historical labels and run models and rules in shadow against live traffic to measure lift and FPs.- A/B test on a small percentage with rollback/revert capability; measure chargebacks, customer complaints, conversion impact.- Statistical thresholds: require p<0.05 for primary metric improvement or Bayesian sequential testing during pilot.- Provide clear dashboards: weekly KPIs, confusion matrix, precision/recall over time, blocked amount vs false positives.Architecture & integration notes (Solutions Architect lens)- Design minimally invasive integrations: ingest payment webhook, Kafka topic, or batch CSV depending on client maturity.- Two-path architecture: fast-path rules + real-time scoring (API/edge) and batch ML retraining pipeline (feature store, model registry).- Privacy/compliance: PII minimization, retention, consent; align to PCI/ GDPR.- Observability: logging, explainability for declines, audit trails for disputes.- Rollback and SLA: feature flags, canary rollout, latency SLAs for scoring (<50–200ms depending on product).Trade-offs & next steps for sales- Conservative short-term rules reduce risk but give limited lift; ML gives higher lift but needs labeled feedback.- Propose a 30–60 day pilot: data ingestion + shadow scoring → measurable dashboard → A/B for safe blocking. Deliverables: KPI baseline, pilot results, production integration plan, ROI projection.This plan translates “reduce fraud” into quantifiable outcomes, clear signals, staged experiments deliverable during a sales cycle, and technical architecture that supports quick validation and safe rollout.
HardTechnical
61 practiced
Procurement demands a lower price but core non-functional requirements cannot be reduced. Describe negotiation tactics and trade-offs you might offer (for example: phased features, extended T&M for non-core items, training and handover), and explain how you would document concessions to protect engineering and future deliverables.
Sample Answer
Situation: Procurement is pushing for lower cost but our non-functional requirements (NFRs) — availability, security, latency, compliance — cannot be compromised.Approach / Negotiation tactics:- Prioritize scope by business value: propose a must-have / nice-to-have split where all core NFRs remain for must-haves; lower-cost options apply only to lower-value UX or reporting features.- Phased delivery: deliver an initial Minimum Viable NFR-compliant phase (core flows + full NFRs). Defer lower-priority features to later phases with separate budgets.- Fixed-price for core NFR work + extended T&M for non-core items: protects engineering from underestimation while giving procurement cost control for optional work.- Reduce one-time costs: offer longer amortization (spread implementation over milestones), or trade for commercial concessions (longer contract term, faster payment).- Efficiency levers: reuse existing components, reduce customizations, adopt vendor-managed services for non-core functions to lower cost without touching NFRs.- Offer optional training/handover packages as T&M or capped-cost line items; basic training included, advanced as paid add-on.Documenting concessions and protections:- Update Statement of Work (SOW) and Master Services Agreement with explicit deliverables, acceptance criteria tied to NFR metrics (SLA numbers, test cases), and which features are deferred to later phases.- Add a Concessions Log / Decision Register recording: requested change, rationale, agreed trade-off, impact on schedule/cost/risk, owner, and expiry (who can reverse).- Include a Risk Register mapping concessions to residual risk and mitigation actions.- Use change-control process: any re-scope must pass formal Change Request with engineering estimate and procurement sign-off.- Define rollback and warranty terms, performance-based milestones, and liquidated damages or credits for NFR breaches to protect business value.Why this works:- Keeps core technical guarantees intact, gives procurement flexibility on cost, and creates auditable trail so engineering isn’t exposed to scope creep or unpriced risk.
EasyTechnical
73 practiced
Explain the difference between open-ended and closed questions in discovery. For an e-commerce checkout redesign, provide three open-ended and three closed questions you would ask product and engineering to surface assumptions, constraints, and acceptance criteria.
Sample Answer
Open-ended vs closed questions — difference:- Closed questions elicit short, specific answers (yes/no, a number, a choice). They’re great for confirming facts, constraints, or acceptance criteria.- Open-ended questions invite explanation, context, motivations, and uncover assumptions or hidden needs. They’re ideal in discovery to generate insights, trade-offs, and risks.For an e‑commerce checkout redesign, here are examples and why I’d ask them.Open-ended (to surface assumptions, user journeys, nonfunctional needs):1. “Walk me through the edge-to-edge checkout flow you expect a first-time customer to experience — what decisions, errors, and integrations matter most?” — uncovers assumptions about UX, integrations (payments, fraud), and error handling.2. “What business metrics or customer behaviors are we trying to change with this redesign and why?” — surfaces success criteria, priorities, and product assumptions.3. “Describe any regulatory, security, or performance concerns you’ve had in production or heard from customers.” — reveals constraints (PCI, GDPR), risk tolerance, and latency expectations.Closed (to confirm constraints and acceptance criteria):1. “Do we require PCI DSS Level 1 compliance for all card data processing in this project?” — confirms a hard compliance constraint.2. “Is the target page load time under 300ms for the checkout entry point?” — sets a measurable performance acceptance criterion.3. “Will we support guest checkout in the initial release (yes/no)?” — fixes scope and downstream architectural decisions.Use open questions first to explore context and assumptions, then closed questions to lock down constraints and acceptance criteria for the architecture.
MediumTechnical
60 practiced
Explain the MoSCoW and RICE prioritization frameworks and common situations when each is preferable. Using RICE, show an example calculation for three candidate features from an initial discovery backlog, and explain the assumptions behind your scores.
Sample Answer
MoSCoW and RICE are complementary prioritization frameworks serving different needs.MoSCoW (Must, Should, Could, Won’t) is a qualitative, stakeholder-driven method:- Must: non-negotiable (legal, security, core functionality)- Should: important but can be deferred- Could: nice-to-have- Won’t: out of scope nowUse when requirements are fuzzy, you need rapid alignment with stakeholders (sales, customers, engineering) or during negotiation of scope for an SOW/PoC. As a Solutions Architect, MoSCoW helps separate mandatory technical constraints (e.g., compliance, API compatibility) from nice-to-haves during proposal discussions.RICE (Reach, Impact, Confidence, Effort) is quantitative and useful for comparing many initiatives:- Reach: how many users/events in a time window- Impact: relative benefit per user (e.g., 3=massive, 0.5=small)- Confidence: % confidence in your estimates- Effort: total person-months (or person-weeks)RICE score = (Reach × Impact × Confidence) / Effort. Prefer RICE when you have metrics or discovery data and need objective trade-offs, e.g., sizing backlog items for a roadmap or deciding which features to include in a demo for a specific account.Example — three candidate features from discovery (quarterly window):1) SSO integration- Reach = 10 enterprise clients- Impact = 3 (high: enables sale)- Confidence = 0.8 (well-understood)- Effort = 2 person-monthsRICE = (10×3×0.8)/2 = 122) Advanced reporting dashboard- Reach = 200 users (admins + power users)- Impact = 1.5 (moderate)- Confidence = 0.6 (some unknowns in data model)- Effort = 3.5 person-monthsRICE = (200×1.5×0.6)/3.5 ≈ 51.43) Performance optimization (DB indexing + caching)- Reach = all 5,000 daily users- Impact = 2 (improves retention, reduces complaints)- Confidence = 0.7 (profiling data exists)- Effort = 4 person-monthsRICE = (5000×2×0.7)/4 = 1750Interpretation and assumptions:- Reach measured in affected users/events in quarter; if sales-driven (SSO) we measured potential closed deals.- Impact is relative and domain-specific; I calibrated on 0.5–3 scale.- Confidence reflects quality of discovery data: requirements, benchmarks, stakeholder alignment.- Effort includes design, implementation, testing, and deployment.As a Solutions Architect, combine RICE scores with MoSCoW constraints: e.g., SSO might be a Must for a target customer even if RICE is lower. Use RICE to rankable backlog and MoSCoW to enforce non-negotiable technical or contractual items.
MediumTechnical
60 practiced
How would you capture non-functional requirements for multi-region availability and recovery objectives (RTO/RPO) during discovery? Provide a template of questions, types of expected answers, and explain how those answers map to architectural patterns such as active-active, geo-replication, and backup strategies.
Sample Answer
Approach: Capture non-functional requirements by asking targeted discovery questions that quantify availability, RTO/RPO, data consistency, traffic patterns, failover automation, and cost/complexity tolerance. Use answers to map to architectural patterns (active-active, geo-replication, backups) and trade-offs.Discovery question template (question → expected answer types → architectural mapping / implications):1) What is the required Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for the system or each data class?- Expected: RTO in seconds/minutes/hours; RPO in seconds/minutes/hours; per-data-class (e.g., transactional vs. logs).- Mapping: RTO ≤ minutes + RPO ≤ seconds → active-active with synchronous or semi-sync replication and automatic failover. RTO hours + RPO hours → backups/restore or async geo-replication acceptable.2) What availability (SLAs/uptime %) and acceptable single-region outage scenarios?- Expected: % uptime (e.g., 99.99%), tolerance for degraded mode.- Mapping: >99.99% and zero tolerance for region loss → active-active across regions with load balancing and health checks. 99.9% → active-passive or geo-replication with warm standby.3) Which components are stateful vs stateless? Which data must be strongly consistent?- Expected: list of services (stateless app servers, stateful DBs, caches) and consistency needs.- Mapping: Strong consistency → use regional primary or distributed databases with consensus (spanner-like) or leader election; eventual consistency → async geo-replication, multi-master with conflict resolution.4) What is peak and steady-state traffic per region and cross-region latency tolerance?- Expected: TPS, bandwidth, latency budget (ms).- Mapping: High global traffic + low latency → active-active with regional routing (DNS load balancing/CDN) and data partitioning. Low traffic → cold standby or replication.5) What are RTO/RPO priorities by data criticality and cost constraints?- Expected: prioritize core transactions vs. analytics; budget for multi-region.- Mapping: High-criticality + budget → cross-region synchronous replication or distributed transactional stores. Cost-sensitive → snapshots, async replication, or backup+restore.6) How should failover be triggered (automatic vs manual) and what orchestration is acceptable?- Expected: automatic immediate, or manual after validation.- Mapping: Automatic → need health checks, leader election, global load balancer. Manual → simpler warm-standby with runbooks.7) Compliance, data residency and regulatory constraints?- Expected: region restrictions, encryption at rest/in transit requirements.- Mapping: Data residency may prevent active-active across regions → geo-replication with region-specific primaries or application-level data partitioning.8) Backup/Retention and restore testing requirements?- Expected: retention windows, point-in-time recovery needs, test cadence.- Mapping: RPO tolerates hours/day → regular backups + tested restore. RPO seconds/minutes → near-real-time replication + transactional logs.Example mapping summary:- Active-active: chosen when low RTO/RPO, global low-latency access, and budget allow; requires distributed consensus, conflict resolution, global LB.- Geo-replication (async): good for moderate RTO/RPO and cost sensitivity; may accept data lag and eventual consistency.- Backup + restore: for high RTO/RPO tolerance, cheapest; rely on tested runbooks and longer recovery.Use answers to produce an SLA matrix (component × RTO × RPO × pattern), cost estimate, and a runbook for failover. Validate with recovery drills and measure actual RTO/RPO in a proof-of-concept.
Unlock Full Question Bank
Get access to hundreds of Technical and Business Requirement Discovery interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.