development (idea)

1. Deciding what to do (see User Requirements)
   • investigate the problem that needs to be solved by discussions with those parties suffering the problem
   • write down what they expect a solution to provide
   • do NOT write down how the solution should be provided
   • postulate a number of alternative solutions that could be employed
   • discuss these alternatives with the parties involved
   • select the most promising alternative for further investigation
   • make sure the parties want a solution and get some idea how much benefit they expect to get from it
2. Working out the details (See System Proposal)
   • break down the problem into more manageable parts
   • write down what these parts should achieve and what they contribute to solving the problem
   • discuss the parts (and the whole) with the parties involved
   • agree that all the parts are required
   • work out how to describe the problem in essential terms
   • discuss this model with the parties involved
   • apply the real world to the model and fix the bits that break
   • discuss the result with the parties involved
3. Working out how to do it (See Analysis and Design)
   • look at what's currently in use by the parties suffering the problem
   • decide whether it can be used - or modified - to fix the problem
   • if not, look for other existing systems that could be used - or modified - to fix the problem
   • if you fail, look for existing systems that fix some of the problem
   • work out what needs to be modified or created to fix the whole problem
   • write down how to prove the problem has been fixed
   • knock up a quick schedule of works and get tenders
   • discuss the costs with the parties involved and confirm the problem is worth fixing
4. Build the system
   • This is generally considered the easy bit
5. Making sure it does what it's meant to do (See "v model".)
   • collect all that writing down done earlier
   • demonstrate that the system does what you said it would
   • debug any faults (see also Debugging techniques)
6. Sending it off out into the big wide world
   • This may be considered passe... but even the Linux kernel has releases.

Never forget to go back to the top and repeat the process as often as you can.

"Parties involved" will tend to grow over time and must include the people who'll be using the system and the people who'll be supporting the system, otherwise you're going to be hated by one or other (or probably both) groups.

Little and often is a good motto - people get used to continuous improvement and start looking for things to make their lives better. This keeps you in work and them happy.