Types of requirements

I am amused by the teams that divide their requirements into "functional" and "non-functional" groups.

Invariably it is in shops that used to have only functional requirements, and now have a second category.

The first group of requirements contains those specifications that are derived from business operations. They include things such as inventory levels, pricing functions, and billing terms.  The natural name for these specifications is "functional requirements" because, in the minds of the business analysts, there is a direct mapping from the software back to the business world.

The second group of requirements refer to  aspects of the system that are not tied to business operations. These can include things such as platforms, upgrades and updates, response times, system availability, and GUI design.

Frequently a development team starts with a single list of requirements, and then starts creating subgroups within the list. The non-functional requirements are usually groups together, since they don't fit in with any business initiatives. Sometimes the non-functional requirements have no official sponsors, or no sponsors from within the business.

The action of dividing requirements is a "lumping and splitting" problem. We humans associate like things and group them. We also split out unlike things. It's part of our psychology, and we should leverage it with software development and the management of requirements.

But the simple division of "functional" and "non-functional" is wrong. Even the term "non-functional" is a clue that one has given  little thought to the problem.

The term "non-functional" is an artificial one, akin to "manual transmission". (Prior to the introduction of the automatic transmission, a manual transmission was simply a transmission. No adjective was needed.) The term "non-functional" is needed to differentiate some requirements from the group of functional requirements.

The term "non-functional" is a negative term. It tells us what the requirement is not, but it does not state what the requirement *is*.

If you are using the term "non-functional requirements", then you are giving insufficient attention to those requirements. In addition, you implicitly make them second-class citizens in the requirements world.

Here is a list of terms that can replace "non-functional requirements":

- Performance requirements
- Maintainability requirements
- Availability requirements
- Upgrade requirements
- User interface requirements
- Business continuity requirements

The list is incomplete and perhaps not exactly what you need. Take the ones that make sense, and add others as you need.

Many folks will avoid using the specific terms and keep to "non-functional". The term is in place, everyone on the team agrees with it and understands it, and there is no clear benefit to these new terms. They would say that it makes no business sense to change.

And they will be right... until the list of non-functional requirements grows... and someone wants to split it.