Creating software is often said to be an art – this is true to some degree, but at its core, building software is an engineering task. Software is usually made to serve a purpose or solve a problem and as much as possible, functionality, delivery dates and costs should be known in advance and met when the software is delivered. To do this you need to spend time up-front gathering requirements, working out the technical details and breaking the work into manageable tasks; and then costing it. This will help you make promises you know you can keep and may mean the difference between success and failure.
Before you begin
Talk and think about the project. Talk to users and client and gleam as much information as possible. Try to get them to put as much as possible into writing. Clients are usually not software professionals so they will omit things; work with them to get a clear picture of what they really want to do. Don’t worry about the implementation at this stage, just think about the real world implications of what they want.
Requirements
Once you have an initial understanding of the requirement start creating a Requirements Definition (RD). The RD will contain an overview of what the problem is, and the proposed solution. This should be understandable by everyone involved in the project.
Cover all the tangibles: benefits, features, efficiencies, etc. that should be delivered. Then describe the solution. It is often a good idea to scope the development and mention what isn’t covered too. Be as detailed as possible but use judgement - there is no point writing a 20 page requirement document for a 2 days project.
In a big project, it’s often a good idea to break the requirement into several stages that can be built consecutively but are useable on their own. This will allow the client to control her costs and force prioritisation.
It’s important to get the RDF approved. Make sure the person signing-off understands it and make sure it is as close as possible to their initial dream. It is often necessary to revise this a few times and move feature in, out and around.
Technical Design
The audience for this is mainly internal; this is meant as a guide for the development process. Its purpose is to allow you to budget and schedule and may feed back into the requirements documentation. It is then used by the developers implementing the software.
The most important thing to cover here are the processes in the software. The business rules, algorithms, data models, etc that your software will implement.
Don’t try to capture every detail of the program, by the time you’ve done that – it’s already written. Only cover things that aren’t obvious. The size of the project is a guide to how detailed this should be.
In addition to a written document you may need to produce some of the following: Use cases, data models, screen designs, class designs and state diagrams.
Work Order
This should be the final output of the design process. The work order is a list of tasks and materials needed to build the software.
This can be broken down in various ways. By the headers in the RD, by type of professional or anything else that makes sense.
A separate work order should be created for each phase of the development.
Some items to include in addition to project specific ones are: testing, documentation and training.
If there are any third party requirements: hardware, software or otherwise, mention them here.
We have done a considerable amount of work at this stage but still no software has been produced. It’s a good idea to make the client aware of this in advance and try to agree a fee in case they decide not to go ahead with the project.
Finally
In practice it is very hard to think of everything in advance and the price of a project is usually decided by what the customer is willing to pay. Focus on understanding what’s impotent to them and what they want to achieve. Be sure to build enough time into your estimates for anything you’ve missed during the design phase. Allow time for reworking based on customer feedback. Use your gut but don’t rely on it. If the algorithms are complex or if the requirement is to use a piece of third party software: it may be a good idea to spend time proofing the solution first so you are confident that you aren’t getting into something you can’t control.
Talk to your customers and users during the development process, show them youre progress and make fine adjust as you go along. On the other hand – don’t be tempted to rip everything up and start again. Identify problems and address them directly as quickly and painlessly as possibly – using as few resources as possible.
Good Luck!
