Answer.

Functional requirements describe what the system should do: business operations, processes, user scenarios — that is, functionality.

Non-functional requirements define how the system should work: constraints, quality parameters, performance, security, usability, etc. These requirements often influence technology choices, scalability, and the robustness of the solution.

Why distinguishing is important:

• Clear separation helps in accurately setting tasks for developers and testers.
• It allows avoiding the omission of critical characteristics (for example, security, scalability).
• Unaccounted non-functional requirements often become a source of project failure.

Key features:

• Functional requirements are about the behavior of the system.
• Non-functional requirements are about quality and constraints.
• Both types must be explicitly documented and agreed upon.

Trick Questions.

Does “usability of the interface” fall under functional requirements?

No, it is a non-functional parameter (usability). A functional requirement is the presence of, for example, a "Save" button, while a non-functional requirement relates to its response speed and ease of use.

Can non-functional requirements be ignored if they are not explicitly stated by the customer?

No. The analyst must discuss and formalize even implicit non-functional requirements, otherwise, the risk of launch failure, user complaints, and additional costs increases.

“The system must be able to handle 1000 requests per minute”. Is this a functional requirement?

No, this is a non-functional requirement — a performance characteristic.

Common Mistakes and Anti-Patterns

• Focusing only on functionality ("as long as it works, speed can be dealt with later").
• Implicit phrasing of non-functional requirements — "should be fast", "reliable", "secure".
• Ignoring the testing of non-functionality.

Real-life Example

Negative case: The system fully implemented the declared business functionality, but under heavy load, it began to "lag" because performance was not taken into account at all. Pros:

• Fast development, precise fulfillment of declared scenarios. Cons:
• The system was not suitable for operation under real load conditions, the company had to urgently refine the architecture.

Positive case: The analyst, together with the architect and customer, documented the maximum load, response criteria, and conducted load testing. Pros:

• The product worked consistently and handled user growth.
• Development plans included scalability. Cons:
• At the design start, more time had to be devoted to discussions and additional tests.