I think this is an excellent topic.
In regards to URS: Absolutely you want your end user to be involved in the requirements. Be careful though not to let others hijack this process and try to turn it into a commercial/contractual document. If there is a desire to make it part commercial in nature have something proceduarlized to distingusih between true validation/product quality requirements (Materials, Operating Pressure, Operating Temperatures) and Commerical Requirements (Dates of Delivery, Number of Workers to support commissioning)
In regards to an FS: That should definitely be a response from the supplier when possible. I would like to add to what has already been said in stating that we as customers should be auditing companies to determine their ability to work in our regulated enviroment. The postal audit from GAMP 4 (Produced by ISPE) provides a great mechanism to do so.
As a generalization - I would expect those companies with mature software development programs to support Category 4 and 5 software as defined in GAMP 4 to usually be capable of providing design specs. If they can’t it would be a red flag against the company and I would immediately consider either another vendor or if they were the only vendor what measures I would put in place to ensure the quality of that software. Especially if this is for high risk/critical gxp systems.
For “simple equipment” or low gxp risk equipment I would not be as fussed and much more inclined to do an inhouse FDS to support the manufacturers shortcomings. Ideally in these situations your requirements are minimal as well so the FDS is easy to generate.
As mentioned nothing is worse than sitting at OQ and not getting the functionality you needed out of the code. The costs of catching it then are so much more magnified then catching errors in an FS/DS or even at SAT/FAT. A good validation plan can go a long ways and be prepared to document your rationales.