Skip to Content

Is there need for functional specification?

What is A Functional Specification?

Functional specification (functional specs) is a blueprint for how you want a particular Functionality or application/Development to look and work. It details what the finished product will do, how a user will interact with it, and what it will look like. By creating a functional spec of the development first, time and productivity are saved during the development stage because the programmers can program instead of also working out the logic of the user-experience. It will also enable Functional Consultant to manage the expectations of Business users/clients or management, as they will know exactly what to expect.

It is a formal document used to describe in detail for developers a product’s intended capabilities, appearance, and interactions with users. It’s a kind of guideline and continuing reference point as the developers write the programming code.

A functional specification can substantially simplify and streamline the process of application development. Intended to describe how a piece of program works, it provides a ready reference for developers and aligns large and disparate development teams to a single goal. In the process, it provides technical clarity on how the different components of a particular application are to be designed, implemented and integrated with each other, and (if used correctly) significantly reduces the time and cost component of any development exercise.


Why write a Functional Spec?

A key benefit of writing up a Functional Spec is in streamlining the development process. The developer working from the spec has; ideally, all of their questions answered about the application and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed…and this, in a nut, explains my love affair with the Functional Spec.

Writing A Functional Specification:

A functional specification is written primarily for the development team, with the objective of providing the members of that team with all the information they need to begin designing an application. It aims at outlining the entire experience of the application, without really getting into the details of implementation, thereby providing the developers with a comprehensive knowledge base and reference for any and all questions concerning the project. The idea here is for the kinks in the design to be worked out at a conceptual level, and (more importantly) for the customer to get a clear idea of what the deliverable is and how it will work

Once finalized and approved by the customer, the functional specification can be used by a developer to create a detailed Technical solution, which contains high-level architectural diagrams of the system, together with descriptions of the components used and their relationships via a modelling language. Development then becomes a matter of implementing what has been frozen in the specification.

The level of detail in this document varies from project to project and company to company, and depends on the level of complexity inherent in the project, and the amount of time and staff available to compile the data obtained into a structured report. If you’re an independent developer or a project manager with a small team, you might prefer a smaller, simpler document; if, on the other hand, you have a full-fledged team behind you, work in a large, process-driven organization and/or have a complex project to tackle, you might prefer a document that drills down to the very last level of detail.

The functional specification should be written by a person who is isolated from the actual development of the program, so as to add a degree of impartiality and independent thinking to the process. Obviously, this person needs to have a wide range of skills: an understanding of how users think; a thorough knowledge of the capabilities of various functionalities and tools; the experience and creativity to break down a large and complex project into smaller, discrete modules and data structures; and, most importantly, the ability to communicate all of the above in a clear and concise fashion via a formal document.

This, you will agree, encompasses a fairly wide (and hard-to-find) range of talents, which may require years of experience to develop. But talent is just one of the things a functional spec writer needs…time is the other.

My experience with larger implementation suggests that creating a functional specification is a fairly time-consuming job. As a functional spec writer, you need to spend a fair amount of time understanding the requirements and business vision for an application, discussing design and implementation with the development team, and mapping the two together to ensure that the final deliverable satisfies the customer’s needs…all before you can even begin to think about structuring this information into a formal document. This process is, obviously, not something that can be accomplished in a matter of hours; depending on the complexity of the application, creating a detailed functional specification can consume days or even weeks.

In case you are wondering whether the process is really worth the time, the answer is a resounding yes. The consequent benefits of the process – a streamlined development process, better risk and change management, greater clarity in the development team and fewer course corrections – all add up to a substantial cost and time benefit in the final analysis. If you are having an agreement with all stakeholders about the functionalities/system/process of the final product, it makes easier to develop and deliver within clear time and money budget

