There are a nearly limitless number of opinions about how – or even whether – requirements should play a role during development.
Wherever you fall along that spectrum, welcome!
Because we are all human, each person’s viewpoint is based on their own relatively narrow personal experience. The danger that creates is being overconfidently “right” within a narrow working context and unknowingly “wrong” everywhere else.
In this short article we’ll introduce seven fundamental truths – things that a lifetime of experience has taught always apply to the relationship between requirements and development – and leave it up to you to retain or revise your view.
Truth #1: Requirements Define the Specific Future We Will Call Success
Everyone has struggled to make headway on a creative assignment. You devote enormous amounts of energy but make very little progress – until an almost magic point arrives where there is enough definition that the remaining effort becomes mechanical and almost completes itself.
The 1st reason you should personally care about requirements is that – when done properly – they provide the essential framework you need to get started, thereby increasing your productivity and lowering your stress level.
Truth #2: Requirements Create a Single Definition of Success that Can be Shared by All
Everyone has at some point in their career been stuck on a team whose members held divergent – even conflicting - views of success, and no rational person would want to repeat that experience. A team can’t be “right” if even one of its members is wrong.
The 2nd reason you should care personally care about requirements is that – when done properly – they focus everyone’s attention on the real task and avoid pointless frustration.
Truth #3: Poor Requirements are Costly
Everyone has struggled to please a boss that can’t (or won’t) actually tell you what they expect. Even if you eventually satisfy them, you are guaranteed to take far more time, energy and abuse than the task actually warranted had everyone just been clear up front about what they wanted.
The 3rd reason you should personally care about requirements is that – when done properly - they help leaders effectively match valuable talent like you to meaningful tasks, and help protect you from association with embarrassing cost, schedule and technical surprises during development.
Truth #4: The Goal is “Good Enough”
Everyone has been at the point where they have a clear idea of what is expected and thereafter are simply being delayed and disrupted by excessively detailed instructions. It is especially frustrating when your boss tells you exactly how to do a job you’ve mastered but they have not.
The 4th reason you should personally care about requirements is that – when done properly – they enable management to leverage your talent and experience rather than micromanage it.
Truth #5: Too Much Definition Costs Innovation
Everyone has experienced what should be a simple task – such as grabbing coffee for a colleague – turn into an onerous and potentially impossible quest due to overspecification. The more requirements you impose, the smaller the number of solutions there are to choose from, and eventually that number becomes zero.
The 5th reason you should personally care about requirements is that – when done properly - they leave you room for innovation, creativity and skill rather than tying you down in unreasonable ways that just make the entire task difficult or even impossible.
Truth #6: Too Little Definition Costs Lives
Everyone has experienced unexpected challenges within apparently simple tasks they confidently took on, and observed weakness in the systems we ourselves encounter. Billions of lives are now dependent upon highly complex systems. Nothing – absolutely nothing – is simple when done well, and the decisions we make during design always impact people in some way.
The 6th reason you should personally care about requirements is that – when done properly – they offer the best protection individuals, companies, nations, and even civilization itself has against breakdown in the systems we all depend upon.
Truth #7: Requirements are the Language Development
Everyone has experienced the ease of working with others who share a common concept vocabulary and can thus communicate very effectively. There is sheer joy in being part of such a community, and the larger the group that can share a common vision, the more spectacular the possibilities become.
The 7th reason you should personally care about requirements is that – when done properly – they enable you to interact with other development professionals far more effectively and can open up collaboration and personal enrichment opportunities you’ve only dreamed of to date.
No doubt you’ve noticed the universal “when done properly” caveat throughout this discussion.
No matter what you might have read or been told, there is no “single perfect recipe” for doing requirements well. Instead there is a broad functional obligation to reach shared agreement on intended direction, and countless ways people have found to make that happen.
The difficult truth here is that everything about requirements effectiveness in practice depends upon the situational match of method and underlying task need. Too little definition puts lives at risk, too much definition kills creativity and efficiency. Without someone acting as a skilled prescribing physician, the medicine of requirements can easily kill instead of cure the patient.
Your personal view of requirements has almost certainly been biased by the overall suitability and quality of the requirements management processes you’ve encountered.
Many of us have created complex, detailed requirements documentation for simple tasks that then became difficult as a result of over-specification. (Dumb, just dumb.)
More than a few have written requirements only as a contract deliverable to match what design had already released. (Going through the motions to get paid.)
Another may have experienced the painful consequences of effort that proceeded without clear direction and be certain that more definition is always better. (Fear driven over-response to managing uncertainty.)
I’d encourage you to consider that the problems you may have noticed always arise from patterns of misuse rather than any inherent fault with the idea of requirements.
I promise that the logic of using requirements as a tool to support development is pure, and that investing in your ability to effectively tailor methods to match a given situation will pay off handsomely!
Empty space, drag to resize
Login or sign up to start learningLogin to start learning
