« Decisions and the potential for agile services | Main | Using EDM to improve marketing operations »

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: , , , , , , , , , , , , , ,

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:


TrackBack URL for this entry:

Listed below are links to weblogs that reference Use Cases and Requirements - a response:

» Requirements, business process and business rules from James Taylor's Decision Management
Roeland had an interesting post this week on the need for a new approach to requirements and BPM's role in that. He outlined the three classic causes of problems with projects (Lack of User Input, Incomplete Requirements & Specifications, Changing... [Read More]


Stephan Meyn

I always regarded Use Cases as a discovery tool. They are the form that allows the user to contribute effectively. The BA then takes that material and by investigating and questioning it discovers all the other requirements: business rules, business objects, non-functionals, assumptions etc.

The comments to this entry are closed.

Search Site



  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.