One of the common issues software designers wrestle with when defining the solution to a client’s problem is how much detail to include in the solution design documentation.
Agile development proponents would argue for very little, the so-called ‘No Design Up Front’ (NDUF) approach with few formal documents and an emphasis on flexibility and incremental delivery of working software. The possible pitfalls of this approach were illustrated by a recent episode of Kevin McCloud’s Grand Designs, when a client insisted on proceeding with the renovation of a 19th century Irish castle – worth a million Euros – without any design documents. It’s probably not spoiling the episode too much to reveal that all did not go smoothly!
At the other end of the spectrum is the highly detailed ‘Big Design Up Front’ (BDUF) approach, with high formality and very detailed documents that are reviewed and signed off by clients before development commences. At its extreme, this approach is characterised by ‘analysis paralysis’, where the specification & design phase continues indefinitely without ever producing a working system.
So which approach is best?
I like Grady Booch’s pragmatic ‘risk management’ approach to this issue, illustrated by comparing it to a building project: If you’re building a doghouse, you can probably envisage everything in your head, and no detailed plans and elevations are needed – the risk if you get it wrong is minimal. If you’re building a second storey extension to your house, with a couple of rooms and a new bathroom, you probably want to see some structural engineering drawings, a variety of elevation drawings, and maybe some sketches of how it will look inside – the risk if you get it wrong is significant. But if you’re building a high-rise building… well you get the idea.
It’s the same with software enhancements to Dynamics NAV – if you’re just adding a few new fields to a page or report, you don’t need a formal design document, but if you’re enhancing some of the core modules that will add significant functionality and value for a client, you should expect to see a concise design document that explains:
- Why the enhancement is needed (the business case)
- How it will work from the client’s point of view (the main use-cases)
- How it will work from the product’s point of view (technical detail for the developers)
Once the functionality is completed, you can compare the final design based on what was originally documented and see whether those benefits and outcomes are realised as expected.
