Late 'One-Click Claim' Request
Haven Insurance has baselined requirements version 2.1 for a claims management release. Six weeks before go-live, the marketing director requests a 'one-click claim' feature for the mobile app. The request arrives as a two-line email: 'Customers should file a claim in one click. This is critical for retention.' The current baseline has 42 functional requirements, 18 non-functional requirements, and 9 use cases. The change would affect the claim intake use case, the document upload interface, the fraud-check service, and an audit requirement that every claim submission record the policyholder's confirmation. The traceability matrix is incomplete: 7 requirements have no downstream links, and 3 test cases reference requirements that were deleted in version 2.0. The change control board meets weekly, but the next meeting is in 5 days. The release has a regulatory audit date fixed at 8 weeks from now. The product owner wants to 'just add it to the backlog' without a change request.
1. Is 'one-click claim' a requirement? What would you clarify before any impact analysis, and with whom?
Read the worked answer
'One-click claim' is a solution idea, not yet a requirement. It may mean: preselect the policy and claim type, reuse stored documents, submit with one confirmation, or bypass fraud checks, each with different risk. Before impact analysis, clarify the problem: which customer segment, which claim types, what abandonment rate or cycle time is targeted, and what audit evidence is non-negotiable. Ask marketing for the retention evidence and the target metric; ask compliance whether a single click can satisfy the requirement to record policyholder confirmation; ask the fraud team what data must be captured before submission. Restate as a need: 'A policyholder with an existing policy shall be able to submit a completed claim for a covered event in no more than X interactions and Y minutes, with confirmation evidence stored.' Then derive options, including one-click for low-value claims only. This reframing prevents the team from estimating a slogan and prevents marketing from later claiming the delivered feature is not what they meant. The clarification should be documented in the change request, not just in chat.
2. The traceability matrix has 7 unlinked requirements and 3 test cases referencing deleted requirements. How should the team perform impact analysis under this uncertainty?
Read the worked answer
Treat the incomplete matrix as a risk, not a blocker. First, time-box a repair: identify the 7 unlinked requirements, assign each to a use case, design element, or test, and flag any that cannot be linked. Remove or rewrite the 3 orphan test cases so they do not create false confidence. Then perform impact analysis in two passes. Pass 1: forward trace from the proposed change to claim intake, document upload, fraud-check, and audit confirmation, which are known touchpoints. Pass 2: backward trace from each affected artifact to requirements and tests, looking for hidden dependencies. Because the matrix is incomplete, add a structured review with the claim intake product owner, fraud lead, and compliance officer; ask each to name affected rules, interfaces, and reports. Use the test suite as a second map: which tests exercise claim submission and document upload? Estimate effort with a range and state the uncertainty. Record the analysis in the change request, including the assumption that no other interfaces are affected. The decision may still be 'approve,' but it should be an informed decision, not a guess.
3. The product owner wants to add the feature to the backlog without a change request. What are the risks, and what process should the team follow given the audit date?
Read the worked answer
Skipping change control risks three things: unauthorized scope change against a fixed audit date, untested effects on audit evidence, and loss of traceability for the regulator. The feature touches a regulated claim-submission record, so 'just a backlog item' is not a low-risk administrative change. The team should raise a change request now, even if incomplete, and ask the change control board for a fast-track decision at the next meeting or an extraordinary session. The request should include the clarified need, impact analysis with uncertainty, options (full one-click, limited to low-value claims, defer to next release), and a recommendation. If the board approves, rebaseline the affected requirements, update the traceability matrix, and add acceptance criteria and regression tests. If it defers, record the decision and the workaround. The audit date does not remove the need for change control; it raises the cost of undocumented change. The product owner can still prioritize the work, but the decision must be visible and owned.