Non-Functional Requirements

A functional requirement states the behavior of a software system. It answers the question, “What does your app do?” A non-functional requirement states a system quality attribute that the system must have, or a constraint on how we may build or operate it. It answers questions like, “How well must the system perform this behavior?” and “What limits must we respect while building or operating it?”

“Readers can open published posts” describes required behavior, so it is a functional requirement. It does not tell us how quickly a post should appear, how many readers HopPress must serve at the same time, or how long the university can tolerate the site being unavailable during maintenance or after a failure. We need separate non-functional requirements for those questions.

Non-functional requirements are not optional. A publishing feature that is too slow to use or unavailable when readers need it does not satisfy the real need.

Non-functional requirements cover many concerns, and we will study them throughout this course. Here, we will briefly look at a few quality attributes and system constraints.

System quality attributes

Examples of system quality attributes include performance, availability, scalability, reliability, security, usability, maintainability, and modifiability. We will focus on performance, availability, and scalability here.

Performance describes how quickly the system responds to a request. For example, a performance requirement might say: “When a reader requests a published post, HopPress must return the response in under 2 seconds.” The phrase “under 2 seconds” is a response-time target. Response time is the time between a client sending a request and receiving a response, including network delays and queuing time. It is one way to quantify and measure performance.

Scalability describes how well the system continues to meet its requirements as demand grows. For example, a scalability requirement might say: “HopPress must continue to meet its response-time target as the number of simultaneous readers grows from 50 to 500.” The “number of simultaneous readers” is one of many ways to measure HopPress’s system load. It helps quantify the amount of work the system is handling at a given time. Scalability is the system’s capability to handle increased load without a significant drop in performance.

Systems can become unavailable for several reasons, including hardware failures, software errors, network problems, and planned maintenance. A system is available when users can access it and perform the actions they need. For example, an availability requirement might say: “During each calendar month, readers can open published posts at least 99.9 percent of the time.” The phrase “at least 99.9 percent of the time” quantifies uptime, the period during which the system is operational and accessible. This requirement allows the site to be unavailable for at most 0.1 percent of the month. In a 30-day month, that is about 43 minutes. Planned maintenance and unexpected failures consume the same allowance, so the university must decide how to divide that time.

Notice that these examples do not simply say “the site must be fast,” “the system must scale,” or “the site must be available.” Those statements express goals, but different people can interpret them differently. When you specify quality attributes, state measurable requirements, so that everyone interprets them the same way and there is an objective way to test whether the system meets them.

Quality attributes can also constrain one another. For example, stronger security measures may make a system less convenient to use. So when you make a design decision, consider the requirements together rather than optimize one attribute in isolation.

System constraints

System constraints limit the choices available to the team. They can come from decisions already made or conditions the team cannot change. For example, requiring HopPress to use the university’s identity provider rules out some authentication designs, but it also removes the need to build its own identity service.

System constraints can be technical, business, or legal.

Technical constraints limit the technology we can use. These include limits related to hardware, software, infrastructure, and integration requirements. For example, HopPress may be required to run on the university’s existing hosting platform rather than on a new cloud service.

Business constraints reflect organizational limitations, such as budget and schedule. For example, HopPress may have a fixed budget and a three-month deadline for its initial release.

Legal constraints come from laws, regulations, and institutional policies. For HopPress, these constraints may require the university to protect personal information and meet accessibility requirements.

Before evaluating a design, record the system constraints alongside the functional requirements and system quality attributes. A design that violates a fixed constraint is not acceptable, even if it satisfies the other requirements.