I don’t agree with Jason Fried ( about redundancy of Functional Specification, but it’s worth to read his views and comments on it. It will help us to improve the Functional Specs.

Approach for writing the Functional specification:

As we discussed in earlier part, the functional specification begins where the requirements documents ends, and it performs the important function of describing how the deliverable will meet the items listed in the requirements spec. Requirement Documents are complete with design requirement at a very high level; mostly it will be in a business language. Business requirement document contains the pain/improvement area and expected solution.

Therefore it becomes an important objective of functional specification to convert these loose requirements into a more solid expectations and functionalities. It must therefore begin with the identification of the purpose of the development and the business objectives.

These objectives serve as the basis for derivation of the features required in the development. It’s important to spend time on making an exhaustive list of all the features

It’s always a better idea to represent the information using diagrams and flowcharts – for example, data flow diagrams, which indicate how data is stored and processed by the application, and object interaction diagrams, which provide an overview of the objects that make up the application and their interaction. In case your application uses a database, you might also consider including one or more entity relationship diagrams to represent the design of your database.

A very, very important rule of creating specifications is to be consistent and extremely precise in your use of words. For example, if you’re using the word “function” to indicate the, well, functions of your program, you shouldn’t at any point switch to “features”, “commands”, “menu items” or “actions”. To this end, make yourself a glossary of the terms that you’re going to use right at the start, and stick to them consistently. Add this glossary to the end of your specification so that your readers have a ready reference, and to ensure that developers can communicate with each other using the right words. In my experience I have seen many developments getting dragged and delayed for interpretation same information put at 2 sections of FS in different words.

The best Functional specification has following qualities:

  •   Clear – Use as much layman terminology as possible.
  • Concise – Do not confuse the customer with long, technical treatises detailing every aspect of the application.
  • Provides lots of pretty pictures – Humans are visual creatures. Providing even simple flow diagram is essential for your customers to visualize what you are documenting.
  • Conventions in the document lead to patterns that the users can grasp. They then start expecting information in a particular format, thus increasing their level of comfort with the document. Using consistent styles also speeds up assimilation of the information, and helps spot particular information easily on re-reads.
  • Headings are a powerful tool in making a huge mass of text look manageable. A common model is that as you go deeper in a particular topic, you indicate that by descending prominence of headings. So, all top level headings will be, say, in a large font size and bold typeface, with the next level taking a smaller font size, and so on. You might also want to number the headings to help users understand the grouping of information.
  • Use bullets and numbering to break up complex concepts into simpler, smaller information nuggets. The convention here is to use numbering for sequential information only and bullets for information that is best presented in points instead of a paragraph. Bullets also allow you to group together points related to a concept and ascribe them levels of importance.
  • Use screen shots, schematics or flow diagrams to increase the efficacy of your document. Since a functional specification also includes information on what the user will see in the application, it will include schematics, screen flow diagrams and sample screens. These screen shots will be help developers’ to ensure that the final product conforms to what has been decided in the specification. Ensure that you are consistent in your usage and labelling of screenshots.
  • Ensure that nothing is left open to interpretation. Since this document will be used as a guideline for the actual implementation of the application, it’s important that it is clear, concise and accurate at all times. Ambiguity and a failure to resolve troublesome points are sure signs of trouble in the future.
  •  Last but not least ensure that there is formal sign off for the Functional specification
You must be Logged on to comment or reply to a post.
  • Interesting.  We’ve tried writing the functional documents prior to development with little to no success.  We do write a skeleton prior to development.

    We consider functional specs a working document until the development is complete.   There are several reasons why.  The biggest reason is that we don’t know all the answers until the application is built.  I don’t know anyone who can put all the information into a functional spec and not have it change during the development. 

    Another good reason for a functional spec. is understanding the program(s) / system at a later date.  It’s nice to know and understand the background.

    By the way – I think developer’s can write the functional specifications as easy as the functional person.  Assuming they work and communicate throughout the process.

    • Hi Michelle,
      Thanks for Feedback
      Yes I perfectly agree.
      Functional specification should not be a static document, it should be enhanced and updated as the development progresses.
      In order not to make this blog a huge lengthy item……and then nobody reading it, I have not touched the support part of development.

      I never belive FS as a static document and there for quoted the non agreement with Jason Fried.

      If time permits I will come up with ablog having…….. the Application support view for the Functional specifications.
      The very purpose of FS is not to put all information in one go, but to come up with the information available at hand in a structured way and agree with stakeholders.

      I donot think Developer will be writing a Functional specification, his role will be limite to technical specifications. Offcourse this is with individual capability…I have worked with several developers , having business understanding at par with functional consultants.
      And in some cases I have used there inputs to improve my Functional specification

  • I couldn’t resist making a reference to iRise. ( ) Looks like a good alternative to many of the documents one prepares during a life-cycle of a project.

    However in absence of an automated tool , I agree to a large extent to author’s opinion. FS serves two ways :

    a) end-user agrees with what the domain expert has projected as their needs
    b) developer understands what the end-user needs

    I believe the problem is with a), because the end-user never sees the end product until the delivery stage and comes back with “Oh! Good lord, this is not what I intended” and if you usually look at the usability factor after a year after development, you would be surprised that my god I went through hell for the 100 reports the end user asked for and the end user uses only 10 of them, worse none.

    My 2 cents.

    Subramanian V.

    • Hi Subramanian ,
      I have not used the, so very difficult to comment on it. However thanks for suggesting, I will explore the information pack on it.

      However the fact that you mentioned above is really painfull… I have personally faced the issue…the  Reports which my team developed by burining midnight oil ..are not used by business.

      Since I graduated to a senior role , I can see that key to this problem is in only our hand.  I am participating in Business review/requirement review sessions with Architects , thereby able to use this knowledge to cahllenge the new requirements. If we are moderately succeful in challenging these item, it would atleast avoid 100 s useless reports being generated.
      and we will really work on vital few items

      Thanks for feedback