There exists a common misconception among IT leaders and developers alike that functional specs are a waste of time for agile projects.
Agile projects have changed development processes by de-emphasizing the need for functional specs. However, functional specs can be and are, in some cases, just as important to agile projects as they are to traditional development projects.
The Value of Specs
Functional specs add great value to the iterative development process:
A valuable specs document leaves nothing left to interpretation and stands as an insurance policy to ensure that the client and development team understand all project requirements. To limit project failure, unexpected investment, and customer disappointment during the development process, avoid these common pitfalls:
- Documented specs streamline the development process and provide an element of discipline to overall development.
- They minimize communication problems and misunderstanding, and they keep everyone involved in the project on track.
- Since all specs must be approved by the client, developers have a good sense that what they are building is what the client wants.
- They address the growing need to document application functionality and draw attention to regulatory requirement/statutes and compliance.
The value of written specs increases in proportion to team size and turnover, geographic distance between team members, and the number of interrelated project pieces. Similarly, if outsourcing development, then it is critical to record detailed specifications if there is any hope of delivering the customer requirements.
There are situations where functional specs may not be required:
- The development team is small and working directly with the business and external clients on a frequent and ongoing basis.
- The project is being developed in an iterative manner with the use of prototypes and pilot releases, which act as the functional specs themselves.
- The requirements are neither many nor complex.
- The design follows an existing pattern or approach familiar to the team.
Level of Detail
The subject of detail is a common point of dispute for functional specs in agile project approaches. It is generally accepted that requirements focuses on the "what" of the product design while the functional specs focus on the "how," but not to the level of defining or developing the actual design. This is intended to give room for adaptability and changing requirements from clients while at the same time providing developers with some leeway to design the best solution.
Consider the following example:
- A team is given a set of requirements that tell them what is required by a client. In one case the requirements call for bread and in another case they call for beef stew. Remember, requirements focus on "what" not "how." This is where functional specs come into play – to start explaining the "how."
- Most cooks know from experience that they can get away with a lack of specification for cooking, but not for baking.
- As long as the team has the desired/required ingredients for the stew, then there is a lot of flexibility in the amounts of meat, spices, and so on that can be added and still result in a beef stew. The stew can cook for four hours or 24 hours and (as long as pot doesn't go dry) the end result is still beef stew. The specs, or how the requirements of making stew were to be met, offer a lot of leeway.
- Bread, on the other hand, needs a higher degree of specification. Baking requires that the ratio of baking soda to flour be correct. The amount of yeast must be clear, and the rising time, resting time, and baking time are specific. Only very experienced bakers dare to vary the specifications. The risk of failure in deviating from the specifications is quite high.
The detail level of functional specs is specific in order to identify the risk and complexity of the project at hand. Overall, the value derived from functional specs should be in direct proportion to the cost of mistakes and failing to meet the customer's requirements.
Bottom Line
Agile project approaches have changed development processes by stressing frequent releases and little or no documentation. Object-oriented analysis that drives use case modeling has de-emphasized the need for functional specs in agile projects.
