5 Ways to Spec a System
October 20, 2016
You’ve decided you need a system developed, or perhaps a new website.
What next? How do you turn your business objectives into clear instructions for software developers to create a system that will fulfil your needs?
1 Write a Spec
The traditional approach is still used widely. Sometimes it’s used in conjunction with other approaches, eg writing small specs during Agile development, sometimes referred to as ‘Stories’.
My view is that you should always start with some kind of written statement of what you intend to develop. Doing so focusses ones thoughts and leads to further insight.
Problems can arise when too long is spent on this stage and either the business has moved on in the meantime, or the level of detail is more than can be reasonably worked out without reviewing a prototype or an initial phase of the development.
Is there a template for writing specifications? Yes, there many, but no one of them could reasonably by regarded as a standard for the industry. At The Bridge we have our won which we modify depending on the kind of system eg website, interface etc. A quick online search will reveal many to choose from.
I recommend you choose a template that is closest to what you are doing, and make sensible modifications that will enable you to ask the right questions. You should also ask your developers what they would like to see.
Then start writing, but don’t overcook it.
2 Agile
Agile is more than just writing software in smaller stages.
There are different flavours of Agile, but the key characteristics are small stages (often called Sprints, typically of 3-6 weeks each) and production-ready software at the end of each stage.
So it’s not the same as prototyping, or just breaking up a large project into smaller pieces. There also has to be usable software at the end of each phase.
At the heart of the Agile approach is the notion that it doesn’t make sense to try to specify large systems up-front – it’s too complex and subject to change as business requirements themselves evolve.
Of course by definition, you can’t accurately estimate a full set of Agile phases that represents the end goal. Only the individual Sprints are estimated. But the client can stop at any time, they aren’t committed to a long multi-period contract.
Once the principles are accepted, Agile can work very well. The only issues I’ve seen are when the client underestimates the involvement they need to commit to. Frequent iterations means constant feedback in the form of requirements (or Stories) and testing.
So accept the principles, and stay involved!
3 Develop a Prototype
Prototyping is another approach that reduces risk by taking smaller steps, but it differs from Agile in that it’s not intended to be a production system at any point, and there are no real guidelines as to how the process is supposed to work.
It’s an obvious way to go if what you are doing is breaking new ground, or you need a proof of concept.
I’ve seen it work very well using Excel as a way of specifying a system that contains a lot of complex calculations. The business user may be skilled in the use of Excel and so can quickly create and modify formulae until they are happy with the results. Then the development team working on the full system can more easily emulate and compare during testing.
In the right situation, with appropriate business users involved, this approach can vastly reduce risk and development effort.
4 Templates
This is commonly used approach for developing websites, rather than developing a bespoke site from scratch you can choose from a selection of templates.
Of course your websites will look like hundreds or even thousands of others, but if that’s not a problem then there is the potential to reduce costs and timeframe.
The other issue is that it may not be easy to add more complex functionality later on, so choose carefully.
May also be a good temporary solution, to be replaced later on as the business evolves.
5 Leave it to the Developers!
This might sound very risky, but in certain situations where talented developers understand the business very well, they are able to create useful applications, sometimes that the users of the systems hadn’t thought of.
Obviously this kind of development needs to be kept under control, with frequent deliverables. It shares features in common with Agile in that management overhead is kept to a minimum, and timeframes are short.
If you’d like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au