This topic covers the end to end practice of clarifying ambiguous problem statements, eliciting and defining functional and non functional requirements, and scoping solutions before design and implementation. Candidates should demonstrate the ability to identify target users and user journeys, conduct stakeholder interviews, ask targeted and probing clarifying questions, surface hidden assumptions and root causes, and convert vague business language into measurable technical and business requirements. They should capture acceptance criteria and success metrics, define key performance indicators, and translate requirements into testable statements and test strategies that map unit, integration, and system tests to requirement risk and priority. The topic includes assessing technical constraints and operational context such as expected scale, throughput and latency requirements, data volume and read write ratios, consistency expectations, real time versus batch processing trade offs, geographic distribution, uptime and availability expectations, security and compliance obligations, and existing system state or migration considerations. It also requires evaluation of non technical constraints including timelines, team capacity, budget, regulatory and operational concerns, and stakeholder priorities. Candidates are expected to synthesize inputs into clear artifacts such as product requirement documents, user stories, prioritized backlogs, acceptance criteria, and concise requirement checklists to guide architecture, estimation, and implementation. Emphasis is placed on scoping and prioritization techniques, distinguishing must have from nice to have features, conducting trade off analysis, proposing incremental or phased approaches, identifying risks and mitigations, and aligning cross functional teams on scope and success measures. Expectations vary by seniority: entry level candidates should reliably ask core clarifying questions and avoid solving the wrong problem, while senior and staff candidates should rapidly prioritize requirements, anticipate critical non functional needs, align solutions to business impact, and communicate trade offs and timelines to stakeholders.
MediumTechnical
106 practiced
A client requires GDPR compliance and data residency in the EU. During scoping, what specific questions and acceptance criteria would you capture related to data storage, processing, deletion, and consent management? Include at least 10 items and how they translate into technical requirements.
Sample Answer
Situation: During scoping for an EU-GDPR + EU data residency requirement, capture the following specific questions and acceptance criteria, with each mapped to concrete technical requirements.1) Where is data stored?- Question: Which data classes must remain in the EU (PII, logs, backups)?- Acceptance: All PII and backups reside in EU zones.- Technical req: Use EU region cloud storage (e.g., eu-west-1), block cross-region replication.2) Who processes data (subprocessors)?- Q: Which third parties will access/process EU data?- Acceptance: All subprocessors approved and under EU SCCs.- Req: Maintain subprocessors list; implement contractual SCCs; deny access until approved.3) Cross-border transfer policy- Q: Is transfer outside EU allowed under any conditions?- Acceptance: No transfers without legal basis & encryption plus contractual protections.- Req: Disable egress to non-EU; if needed, enforce VPN/TLS + DPO signoff & SCCs/adequacy.4) Data classification and mapping- Q: What fields are PII/sensitive?- Acceptance: Data map completed and signed off.- Req: Metadata tagging, catalog (Glue, Atlas), apply policies by tag.5) Consent capture & provenance- Q: How/where is consent recorded and linked to records?- Acceptance: Every user record has consent timestamp, scope, source.- Req: Consent service API, immutable audit log (WORM), tie consent ID to user record.6) Purpose limitation & processing records- Q: What purposes are allowed per dataset?- Acceptance: Processing only for declared purposes.- Req: Policy enforcement layer that rejects jobs outside declared purpose; maintain processing register.7) Retention & deletion (right to be forgotten)- Q: Retention periods and deletion workflows?- Acceptance: Automatable deletion for expired/erasure requests within SLA (e.g., 30 days).- Req: TTL policies, soft-delete + secure purge, deletion audit trail, propagate to backups within SLA.8) Access control & segregation- Q: Who needs access (roles, geographies)?- Acceptance: Principle of least privilege; EU-only admin access where required.- Req: RBAC/IAM with attribute-based access, access restricted to EU IPs or bastions, just-in-time elevation.9) Encryption & key residency- Q: Are keys allowed outside EU?- Acceptance: Keys for EU data must be stored in EU HSMs.- Req: Customer-managed keys in EU KMS/HSM, enforce encryption-at-rest and in-transit.10) Logging, monitoring & DPIAs- Q: Audit/log requirements and DPIA completion?- Acceptance: Full audit trail for access/processing; DPIA approved.- Req: Centralized SIEM in EU, immutable logs, alerts for anomalous access, retention per policy.11) Backup & DR residency- Q: Backup locations and DR runbooks?- Acceptance: Backups in EU; DR runbooks comply with residency.- Req: Configure backup targets to EU regions, test failover staying within EU.12) Incident response & breach notification- Q: Notification timelines & stakeholders?- Acceptance: Notify controller/DPA within 72 hours; playbook in place.- Req: Incident runbook, automated detection/forensic snapshots in EU, escalation matrix.Translate these into acceptance tests: region-restricted storage checks, IAM policy audits, encryption key location verification, consent record presence for sampled users, successful deletion propagation tests, subprocessors contract verification, DPIA signoff, and simulated breach notification run.
EasyTechnical
69 practiced
You must produce acceptance criteria for the following KPI: 'Reduce cart abandonment rate by 15% in 90 days.' Provide a measurable acceptance criteria breakdown that an engineering and QA team can use, including baseline measurement, target measurement method, sampling, and potential A/B test design.
Sample Answer
Context & definition- KPI defined: reduce cart abandonment rate (CAR) by 15% relative in 90 days. CAR = (1 − completed_checkouts / initiated_checkouts) * 100%. Agree on event names: checkout_initiated, order_completed.Baseline measurement- Baseline period: last 30 days prior to experiment start.- Baseline value: compute CAR_baseline = 1 − Σ(order_completed) / Σ(checkout_initiated) over baseline period. Report absolute % and sample counts (N_initiated, N_completed).- Instrumentation check: events present on >99% page flows, timestamps, user/session IDs, and deduplication logic validated.Target & success criteria- Target: CAR_target ≤ CAR_baseline * 0.85 (i.e., ≥15% relative reduction) measured at day 90.- Statistical success: observed relative reduction ≥15% AND p-value ≤0.05 (two-sided) with 95% CI not crossing zero improvement.- Secondary pass/fail: conversion uplift (completed_checkouts / users) and revenue per session must not decline >2%.Measurement method- Unit: user-session (session_id). Count each checkout_initiated once per session.- Calculation window: rolling 7-day and cumulative to 90 days. Primary evaluation at day 90.- Attribution: include only organic/paid traffic channels targeted by change; exclude bots and test accounts.Sampling & power- Minimum detectable effect (MDE): 15% relative reduction. Use alpha=0.05, power=0.8. Example sample size calc for baseline CAR 70% abandonment (0.7): to detect 15% relative reduction (~0.595), need ~X sessions per arm. QA/engineering should run exact power calc; acceptance requires sample >= computed N per arm and test duration ≥7 days and covering weekday/weekend.A/B test design- Randomization: user-level random assignment (stable user_id cookie); stratify by device (mobile/desktop) and geography.- Variants: A = control (current flow), B = treatment (proposed change).- Metrics: - Primary: CAR (as defined) - Secondary: completed_checkouts, revenue per session, average order value, page load times, checkout error rate- Exposure: 50/50 split initially; consider ramp to 25/75 if risk mitigation needed.- Duration & stopping rules: run until min sample per arm met and at least 14 days elapsed, or max 90 days. Stop early only if clear negative impact on revenue (>2% decline with p≤0.01) or major errors.- Analysis: use binomial proportions test / logistic regression controlling for stratification factors. Report effect size, p-value, 95% CI, and power reached.QA & instrumentation acceptance tests- Event firing tests (unit/integration): simulate N sessions, verify checkout_initiated and order_completed counts match expected.- Data pipeline: staging -> analytics must preserve event fidelity; reconciled totals within 1% of raw logs.- Canary: deploy to 1% traffic first, monitor errors and metric drift for 48 hours.- Rollout criteria: pass canary, no increase in checkout_error_rate >0.5pp, and tracking validated.Deliverables for engineering/QA- Baseline report (value, N, time window)- Power/sample-size calculation with inputs- A/B configuration (randomization code, feature flags)- Data validation plan and test scripts- Final evaluation template with queries and significance testsIf baseline CAR is unclear, require engineering to compute and sign off baseline before experiment starts.
HardTechnical
75 practiced
Draft a short testability strategy that maps requirement criticality to test depth for a fintech product. Include how you would allocate unit, integration, contract, performance, security and chaos tests across requirements categorized as 'critical', 'important', and 'nice-to-have'.
Sample Answer
Overview: For fintech, testability must be risk-driven: map requirement criticality to depth and type of testing so high-risk financial flows get exhaustive coverage while lower-risk features get proportional effort. Below is a concise strategy with coverage targets, frequency, and responsibilities.Critical (e.g., payment processing, KYC, settlement, anti-money-laundering):- Unit: 95%+ coverage of domain logic (automated, gated). Fast local runs.- Integration: Extensive—end-to-end happy/fail paths with external adapters (banks, ledgers) in CI.- Contract: Mandatory consumer/provider contracts with external partners; run on every build.- Performance: SLA-driven load/stress tests (peak throughput, p99 latency); run nightly and before major releases.- Security: Full SAST/DAST, dependency scanning, pen-test annually and after major changes; vulnerability triage SLA (<72h).- Chaos: Targeted fault-injection on stateful services (latency, partial failures, DB partition) in staging; executed in controlled windows with rollback playbooks.Important (e.g., reporting, notifications, reconciliation):- Unit: 80–90% automated coverage for core modules.- Integration: Key path integration tests covering common failure modes; executed in CI per merge.- Contract: Required for any external API boundaries.- Performance: Smoke performance tests (throughput baselines) on release candidates.- Security: Automated scans (SAST/secret scanning); manual review for sensitive changes.- Chaos: Periodic resilience tests on non-critical times; focus on retry/backoff behaviour.Nice-to-have (UX enhancements, optional dashboards):- Unit: 60–75% where cost-effective.- Integration: Basic integration smoke tests.- Contract: Optional unless exposing APIs externally.- Performance: Baseline load tests quarterly or when feature gains users.- Security: Automated dependency and credential scans.- Chaos: Minimal — only when feature matures or impacts other services.Implementation details:- Automate and gate: enforce unit/contract/integration pass for merge to main.- Test environments: isolated CI for unit/integration; staging mimics production for perf/security/chaos.- Metrics & SLAs: test pass-rate, coverage, mean time to remediate vulnerabilities, perf SLO compliance.- Tooling examples: pytest/JUnit, Pact for contracts, JMeter/k6, OWASP ZAP/Snyk, Chaos Mesh/Gremlin.- Governance: Solutions Architect defines criticality, Security/QA own execution, product owners sign-off risk trade-offs.
EasyTechnical
52 practiced
As a Solutions Architect working with sales and product teams, explain in your own words what 'requirements elicitation and scoping' means for a client engagement. Describe the primary goals, the typical artifacts you would produce (e.g., PRD, backlog, acceptance criteria), and why getting scoping right early prevents delivering the wrong solution. Include at least three concrete examples of outputs and how they are used downstream by engineering and QA.
Sample Answer
Requirements elicitation and scoping is the structured process of uncovering a client’s real business goals, constraints, and success criteria, then translating them into a bounded, testable technical scope. Primary goals: discover what problem to solve (not just requested features), capture constraints (budget, timeline, compliance), agree on measurable acceptance criteria, and limit scope to what can be delivered reliably.Typical artifacts:- Product Requirements Document (PRD) / feature specs- Solution architecture and sequence/ER diagrams- Prioritized backlog (epics/stories) with estimates- Acceptance criteria and test cases- Statement of Work (SOW) / implementation plan- API contracts and data modelWhy early scoping matters: it prevents building the wrong thing by aligning stakeholder expectations, surfacing hidden dependencies (e.g., legacy integration, data quality), and enabling accurate cost/time estimates—reducing rework, change orders, and scope creep.Concrete examples and downstream use:1) PRD with user outcomes and success metrics — used by engineering to select architectures and by product to prioritize iterations.2) Acceptance criteria mapped to user stories — directly converted into QA test cases and automated test suites to verify delivery.3) Sequence/architecture diagrams + API contracts — used by engineers for integration design and by DevOps to provision infra; contract-driven mocks accelerate parallel development and reduce integration defects.Getting scoping right early creates a single source of truth that guides sales commitments, engineering design, and QA verification—saving time and preserving client trust.
HardSystem Design
73 practiced
A large customer expects you to support 1M monthly active users spread globally with 95% of traffic from APAC. During scoping, describe how you would determine appropriate CDN strategy, regional caching, data locality, and capacity headroom, and include measurable acceptance criteria for the CDN behavior.
Sample Answer
Requirements & constraints (clarify up-front)- 1M MAU global, 95% traffic APAC, SLAs: <200ms median page load in APAC, 99.9% availability, data residency for sensitive data in region.- Traffic profile questions to ask: requests/user/day, percent static vs dynamic, peak concurrency multiplier, upload/download sizes, write frequency (cache-invalidation needs).Sizing / capacity baseline (example calc)- Assume 1M MAU × 10 requests/user/day = 10M requests/day → avg ~116 RPS.- Apply diurnal + flash peaks: 5× peak factor → ~580 RPS global; APAC gets 95% → ~551 RPS peak.- Add headroom: target 3× buffer for autoscaling/spikes → provision for ~1.65k RPS in APAC. (Adjust with customer metrics.)CDN strategy- Multi-CDN or single large CDN with strong APAC footprint (POPs in Tokyo, Singapore, Sydney, Mumbai, HK). Use DNS-based GSLB + health checks.- Edge configuration: - Cache static assets with long TTLs (24h+), immutable asset fingerprinting. - Cache dynamic content at edge via signed cookies / tokenized cache keys where safe (stale-while-revalidate, stale-if-error). - Use Origin Shield or mid-tier POPs to reduce origin load. - Enable HTTP/2 or HTTP/3, TLS 1.3 at edge.Regional caching & data locality- Keep sensitive PII and regulated data in-region: place origins or read-replicas in APAC (AWS APAC regions or customer DCs) and use CDN edge only for non-sensitive cacheable content.- For dynamic personalized responses, use edge compute (Cloudflare Workers/Lambda@Edge) to render without leaving region when possible, or route to regional origin.- Configure CDN to respect Geo-restrictions and regional cache keys.Capacity & scaling- Autoscale origin and mid-tier based on incoming RPS, CPU, queue lengths; use concurrency/p95 latency as trigger.- Pre-warm POPs for planned campaigns; implement rate-limits and global throttling fallbacks.- Capacity headroom: maintain 3× typical peak RPS and 1.5× for long-tail growth; maintain origin offload target (see below).Monitoring, observability & runbook- Real-time dashboards: edge latency (p50/p95/p99), cache hit ratio, origin request rate, error rates (4xx/5xx), TLS handshake time, purge lag.- Alerts: cache hit ratio drop >10% from baseline; origin RPS >80% of provisioned; 5xx rate >0.3% sustained.Measurable acceptance criteria (CDN behavior)- APAC median time-to-first-byte (TTFB) ≤ 50–100 ms; p95 TTFB ≤ 300 ms.- Cache hit ratio: static assets ≥ 95%; overall edge hit ratio ≥ 85%.- Origin offload: ≤ 10% of requests go to origin under steady-state.- Availability: CDN edge availability ≥ 99.95% (regional).- Purge/Invalidate: explicit purge propagates to all POPs within ≤ 2s for soft, ≤ 15s for hard invalidation.- TLS handshake p95 ≤ 150 ms and HTTP/3 enabled where supported.- Scalability: sustain 3× peak RPS without increased p95 latency >20%.- Security: WAF blocks OWASP Top 10 with false-positive rate <1%.Trade-offs & alternatives- Multi-CDN reduces single-vendor risk and improves APAC coverage but increases operational complexity (monitoring, routing).- More aggressive edge compute reduces origin load but increases cost and testing surface.Why this approach- Matches traffic distribution (APAC-focused), maximizes user-perceived latency by placing compute and caches near users, balances data locality/regulatory needs, and quantifies capacity/headroom and acceptance criteria so success is measurable.
Unlock Full Question Bank
Get access to hundreds of Requirements Elicitation and Scoping interview questions and detailed answers.
