Lurking inside the idiocy of the document-as-a-product mindset that has metastasized across engineering domains globally, resides the most stupidized, bastardized, mutated entity ever: the requirement. Why the sudden acidity, you may ask? Because engineers managed to find yet another way of making themselves unable to see the forest for the trees: fabricated requirements (trees) eclipsing the essential conceptual design (the forest).
Requirements have become a robotic instrument used just for appearances, to create an aura of ‘thorough work’, only to end up being disconnected both from what the customer wanted and from what the design will end up implementing. Because, at the end of the day, reality will provide enough calibration down the road to adjust the latter with the former. Sooner than later, the design activity adjusts to what the customer wants (because there are reviews, demos and trials as the project goes and customers will express how they feel about it) while the requirements will sit there inanimate, stating things that someone came up with only for the sake of filling pages and complying with deliverables.
The way we seem to be doing requirements at the moment—that is, jumping to fake them before we even remotely know what needs to be done—they add not just zero value to the engineering design process but in fact they bring a negative contribution, because you still need to input energy to write them and organize them.
Requirements do a total disservice to the otherwise noble task of getting to know what your customer wants and coming up with a concept out of it. There is beauty in witnessing the first steps of a project related to designing a complex thing. The confusion, the ambiguity, the sense that everything is to be defined and up for grabs. It is enjoyable to interrogate the stakeholders with questions and try to understand what the heck it is they want. It is interesting to mine their minds because it also teaches about communication; human communication. There is a certain magic in the process of guiding customers—who may legitimately not fully know what they want—and helping them converge into something, not without a dose of opportunistic nudging so they end up choosing something that makes sense for us; that’s the fee we charge them for helping them figure things out.
When did we forget to do conceptual design?
The joy is killed when the bureaucrats step in and start to parrot about requirements and documents too early in the process when you still have no clue what is the problem you are trying to solve in the first place. Imagine you are feeling bad and you go to the doctor and the doctor gives you a prescription before even checking what is going on with you. Would you take that pill?
By the way, I happen to be fully aware of the heresy I am committing here, considering that requirements are, in Systems Engineering circles, sacred. I am aware of the risks I am taking by turning the powerful industry of the requirement against me. I have nightmares where furious hordes composed of the authors of the myriad of books about Requirements Engineering (don’t you love that oxymoron?) and Model-Based Requirements Engineering (a turbo-charged oxymoron) come to my door asking for my head.
I have a theory: the problem with requirements is not malice from engineers but just their incapacity of breaking down work in a sound manner. And the bureaucracy pressure does not help. When an engineer is pressed to define a Work Breakdown Structure (WBS) so the project managers can transform it in a collection of work packages1, then the engineer may easily neglect or underestimate the conceptual design stage and jump right into requirements phase. What is more, my theory is that some may use “requirements” as loose, more formal synonym for “trying to figure out what to do”, when in reality both are two very different things. Every project should have a “trying to figure what to do” phase and no one should be ashamed of it, because it would feed the requirements phase very well.
The right sequence is, and should have always been: first you talk to your stakeholders, you ask your questions, you do your homework, you understand the problem well, then you go and write whatever you want.
Requirements are not, and should never be written directly. Requirements are analyzed into existence. Requirements are a to-do list which gained, for reasons that are beyond me, too much relevance. Flowing down requirements is just unpacking your to-do list a bit better to further understand the work to be done.
In a normal world, requirements are purely a transcript of a conversation between you and your customer in a set of concise phrases.
End of the story.
What a terrible invention the work package and how much we are not discussing that a work package is basically a silo in disguise