Working Out the Project Specifications

Before you start to search for executive for your work, you should make some preparations. You need to figure out WHAT EXACTLY results do you want to get from the programmer. Without clear idea of the future application you may waste a lot of time and money in the endless e-mail discussions with the consultant. Without having clear specs you take a risk to be overcharged by the consultant, because then you will have to request a new program features during the development.

The best way to exclude this is to compose good specs.

The most possible purpose of the new system is to collect information and generate reports from it. The main way of information collecting in the Web are the forms. You certainly use a lot of paper forms in your everyday work. Try to create its electronical analogues using any HTML editor, or just draw it as a tables in Microsoft Word (you already have the ones, don't you ?) If it is difficult for you to use HTML editor, then scan the forms and send it to the programmer. Figure out what fields should be required in the forms and what should not. Keep in mind that each form processing result in the Web is some confirmation page, for example the page with the success/error message. Create the draft of such a page for each form and make a hyperlink from the form to that page (instead of Submit button). By doing that you will make the model of your application !!!

If you use some standard reports and want to have the same in the new application then give its examples to the programmer.

Decide how many users will work with the program. You may want to give access to the application to your workers, and maybe to your customers and suppliers. You should think out what kind of information should be accessible to each category of the users (customers should not see the orders and names of other customers, and mid-level workers should not see financial reports). By doing that you will design the access and security system of the application ! This should be done BEFORE the development starts; it is proved by experience that it is very expensive and difficult to integrate such a function when the application is done.

The ideal specs for the web-application is a set of HTML pages with links between it, including the forms and confirmation pages (see above). In another words it is a static model of application. It is also good to have a classical specs where you describe the application functioning requirements, input and output data, ways of info collection and processing, access sharing and so on.

Once you figured out the specs you should not change it during the development. It is very difficult to change programming concept and database structure once it were designed. It may cause more bugs and problems as the result than if you ask that feature before the development starts. Of course it is impossible to foresee all the issues when you compose the specs, anyway just keep this rule in mind. If you found some cool feature somewhere at the competition site, do not ask for it immediately. Write down it to the specs for the version 2.0. Once the system will be completed and tested out, you can schedule the new site version while the current version is already in production. In this way you can shorten the development time and therefore increase the return of investment.