You know from experience that users don t understand what you re doing until they can play with it, and then suddenly they have all sorts of ideas and requests about what it should really do. A system specification is usually just a document that people often don t read carefully, but they can see exactly what you mean if you let them experiment with a running program. Things will always be about four times more complicated than you imagine they will be, so try to be conservative about what you can accomplish. If you haven t done something before, it s imperative that you quickly find out whether or not it s even possible otherwise, you ll end up wasting a lot of money building a program that ultimately won t work. Resist the temptation at this stage.
Premature optimization is the root of all evil.
While optimization can be a key factor on some projects, it makes no sense to optimize before you know if the program is feasible. Explore the problems before building the system. You should focus on this area first, and create a test program or prototype to find a solution to that problem. Until you know whether you can do it and how difficult it will be, you have no way of knowing if the project can succeed, how to schedule it, or how much it will cost. Use the right tools.