Define all constraints

A model must contain all of the constraints.

Technically satisfying the constraints in a specification may not always meet the client’s expectation.

For example, in the design of a telecommunication network, the problem description might demand that every pair of nodes in the network must have at least two paths between those nodes for robustness and reliability.

To meet that demand, one might design a model, taking into account that constraint on every pair of nodes. In a first-cut of that model, CP Optimizer could find a solution that is quite logical: the solution consists of a huge loop, passing through every node. Since a such a loop can be traversed in both directions, this first-cut solution technically contains two paths to between every pair of nodes, though the paths between some pairs may be rather long. When the solution is shown to the client, however, the designer learns, alas, that solution is not acceptable in practice, so the designer goes back to the phase of describing the problem again and adds constraints on the length of paths between pairs of nodes. In consequence of this change in the problem description, the model and the implementation must change as well.

A better problem description in the first place (one that included all the constraints, especially those on the lengths of paths between pairs of nodes) might have avoided this repetition. Certainly a sound initial problem description is the surest safeguard against the infamous encroachments of an incremental specification.