Northline Credit Union: Turning Four Conflicting Initiatives into a Requirements Baseline
Northline Credit Union operates 38 branches, two data centers, and a 1,100-person workforce. Access switching is Juniper EX3400; each branch has an SRX345 on an MPLS circuit. Four initiatives collide. Mobile check deposit must meet PCI DSS segmentation. A merger adds 12 branches running Cisco Catalyst with no Juniper skills on site. The contact center wants a cloud CRM that currently answers in 180 ms from branch desktops, and agents say call quality collapses above 150 ms. The board set 99.9% branch uptime and a $1.8M capex ceiling. Security insists all branch traffic backhaul to the primary data center; the network team wants local internet breakout; branch staff cannot absorb new troubleshooting. A discovery workshop ended with three conflicting requirement lists and no agreed priority. The program manager asks you to turn this into a design-ready requirements baseline before the 9-month deadline.
1. What requirements structure and prioritization method would you produce, and which items genuinely drive the design?
Read the worked answer
I would produce a four-layer baseline: business objectives, technical requirements, constraints, and assumptions. Every entry gets an ID (BR-01, TR-01, CON-01), a source, an owner, an acceptance criterion, and a verification method. Prioritize with MoSCoW, but force the program board to define "must" as tied to a dated business outcome rather than a preference.
The design-driving items are: 150 ms CRM latency, which rules out full backhaul for that flow; PCI DSS scope, which drives segmentation and encryption; 99.9% branch availability, roughly 43 minutes per month, which drives local survivability or dual transport; the 9-month deadline, which rules out a forklift refresh; and no branch skills, which drives zero-touch provisioning and centralized policy.
I would defer Cisco replacement unless the merger agreement sets a date, and standardize on Junos only at new sites. Publish a traceability matrix and a conflict log, and escalate unresolved conflicts to the sponsor with cost and risk quantified. That converts opinion into testable requirements.
2. How do you resolve the backhaul-versus-local-breakout conflict without letting the loudest team win?
Read the worked answer
Separate the question into data class and failure impact. Cardholder data and branch management traffic stay in a PCI-scoped path to the data center. SaaS CRM traffic can break out locally if the SRX345 enforces the same security policy and logs to the central collector.
Test the latency claim first: measure round-trip time from a branch to the CRM through the data center versus direct internet. If direct breakout saves 90 ms and meets the 150 ms requirement, design a policy-based forwarding rule on the SRX for the CRM address ranges with deny-by-default and TLS inspection where legally permitted. If security refuses, ask which specific control local breakout breaks; usually it is logging or egress filtering, and both are solvable.
Never split-tunnel PCI traffic. Record the decision as an architecture decision record with residual risk accepted by the CISO, and set a review trigger if the CRM moves regions. This makes the trade-off explicit and auditable.
3. What belongs in the design justification that gets both security and finance to sign?
Read the worked answer
One page per major decision, not a slide deck. For breakout, show measured latency, the user-impact estimate in agent calls per day, the security controls retained, and the residual risk. For the merger, show the cost of early Cisco replacement versus a 12-month coexistence with a Juniper border. For uptime, show the cost of downtime per branch-hour against the incremental LTE or second-circuit cost.
Include a phased roadmap that maps spend to the $1.8M ceiling and states what is deferred. Finance signs cost and deferral; security signs residual risk and monitoring. Add exit criteria for each phase so the program can stop if benefits do not materialize. The point is not to win the argument but to make the decision defensible when the first outage or audit occurs.