Este artículo también está en Español.
It would seem that gathering requirements and assessing needs are two ways of saying the same. However, methodologically speaking they are not, and this difference is key.
The only thing that gathering requirements and assessing needs have in common is that users are involved. But similarities stop there.
Gathering requirements
Gathering requirements is about asking clients what they want and what they need. But we know that there’s a big difference between what clients ask, want, and need:
- What the client wants is to increase online sales
- What they ask for is a digital marketing campaign
- What they actually need is to improve product information on their site because users don’t understand what it is and that prevents sales
So, when we gather requirements we focus on what the client wants and asks, which, as we just saw, may not necessarily be what they need.
The output of this activity is usually a (long) list of requirements. And the problem with that is that when we ask clients what they want, if we don’t include their request in our solution they will be disappointed and will feel like we didn’t listen. Worse yet, they may think we didn’t do our job right, especially if the requirements gathering process involved talking to stakeholders.
Assessing needs
When we assess needs all we do is observe. That’s it, we just observe. We don’t ask, we simply watch clients use the product, how they use it, what problems they encounter, what other tools they use, what the pain points are, frustrations and satisfaction too.
And only after we have observed them we can define the problem they need to solve and what the best solution is.
And the good part is, since the client didn’t ask for anything in particular, we don’t need to deliver any specific artefact, solution or feature. We’re free to think the best solution.
In short…
… Gathering requirements is like asking the patient to perform a self diagnosis and ask us what they want us to give them. Assessing needs is about listening to the patient, understanding the symptoms and based on that define a treatment plan.
Because if the patient has a headache it is our responsibility to decide whether to give them an aspirin or perform a few tests to see if what they really need is a pair of glasses.
In the first case we’re foregoing our responsibility and doing what the patient asks, in the second we’re using our skills to understand and address what they need.
Este artículo también está en Español.
It would seem that gathering requirements and assessing needs are two ways of saying the same. However, methodologically speaking they are not, and this difference is key.
The only thing that gathering requirements and assessing needs have in common is that users are involved. But similarities stop there.
Gathering requirements
Gathering requirements is about asking clients what they want and what they need. But we know that there’s a big difference between what clients ask, want, and need:
- What the client wants is to increase online sales
- What they ask for is a digital marketing campaign
- What they actually need is to improve product information on their site because users don’t understand what it is and that prevents sales
So, when we gather requirements we focus on what the client wants and asks, which, as we just saw, may not necessarily be what they need.
The output of this activity is usually a (long) list of requirements. And the problem with that is that when we ask clients what they want, if we don’t include their request in our solution they will be disappointed and will feel like we didn’t listen. Worse yet, they may think we didn’t do our job right, especially if the requirements gathering process involved talking to stakeholders.
Assessing needs
When we assess needs all we do is observe. That’s it, we just observe. We don’t ask, we simply watch clients use the product, how they use it, what problems they encounter, what other tools they use, what the pain points are, frustrations and satisfaction too.
And only after we have observed them we can define the problem they need to solve and what the best solution is.
And the good part is, since the client didn’t ask for anything in particular, we don’t need to deliver any specific artefact, solution or feature. We’re free to think the best solution.
In short…
… Gathering requirements is like asking the patient to perform a self diagnosis and ask us what they want us to give them. Assessing needs is about listening to the patient, understanding the symptoms and based on that define a treatment plan.
Because if the patient has a headache it is our responsibility to decide whether to give them an aspirin or perform a few tests to see if what they really need is a pair of glasses.
In the first case we’re foregoing our responsibility and doing what the patient asks, in the second we’re using our skills to understand and address what they need.
