As we described in Chapter 20, design constraints typically impose limitations on the design of the system or the processes we use to build a system.
We provided the following definition
Sources of Design Constraints
While the sources are varied, design constraints typically originate from one of three sources: restriction of design options, conditions imposed on the development process, and regulations and imposed standards.
Restriction of Design Options
Most requirements allow for more than one design option. Whenever possible, we want to leave that choice to the designers rather than specifying it in the requirements, for they will be in the best position to evaluate the technical and economic merits of each option. Whenever we do not allow a choice to be made ("Use Oracle DBMS"), the design has been constrained, and a degree of flexibility and development freedom has been lost.
Conditions Imposed on the Development Process
Another type of design constraint occurs when a requirement is imposed on the process of building software. These types of design constraints can often be found when specifying the team's developmental infrastructure. Here are some examples.
There may be many such sources and rationales, and the designers may have to accept them whether they like them or not. But it's important to distinguish them from the other types of requirements, for many of the constraints may be arbitrary, political, or subject to rapid technological change and might thus be subject to review or renegotiation at a later point.
Regulations and Imposed Standards
Typically, the body of regulation imposed by these types of design constraints is too lengthy to incorporate directly into your requirements. In most cases, it is sufficient to include the design constraints by reference into your package. Thus, your requirements might appear in the form "The software shall fail safely per the provisions of T ¼V Software Standard, Sections 3.1 “3.4."
Incorporation by reference has its hazards, however. Where necessary, you should be careful to incorporate specific and relevant references instead of more general references. For example, a single reference of the form "The product must conform to ISO 601" effectively binds your product to all the standards in the entire document. As usual, you should strive for the "sweet spot" between too much specificity and not enough. (We'll explore this issue further in Chapter 23.)
Handling Design Constraints
Almost all projects have some design constraints. Generally, the best way to handle them is to follow these guidelines.
Are Design Constraints True Requirements?
You could argue that design constraints are not true software requirements because they do not represent one of the five system elements in our elaborated definition. But when a design constraint is elevated to the level of legitimate business, political, or technical concern, it does meet our definition of a requirement as something necessary to satisfy a contract, standard, specification, or other formally imposed documentation.
In those cases, it's easiest to treat the design constraint just like any other requirement and to make certain that the system is designed and developed in compliance with that design constraint. However, we should strive to have as few design constraints as possible since their existence may often restrict our options for implementing the other requirements, those that directly fulfill a user need.