By Igor Polkovnikov, 2020
Working while employed at large companies, I was at times confused as to what was considered to be a requirement and how a specification differs from it. Upon reading more about it, I have discovered the absence of a precise definition of a Requirement. All explanations are vague. I offer here a precise definition which should provide clarity.
Requirements are the description of a problem to solve
(many problems, as is usually the case).
Specifications are the way to solve them.
Requirements define WHAT should be solved,
Specifications - HOW.
This definition itself solves many problems during the early stages of design.
1. In practice, requirements, or whatever is understood under them, are often changed or modified. This is a continuous disaster for development. This happens because requirements are replaced by what the Specification should do. It describes HOW the problems should be solved rather than WHAT should be solved. It results in re-design, which is always painful. A developer is unaware of precisely WHAT has to be solved. This gives rise to micro-management. It suppresses strong and inventive solutions. Providing an answer to a problem within a requirement is a mistake. There is only one condition when requirements may be changed or modified from within the development unit. I'll show it below.
2. In practice, specifications are demanded to not be changed. That leads to design un-flexibilities, where after diligent exploration of possibilities a better solution might come later. Any problem can be solved in multiple ways, and a variety of problems multiply this. When everything is taken in account, an optimal design should be found. Making specifications rigid limits creativity and leads to weak solutions which are painstakingly difficult to change later.
One common mistake in characteristics of requirements is the demand that they must be consistent: "The requirement does not contradict any other requirement" This is wrong! Requirements can be inconsistent. And they should be especially if problems needing solutions are difficult. It is the task of an engineer to find a solution which satisfies both "inconsistencies". If the elimination of inconsistencies are attempted during the stage of requirement development, the requirement lowers the level of the problem, and this is NOT WHAT THE CUSTOMER WANTS. It leads to weak solutions, which will be shown to be unsatisfactory. This eventually leads to requirement changes and expected disasters which follow.
Do not be afraid of inconsistencies in requirements
(or, in other words, contradictions).
They can be solved!
Inconsistencies are part of life and that is usually why new systems are developed - to solve them! Do not hide them in the first place.
Here we come to the question of when a requirement could be changed. A requirement (or, more correctly, at least a pair of them) could be changed when it is discovered that despite all efforts, the inconsistencies cannot be solved.
Specifications are developed on the basis of requirements. What does this mean? It is the process of invention, finding solutions to satisfy problems stated in requirements. It may require the research and development of pilot projects which may provide proof of an approach to a solution. If it is later found that solutions are not satisfactory, there is no need to change the requirements. One has to creatively re-think, re-invent, re-research, re-design. In this case specifications will change, but not requirements.
A well designed system will always perform better than required. That mitigates the possibilities of requirement changes. It is useful to understand that the requirements are only a low-bound for the system. When one's mind is set for "better than required", he may come to better solutions. They may be not better for the customer only, but also for the producer himself - being more effective, less resource consuming, and more patentable.