Requirements Gathering and Business Analysis Questions

Plan overview: Run a focused, two-day discovery workshop to align executives, PMs, engineers and customers on business outcomes, user needs and a technically-feasible MVP scope. Emphasize decisions, traceability, and next-step owners.

Pre-work (sent 7 days prior)

• 1‑page context brief: business goals, constraints, success metrics, stakeholders.
• Current-state artifacts: analytics snapshot, existing architecture diagram, customer quotes.
• Pre-survey: top risks, must-have vs nice-to-have, 2-minute customer pain description.
• RSVP roles & tech constraints (compliance, integrations).

Day 1 — Alignment & Problem Framing

• 09:00–09:30: Kickoff — objectives, success criteria, norms, decision rules (RACI + DACI).
• 09:30–10:30: Executive context — goals, KPIs, constraints.
• 10:45–12:30: Customer voice & personas — validated jobs-to-be-done.
• 13:30–15:30: Story mapping (top-level backbone) — outline user activities and pain points.
• 15:45–17:00: Impact mapping — link features to business outcomes; vote on highest-impact areas.

Day 2 — Scope, Feasibility & Decisions

• 09:00–10:30: Technical feasibility quick-review — integration points, data flows, non-functional requirements.
• 10:45–12:30: Prioritization workshop — MOSCOW + weighted scoring (business value, effort, risk).
• 13:30–15:00: Define MVP slice(s) — map minimum backbone from story map, dependencies, acceptance criteria.
• 15:15–16:15: Risks, Mitigation & Implementation approach — spikes, cutover, monitoring.
• 16:15–17:00: Decision & Next Steps — assign owners, timelines, success metrics.

Artifacts to prepare

• Printed story-map canvas, sticky notes, dot-vote stickers, timers.
• Templates: Persona cards, impact map, prioritization matrix, decision log.
• Architecture whiteboard: current & proposed integration sketches.

Exercises & techniques

• Story mapping: build backbone → slice vertically for MVP.
• Impact mapping: goal → actors → impacts → deliverables.
• Weighted scoring: numeric scoring for transparent prioritization.
• "Fist of Five" quick consensus checks; silent dot voting to avoid groupthink.
• Time-boxed lightning tech reviews with pre-assigned SMEs.

Facilitation for decision-making

• Establish decision framework up-front (DACI: Driver, Approver, Contributors, Informed).
• Use evidence-first: require metric or customer quote for claims.
• Provide clear, binary decision points (approve/reject/defer) with owners and deadlines.
• Capture decisions in a live decision log visible to all.

Conflict mitigation

• Normalize dissent: set "disagree & commit" norm.
• Use caucus technique: 10-minute private chat between disagreeing parties facilitated by neutral architect to surface root concerns.
• Escalation path: if executive-level conflict, defer to pre-agreed approver within 24 hours.
• Reframe conflicts to criteria: map disagreement to value/effort/risk to depersonalize.

Post-workshop deliverables & owners (deliver within 3 business days)

• Workshop summary + decision log (Owner: Workshop facilitator / Solutions Architect).
• Finalized MVP backlog slice with prioritized stories, acceptance criteria and dependencies (Owner: Product Manager).
• High-level solution architecture diagram with identified integration points and non-functional requirements (Owner: Solutions Architect).
• Implementation roadmap with risks, spikes, and first three sprints plan (Owner: Engineering Lead).
• Success metrics dashboard spec and measurement plan (Owner: PM / Analytics).
• Outstanding questions & owners list with deadlines (Owner: Workshop facilitator).

Success measures

• Clear, signed-off MVP scope, prioritized backlog, architecture alignments, named owners for all actions, and commitment to next milestones within 72 hours.

When decomposing monitoring for a multi‑tier app I define signals by tier/function, map them to SLOs, then derive sampling/retention/alerts from business risk and cost.

Key signals and example SLO mappings:

• Metrics (high-cardinality, low-cost, real‑time)
  • Frontend: request rate, p50/p95/p99 latency → SLO: 99.9% requests < 300ms (per region)
  • API/service: error rate (5xx%), throughput, concurrency → SLO: error rate < 0.1% per minute
  • DB: query latency, connections, cache hit ratio → SLO: p95 DB latency < 50ms
• Traces (distributed context for latency hotspots)
  • End-to-end trace latency and span duration → SLO tie-in: trace success rate and tail latency budget (e.g., 99% of traces < 500ms)
  • Sampling should be adaptive: keep 100% for errors and slow traces, 1–5% for normal traffic, and higher for new deployments
• Logs (detailed diagnostics)
  • Structured app logs, audit logs, exception stack traces → SLO: mean time to detect (MTTD) / mean time to resolve (MTTR) targets (e.g., MTTD < 2 min)
  • Retain error and security logs longer (90–365 days), debug logs short (7–30 days)

