What do you use an ATM for?
Business Analysts and Product Managers: Here in lies the clarification to all your confusions about requirements
What do you use an ATM for?
Most people, and I imagine you too, would answer as follows: Withdraw Cash, Print Mini Statement, Transfer Money, Change PIN, and so on.
I want you to focus on those answers. Is there something you notice?
No? Okay. Let me help you.
You can press keys on the ATM’s keypad, can’t you? Why didn’t you include this in your answer?
You can enter your PIN, right? You didn’t say this. How come?
You can state how much cash you’d like to withdraw, can’t you? Why did you skip this?
If you’re thinking, “But these are small steps. They aren’t why we use the ATM.”, I’d say, “Bingo!”
Withdraw Cash, Print Mini Statement, Transfer Money, Change PIN, and so on, are user goals.
They are what are known as “Stakeholder Requirements”
This post is a continuation of my earlier post on Business Requirements.
If you have not read that post, I recommend you take a few minutes to do that first.
In this post, let’s discuss Stakeholder Requirement. Some people refer to this as User Requirement.
Stakeholder Requirement describes how a given stakeholder would like to interact with the solution, in the context of a business requirement.
Let’s take an example to understand this better.
In my previous post, we had discussed the example of an Insurance Company.
We noted a Business Requirement: Ability To Pay Premium Remotely.
In order to meet this Business Requirement, there are several solutions possible:
· First obvious solution: enable internet and mobile payment
· Enable direct debit from the customer’s bank account
· Partner with one or more banks and enable the banks to collect the premium
· Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
· Establish several satellite premium collection centres
Suppose we select the internet solution, i.e. the insurance company builds a website where customers make premium payments.
The following would be some of the Stakeholder Requirements:
Customer: Ability for a Customer to view a list of all policies where premium is due
Customer: Ability for a Customer to make a payment for policy where premium is due
Admin: Ability for the Admin to update the list of policies where premium is due for all customers
Stakeholder Requirements form the basis for defining Solution Requirements.
One might ask why bother defining Stakeholder Requirements at all, if it is not useful for the implementation team to design the solution.
The reason is simple: A top down structured approach will ensure that the requirements coverage is close to 100%, and the probability of missing out on requirements is greatly minimised.
