Don’t Fence Them In! Write Functional Requirements that won’t Sabotage your IT Vendor’s Ability to Deliver an innovative Pension Administration Solution

Following up a previous article on creating great functional requirements for your RFP, this post further examines what a functional requirement is and—just as important—what it isn’t. Understanding this key distinction can make all the difference when you’re trying to compose an RFP that accurately identifies your unique business requirements but which doesn’t compromise the IT vendor’s ability to deliver an innovative pension administration system that truly empowers your organization.

Why is it important to understand functional requirements?

Excellent functional requirements are essential to the overall success of any software administration implementation project.  The most devastating consequence of poor requirements is time and expense of rework, which can consume 30-50% of your total development costs. Additionally, errors relating to poor requirements can account for 70-85% of rework costs. Because many projects are considered successful only when an administration solution satisfies both the functionality and the quality expectations at an agreed-upon cost and timeframe, writing great functional requirements early in the procurement process becomes a critical task.

So…what is a functional requirement?

Functional requirements identify specific pieces of functionality that must be built into an overall software product. In short, they indicate what a system should be able to do. These specifications can be high-level (i.e., contain general information) or low-level (i.e., contain lots of detail). For project managers and IT staff, the important thing is that, functional requirements provide a way to track progress toward the completion of a project. When written correctly, they clearly illustrate the work that's left to do versus the work that's already been done while helping to control project scope.

Here are examples of four well-written functional requirements:

"The system must be able to perform disability benefit calculations accurately on demand."

"The system must allow the user to generate, edit, print, and archive correspondences to all applicable parties without leaving the line-of-business solution."

"The system must be able to capture federal and state tax table information."

"The system must provide the ability to track which user made the tax adjustment and why the adjustment was made."

OK…then what isn't a Functional Requirement?

A functional requirement is not a high-level organizational goal, business rule, law or legislation, company policy, or implementation information (such as specifications for the development environment). The line between these can get blurry, so we’ve provided some examples below to clarify the differences between them.  

"The system must calculate the annual benefit by multiplying the Final Average Salary by the Total Years of Service and the Retirement Multiplier." True, this does specify what the system should do, but this is actually a business rule, not a functional requirement.

"There must be separate identical regions for development, test, quality assurance and production."  This is an implementation requirement. Under different terms or options, this organization might elect for fewer—or even additional—regions. This information does not communicate what is actually desired of the new system.

"The vendor must provide a meeting agenda and any documentation to review at least 24 hours before each scheduled meeting."  This is a project requirement. It would be nearly impossible to track this requirement to completion in large-scale projects throughout which hundreds or thousands of meetings would likely take place.

"The system must provide the ability to merge two accounts/records where one account is for the same person with an incorrect social security number by allowing the user to click the incorrect, make the changes to the correct account, and then delete the incorrect account automatically after an account has been locked for this purpose."  While the first part of this statement is a proper functional requirement (ability to merge two accounts, one with the wrong SSN), the second part is a design specification—it specifies how the system should accomplish a particular function, not what function it should perform.

The Bottom Line

Functional requirements should only state what the vendor should build, not how the vendor should build it. The how will be determined by a variety of conditions and constraints that cannot be fully understood without collaborative discussion and research (not at the time of writing your RFP).

Remember, vendors are in the business of providing innovative solutions to your challenges—so let them! Your project stands a much better chance of succeeding if you allow vendors the freedom to offer options that you may not have been aware of and that could address your project goals more effectively than you imagined.

What examples do you have of functional requirements vs. other specifications, rules, or regulations?  How do you tell the difference and show that difference when writing and RFP?  What advice can you offer?

Learn more about writing functional requirements by downloading our free insider's guide.

About Sagitec Solutions:

Sagitec Solutions, LLC designs and delivers tailor-made pension, provident fund, and unemployment insurance software solutions to clients of all sizes. Sagitec has the expertise necessary to help their clients achieve strategic business objectives, enhance service offerings, and lower operating costs. Find further information by visiting http://www.sagitec.com. For more information, contact Rick Deshler at (651) 335-3406 or at rick.deshler@Sagitec.com.