Functional Specifications and Gaps

Most of you would have spent considerable time preparing, reviewing or reading through pages of Functional Specifications (FS) for your projects. In fact, functional specifications are the start point for most of the project leads, technical developers and system testers. If the FS is not of good quality, all the downstream outputs like the Technical Specifications, Functional Test Plans, etc will follow the GIGO (Garbage In – Garbage Out) rule.

In my experience in enhancement type projects, the FS, normally details all that is required from the system. It flows down from the business requirements. This would have been okay if the project is a green field new development project, where everything is to be built from the scratch. But in typical enhancement projects, where there are modifications to be made to an existing code base to satisfy the new requirement, if the FS is a compilation of all that the system should do, it becomes no more than a user manual. And subsequently, when the development teams and the testing teams review the FS to figure out what changes are required to be done or what is to be the focus area of testing, they again have to fall back on the author of the FS or some other person with knowledge of the existing system, to point out the specific area of change. This clarification takes a lot of time and effort which could have been saved if the author of the FS clearly specified the area of changes.

Ideally, the FS should contain a section on the gaps between the existing functionality and the required functionality. For larger implementations, the Gap document should be a standard output for each functionality that is required.