Functional vs. nonfunctional requirements in software engineering

Software functional requirements

In software engineering, a functional requirement provides a description of a system behavior. A functional requirement defines what a system must, or must not, do. A software development project often includes many functional requirements, each of which describes an intended behavior, usually called a function, service or task.

Every function provides:

• an input parameter (a set of conditions);
• a behavior (a calculation, algorithm, data translation, process, user interface activity or any other functionality); and
• an output (a set of responses).

When a development team collects and organizes functional requirements, it defines the system.

Well-documented functional requirements directly influence software testability. QA engineers can write a set of deliberate test cases for each function. Through functional testing, they apply specific inputs intended to check a function and elicit an expected output. If the software does not provide the intended behavior, it is not functioning properly, and will not meet its intended goals.

Functional requirements examples

As we established, every functional requirement involves an input, a behavior and an output. Consider these requirements from the National Gallery of Art in Washington, D.C.:

"System shall allow user to click on a link associated with a content object or search result item to generate a preformatted scholarly citation that can be cut and pasted by the user."

This requirement is basically a search/select function that allows the software's user, presumably an academic, to receive additional information about a selected object from a catalog. Another functional requirement states:

"System shall generate a preformatted content object citation in a structured format that can be imported by EndNote, Zotero."

A functional requirement defines what a system must, or must not, do.

This requirement stipulates that the software can export content into tools that academic users often work with, such as EndNote or Zotero.

There are countless other examples of functional requirements that cover countless other objectives. For example, software might demand interoperability or be designed to meet prevailing business standards.

Some other functional requirement examples include:

"The software must validate customers against the in-house contact management system."

"The software must be integrated with the current banking API."

"The whole system must pass Section 508 accessibility requirements."

Software nonfunctional requirements

A nonfunctional requirement is a goal or stipulation that describes how a software system must work or perform. Nonfunctional requirements define the effectiveness, usability and user experience (UX) for a software product; they typically don't affect the underlying system functionality. In most cases, software can perform its intended purpose even when it does not meet its nonfunctional requirements. Still, while it does work, the result can be unacceptable or unsatisfactory system performance.

Non-functional requirements usually include conditions or constraints that recognize technical limitations in resources, such as network bandwidth levels or storage performance. With nonfunctional requirements, the development team defines how the software will perform, through an objective, pragmatic or measurable lens. For example, a specific system behavior is a functional requirement, while the need for that behavior to take place at a certain time and under a certain system load is a non-functional requirement.

Non-functional requirements examples

Website load time demonstrates an example of nonfunctional requirements. The fact that a website must be able to load certain information and displays for the user is a functional requirement; the non-functional requirement dictates a response time threshold:

"The site should load within four seconds, when the number of simultaneous users is greater than 10,000."

Nonfunctional requirements define the effectiveness, usability and user experience (UX) for a software product.

The software will still function if the site takes longer to load, but the user experience will not hit expectations set by the software's stakeholders. Poor performance is likely to compromise the software's acceptance and marketability, which consequently impacts the business. A nonfunctional requirement helps the organization apply objective measures to the software behavior, which is just as meaningful and testable as any functional requirement.

Some other nonfunctional requirement examples include:

"Users must change default passwords on first login."

"Login passwords cannot be reused at any point."

"Unsuccessful login attempts must be logged and copied to security administrators."

"A website must be able to support average traffic loads of up to 10 million simultaneous users without impacting performance."

How to gather functional and nonfunctional requirements

Use different criteria for each type.

Project managers, or senior-level system architects or software engineers, usually take the lead in gathering requirements for a software project. But the entire software development team must clarify and understand functional and nonfunctional software requirements. Factors affect the approach, including the size of the business, the project's complexity and software documentation expectations.

The most popular method of requirements gathering is a guided brainstorming session. Summon the technical stakeholders together to discuss project objectives, outline intended behaviors and cover preferred characteristics. These meetings are an ideal opportunity to define the project and expose any disagreements between stakeholders. While senior department managers and other leaders can usually provide high-level business goals for a project, the organization should also enlist user representatives in the form of employees, business partners and actual end users. These individuals can set user expectations of the software.

The requirements gathering process typically covers several types of functional requirements, such as:

• business requirements, which detail what the organization must achieve for the entire project to be a success, such as need to build a business order entry and billing system;
• administrative functions that must take place, including reports and alerts;
• user requirements, like interfaces or navigation requests; and
• system requirements, which define functional aspects of the project, like the underlying hardware and software needs.

Nonfunctional software requirements include several different categories as well, including:

• usability, such as response times and display or background color schemes;
• system reliability and availability, such as an uptime requirement;
• scalability, which calls for the ability to serve a given capacity of users;
• performance attributes, such as database access time or network bandwidth;
• security; and
• support.

Software requirements documentation

All the requirements gathering work feeds into a software requirements specification (SRS), which details, organizes and prioritizes requirements. This SRS document generally avoids specific decisions about the project implementation approach, such as the architectural design. Rather, the SRS forms the foundation for implementation. Early in the project lifecycle, the SRS summarizes the project requirements and provides a common document for stakeholders' approval.

The Agile methodology encourages organizations to detail user stories and use cases. A user story describes functionality from the end user perspective, often following a common nontechnical format such as: "As a <type of user>, I want to <goal> so that <reason>." User stories can translate into requirements for an SRS.

Use cases simply describe what a customer actually does when they perform a task. A use case specification might detail, for example, each step in the process to purchase a product in e-commerce software.

Stakeholders and requirements

In software engineering, it's a team effort to put together comprehensive functional and nonfunctional requirements. A typical software project involves several stakeholders -- individuals with the power to influence the project direction and goals.

Each stakeholder is involved in the requirements gathering process. These business and technical stakeholders include:

• actual users, such as employees, customers or partners;
• operations staff members who manage and maintain the software;
• software developers who design, build and test the software alongside project management;
• leaders involved in the business processes or systems that the software affects;
• anyone with a financial interest in the software, including C-level leaders; and
• regulatory or compliance officers.

These people present a wide array of perspectives, attitudes and experiences. Their collective knowledge should ensure the requirements best fit the unique needs of the business. But such a diverse cross-section of people can also complicate requirements gathering. Different stakeholders use different terminology for the same thing, for example, leading to misinterpretations. There can be some complicated areas that arise when the group writes and approves a single cohesive requirements document, a challenge called terminological interference.

Even established requirements are not permanent and unchangeable. Stakeholders frequently add or change requirements during the software development process. New and changed requirements can appear at any time, often in response to shifting business conditions, the emergence of new technologies, increased vendor competition or new customer preferences. Software development teams need a workflow to handle new or changed requirements during iterative development cycles; all stakeholders must understand this workflow.

The development team should maintain engagement with stakeholders for these updates and input. If a stakeholder loses interest or disengages from the development project, it jeopardizes the project's success. For example, if a new regulatory requirement wasn't communicated by the corporate compliance stakeholder, the software might be delayed until it can comply. New or changed requirements aren't easy for the development team, but adaptability is necessary. Project managers and the development team must work to maintain collaboration and engagement with all stakeholders.