Consultative Discovery and Requirements Gathering Questions
Eliciting needs, requirements, and context through structured questioning and interviewing. Covers asking effective clarifying and scoping questions, conducting stakeholder or subject-matter-expert interviews, extracting tacit knowledge, and synthesizing findings into requirements. Focused on the inbound discovery half of communication where you draw information out of others.
After a discovery session how do you quickly verify stakeholder alignment? Describe two practical techniques (for example: annotated summary email, alignment workshop) and provide a three-bullet example email summary you would send to confirm shared understanding and next steps.
Sample Answer
Situation: After a multi-stakeholder discovery session for a cloud migration, different attendees left with slightly different priorities (cost vs. speed vs. compliance). Task: As the Solutions Architect supporting pre-sales, I needed to quickly confirm everyone was aligned so the proposal reflected the agreed scope.
Action:
- Technique 1 — Annotated summary email: I send a concise, annotated recap within 24 hours that lists key decisions, assumptions, open questions, and proposed next steps. Each item tags the responsible stakeholder and a deadline for confirmation. This creates a written record and forces a yes/no/correct response quickly.
- Technique 2 — 30‑minute alignment workshop: If replies are mixed or there are >2 unresolved issues, I run a focused 30-minute workshop with a short agenda: review divergences, decide alternatives using a decision matrix (impact vs. effort), capture outcomes in real time, and confirm owners. This gets live consensus and updates the proposal immediately.
Result: Using the email first, 80% of items were confirmed within 12 hours; the 30‑minute workshop resolved the remaining issues and accelerated signing by one week.
Example three-bullet summary email to confirm shared understanding and next steps:
- Agreed scope: Migrate 120 VMs to AWS over 3 phases (Phase 1: 40 VMs — app servers; Phase 2: DB replication; Phase 3: cutover). Assumption: no major app refactor required. Please confirm or correct by EOD Tue.
- Open items & owners: Backup retention SLA (John) — propose 90 days; Security scanning cadence (Priya) — propose weekly. Please confirm or propose alternatives by Thu.
- Next steps: I’ll produce an updated high-level architecture diagram and cost estimate by Fri; schedule 30-min alignment call if any item remains unconfirmed.
During discovery a client states: "We must keep the existing legacy database." How would you surface additional technical and business constraints (schema access, versioning, support windows, licensing), what clarifying questions would you ask to determine impact, and how would that constraint change your preferred architecture options and the project's risk register?
Sample Answer
Situation: During discovery the client insists "We must keep the existing legacy database." My goal is to surface hidden constraints, quantify impact, and adapt the architecture and risks accordingly.
How I'd surface constraints (process + artifacts)
- Request documentation and run workshops with DB admins, app owners, and business stakeholders.
- Ask for read-access to schema, sample data, data dictionary, ER diagrams, and current integration points.
- Run lightweight discovery—connectivity tests, explain plan / profiling, and a vendor/license review.
- Produce a constraints checklist and circulate for sign-off (schema access, read/write patterns, SLAs, maintenance windows, versioning, backups, licensing, support contacts).
Clarifying questions to determine impact
- Technical:
- What DB engine and exact version? Any planned upgrades?
- Do we have read/write access or only via application APIs?
- Are there stored procedures, triggers, or non-standard types we must preserve?
- What's the expected QPS, peak load, and latency requirements?
- Which integrations depend on the DB and how are data contracts managed?
- Business/operational:
- Why must it be kept (regulatory, budget, business continuity)?
- What are permitted change windows and rollback expectations?
- Who owns support/patching and what SLAs exist?
- Licensing constraints or expiry dates?
- Retention, encryption, and compliance requirements?
How the constraint changes architecture options
- Prefer integration/strangling approaches rather than full migration: build an API/adapter layer to encapsulate legacy behavior.
- Use a canonical data model and change-data-capture (CDC) or read-replicas if near-real-time sync is needed.
- Avoid designs that require refactoring internal schemas; prefer anti-corruption layer, façade services, or middleware to translate between new services and legacy schema.
- If write-heavy and latency-sensitive, consider caching, CQRS (read model derived into new store) or staged migration with dual-writes only if risk acceptable.
- Cloud-native managed DB options are limited; might need hybrid architecture with secure network connectivity (VPN/Direct Connect) to on-prem DB.
Changes to the risk register (examples)
- Risk: Unknown schema complexity → Mitigation: Early schema audit, sample data profiling; Contingency: Allocate buffer sprint.
- Risk: No direct write access / limited APIs → Mitigation: Build adapter layer; Contingency: Adjust scope for functionality gaps.
- Risk: Vendor/licensing prevents replicas or exports → Mitigation: Legal/vendor review; Contingency: Budget for license workarounds or procurement.
- Risk: Performance bottleneck at legacy DB under new load → Mitigation: Load testing, caching, read-replicas; Contingency: Throttle features, phased rollout.
- Risk: Limited maintenance windows → Mitigation: Nightly batch syncs, deploy zero-downtime patterns; Contingency: Extended timeline and careful release windows.
Result: With these actions I deliver a clear decision map for architecture—showing low-risk integration-first options, when migration becomes necessary, and quantified risks/costs so stakeholders can decide with full technical and business context.
You must align stakeholders across regions with conflicting P&Ls and objectives. Describe a multi-step discovery strategy to reconcile priorities, quantify ROI for each region, and produce an executive recommendation that supports a single solution architecture.
Sample Answer
Step 1 — Clarify scope & stakeholders
- Identify regions, P&L owners, decision-makers, KPIs, timelines, and technical constraints.
- Run 30–60 minute intake calls to capture objectives, must-haves, pain points, and existing architectures.
Step 2 — Discovery workshops (regional)
- Facilitate structured workshops per region using the same agenda: business goals, cost drivers, data flows, compliance, performance SLAs, and migration risk.
- Capture quantitative inputs: current spend (infra, ops, licensing), revenue attribution, projected growth, and qualitative constraints.
Step 3 — Consolidated requirements model
- Normalize region data into a single spreadsheet/model: cost categories, required features, traffic patterns, compliance tags, and ROI drivers.
- Classify requirements as Global (must for all), Regional (unique) or Optional.
Step 4 — Option design & ROI quantification
- Define 2–3 solution architectures: fully centralized, hybrid (regional gateways + shared core), and fully regional. For each, estimate:
- Implementation cost (one-time)
- Ongoing OPEX (infra, data transfer, support)
- Migration effort/risk
- Revenue/efficiency impact (latency -> conversion uplift, oper. efficiency -> cost savings)
- Use NPV over a 3–5 year horizon and sensitivity analysis for key variables (traffic, FX, compliance costs).
Step 5 — Trade-off analysis and reconciled priorities
- Map each region’s top priorities to solution features; highlight where trade-offs occur (e.g., data residency vs cost).
- Propose mitigations: edge caching, regional VPCs with shared control plane, or encryption-at-rest to satisfy compliance without full regional duplication.
Step 6 — Executive recommendation
- Present a single recommended architecture (usually hybrid): shared scalable core for common services, regional ingress/egress for latency & compliance, unified observability and centralized governance.
- Provide clear summary: quantified ROI per region, implementation timeline, risk register, and governance model (roles, SLAs, escalation).
Step 7 — Governance & rollout plan
- Pilot in 1–2 representative regions, measure KPIs, then phased rollout with checkpoints.
- Establish cross-regional steering committee, cost allocation model, and success metrics.
Why this works
- Standardized discovery ensures apples-to-apples ROI comparisons. Hybrid architectures commonly balance cost and regional needs. Sensitivity/NVP and pilot reduce executive risk and make the recommendation defensible with numbers and mitigation plans.
List the targeted discovery questions that reveal non-functional requirements (performance, scalability, availability, security, compliance). For each NFR category provide example phrasing and what follow-up evidence or metrics you'd request from the customer.
Sample Answer
Performance
- Example phrasing: "What are the expected response-time SLAs for key user flows under peak load?" / "Which transactions must complete within X ms?"
- Evidence/metrics to request: current latency percentiles (p50/p95/p99), baseline load tests, RPS, typical payload sizes, APM traces.
Scalability
- Example phrasing: "How should the system grow — user concurrency, data volume, geographical expansion?" / "What growth rate do you expect over 1, 3, 5 years?"
- Evidence/metrics: current users/transactions/day, projected CAGR, data retention per month, peak concurrency, sharding/partitioning constraints.
Availability & Reliability
- Example phrasing: "What uptime SLA is required? Acceptable RTO/RPO for failures?" / "Which components require geo-redundancy?"
- Evidence/metrics: target SLA (e.g., 99.95%), past outage reports, MTTR/MTBF, backup frequency, failover test results.
Security
- Example phrasing: "Which data is sensitive/classified? What authentication/authorization models and threat profile apply?" / "Do you require encryption at rest/in transit?"
- Evidence/metrics: data classification, existing security policies, penetration test or VA reports, identity provider details, audit logs, encryption key management.
Compliance & Legal
- Example phrasing: "Which regulatory frameworks apply (GDPR, HIPAA, SOC 2)? Any data residency or retention mandates?"
- Evidence/metrics: required compliance certifications, DPO contact, data residency maps, retention schedules, previous audits and remediation reports.
Operational & Observability
- Example phrasing: "What monitoring, alerting, and runbook expectations exist?" / "Who is on-call and what are escalation rules?"
- Evidence/metrics: required metrics/SLIs, alert thresholds, existing dashboards, on-call rota, runbooks, SLOs.
Cost & Resource Constraints
- Example phrasing: "What budget limits or cost-per-transaction targets should we meet?"
- Evidence/metrics: monthly budget, cost per user/transaction targets, preferred cloud vendors, procurement constraints.
For each answer, request concrete numbers, historical logs/reports, and test artifacts so requirements can be translated into architecture decisions, capacity planning, and SLA-backed designs.
You are scoping a file upload service and the client says: "files can be large sometimes." Provide a set of clarifying questions to surface edge cases (max file size, concurrency, resumable uploads, client bandwidth, virus scanning, retention rules), explain why each is important, and describe how different answers would change acceptance criteria and architecture.
Sample Answer
Clarifying questions (grouped) with why they matter and how answers change acceptance criteria & architecture:
- Max file size per upload / typical distribution
- Why: drives storage, network limits, chunking, memory use, and cost.
- If small (<50MB): simple direct upload to object store acceptable. If large (GBs–TBs): require chunked/resumable uploads, serverless limits avoided, multipart upload APIs (S3), and streaming processing.
- Concurrency and throughput expectations (uploads/sec, simultaneous users)
- Why: capacity planning for ingress, load balancing, rate-limiting, and autoscaling.
- Low concurrency: single-instance or small autoscale group fine. High concurrency: CDN, pre-signed URLs, edge upload acceleration (AWS S3 Transfer Acceleration), and ingress autoscaling.
- Resumable uploads / pause-and-resume / unreliable networks
- Why: important for UX on flaky mobile links and very large files.
- If required: implement chunked uploads with idempotent resumable protocol (tus, S3 multipart), server-side state or client tokens. If not required: simpler upload flows.
- Client bandwidth / latency / upload source (browser, mobile, IoT)
- Why: affects chunk sizes, parallelism, and client-side hashing.
- Slow mobile: smaller chunks, background upload, retry backoff. High-bandwidth sources: parallel chunk upload to speed completion.
- Integrity and virus/malware scanning requirements
- Why: security & compliance; affects processing pipeline and latency.
- If mandatory: quarantine area, async scanning (ClamAV, commercial engines, or cloud malware scanning), blocklist policies, signing/verifying checksums. Acceptance: files not available until scan passes.
- Retention, versioning, and lifecycle rules
- Why: storage cost, legal/compliance, backup strategy.
- If short retention: lifecycle policies to auto-delete. If long-term retention or immutability: WORM/immutable buckets, legal hold support, backups.
- Access control, sharing, and preview needs (streaming, thumbnails)
- Why: influences metadata, CDN usage, streaming protocols, and on-the-fly transcoding.
- If previews required: generate thumbnails/video transcodes asynchronously. If private: use short-lived pre-signed URLs and audit logging.
- Compliance and encryption (at-rest, in-transit, KMS)
- Why: regulatory requirements affect key management and architecture.
- If customer-managed keys required: integrate KMS, enforce encryption-at-rest and strict IAM.
- Failure modes, SLA, and acceptable retry/backoff policies
- Why: defines UX and retry semantics.
- Tight SLA: synchronous validation and higher redundancy. Lenient SLA: async processing acceptable.
- Cost constraints and expected data growth
- Why: influences storage class choices, hot vs cold storage, and archival strategy.
- High growth: tiering, lifecycle transitions, optimized egress.
How answers change acceptance criteria & architecture (summary):
- Small files + low concurrency = direct uploads to object store with basic API and server-side metadata.
- Large files + unreliable clients = resumable multipart uploads, client-side hashing, stateful coordinator or serverless support (S3 multipart + Lambda orchestration).
- High concurrency = CDN, pre-signed URLs, autoscaling ingress, backpressure and rate-limits.
- Security/compliance = quarantined staging, async scanning, KMS, audit logs, immutable storage options.
- Preview/transcode = async worker pool, message queue, and media services.
- Retention/compliance = lifecycle policies, archival integration, and retention enforcement in acceptance tests.
Acceptance criteria examples (based on answers):
- "Supports uploads up to 10GB, resumable, resume within 24h, virus-scanned before availability, 99.9% upload success under 500 concurrent users" → multipart resumable + async scanning + autoscale + monitoring.
- "Supports up to 100MB, no resumability, authenticated uploads only" → direct signed uploads, simpler backend.
This set of questions lets us convert “files can be large” into concrete non-functional requirements that directly determine protocols (multipart/tus), cloud services (S3, CDN, KMS), processing pipelines (scan/transcode), and acceptance tests (max size, resume behavior, scan pass/fail, concurrency).
Unlock Full Question Bank
Get access to all Consultative Discovery and Requirements Gathering interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.