How these influence architecture:

• Sampling: aggressive sampling for traces/logs on high volume tiers to control cost; use tail/exception capture and dynamic sampling during incidents or canary windows.
• Retention: metrics aggregated (rollups) for long-term dashboards (months/years); store high‑resolution recent data (1s–1m) and lower resolution older data; longer retention for compliance/audit logs.
• Alert thresholds: set alerts tied to SLO burn rate and business impact (use SLO burn alerts rather than static thresholds). Example: trigger page if burn rate > 4x over 5 minutes or error rate spikes above 0.5% sustaining 3 mins; use warning alerts earlier (e.g., 1.5x) to investigate.

Trade-offs and recommendations:

• Prioritize SLOs that map to business outcomes (latency, availability, correctness) and tune sampling/retention to balance observability vs. cost.
• Use feature flags and higher telemetry during rollouts; automate sampling and retention policies per environment.
• Ensure dashboards show both service-level SLOs and underlying signals (metrics → traces → logs) for fast root cause analysis.

Approach: with only diagrams and two stakeholder interviews I’d do a focused risk-first feasibility assessment: identify the highest-impact unknowns, capture testable assumptions, and prepare a rapid validation plan to resolve them when I get access.

Top five risks

1. Integration risk — unknown APIs, protocols, adapters, and data formats between systems.
2. Data quality/volume risk — unclear data size, growth, latency, and transformation needs.
3. Security & compliance risk — unverified auth flows, encryption, network zones, and regulatory constraints.
4. Operational/Runbook risk — gaps in monitoring, backups, DR, and support model.
5. Timeline/cost/dependency risk — hidden third-party dependencies or licensing that block delivery or inflate cost.

Key assumptions to document (explicit, testable)

• Source systems expose REST/gRPC or require middleware (integration assumption).
• Peak data throughput and retention (e.g., X TPS, Y TB/month).
• Authentication method and trust boundary (OAuth2/SAML, client certs).
• SLAs for RTO/RPO and acceptable latency.
• Ownership of infrastructure and access timelines (who provides accounts/config).

Quick validation plan once access is granted (first 1–7 days)

1. Sanity walkthrough: run a 1-hour architecture review with stakeholders to confirm diagrams and record divergences.
2. Access checklist: request sample API specs, schema dumps, a representative data sample, network diagrams, and credentials in a vault.
3. Smoke tests: call a sample API, transfer a small data batch, authenticate, and verify basic telemetry to confirm protocols and auth.
4. Metrics check: run simple load probe on representative data to validate throughput and storage sizing assumptions.
5. Security check: confirm TLS, auth flows, and any compliance docs; run a quick threat checklist.
6. Dependency map & reforecast: enumerate third parties, lead times, and revise timeline/cost and residual risk heatmap.
7. Risk mitigation plan: for each residual risk propose short-term mitigations (stubs/queues/feature flags), and recommend a focused PoC if critical (2–3 day spike).

Why this works: it prioritizes high-impact unknowns, makes assumptions explicit and measurable, and uses minimal-touch validation (walkthroughs + smoke tests + metrics) to quickly convert unknowns into decisions or mitigations for a reliable feasibility answer.

Use both diagram types because they answer different questions: sequence diagrams show the temporal interaction between actors/components (who calls what, in what order), while data flow diagrams (DFDs) show how data moves, where it’s stored, trust boundaries, and transformation points. As a Solutions Architect I use them together to decompose authn/authz.

High-level (stakeholder sign-off) — appropriate detail:

• Purpose: communicate end-to-end behavior, responsibilities, and risk areas to product owners, security, and business stakeholders.
• Artifacts: a 1–2 page sequence diagram with swimlanes for User, Client App, API Gateway, Auth Service, IdP, and Resource Server plus a Level-1 DFD that highlights data stores (user credentials, session tokens, audit logs), trust boundaries, and data classification.
• Content: show principal flows (login, token issuance, token refresh, access request, logout), success/error high-level states, and where sensitive data resides. Avoid protocol minutiae (no raw HTTP headers, no exact JWT claims).

Developer implementation (detailed) — appropriate detail:

• Purpose: provide implementable behavior, edge cases, and integration contracts.
• Artifacts: detailed sequence diagrams with message names, HTTP methods, endpoints, payload snippets (e.g., OAuth2 token request/response, JWT verify steps), timeouts/retries, and error branches; a Level-2 DFD mapping to services, schemas, and storage (encryption-at-rest, retention), plus trust-boundary and network segments.
• Content: exact authentication protocols (OAuth2 Authorization Code with PKCE, SAML, OIDC), token formats and claims, cryptographic expectations (algorithms, key rotation), TTLs, cache behavior (session store vs stateless JWT), auditing hooks, and rate-limits. Include sequence branches for refresh, revoked tokens, multi-factor prompt, and failure recovery.

