December 4, 2006
In an informal survey, Accelerance Global Partners report that over 70% of their clients have little or no specifications at the beginning of an engagement.
And yet, good specifications are a key success factor for offshoring.
One shortcut is to have the vendor collaborate with you to write the specification. This can be very helpful if you don’t have a lot of experience in specifying software.
But you have to be committed to describing your software. You can outsource the design and development, but not the responsibility for defining what your software should do.
So let’s assume you will write the specification for your software, maybe sharing some of the work with your vendor. What do you write? How much detail do you need to provide?
The answer depends on your software development strategy.
There are two software development strategies that are popular today – Waterfall and Agile. Which one you use depends on two major factors:
- How many details you know upfront about the behavior of your software
- The consequences suffered if your software fails
Some software requires high reliability and accuracy, because of terrible and painful consequences if a failure occurs. In this case, you must use a very formal process to design and development your software (often real-time systems) that may be difficult or dangerous to test (launching a rocket, for example).
Finding errors in such systems at the end of development cannot be tolerated, and therefore great emphasis is placed on the front-end requirements gathering, specification writing, and detailed design. These design documents are reviewed thoroughly before coding begins.
Coding then uses peer reviews, code walk-throughs, string module inspections, module integration, and rigorous testing by the designers. Such a formal software development process proceeds with great ceremony.
The old Waterfall style of software design has separate sequential steps from Requirements to Design and so on down through Coding and Testing until you get to the end of the project.
The waterfall approach is still the recommended way to communicate the desired behavior of your software when you need to build extremely reliable software or you are re-implementing an existing system.
For example, if you are re-implementing an existing client/server application as a new Software as a Service (SaaS) with the same functionality, then your old software is an excellent example of what the new SaaS application should do. Screenshots and live examples from the old software can be used to support a Waterfall strategy.
But it is rare to know all the details of what your software should do when you are at the beginning of a brand new software application project.
Observant software engineers have realized that they jump back and forth between the different waterfall boxes during the course of developing new software. Enforcing the sequential Waterfall process of requirements, design, and then development is artificial and counterproductive for new software application development.
Therefore, development of new software, where all the details are not known upfront, is best suited for an Agile strategy.
But if your software needs extremely high reliability and/or most of the details are already known, then use of the old tried and true Waterfall method will improve your chances for success when using offshore resources.
