Requirements define what a product must do — a documented expectation of the outcome of a project's implementation. This document captures the expectations of the customer as well as those of the developer regarding the program, its functions, and the project as a whole. Requirements encompass characteristics, cost, schedule, and risks. Thus, requirements represent a statement of what you need to develop, or a precise quantitative description of what you expect to obtain as a result of the project's implementation. Poor requirements definition is the primary cause of problems during project execution.
Requirements specify what must be done, how well, and under what constraints. If the requirements are wrong, the project and product will be flawed. Requirements, constraints, and assumptions break the problem into parts. This determines the overall success of the project.
Types of requirements:
- Functional requirements define what a given system element must do.
- Performance requirements define the quantitative parameters of the corresponding functions performed by the system.
- Constraint requirements arise from operating mode limitations, environmental conditions, safety considerations, or regulatory compliance.
- Verification requirements provide confidence that the system possesses the specified characteristics in its actual operating environment.
- Interface requirements define the functions, characteristics, tolerances, and constraints of all interfaces.
- Operational requirements specify the system's operational readiness, focusing on system performance, while also defining how the system interacts with users.
In English-language literature, the acronym SMART is used to remember the characteristics of good requirements.
- Specific — requirements must address only one feature of the project or characteristic of the system. They should be formulated in terms of what must be done and how well, but never in terms of a possible solution — how to do it.
- Measurable — a measurable parameter is expressed objectively and quantitatively.
- Achievable — a requirement must be technically achievable at a reasonable cost.
- Relevant — a requirement must correspond to the chosen level of the system.
- Traceable — lower-level requirements must explicitly derive from and/or be supported by higher-level requirements. Requirements without "parent" requirements are regarded as "orphans" and must be assessed for the necessity of their implementation.
Necessity. If there is doubt about whether a requirement is needed, simply ask: "What harm will come to the system if this requirement is not included in the list?" If you have no answer, the requirement is probably unnecessary.
Verifiability. As soon as a requirement is formulated, it is necessary to determine how it can be verified. To do this, an appropriate compliance criterion must be selected.
Achievability. To be achievable, a requirement must be technically feasible within the given schedule and budget, subject to additional constraints. If there is uncertainty about the technical feasibility of a requirement, an appropriate study or further investigation must be conducted. If uncertainty remains even after that, a goal should be formulated rather than a requirement. It is clear that even if a requirement is technically feasible, it may be unachievable due to cost, schedule, or other constraints such as weight. It is pointless to formulate a requirement for something that is impossible to accomplish; one must be pragmatic.
Clarity. Each requirement must express a single idea and be concise and simple. It is important that the requirement be clear and unambiguous. Good requirements often need nothing more than simple sentences.
A requirement should be stated in a positive manner and should never begin with a negation. It must be grammatically correct, free of typographical errors and omissions. Consistent terminology must be used at all levels of the system.