Requirements can be checked objectively.
Functional requirements specify a capability of the system and can be tested fairly easily. E.g. the requirement “As a user, I can click a button to get a funny cat picture” can be tested by assuming the role of a user and clicking the button. Did I get a cat pic? If so, the requirement has been fulfilled by the system.
Non-functional requirements specify a quality of the system, but this quality must be measurable or verifiable too. One quality is performance of the system. A wish “the system should be fast” isn't a requirement because it can't be tested, measured, verified. What is “fast”? A requirement like “The system can handle 200 funny cat picture requests per second” can be verified objectively through a load test, and therefore is a valid requirement.
If you are dealing with vague wishes that can't be verified, it's the job of a software developer to clarify them. Often, there is a more fundamental requirement underneath these wishes. Why is distributed installation important, why should cabling be reduced? Is there perhaps a hidden reliability requirement? What if you can satisfy the real requirement better by not using a distributed system? What is the maximum acceptable amount of cabling? Every feature is a trade-off: Can we trade in more cabling for some more important features?
While requirements should not generally prescribe implementation details of the system, it is often sensible to impose some design constraints, especially if they touch on an organization's strategic decisions. E.g. if a company decided to standardize on hardware from a specific vendor, the system will have to live within these constraints.
But not every requirement is equally important. Techniques like the MoSCoW method allow us to grade their importance (must, should, could, or won't) (compare also RFC 2119). Certain capabilities or qualities are desirable but not absolutely necessary. Your “as much as possible” requirements could be reformulated to be measurable, but have a middle priority. E.g:
- The system MUST continue to operate even when any one server fails.
- The system SHOULD use the same hardware and operating system for all servers.