Non-functional requirements revisited

Functional requirements represent work that needs to be done to address customer needs. Customers pay for the functionality. Any work that…

Functional requirements represent work that needs to be done to address customer needs. Customers pay for the functionality. Any work that does not deliver desired functionality belongs to non-functional requirements.

But there seem to be some gray areas that blur the boundaries between functional and non-functional requirements. Arguably, system availability could be considered as functional requirement. Without the system being available, no functionality is available, which significantly affects all customers.

Same consideration applies to other aspects of the system. Aspects such as performance, security, and so on.

So, does that mean that the distinction between functional and non-functional requirements is artificial? No, not really. But we need to shine some light on the differences between those two categories of requirements.

Can we sell non-functional aspects of the system?

The main reason many companies are investing money in creating, releasing, maintaining, and supporting software products is to serve their paying customers.

Of course, not every aspect of the complex software product is directly relatable to end users/customers. For example, various government regulations may force businesses to invest considerable time and funds into making modifications that would make no noticeable difference to the paying customers. If the businesses would try to charge their customers extra for that ‘invisible’ work, most (if not all) customers would flatly decline to pay extra.

So, in that light, I’d say that only the functionality that directly affects end users/customers belongs to the functional requirements category. Any functionality that users would not be interested in paying for belongs to the non-functional requirements category.