Practical approach and checkpoints:

• Start with stakeholder-level diagrams for alignment and risk sign-off (security, compliance); get explicit acceptance on trust boundaries and SLO/SLAs.
• Expand approved flows into developer diagrams and DFDs; review with engineering for feasibility and update until implementation-ready.
• Keep mapping between levels (traceability): label each high-level flow with references to detailed diagrams and API spec.
• Include security controls and monitoring as first-class items (audit logs, alerting, revocation paths).

This combination ensures the business understands scope and risks while engineers get unambiguous, testable implementation guidance.

Requirements & constraints (clarify up front):

• Non-functional: near‑zero downtime (target <5 min outage), RPO <1s, RTO <15m
• 200k TPS/day (~2.3 TPS average, spikes unknown), 2TB DB, on‑prem ERP with transactional integrity
• Compliance, network bandwidth, latency, and maintenance windows

Phased feasibility assessment (high level):

1. Discovery (2–3 weeks)

   • Inventory schemas, table sizes, PKs/FKs, long‑running transactions, triggers, stored procs, app read/write patterns, peak QPS, replication‑safe types.
   • Network assessment: bandwidth, VPN/Direct Connect, latency.
   • Define success metrics, rollback SLAs, compliance controls.

2. Proof of Concept (2–4 weeks)

   • Choose cloud target (RDS/Aurora, Cloud SQL, Azure DB) and replication tool (Debezium/Kafka Connect, AWS DMS, Oracle GoldenGate).
   • Small subset pilot: one high‑velocity table + supporting microservices. Validate CDC, schema conversion, latency, conflict handling.

3. Pre‑migration sync & validation (2–6 weeks)

   • Full snapshot + continuous CDC to keep target in sync.
   • Data validation: checksums, row counts, business query parity, end‑to‑end test transactions in staging.
   • Performance testing on target (read/write latency, connection pooling).

4. Pilot production & shadow mode (1–2 weeks)

   • Dual‑write or read‑split: route reads to cloud target while writes still go on‑prem (or shadow‑write non‑production flows).
   • Monitor replication lag, error rates, query performance.

5. Cutover (window planning)

   • Option A (near‑zero): short transactional freeze (seconds to minutes) + final CDC apply + switch DNS/load balancer.
   • Option B (zero downtime): implement dual‑write + drain on‑prem, then flip writes when throttles validated.
   • Post‑cutover validation & rollback window.

Tools & patterns:

• CDC/replication: Debezium + Kafka (open), AWS DMS (managed), Oracle GoldenGate (enterprise), Striim (complex transforms).
• Network: Direct Connect / ExpressRoute, VPN for secure low‑latency pipe.
• Schema conversion: AWS SCT / custom scripts; use feature flags for behavioral changes.
• Validation: row‑level checksums, query result comparison (commercial tools: Confluent Replicator, HVR), automated end‑to‑end tests.
• Orchestration: Terraform/Ansible for infra, Kubernetes or cloud autoscaling for app services.
• Monitoring: Prometheus/Grafana, CloudWatch, replication lag alerts.

Risk triggers (raise immediate action):

• Sustained replication lag > acceptable threshold (>5s or defined SLA)
• High rate of CDC errors (schema mismatch, unsupported types)
• Data validation failure (checksum mismatch, row count drift)
• Network degradation (packet loss, bandwidth drop)
• Production performance regressions (latency, error rate)
• Long running lock or DDL events blocking apply

Rollback / fallback strategies:

• Pre‑cutover: keep on‑prem writable and target in read/standby mode; have automated reverse‑replication plan if needed.
• Dual‑write rollback: stop writes to cloud, reconfigure app to on‑prem, replay data if partial writes occurred (use idempotent writes, transaction ids).
• Snapshots/backups: pre‑cutover snapshot of on‑prem and cloud, ensure point‑in‑time recovery.
• Emergency failback: keep CDC pipeline able to reverse replicate (target→source) for short periods; if not feasible, restore on‑prem from snapshot and resume.
• Communication & runbook: automated runbook for each trigger, stakeholder notifications, cutover owner with decision authority.

Trade‑offs & recommendations:

• Managed DB reduces ops but may impose engine/version limits; test stored procs/locks.
• Debezium+Kafka gives flexibility and strong audit; managed DMS is simpler but less flexible.
• Aim for a small freeze window for final consistency; full zero‑downtime increases complexity (dual‑write conflict handling).
• Budget time for schema refactor and app tuning.

Deliverables for the assessment:

• Migration plan with timeline, roles, cutover checklist
• Pilot results and performance baselines
• Risk register with triggers & automated alerts
• Rollback playbooks and test sign‑offs

This approach balances risk and speed: validate with a POC, use CDC + continuous validation for near‑zero downtime, and keep robust rollback options and triggers defined before cutover.