Why Functional Requirements are so Important

by Colin Kennedy - Apr 30, 2013

In a recent article about the software industry, we highlighted the fact that an estimated 68% of projects are classified as challenged or failed projects by the IT managers who commissioned them.

A well written functional specification can spell the difference between a successful and a failed project.

© Neuron Global

This number is staggeringly high, completely unacceptable, and we feel that it’s usually a result of what does (or doesn’t) take place during the first stages of a project.

Too often, what doesn’t take place is proper planning. Concepts are discussed, options are spoken about in generalities, an estimate is given…and a project begins without any Functional Requirements. For those of you who are not familiar with the term, Functional Requirements are the detailed document(s) that clearly define every component that goes into creating a fully-functioning piece of software – one that matches the client’s vision for said software.

Most people would agree that you wouldn’t build a house without doing an assessment of the site, interviewing the owner to understand what it is that they want and why, and creating blueprints to work off of – so why is it that so many people want to skip this step when developing software? And what does it say about the service providers who are willing to provide an estimate for a project that has no plan?

With this as the back drop, let’s have a look at the reasons why 2/3 of software projects experience significant problems – as stated by the IT managers who commissioned them:

Project Challenge Factors % of Responses
Lack of User Input 12.8%
Incomplete Requirements & Specifications 12.3%
Changing Requirements & Specifications 11.8%
Lack of Executive Support 7.5%
Technology Incompetence 7.0%
Lack of Resources 6.4%
Unrealistic Expectations 5.9%
Unclear Objectives  5.3%
Unrealistic Time Frames 4.3%
New Technology 3.7%
Other 23.0%

Source: Standish Group Report 2009

It comes as little surprise to us that the top 3 reasons, and 6 of the top 10 (highlighted in blue) can be traced back to poorly done (or completely neglected) Functional Requirements. If both parties aren’t clear on what the intended end result should be, expectations are bound to be out-of-whack. When this happens, people get upset and at least one of the following outcomes will manifest:

  • The client ends up feeling like they paid for something other than what they really wanted and expected.
  • The development company gets frustrated with the client because they feel as though the client is asking for “new things” - work that was outside of the intended scope of the project. But without a plan, who’s to say who is right?
  • The project takes a lot longer than anticipated, because new requirements are “discovered” during development, or worse, after development has completed.
  • The project costs the client a lot more than anticipated, because the items that are deemed to be “new” aren’t done for free. If a provider does agree to do them for free, the client runs the risk there will be a quality issue later on.
  • The development company becomes less and less responsive to client requests. Because they improperly bid on the project, they simply can’t afford to spend more and more time to develop parts of the software that they didn’t consider when submitting their bid. Maybe the worst that happens is a prolonged development process…but maybe the project never ends up being completed.

We could go on and on, but you get the idea. It was none other than Benjamin Franklin who said, “If you fail to plan, you are planning to fail!”

Open communication is the most important part in creating good functional specifications

If you’re still not convinced, here is a list of benefits that both Neuron Global and our clients have experienced by engaging in the requirements gathering process:

  1. The # of bugs are reduced: Functional Requirements eliminate bugs in the production version of the software by creating a clear framework for the client, the developers, and project manager to plan the development of the software. When a strong plan exists, you avoid the “trying to fit a square peg into a round hole” issues that result in buggy software.
  1. They create a framework that allows the client to influence and control costs: By enabling client- the “user” in the chart above -to provide input about the overall design and final solution, the client will gain an understanding of how much each functional module will cost to build. With this information at their disposal, they can prioritize based on budget and time constraints.
  1. Creates a concrete link between what is wanted and what will be created:One of the trickiest things about software development is that both the client and the developers are trying to conceptualize something virtual – in other words, your 5 senses are of little help. What the Functional Requirements do is enable the client to get a view into the software(via wireframes, module descriptions, etc.) before any code is written. Our experience has shown that this process has saved huge amounts of time and money later on. Making changes to code is significantly more complicated and time intensive than making amendments to plans.
  1. Allows the right technologies to be used: As we’ve written about previously, there are so many different programming languages, CMS platforms, 3rd party plug-ins out there, just waiting to be used. Each one has its own unique set of plusses and minuses, but choosing the right mix isn’t always an easy task. By taking the time to consider all available options and selecting the most appropriate ones for your specific needs will result in a better end result (overall performance, scalability, and the level of security, etc).
  1. Creates accountability: If there is no roadmap, how can the client know if their development company is doing everything they said they would, and within the timeframe that was agreed upon? Is it realistic for the client to spend hours each day looking through lines of code and then checking progress against a non-existent project plan? That’s simply not feasible. Functional Requirements demand that clear objectives and expectations are created, which lead to clear milestones, which, in turn, allow the client (who is in all likelihood, non-technical) to measure the progress of a project easily.

We hope that this helped shed a bit of light on an oft-neglected step in the software development life cycle (SLDC). We also understand that this may have raised additional questions about project planning, the SLDC, or something else. If so, please don’t hesitate to contact us – we would be happy to answer your questions and consult as needed.