Calling all LV Architects and Developers: advice required on Build Specifications and Requirements

Question

This is a call to all contractors, consultants, architects etc...
I have been asked to develop and automated test system...  
Long story short - can anyone offer me an example or two or copy of  a specification and requirements document given to them by a company that is in need of a labview system, which specifies what it needs to do, what it should look like, how the data should be stored etc...
The reason I ask is that I have not been given any spec.  And trying to build a system without one is non-sensicle to me.  I am fairly new to labview as well.
The way I see it is that if a job goes out to tender for quotes from different contractors, surely there must be some kind of spec document so that they can give their quotes and understand how to build the system from the ground up and plan ahead.
maybe it should include things like:
Including:
Types of tests
Things to be tested
Who will be using it? Testers/engineers/analysts?
Who will maintain it? What skills do they have?
What should it look like? Colours, menu’s test result feedback format(s)…
What features and functions do they want?
How much test modification control does it need?
Please feel free to add to this list
Hope you can help/advise.  all comments welcome.. Thanks all

Answer 1

Let's get some things straight first:
There are no companies in the world in need of "LabVIEW system". There are companies in need of automated test systems, for which LabVIEW is suitable choice. But this choice is mostly made by you, not by the client. If client explicitly asked you to do it in LabVIEW, he's still in need of test system, but one of the additional requirements might be LabVIEW ("We're standarized for NI hardware" or "Mr. Smith here knows LV, so you'll sell us codes and he'll be able to modify them", etc).
Specifications given by clients are rare. In-depth specifications are unicorns. Most clients would just give you "hey, we want to measure this and check that". And that's just ok - they're not experts in automated test systems, you are. They're just their domain experts. That makes YOU responsible to gather requirements for their test system by cooperating with them. If they knew what exactly is needed to archieve their goals, they'd just do it without your help (or hire you as mindless coder).
No one would probably just give you any specification here. At best such specification is company know-how, but most common it's just proprietary information.
Requirements gathering is hard. Mainly because they're changing. And there are no silver bullets, no "template documentation" which you can just fill and everything would be clear.
Now, adding to your questions list:
What do we automate? Why? What do we want to archieve?
What will be measured? How? What are specifications of measurements (sampling rate, accuracy, etc)? What hardware do we need?
What are the use cases for the system? (you can look up "use case" in internets; this is also closely connected to "Who will be using it?)
How we'll decide that the system is complete and working (Will we have some functionality check list? Is there any calibration required? Do they have any procedures - MSA, etc? Should we provide training?)
Would it be easier if you'd make some demo to show?
...and that's just the top of the ice berg