This article answers the frequently asked question, ‘What is a functional requirement?’ The point of view taken in the post is that of a business analyst, agile team member, or similar role.

Estimated reading time: 8 minutes

What is a functional requirement?

Functional requirements describe the functions that a given product or service, must be able to perform. In the context of business analysis, the product/service is typically an IT system, but the same principles apply to defining the required functionality of any product that is capable of doing something.

The system may be intended for use by internal staff or by external customers. The system’s functions enable the intended users to achieve their objectives or solve a problem that they have.

Who demands the functional requirements?

Functional requirements are typically demanded by the users. In fact, functional requirements are sometimes referred to as, ‘user requirements’, although this term is perhaps a bit loose.

It is the users who should state the requirements. In the case of external customers, organisations must find ways of discovering what is required; this means working out the unsatisfied needs of potential customers. In the case of internal staff, business analysts must work with them to learn their needs.

Functional requirements define ways of solving problems and/or achieving objectives for the customers and internal users of a system. For example, an objective for a hotelier is to able to check guests in and out. Functional requirements for their reception system will therefore include,

• I want/need to be able to check in a guest
• I want/need to be able to check out a guest

Business rules are not functional requirements

Business rules are just that, business rules. They are not requirements, functional or otherwise. However, a functional requirement might refer to one or more business rules.

Check out this article from Business Rules Community. Also see this interview with Ronald Ross, the so called, ‘godfather of business rules’.

Associating roles and jobs with a functional requirement

Our hotelier probably does not want to personally check in and check out every guest. To meet their objectives for a sustainable work-life balance, they should be encouraged to suggest employee roles that can do it. The requirements might then be,

• A receptionist shall be able to check in a guest (a guest?)
• A receptionist shall be able to check out a guest

Separating roles and people

If the hotel has a number of employees in the ‘receptionist role’, then any ‘role holder’ can do the job of checking in guests.

But what if the boss wants to do a bit of checking in? They are a hotelier, not a receptionist.

It’s important when trying to discover requirements to separate roles from the employees who can perform the role. For example, when the hotelier is checking guests in or out, they do so in the role of receptionist.

How much detail should a functional requirement include?

Given that someone is going to have to either build or buy a system that will perform the functions identified by the requirements, a common question is, ‘How much detail is needed in the requirements?’ And the answer, of course, is, ‘It depends’.

It depends very much on what the requirements will be used for.

Uses of a functional requirement

Common uses of requirements include,

• Provide instructions for a designer or programmer to create an application that implements the requirement
• Guide the purchase of an application that implements the desired requirements
• Checklist for selecting a supplier to design and build the application

A more complete list is given in Soren Lauesen’s book, ‘Software Requirements, Styles and Techniques’.

Why is any particular functional requirement necessary?

What’s the problem or objective?

We normally start by agreeing on the objectives that an identified class of users needs to achieve. Another way of looking at this is to consider a problem that the set of users needs to solve. What are the functions, and hence the functional requirements, needed to achieve the objectives and/or solve the problem? What do the users need to be able to do to perform their job?

To understand the problem, involve the people with the problem or objective

Problems and objectives of internal users/customers

An organisation’s internal users are its staff; they are sometimes referred to as internal customers. They have requirements for systems that enable them to do their job.

To identify the functional requirements for internal users, first identify the groups of people with shared objectives. Bring these people together, e.g. in a workshop, and make a first pass at what a product must be able to do if it is to help them solve their problem.

Problems and objectives of external customers

The requirements of external customers may be discovered by involving staff from the organisation’s Sales, Marketing, and Customer Management departments. They will know, or should know, what the customers want.

Information about external customers is can be obtained from loyalty groups, social media comments and requests, and direct comments to sales and marketing and customer complaints, for example.

Longer term and shorter term problems and objectives

An immediately objective might be to simply have an application that helps a user to perform their role, e.g., ‘Make a table reservation for a customer’. If the application works, that particular problem is solved and the immediate objective is achieved.

Longer term problems and objectives are likely to involve multiple requirements as well as changes to business processes, rules, and/or organisation structures. Knowing if a set of changes will solve the bigger problems will usually require the changed systems, processes and structures to be in operation for some longer period. This article is mainly concerned with shorter term objectives.

What is a requirement? – More examples from hospitality

Consider a simplified system to support a hotel or restaurant business. Some obvious functions that it must be able to perform include,

• Take a booking, e.g. for a room or table
• Add customer to loyalty scheme
• Create invoice item
• Record a payment
• Print copy of bill

These are the functional requirements.

Let’s consider the elements of a well formed requirement

What are the elements of a functional requirement

For many decades we have known that a well formed requirement has the following minimum set of elements:

• Name/Brief description, e.g.
  • ‘Create a booking for hotel guest’
  • Check in guest
  • Check out guest
• Role of the person that needs the feature defined by the requirement
  • A role may be filled by a human or non human, e.g. a robot
• Rationale; why the requirement is needed
  • This normally relates to the need, problem or opportunity
  • If there’s no rationale, it’s not a requirement
  • There may be many requirements aimed at solving a given problem
• Acceptance criteria; tests to apply to the finished app to see if it satisfies user expectations
  • If a ‘requirement’ cannot be tested, it’s not a requirement

Identifying roles and functions

Roles and functions may be identified from business processes. A business process will typically contain a number of related ‘activities’/’tasks’, i.e. ‘functions’, that are performed by various roles. A popular way of representing a business process is with a swimlane diagram. Consider this simplified process, for managing a guest stay at a hotel. The roles on a swimlane diagram are usually referred to as actors.

• Take booking, performed by role, Booker
• Check in guest (Record check in), performed by role, Receptionist
• Record paid service (e.g. for a meal or movie), performed by role, Team member
• Check out guest, performed by role, Receptionist

Note that each activity can be broken down into a set of related steps.

What is a functional requirement? – Revisited

The task is the functional requirement

This also takes us back to how much detail is required.

A functional requirement may be written, for example, at the level of the task, e.g.

• A booker shall be able to take a booking for a guest
• A receptionist shall be able to check in a guest
• A receptionist shall be able to check out a guest
  • Taking payment from the guest is a part of this task
• …….

The task provides the context. The documented task steps provide the detail. We know when we have captured all relevant information.

The task step is is the functional requirement

Alternatively, functional requirements can be written at the level of a task step, e.g.

• A receptionist shall take payment from a guest

We can end up with many requirements, perhaps lacking context. It can be difficult to know if we have captured everything. I have been on projects where the BAs claim that there are thousands of requirements.

Use acceptance criteria for the detail

By definition, the set of acceptance criteria should define everything that is needed to ensure that the product built to satisfy the requirement(s) contain(s) everything needed by the customer/user.

Five ways of writing a functional requirement

Explore five popular ways of writing a functional requirement.