Ballpark estimates

If you need to design software when all you have is a set of requirements and a blank sheet of paper, where do you start? Often more importantly, how much will the solution cost? I tend to start with the big picture before breaking up the overall system into a number of different constructs.

I don't often talk about the requirements side of the software design process, but it's *really* important that some analysis is undertaken to understand exactly what needs to be built and why. I typically gather a first draft of the major requirements and, if the domain is new or complex, I'll additionally do some high-level domain modelling to flesh out the business concepts. Only then will I dive into the software design process, identifying the systems, containers and components.

The photos above summarise a typical software design exercise, which in this case had a fairly complex business domain. The problem with complex business domains is that you need to understand enough about it in order to be able to estimate how much it would cost to build a solution to meet the requirements. I prefer a very collaborative exercise where a number of people work together to design the system down to its components and services, using a CRC card approach. In this particular example, we probably spent about a day looking into the business domain/requirements and the same designing the system. The project owes me £4.68 for the index cards and Blu-Tack that we used, but we've been able to use this approach to decompose the overall problem and put together some estimates as a result.

While you *can* estimate a software system top-down from the big picture, I find it easier and more accurate to decompose the overall problem into a number of logical components/services and estimate bottom-up. You don't need to do big design up-front, but some design up-front provides a great basis to do some initial ballpark estimating.