What are functional and non functional requirements and why both matter

In software engineering (and Systems Engineering), a functional requirement defines a function of a system or its component. A function is described as a set of inputs, the behavior, and outputs (see also software). Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases.

non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.

The plan for implementing functional requirements is detailed in the system design.

The plan for implementing non-functional requirements is detailed in the system architecture.

So, with simpler words, the non-functional requirements, in addition to the obvious features and functions that you will provide in your system, are other requirements that don’t actually DO anything, but are important characteristics nevertheless. For example, attributes such as performance, security, usability, compatibility. aren’t a “feature” of the system, but are a required characteristic. Most of the time you can’t write a specific line of code to implement them, rather they are “emergent” properties that arise from the entire solution. The specification needs to describe any such attributes the customer requires. You must decide the kind of requirements that apply to your project and include those that are appropriate.


The most discussed non-functional requirement in software development are:

– Security (incl. Exploitability)

– Performance

– Availability

– Extensibility (adding features, and carry-forward of customizations at next major version upgrade)


The biggest problem

The non-functional requirements are very hard to define, to measure, to compare. What makes a system secure? And how do you say that a system is more secure than the other? Of course, it is possible to compare, but everything depends on the case.

Also, the non-functional features are sometimes very expensive to create and maintain. You might need sometimes to even re-write a software to achieve some of the non-functional characteristics mentioned above. Coming from here, it is very difficult to “sell” them. Would anyone buy a software that is not secure? Of course not, so you can’t say that “our software is more secure than the other”.

It takes experience and some say, art, to be able to find the compromise in the backlog to add function and non-functional requirements.

© Copyright Sorin Mustaca, All rights Reserved. Written For: Sorin Mustaca on Cybersecurity

Check www.endpoint-cybersecurity.com for seeing the consulting services we offer.

Visit www.itsecuritynews.info for latest security news in English
Besuchen Sie de.itsecuritynews.info für IT Sicherheits News auf Deutsch

About the Author

Sorin Mustaca
Sorin Mustaca, (ISC)2 CSSLP, CompTIA Security+ and Project+, is working since over 20 years in the IT Security industry and worked between 2003-2014 for Avira as Product Manager for the known products used by over 100 million users world-wide. Today he is CEO and owner of Endpoint Cybersecurity GmbH focusing on Cybersecurity, secure software development and security for IoT and Automotive. He is also running his personal blog Sorin Mustaca on Cybersecurity and is the author of the free eBook Improve your security .
%d bloggers like this: