Functional Requirements Are Like Door Handles

A functional requirement is like a door handle. It performs a very specific function, nothing more and nothing less. The door handle is used to open or close the door of the house – it is not also used to be the wall of the house or the roof of the house. It is does one specific function, and this is what a functional requirement is. It describes one specific function that a system performs.

Functional requirements are often also called business requirements or solution requirements. The BABOK Guide refers to Functional Requirements as a subset of Solution Requirements. However, for the purposes of this explanation the term functional requirements will be used and describes the concept behind these types of requirements regardless of terminology.

A functional requirement is a requirement that essentially describes what a particular user would like to be able to do using a system. It describes how a business need will be fulfilled with a provided solution. Described in another way, functional requirements describe what functionality a user wants to be able to perform using a system.

An example of a functional requirement statement:

“The ability for the user to save a customer’s personal record using the Customer Relationship Management system.”

In the above example, we are describing the functionality to “save a record” using the system.

The key points to remember when you write functional requirements

1. Describe only one piece of functionality in each functional requirement. If we look at the previous example, this means that you must not describe the functional requirement like this:

“The ability for the user to save and print a customer’s personal record using the Customer Relationship Management system.”

2. Use a consistent sentence structure or styling for each of your functional requirements. This refers to the format of the sentence. You should have the same style when you write the functional requirements. If you look at the example functional requirement used here you should not change the format of the next functional requirement to read something like:

“The system should allow the user to print the records of their customers.”

Ensure that your next functional requirement also reads in the same style:

“The ability for the user to print a customer’s personal record using the Customer Relationship Management system.”

3. Use active verbs and specific functions to ensure it is testable. Make sure you use active verbs that describes a definite action or function when you describe your requirement. Think of this from the perspective of a person using or testing the system when you write your functional requirement statement. When the reader reads your requirement, will they know what specifically they must do when they test the system to ensure your functional requirements are all implemented correctly? Therefore, make sure your functional requirements are all measurable in order to be testable.

 A last word about the way you compose your functional requirements: There are many different styles for writing functional requirements for your project and therefore it is important to consider whether your company already has a standard for this and then to follow or improve on that. The format we used in the example here is one of many ways to formulate functional requirements.
There is currently a trend to start framing your functional requirements from a much more customer focused perspective and could potentially look the example below:

As a user I want to save a customer’s personal record so that I have record of our conversation.”

The above example is worth considering especially if the base set of functional requirements is documented for an Agile Project Environment.