“Inadequately defined requirements” has been for decades one of the biggest reasons software development projects go way over schedule and budget, are often canceled, or fail to result in a useful product. Many studies have concluded this. Here’s one oldie but goodie. I have participated in many atrocities of this nature myself. But these criticisms miss the point, I think. Requirements Gathering itself, as a method, will always be doomed to produce bad products. In this post I outline some of the reasons why, and it is meant as an intro to a solution to the problem, which I will write about later.
Requirements Gathering is typically the first phase of a software development project, but it has its parallels in non-software design. This is the part where the systems analysts or business-process analysts figure out what potential users want from the product. The satisfaction of these wants will be end-result of a successfully implemented product.
There are three presenting problems with this approach
- It is often nearly impossible to know who your “users” will be, except in very narrowly defined situations, such as accounting software.
- Users often don’t know what they want, or what they need
- What most users say they want is often not very relevant for what they will actually find useful
But perhaps the most fundamental problem has to do with the whole frame of this approach: it bypasses problem-definition and starts with solutions. But solutions to what?
Designing this way is like designing by committee. It results in an incoherent laundry list of ideas, and there is no way to tell if you’ve captured all of them. There is really no way to know what “all of them” means. What you have is a list of possible features: but the fundamental question still remains: what is the purpose of this product? What is the purpose that will meet what needs? You need to know this first, before you can even ask potential users the right questions. Requirements-gathering leads to products with no focus, no core direction. No way of prioritizing features, except by voting on them, and they are vulnerable to whims, politics, and power.
Another way of looking at it: a product is a solution to a problem. By asking users what they want, you are asking people to come up with solutions to an as-yet unstated problem. You can implement all the solutions, and end up with something that doesn’t actually solve the real problem, because no one figured out what that really was. This may seem obvious, but it happens all of the time. People will keep coming up with more solutions, and they will change their minds during the implementation, because there’s nothing underneath it to guide it to tell if their requirements were the right ones, or whether any are missing. There’s no purpose. This is, after all, a planning problem.
Without a clear purpose and a clear hierarchy of “means” that rigorously “rolls up” to the purpose, you’ll never know when you’re done, or if you really succeeded. The underlying architecture of the product will be horrible, because sound architecture—both internally and in those external interfaces of the product the form the user’s experience—is a mapping of the product’s purposes on to the product’s features for the sake of usability. Without sound purposes, bells and whistles will vie for supremacy, the features will be disorganized, important ones will be missing, incorrectly defined, or irrelevant. Software architects won’t really know what they are doing. Ask any software architect or programmer: they hate requirements documents. They can’t design from them.
I don’t know how this awful method arose. But I would guess it arose from the failure of autocratic design methodologies whose principal focus was technology, rather than users and their problems. That is, arguably, worse. But what we have now is no solution.
What’s needed is a quite different approach, requiring a quite different set of ideas and skills from those that either users or techies can provide: digital product-innovation development.
“Inadequately defined requirements” has been for decades one of the biggest reasons software development projects go way over schedule and budget, are often canceled, or fail to result in a useful product. Many studies have concluded this. Here’s one oldie but goodie. I have participated in many atrocities of this nature myself. But these criticisms miss the point, I think. Requirements Gathering itself, as a method, will always be doomed to produce bad products. In this post I outline some of the reasons why, and it is meant as an intro to a solution to the problem, which I will write about later.
Requirements Gathering is typically the first phase of a software development project, but it has its parallels in non-software design. This is the part where the systems analysts or business-process analysts figure out what potential users want from the product. The satisfaction of these wants will be end-result of a successfully implemented product.
There are three presenting problems with this approach
- It is often nearly impossible to know who your “users” will be, except in very narrowly defined situations, such as accounting software.
- Users often don’t know what they want, or what they need
- What most users say they want is often not very relevant for what they will actually find useful
But perhaps the most fundamental problem has to do with the whole frame of this approach: it bypasses problem-definition and starts with solutions. But solutions to what?
Designing this way is like designing by committee. It results in an incoherent laundry list of ideas, and there is no way to tell if you’ve captured all of them. There is really no way to know what “all of them” means. What you have is a list of possible features: but the fundamental question still remains: what is the purpose of this product? What is the purpose that will meet what needs? You need to know this first, before you can even ask potential users the right questions. Requirements-gathering leads to products with no focus, no core direction. No way of prioritizing features, except by voting on them, and they are vulnerable to whims, politics, and power.
Another way of looking at it: a product is a solution to a problem. By asking users what they want, you are asking people to come up with solutions to an as-yet unstated problem. You can implement all the solutions, and end up with something that doesn’t actually solve the real problem, because no one figured out what that really was. This may seem obvious, but it happens all of the time. People will keep coming up with more solutions, and they will change their minds during the implementation, because there’s nothing underneath it to guide it to tell if their requirements were the right ones, or whether any are missing. There’s no purpose. This is, after all, a planning problem.
Without a clear purpose and a clear hierarchy of “means” that rigorously “rolls up” to the purpose, you’ll never know when you’re done, or if you really succeeded. The underlying architecture of the product will be horrible, because sound architecture—both internally and in those external interfaces of the product the form the user’s experience—is a mapping of the product’s purposes on to the product’s features for the sake of usability. Without sound purposes, bells and whistles will vie for supremacy, the features will be disorganized, important ones will be missing, incorrectly defined, or irrelevant. Software architects won’t really know what they are doing. Ask any software architect or programmer: they hate requirements documents. They can’t design from them.
I don’t know how this awful method arose. But I would guess it arose from the failure of autocratic design methodologies whose principal focus was technology, rather than users and their problems. That is, arguably, worse. But what we have now is no solution.
What’s needed is a quite different approach, requiring a quite different set of ideas and skills from those that either users or techies can provide: digital product-innovation development.
