Database and Software Specification Process

Having met and discussed requirements and a price, you may like us to proceed to drawing up a specification document. This is usually four to six-pages long.

Sometimes it helps if you can see what we envisage to be your requirements, so we build a proof of concept to navigate around the main forms; this does nothing other than look like a workable design.

At this point you recognise that the nuances of your requirements have escaped our understanding. Then, there is then a flurry of emails as the design takes on its final shape.

At the end of all this, you will understand what we intend to build in considerable detail. This also cuts down the need for training as staff understand the structure of the program and have a stake in it.

The final document will be structured along the following lines...

1. Requirements - A paragraph stating in broad terms what benefits you want the database to bring
2. History - Brief narrative of how you arrived at the decision to create this database
3. How Will It Work? - a description of the how data enters the system, is checked, rejected, modified, stored, displayed and reported on
4. Security provisions for the new system
5. Back-up provision
6. Quality standards for code (augmented by Github Copilot with the latest AI improvements)
7. Deliverables - a list of the main tables forms and reports
8. Response Times - a statement that response times will be acceptable according to local web transmission speeds and that the system will be robust and dependable
9. Our assumptions about your obligations regarding Data Protection
10. Concerns - we will list areas where we feel that your expectations may not be met - e.g. your network may be saturated or your bandwidth is too narrow.
11. Non-Disclosure and Data-Protection assurances
12. Price, VAT
13. Terms - invoice to be issued when the system meets the requirements in the specification and has been up and running for at a month. Payment is expected within 21 days
14. Copyright - to pass to you when payment is received in full
15. Timetable - a set of stages and a delivery date. Usually these are finalised after you have perused the specification
16. Changes to the Specification - a paragraph explaining that minor and cosmetic changes can be made during the build process, but major changes may require a price revision
17. Support - a paragraph asserting that we will fix bugs for free

Before starting development, review our Planning process or contact us to discuss your requirements.

Go to Planning