We business analysts are surrounded by “solution” folks; those whose jobs are to determine how to solve problems. On one side, our business stakeholders are typically tasked with problems in the business domain that they want to solve with the help of technology. On the other side, our designers, architects and developers are tasked with solving the puzzle of enabling the available technology to solve the business problems. They, pretty much reflexively, process the information they’re given in terms of what the solution needs to be and what it needs to look like. And they should. It’s their job, after all.
BA’s are (supposed to be) a different animal. We’re the ones that help our solution-oriented counterparts take a step back to focus first on the problems and their root causes. Then we work to create a shared vision between business stakeholders and the delivery organization as to the essential needs and/or functions required to solve the problem (AKA “specifying the requirements) while being careful not to pigeonhole the design with unnecessary implementation detail.
The challenge is that a lot of us BA’s were solutions people in “prior lives” so describing those essential needs and functions in a way that is free of implied technical and implementation context isn’t necessarily something that comes naturally.
Yes, sometimes we BA’s need to think of unconventional ways to help us withhold the technology and implementation detail from our requirements. Below, I’ll share a couple of those “tricks” for the those of you who might benefit from them.
The example
Let’s take as an example a rough cut at a use case description for withdrawing cash from a bank.
- The customer swipes a card at the ATM.
- The system reads the card and verifies that it is valid, then prompts the customer to enter a PIN.
- The customer enters and submits a PIN.
- The system validates the PIN, grants the customer access to their account, and provides the customer with a menu of options.
- The customer selects the option to withdraw cash.
- The system displays the withdraw cash screen to the customer.
- The customer selects an amount of cash for withdrawal.
- The system verifies that the account has the available funds, that the ATM has the funds available cover the requested amount, and dispenses cash to the customer and provides a receipt.
It’s not a bad use case description. The steps seem reasonable, and they end with the customer getting his cash, so that’s good, right? But do I provide unneeded implementation detail in that use case description?
To check myself, I might use one of these exercises.
Take a walk back in time
Assume we’re operating in the past – before computer systems and software as we know them today. In many cases, systems and software just help humans do things they would have done manually in the past. Imagining that we are operating maybe 40 or 50 years ago, what were the actions – at their simplest – that had to be taken to achieve the goal manually? Often, those will be the same actions today, only they are performed by computer systems and software.
With the past in mind, let’s reconsider the use case for withdrawing cash from a bank. Instead of imagining pin numbers, card swipes, and ATM screens, we might be more inclined to think of how an old-time, customer/teller transaction might take place.
- The customer informs the teller that he/she would like to make a withdrawal from their checking account, and presents the teller with a check written out to “cash”.
- The teller looks up the account number on the check and requests additional proof of identification.
- The customer shows a driver’s license or other valid proof of identification.
- The teller verifies the customer’s identity and notes information from the additional ID.
- The teller looks up the customer’s account balance and verifies that the balance is sufficient to cover the amount on the check.
- The teller deducts the amount of the check from the customer’s account, counts the cash out to the customer and gives them a receipt summarizing the transaction.
Where in the original description we refer to card swipes, PINs, and screens, in the scenario from the past we refer to checks and driver’s licenses. All of those are details of a specific implementation of the use case to withdraw cash.
Simply summarized, thinking through how the process would be done manually helps me recognize my implementation biases in my use cases. I normally wouldn’t completely write out the whole description from the “past” perspective. I’ve done so here just to illustrate the thought process.
Back to the future
By the same token, we could assume we’re operating in the distant future – where your wish is your command. Gone are the crude days of pressing buttons, clicking on links, selecting items from a drop-down list. Assume that you have access to some advanced technical entity – maybe a robot or something – that can enable you to attain your user goals if you just tell it what you need to do.
This would initiate a dialog during which “the system” would “do some magic” in the background and respond with what you need to do next. You would respond in kind until the goal is achieved. Sometimes it is helpful to just think of the “how” as “the magic behind the scenes” as another way to prevent listing unessential requirements or design detail.
Now for the present
After removing implementation context and listing the common elements of both our original and past (manual) descriptions, we might end up with a use case description like this:
- The customer identifies self and provides proof of identification.
- The bank evaluates the identification information, and recognizes the customer as valid and authorized.
- The bank grants the customer account access.
- The customer requests to withdraw cash and provides an amount.
- The bank determines that the customer has a sufficient account balance, that the bank has available funds, and provides cash to the customer. The bank reduces the customer’s account balance by the requested amount and provides a receipt.
Those steps are pretty much the same whether you did a drive through or walk-in transaction 30 years ago, or today. By taking away the technical context, it’s easy to envision the steps working for a drive-thru, walk-in, ATM, online, or any other withdrawal transaction.
Theoretically, the actions – with their accompanying business rules – should still be applicable if the bank decides to move to a different technology , or even when they come up with some revolutionary new way of fulfilling cash withdrawals.
Wrapping it up
Now remember, I’m not saying that it’s a good practice to always check your use cases by reviewing them as is from the past or future. It’s just a trick you can use to condition yourself to recognize unnecessary detail in your use case descriptions if that’s something your challenged with.
With practice, you’ll get better at instinctively leaving out implementation context without the help of extra tips and tricks. You’ll easily be able to write use cases that are portable across technology and, apparently, across time!
I’d be curious to know, have others of you ever tried these techniques? What other tips and tricks do you use to keep your requirements at the proper level of detail?
That was a very clear and concise explanation, and I very much agree that it is good to avoid solution specific language in requirements if possible.
In these days, even in screen based UI’s like web based solutions or the ‘older’ style client applications, functionality can be triggered in a variety of ways, (e.g. via buttons, images or hyperklinks etc).
It means the time travel period is even shorter to find you have been assuming a particular solution context that needs to be changed. E.g. perhaps using ‘The user clicks on the Save button…’ instead of ‘The user triggers the option to Save…’.
Thanks, Alan. Appreciate you stopping by commenting.
And you make a good point – at the rate things are changing today, it doesn’t take long for one type of UI element or “best practice” to be replaced by another.
Great post, Jonathan. Thank you for sharing. A process improvement person, I've seen change of hands/orgs, duties/responsibilities across the board. I might venture to suggest that one replace the word 'bank' with more generic form of provider, such as 'supplier'. In the future, 'bank' may be an investment firm. Just a thought.
Thanks, Tami, and you're right about the banks. It's interesting to contemplate how different fulfillment of services and functions we take for granted may change and how much of our lingo is tied to terms for tools and technology used for fulfillment. I'm thinking about "dialing numbers" for example.