Steve Etter
Lifetime Supporting Member + Moderator
Hi guys,
In the past we have often discussed the need for thorough specifications for jobs to be quoted. Since I have never had to go outside my own shop for program development before, my abilities to develop a decent spec in that area are notably lacking.
I am hoping someone might have a nice guideline for developing program specifications and requirements.
For my particular application, I already know all my I/O and equipment...none of that is an issue. What I really don't know is how to cover all my bases when defining the program in advance.
I imagine some of you will wonder how I can know all my I/O without already knowing and understanding everything the machine must do. Well, I do know. The kicker is that the software will have to do a great deal of behind-the-scenes calculations and such and that is the part I need to contract out. What I am afraid of is my own inability to write the specification tightly enough without being too tight at the same time (if that makes any sense).
What kind of wording is best? To what level should I try to define my functions? Are there typically programming things that are "understood", and if so, what might those be?
In the end, I have little doubt that I will end up with the machine working as needed. Of that I am confident. What I want to prevent is a lot back-end development time and added expense. This needs to be a win-win situation for my company and the programmer.
Any thoughts or ideas will be greatly appreciated.
Steve
In the past we have often discussed the need for thorough specifications for jobs to be quoted. Since I have never had to go outside my own shop for program development before, my abilities to develop a decent spec in that area are notably lacking.
I am hoping someone might have a nice guideline for developing program specifications and requirements.
For my particular application, I already know all my I/O and equipment...none of that is an issue. What I really don't know is how to cover all my bases when defining the program in advance.
I imagine some of you will wonder how I can know all my I/O without already knowing and understanding everything the machine must do. Well, I do know. The kicker is that the software will have to do a great deal of behind-the-scenes calculations and such and that is the part I need to contract out. What I am afraid of is my own inability to write the specification tightly enough without being too tight at the same time (if that makes any sense).
What kind of wording is best? To what level should I try to define my functions? Are there typically programming things that are "understood", and if so, what might those be?
In the end, I have little doubt that I will end up with the machine working as needed. Of that I am confident. What I want to prevent is a lot back-end development time and added expense. This needs to be a win-win situation for my company and the programmer.
Any thoughts or ideas will be greatly appreciated.
Steve