When number of (stateful) system elements grows linearly. the number of compound system states goes up exponentially. The only thing that may constrain this "state explosion" is the application of constraints on system elements and their interactions - in other words design of system architecture that is "not too dense" - posiible interactions between the elements are limited by "interface control documents", complexity of the behavior of the elements is restricted by careful specification of allowed behavior - and so it's done - in the very limited field of safety-critical devices such as medical equipment.
Other systems don't benefit from such rigorous design discipline leaving the complexity issues unsolved until the integration. One of the causes ( in my opinion) to such "lack of discipline" is the over-reliance on requirements. There is simply no way to specify restrictions on the allowed behavior on one hand and consrain the system structure on the other hand using a finite list of (hopefully) verifiable (or better still - falsifiable) statements. The main symptom of the inherent limitation of requirements specification technique is the phenomenon of the "requirements explosion" that is very similar to the "state explosion" - the number of requirements grows exponentially when the predicted (and not actual as in state explosion) system complicatedness (measured by number of elements and interfaces) grows linearly. Employing standards and regulations to constrain the system design only delays the realization that requirements are exploding - citing a single standard may enter hundreds requirements leaving the feeling that only handful of requirements are added.
The problem is worse in the "systems-of-systems" world. The linkage of two systems may be specified with a limited array of requirement leaving the feeling of simplicity whether the (already there) complexity of the constituent systems is overlooked. The same holds humans are allowed to interact with the system in complicated and often unspecified ways - there is no way to impose restrictions on human behavior using the requirements technique.
The (possible) better way is analyse the behavior patterns and system structures directly using modelling and simulation (M&S) instead of exploding the list of requirements. It's still unclear how to use the M&S in contracts - requirements are so adapted to negotiation and litigation and M&S calls to collaboration and risk sharing - but the future is out there.
So - simple requirements may lead to complicated system and then to complex behavior. Complicated requirements will certainly do so but in this case the "requirements explosion" may be detected and dealt with. Complicated "hidden requirements" masked by simple references will do so without ample warning risking problems in integration.
Conclusion - System Integrators have to look for complicated sets of requirements to detect early the future problems in integration - but most of all have to look for the complicated requirements hidden in the simple references. Requirements are the best thing - for the lawers!