If you look at the figure below, what was the first thing that came to your mind..? Take ten seconds to formulate an answer.

I bet it wasn’t: “Thats a great mockup from a functional design about 3D-modelling in Google Earth”? But, as you might’ve guessed by now, that’s exactly what it is. What I’ve tried to do just now is try to expand your beliefs about what a “mockup” could be. For me software design is about taking the invisible and making it visible and that’s rule #1 from Test Driven Requirements engineering (TDR).

I have no idea how I would’ve ever put the picture below in words. Apparently a lot of software designers do, because what I normally see in functional designs is  a document almost completely devoid of images. How does that help their clients to understand what they pay hefty sums of money for. Answer: it doesn’t, at least not in a profound way.

We as software designers have to understand that the time is now to take software designs to another level. Software projects have been over time and budget for far too long and bad software designs have surely played their detrimental part. Visualizing the TDR way is giving your clients a front row seat, managing customer expectations and laying the groundwork for a piece of high quality software.

Next week rule #2: reverse engineer requirements