Requirements Are Always Wrong
As software engineers, we tend to operate under the assumption that our job is to take a set of requirements as input, and emit a bunch of code that meets those requirements as output. If our code does what the requirements say, we give ourselves a big high-five and walk away believing that we’ve done our job. It is a comfortable (for us) modus operandi, and allows us to conveniently place blame elsewhere if the solution we build doesn’t actually solve the problem it was intended to solve: if the requirements aren’t correct, that’s not our fault.
It is a fiction.
Requirements are always wrong, and there is absolutely no guarantee that if we build a solution that satisfies the requirements we were given, it will solve any problem, much less the problem we were trying to solve. It is disingenuous of us to claim to be solving a problem when we know that we may not actually be doing so due to limitations of the requirements we’ve been given.
I’m not suggesting that requirements are always entirely wrong, or even mostly wrong. I do suggest that requirements are always at least partially incomplete, inaccurate, and/or inconsistent. And however correct a set of requirements is at the current moment, it is almost certain that those requirements will change and grow over time. We’re shooting at an ill-defined target that is constantly moving. We know that.
It is a pervasive problem. I suspect that it is a big contributor to the frequent failures of large-scale IT projects — the bigger the project, the harder it is to create a reasonably complete and coherent set of requirements. But it affects projects of all sizes, and is something that we as software engineers have to deal with (if we don’t choose to ignore it). However imperfect requirements may be, we need something to work off of after all— we cannot decide what to build based on throwing darts at a dart board or rolling a d20.
So what can we do?
Process can help, in particular Agile methodologies. Don’t be complacent though: Agile gives you an opportunity to validate requirements early and often, but that only helps if you actually put something in front of the customer and test it out. If you use an agile development process but don’t put anything in front of the customer until development is almost completed, it isn’t going to help. Don’t just iterate, iterate and validate.
You can also approach the entire process differently: rather than initially setting out to spend a large amount of money to build a solution, you can begin by spending a small amount of money to verify that you know what a proper solution is. A proof-of-concept can be a valuable investment.
Beyond process, what else can we as Software Architects do? (I’m assuming here that we’re all at least partially a Software Architect, even if our job title doesn’t indicate it — see my previous post on the topic).
Once we’re conscious of the fact that requirements are always wrong, we can begin to treat them as just a big set of assumptions, rather than as some sort of God-given law. Then we can use Software Architecture as a means of mitigating the risk inherent in big sets of assumptions. I’ve examined some approaches for doing that in more depth in a previous post, Assumptions make an Ass of You and Me: Using Software Architecture to Deal with Uncertainty in Developing Cloud-based Solutions. The basic idea is that we want to use architecture to give ourselves as much flexibility as possible so that when we recognize that our requirements are incorrect or incomplete we can adapt (relatively) quickly and easily.
So we have some options. It doesn’t have to be complicated or expensive to deal with the inherent limitations in the requirements that we are given — but it is essential that we recognize and acknowledge the problem.
It is reported that during triumphal processions Julius Caesar had a slave standing behind him, periodically whispering, “You are a mortal” (“Memento Mori”) in his ear to remind him that he was an ordinary guy and prevent him from getting a swelled head and believing that he was some sort of god. Spoiler Alert: it didn’t work, and things ended badly for Caesar. But maybe he was onto something (slavery aside). Think about it. What if we had some sort of chatbot continually reminding us: Requirements are always wrong… Requirements are always wrong… Requirements are always wrong…
