What are functional requirements?

Functional requirements engineering

The foundation of modern products, good functional requirements, helps to keep a project on schedule and budget.

Functional requirements are part of requirements analysis (also known as requirements engineering), an interdisciplinary field of engineering that addresses complex systems design and maintenance. The systems in systems engineering can be software, electronic hardware or a combination called software-driven electronics.

Functional requirements describe the desired end function of a system and any steps needed to reach that end state. This assures that the design is adequate to reach the desired product and the end product meets user expectations.

The requirements in requirements engineering guide development of the engineered product. Typically, a functional requirement is a basic functionality or desired behavior documented clearly and quantitatively. Requirement engineering ideas might be applied to complex items.

For example, for a jar, a functional requirement would be that it holds a fluid and has a threaded top for a lid to seal the contents for better preservation. When a product fails functional requirements, it usually means the product is of low quality and possibly useless.

How to determine functional requirements

As the detailed plans programmers and designers can follow to build the product, functional requirements are like the blueprints builders follow to construct a building. Often, the more details that can be added to the functional requirements, the better the end product.

When project planning starts, it's vital to have all the stakeholders involved in early functional requirement phases. This way, the business goals can be well understood and recorded in the functional requirements. The outline of the project can be established, and the result well understood. This reduces the need for later changes or additions that often push projects over budget and past deadlines.

The MoSCoW method is a way to prioritize the requirements where each feature is sorted into either must have, should have, could have, or will not have categories.

Another method uses the value a feature adds versus the effort required to implement it. A value versus effort matrix will help identify the areas that will provide the most benefit with the least cost in time. This might also lead to a minimum viable product (MVP) where only the most important features are planned.

Functional requirements can start off at a high level and become progressively more detailed. A high-level requirement might be to have a functional shopping cart. This can be further broken down to smaller requirements such as the ability to add or remove items and process credit cards. Even smaller, the credit card processing can have a requirement to validate the number checksum before processing the card.

Each functional requirement can have associated tests to ensure it meets the requirements.

A unit test might check a piece of code by giving it an input and confirming that the output meets expectations. For example, the credit card number validation function might be given a bad number and a good number. If it doesn't give the right output, it fails the test.

Non-functional requirements

Functional requirements in systems engineering are complemented by technical requirements, also known as non-functional requirements (NFRs). Technical requirements define what is required to deliver the desired function or behavior from a system to a user's standards. Technical requirements can be performance factors, accessibility, versatility, logging, control and backup.

Focusing solely on functional requirements at the expense of non-functional requirements can cause major problems. Functional requirements might be considered met even when the non-functional requirements are not. This can still mean the product is unusable, such as in consideration of performance requirements. For example, the functional requirement might be to produce a sales report, but if it takes 12 hours to finish, it might not be usable. If security NFRs are missed, there might be legal or financial ramifications.

Functional requirements, business requirements and user requirements

Functional requirements can be thought of as the "how" in a project. They define the plan of implementation and how each section works together. The business and user requirements set the "why" of the project.

The business requirements are the overarching reason the project is started and what it hopes to achieve. These might be to increase user retention or improve profitability. The functional requirements then slot into how these are accomplished with definitive testing during the project.

User requirements are the more nebulous needs for the user. These might be UI/UX considerations or user feature demands for the product to accomplish. For example, a dark mode is a user requirement that adds no specific business benefit but has associated functional requirements and costs.

Further explore the difference between functional versus non-functional requirements in software engineering, with clear examples.