Legacy Benefits System Replacement Under Statutory Deadline
Your government agency is replacing a 15-year-old COBOL benefits calculation system. A statutory change requires new calculations by 1 April next year, nine months away. The mainframe has 400,000 lines of undocumented code. The policy team wants a configurable rules engine; IT wants a like-for-like migration; the finance director fears cost overrun. In workshops, three conflicting interpretations of a key eligibility rule emerge, each supported by a different legal precedent. The project board demands a requirements baseline in six weeks. You have two junior BAs and limited access to mainframe SMEs retiring in three months. The board insists on no scope creep and full traceability to legislation. The current system's batch jobs run overnight, and downtime during benefit payment week is unacceptable. A recent audit found 12 calculation errors leading to overpayments.
1. How would you resolve the three conflicting interpretations of the eligibility rule, and what techniques would you use to reach a defensible requirements position?
Read the worked answer
I would treat this as a requirements conflict requiring both analytical and stakeholder work. First, I would document each interpretation in a decision table, showing conditions and outcomes, to expose exactly where they diverge. Second, I would trace each to its legal precedent and identify the specific wording in the legislation. Third, I would facilitate a workshop with the policy owner, legal counsel, and the mainframe SME (before retirement) to agree on a single interpretation. If consensus is not reached, I would escalate to the project board with a recommendation based on legal advice and risk. Technically, I would use a business rules approach: separate the rule from the process, define terms in a glossary, and create test cases for each interpretation. I would also document the decision rationale in a requirements decision log. The goal is a defensible position, not necessarily unanimous agreement. I would also consider prototyping the calculation with sample cases to validate the rule before baselining.
2. Given the six-week baseline deadline and retiring SMEs, how would you structure the elicitation and documentation work?
Read the worked answer
With six weeks and retiring SMEs, I would prioritize knowledge capture. Week 1: run focused interviews with the three SMEs to extract undocumented business rules, using a structured template and recording sessions. Week 2: model the current calculation process and rules, validate with policy and legal. Weeks 3-4: define the statutory change requirements only, using MoSCoW to separate must-have legislative changes from nice-to-have configurability. Weeks 5-6: baseline the requirements, produce a traceability matrix to legislation, and review with stakeholders. I would use two junior BAs to document rules in parallel, with daily check-ins. I would also set up a wiki for asynchronous review. Given the board's 'no scope creep' instruction, I would explicitly park non-statutory requirements in a backlog. The baseline would include a decision table for the eligibility rule, process models, and a glossary. I would also schedule a peer review with IT architecture to ensure feasibility.
3. How would you handle the tension between the policy team's desire for a configurable rules engine and IT's preference for a like-for-like migration?
Read the worked answer
I would first quantify the business benefits and risks of each option. For the configurable engine, I would ask: what future statutory changes are anticipated? What is the cost of change now versus later? For like-for-like, what is the risk of carrying forward undocumented rules? I would then facilitate a workshop with policy, IT, and finance to agree on evaluation criteria: legislative compliance, total cost of ownership, risk, and time to deliver. I would propose a hybrid: migrate current rules as-is for the statutory deadline, but design the data model and interfaces to allow a rules engine later. This reduces immediate risk while preserving future flexibility. I would document the decision as an architectural constraint and ensure the requirements baseline includes a clear separation between calculation logic and presentation. If the board insists on one option, I would present a recommendation with a risk assessment, not just a technical preference.