Put your finger on the pulse of your specification?
The question of your system requirement specification is a very important one, for more than one reason! OK, in order to pinpoint a good system requirement, I have to know that you’ve looked over all the pages on this site at least. If you haven’t yet, you owe it to yourself to do so first, as this page makes reference to some points covered elsewhere on this site. If you have read on further. There are at least two main reasons why your table of specification is important that come to mind straight away. 1 – Firstly, to keep the initial outlay to a minimum while getting value for money, while fulfilling your table of specification. 2 – Secondly, that you are getting exactly all you need from a system and not getting what you don’t need from the system software requirement specification. I’ll tackle these points in that order of priority. Can good value for money can be seen in the price a person has paid for a system. "Only to the well-informed person" I think would be the correct answer here. Other people, with an interrest, will ask how much was it, but they will only really know if the cost is good or bad when the system is referenced against a specific system requirement specification performance. Anyone that doesn't know anything about machine information systems will probably ask next “what does it do for that amount then”. Now they’ll unwittingly be comparing how much you paid against what the system does for you. The likelyhood is that they won't ask anything else after that, either thinking it's worthwhile or not. What that person has done, in a nutshell, is what needs to be done in reverse before parting with any money. Work out what you need from a system. This is your table of specification, write it down so you can make an assessment of value with referance to a specific performance. Find out if a prospective system will give you what you need from it. This is what you should compare different system prices to and only systems that meet or exceed your system requirement specification. Don’t look at anything less than your table of specification? You won’t be getting what you need. But why exceed your system requirement specification? You may well find something that meets your needs with some extras that could be omitted at a reduction in price. Or those extras could be something, which you may need in the future and would work out cheaper to include them now as part of the package. Are you getting exactly what you want? Having decided that a system would benefit your production, working out what you want from it shouldn’t be too hard. Write a list of exactly what information you require. Under it, write a list of how you would like this information presented. Once you have refined this into all you want from a system, run over it to see if there is any duplication. For example, most systems will export a spreadsheet file. If this file can be made in the format of your existing software you could produce bar charts from that. This saves the need for programming bar chart functions into the software. Likewise at the other end of the scale, don’t opt for a system with integral stock control on the components used in production if you have that in operation separately elsewhere. Making sure you only get the information you will use is a quite important part of the selection process. Now you have your specification down on paper go to various sites on machine information systems and see what they can do with your spec. This gives you a real point of reference for the comparison of different systems. Ask if they will supply you with a demo version so you can get a feel for how their system will operate, most will do this free. After doing this you will have a good idea of how several systems will look, operate and of course cost, knowing they will give you what you want. I wouldn’t mind betting the cost is the biggest variation.
Go from here to Technical page.
Return from Specification to Home.

|