In my home town the city built a complete new neighborhood, houses, roads and parking spaces, everything is new. Even the people. I don't know how it is in the rest of the world, but in Holland, such a new area has to have a new work of art. But for $300.000 the locals should have influence on the choice of what kind of concrete with holes and circles they want to have (yep, it's called 'participation').

The first requirement is put up by city hall: the art piece should reflect the struggle between man and the water (we live at the coast you know, 'the struggle between man and the government' would be more appropriate). Next, ten artists are asked to put in their suggestions. Vague drawings of holes and squares, circles and sockets, black and blue blurbs. Intended is that the inhabitants get an idea of what they can have in front of their doors. Everybody can vote (I make no funny remarks about the US 2000 elections, and that's difficult).

The three winners go to the next round. They make a detailed work drawing of the actual construction of their art piece. Is it steel? Is it placed in water? Is it green? Is it ugly? Based upon the final drawings the government chooses. Steel, water, green, ugly? Yep, yep, yep and yep again.

Software design and requirements management

You know, creating a piece of software is also a work of art. Luckily there is no voting with the residents, otherwise no system would ever be build. But the mechanism of taking a requirement and creating first a global drawing and afterwards a more detailed sketch is similar. We wouldn't be fair to the profession if we hadn't a great name for it: a design.

If we have good requirements, they will not say too much on how a system should be built. It should provide us statements on what it should do, in what context, and perhaps, sometimes, how it should be performed. All technicians that read the previous chapter would have wondered "where is my design?" Well, here you are.

Designs are in fact a way of communicating how a software system should be constructed. They are a description of what will be the end result. In this way, it's one of the earliest points in time, when stakeholders can see some glimpses on what is done with their requirements. So, when all the techies go to work, the project manager should make sure they maintain relations between the design choices and the original requirements.

Global and detail

What is global and how deep is detail? There you got me. Draw a line somewhere where you feel natural. If you look at a system as boxes, the global design places the boxes within a certain context, and their dependencies. The detailed design fills the boxes.

Another way of looking at it, is by functional versus technical aspects. The first design (or specification, for now the differences are too tiny to discuss) masters the points on how to handle the system from a user perspective; what should the user do and what will the system do? The second phase covers the technical implementation of the functional one. What data to manipulate? Which file to copy where? This approach reflects the opinion that techies can never lead the design process, the functional aspects rule!

Any way, you start your translation of the requirements to the real world by making designs or specifications. It is of course a communication tool for the technicians within their own species. But stakeholders want to see what happened with the things they yelled, and this is their first opportunity, so you better take care.

Related Links
Big Design Up-Front