It’s a funny thing. Why would something that’s called non-functional be important you may ask. To answer that you have to understand what non-functional requirements are. As we already know, functional requirements are the things that make the product work. The product won’t work properly if the functional requirements are not met! So what about the non-functional?

Think about a piece of software developed for a company. All the functional requirements are met, but the company declines the software. What happened? In this case, let’s say that even though the product worked exactly like it was supposed to, the end users didn’t like ‘the feel’ or user interface. Ultimately, the company that built the software didn’t pay attention to the end users non-functional requirements!

Non-functional requirements can be broken down into eight different categories.

Look and Feel: The spirit or appearance of the product.

Usability and Humanity: How easy or usable is the product.

Performance: How fast and available is the product.

Operational: What kind of environment is the product operating in.

Maintainability and Support: Expected changes and the time needed to make them. The specification of the support to be given to the product.

Security: Is the product accessible, confidential, recoverable and auditable.

Cultural and Political: Is the culture and practices of the end users taken into account.

Legal: The laws and standards that apply to the product.

When describing non-functional (and functional) requirements it’s a good idea to break it down into description, rational and fit criterion. For example, take the Starbucks art design project we are preparing. Functionally it:

Description: Shall only be provided for hot beverages.

The product’s function is to provide service for warm beverages only.

Rational: The art will show better and keep the cost of the cup down.

We believe the art design will show up better on hot product cups which are also cheaper to produce.

Fit Criterion:

Non-functional requirements might feel redundant or obvious but it’s important to clarify them and make sure they are understood an followed. It’s one thing failing to deliver a project because it didn’t function properly. But to deliver a fully functional product only to have it declined due to poor non-functional requirement gathering would be even worse!

When determining the needs of a business, it’s easy to run head first into finding solutions before actually determining the real problems of the business. In software development, time and money is often wasted when starting in the Future How, as most developers must return to the Future What to fully realize what the need, and therefore, solution is! Delving into the lower right side of the Brown Cow Model, we move from a place of virtual abstraction to a the world of physical technology. Having discovered the need in a more abstract way, we can now dig into a more concrete implementation.