The 49 Requirements That Were Really Design Decisions
A regional bank is replacing its loan-origination platform. After eight workshops the business analyst holds 412 candidate requirements, of which 118 are marked 'must'. On review, 27 of the 'must' items describe screen layouts (for example, 'the credit officer must see a three-tab layout') and 22 name a specific vendor product as the implementation approach. The vendor contract is fixed-price, with change control at $1,800 per accepted change request.
Two business owners are deadlocked. Credit Risk requires that once a decision is issued, the application becomes immutable, citing findings from a supervisory review. Operations requires a 48-hour reopen window so that data-entry errors in the applicant's declared income can be corrected without creating a new application. Each has escalated to their own head of department. The executive sponsor wants requirement sign-off in three weeks so build can start, and the vendor's own analyst has already begun drafting screens.
1. What should the analyst do with the 27 layout requirements and the 22 vendor-naming requirements before the baseline is signed? Why does it matter beyond tidiness?
Read the worked answer
These are solution requirements written in the grammar of business requirements. Left as 'must' items they cause three concrete harms: each costs $1,800 to change once baselined; none can be accepted by a business owner, because a tab layout is not an outcome they can judge; and they freeze design before architects and users have compared alternatives.
Process: for each item, recover the need behind the wording with its author. 'Three-tab layout' almost certainly encodes something testable, such as 'applicant, financials and collateral data must be reachable within one screen transition'. Rewrite it as a solution-functional requirement with a measurable fit criterion. Record the original phrasing in a decision log or constraint register with author, date and rationale, not in the baseline.
The 22 vendor-naming items are usually architectural or commercial constraints ('integrate with product X because a group licence exists'). Keep the constraint, strip the product-specific phrasing, and route the commercial implication to procurement, because the contract may already be priced on that assumption.
Assign every requirement a verification method (test, demonstration, inspection, analysis). Layout items can only be 'inspected', which is itself the signal that they belong in design. Finally, report the honest count of 'musts' to the sponsor: the baseline should contain roughly 69 fewer items than the number they have been shown.
2. Credit Risk and Operations are deadlocked over whether an issued decision can be reopened. How should the analyst resolve and document this, and in what artefact does the outcome live?
Read the worked answer
This is not a binary choice; it is a business rule with parameters, and framing it as a winner-takes-all conflict is what is blocking progress. Both positions are legitimate: immutability protects the credit decision record, and reopen protects data quality on facts that were mistyped, not re-decided.
Steps: (1) Verify the claimed authority. Ask each side for the actual clause or finding they are citing; in practice one side is often citing a policy that permits controlled amendment with an audit trail. (2) Convene a decision session with a named decision owner identified in advance (typically the Chief Credit Officer, with Operations consulted) rather than seeking consensus. (3) Model the rule as a state-transition matrix: which states may be reopened, by which roles, for which fields, within what window, with mandatory reason codes, and with before-and-after values written to an append-only audit table. A 48-hour, reason-coded, field-limited reopen before disbursement is compatible with an immutability requirement that targets the decision itself, not the applicant's income figure. (4) Record the outcome in a decision log (decision, alternatives considered, owner, date, review trigger) and trace the resulting requirements back to both the audit finding and the operations policy.
Note the non-functional consequences that must follow the rule: audit retention period, database-level enforcement (no in-place updates on the decision table), and reporting on reopen frequency as a quality metric on the Operations team.
3. What should the analyst tell the sponsor about the three-week sign-off target?
Read the worked answer
The honest answer is that a baseline containing an open 'must'-level conflict cannot be signed, because whichever way it is implemented one owner will claim the requirement was violated. Signing anyway converts a business argument into a change request later, at $1,800 per change and with a design already built around one interpretation.
Recommended position: propose a two-track sign-off. Track one is the agreed core, roughly 70 percent of the baseline, which can be frozen on schedule and released to build. Track two is a short list of open decisions, each with a named owner, a decision date inside two weeks, and an explicit statement of what build work is blocked. This keeps the vendor productive on screens and data model without committing to the contested rule. Present the cost of delay honestly: two weeks of decision time against the cost of reworking a state machine and its audit trail after build has started.
Also use the three weeks to close the solution-shaped requirements, because that work is cheap now and expensive later. Flag the schedule risk formally if the decision owners cannot commit to dates, since the sponsor, not the analyst, owns escalation. Finally, ask the vendor to confirm in writing which of the 49 items they have already assumed in their fixed price; that answer changes the negotiation position and is worth having before signature, not after.