One Muddy Requirement, Two Cards

In practice

The old requirement reads: the system shall manage renewals and notify members. It fails the first check at once, because no single thing is named. Asked which things it touches, the team finds three. The Loan changes its due date. A notice is generated to the member. And a waiting member's Hold may be affected. It also fails atomicity, because it describes two behaviors that happen at different times. The rewrite produces two cards. The first is REQ, LOAN, zero four, Renew Loan, an update to the Loan. Its rules: a loan may be renewed at most the number of times the policy version allows; it may not be renewed if another member holds the item; and the new due date comes from the policy version in force on the day of renewal, not the original one. That last rule takes ten minutes of argument with circulation staff, and is written down for the first time. The second is REQ, LOAN, one zero, Generate Renewal Confirmation, a generate card. It is triggered by a successful renewal and carries the new due date, but is not sent when the renewal happens at the desk with the member present. The team also notices a gap. Nobody has written what happens to a Hold when a renewal is refused, so they record an open question for the Hold's owner.