Use Cases and Requirements - a response

Scott Sehlhorst, with whom I am presenting at Business Rules Forum this year, just posted Use Case Example With Business Rules. In the post Scott identifies 4 opportunities, in an ATM withdrawal use case, to find decisions and I thought I would expand on it (as part of our ongoing efforts to develop some coherent thoughts and guidance around rules and requirements). Below are the opportunities I see (added one in bold) with my thoughts on the decisions contained:

• Validates the card information.
• Is the card valid?
  This might be simple (matching account numbers) or complex (matching account number, internal records and other coded information on the card). It might also be different at an ATM with a thumbprint reader or iris scanner!
• Is the card compromised?
  This might simply involve checking a list of reported stolen cards but it might also involve more complex event processing kind of checks (has this card been used at another ATM so recently that we suspect there are multiple copies, what risk score comes back from a neural net designed to detect fraud).
• Who is the customer? 
  Simple decision so we know who we are dealing with (which will become important further on)
• Selects transaction.
• What options should we display?
  Although Scott does not think this is an explicit decision, I do. Scott notes that the options available may change over time but there are other issues. After all we know who you are at this point. As a result we should be able to personalize this and:
• See if there is a transaction you do so often that the right thing to do is display that option only (to make it quick) with an option to do "something else"
• See if there is a small set of transactions you favor over others for a similar reason or if  predictive model suggests that some options are much more likely to be relevant than others
• Identify the options that are reasonable (if you only have one account then don't display the option to transfer money for instance
• Validates transaction details.
• Is the transaction valid?
  Could be simple (enough cash in the account) or more complex (is this kind of transfer allowed)
• Can the ATM complete the transaction?
  Could be simple (enough cash in the ATM) or more complex (system availability for a linked system)
• Make Offer.
• Is a follow-on offer appropriate
  Once the transaction is done the ATM could choose to make a follow-on offer. Deciding on this might be a function of the time since the last customer (a measure of busyness that might cause us to prioritize the next customer over a follow-on activitiy), the customer's own preferences, prior history with this customer, best next action for this customer and so on.
• Updates the account.
• What fee is there?
  Might be a simple calculation or a very complex one in terms of good customers getting fees waived etc.
• Does the transaction require follow-up?
  "Know your customer" legal requirements might be involved, though these are likely to be handled in the back office not at the ATM

This kind of more sophisticated interaction is part of what I call building the bank of the future and involves a ruthless focus on micro decisions. BTW I would also recommend another book, Use Cases: Requirements in Context (reviewed here), as it not only has good advice on use case development, it also focuses on keeping rules separate.

Technorati Tags: analytics, best next action, business rules, customer decisions, customer-centric, decision management, event processing, fraud, know your customer, marketing, personalization, predictive analytics, requirements, Scott Sehlhorst, use case