Today, a very common buzz in project management is ‘Agile’. Agile this, agile that… and when project scope and budget slip away everyone is ready to point fingers. When developing complex IT solutions for clients who want to be in step with modern business solutions we often come across clients who don’t have enough information to fully estimate the impact of digital transformation on their businesses. This is completely normal, considering the transitional characteristics of our society. Therefore, we must consult and work with our clients to establish mutual understanding and point to the exact scope of the project. In order to do that, we take a tool from our PM toolbox called Functional Specification.

A functional specification is a document that describes the functionalities which will be implemented as a part of the solution. The document outlines everything that is required for the solution to function within the given range, in addition to describing the inputs and outputs required for carrying out its processes. It brings together the results of the requirement analysis and the analysis of the existing situation.

The actual goal of composing the functional specification is to clearly define the workload that the designers and development experts have to do, but also for the Client to know the exact range of the system they are receiving. (Timms, 2012) rightly points out that functional specification describes how the system will work entirely from the user’s perspective. It doesn’t care how the thing is coded. It talks about features. It lists the key aspects that must be included. It specifies screens, menus, outputs, and so on. To make the very document, we organize a series of workshops to familiarize ourselves with the business processes of our Clients. Also, it is an excellent opportunity to get to know each other and establish a firm business relationship. By the end of the workshop cycles, we furbish the wants of the Client into their needs and point the finger around the scope of the project with mutual acceptance. When the team agrees that the consensus of the functional specification has been reached, the document is declared „complete“, and is verified with the signature of the Client’s project manager. After that, the software development and the testing team usually write the source code and test scripts using the functional specification as a reference. During the testing phase, the program behavior is compared with the expected behavior defined in the functional specification.

You know you’d like to see it!

Send me an email and I will gladly share with you my template of the Functional Specification.

After laying out the field for such a fruitful business relationship, managers of both teams have to hold the fences and let the magic happen. As (Douglas, 2018) says, functional specification documentation keeps all team players on the same page, working from one source of truth. Deviating from that can result in a poor project and frustrated individuals so for the benefit of everyone’s stress levels, it’s best to create a well-thought-out spec.

References:

• Douglas, S. (2018, July 6). Functional specification documentation: Quick guide to making your own. Retrieved from JustInMind: https://www.justinmind.com/blog/functional-specification-documentation-quick-guide-to-making-your-own/
• Munson, J. C. (2006). Software Specification and Design: An Engineering Approach. New York: Auerbach Publications.
• Timms, L. R. (2012). Sap: How to Write a Report Functional Specification. Bloomington: AuthorHouse.