nonfunctional requirements

How Many Times Have You Fallen In Love Because Of Nonfunctional Requirements?

When attempts are made by a fresh business analyst to elicit or document nonfunctional requirements, the attention often shifts back to the functional requirements.  To them, the nonfunctional requirements can be like those aunts and uncles at the family reunion that you don't seem to know much about. You know they are family but you struggle in attempts to start up a conversation with them. 

Many times, nonfunctional requirements and constraints are considered so similar that an analyst will simply group them together with the same label. In those cases, the label chosen is "Constraints", simply because the word is easier for most stakeholders to understand. I've heard it explained that most constraints are written from a negative context such as "the product can not, should not, will not". Requirements are best written in the positive voice including the verbs of can, should and will. 

One of the most common descriptions of nonfunctional requirements are needs a user must have but they may not realize it. I've seen the importance of nonfunctional requirements compared to products from Apple computer and include the branding, presentation, size and even customer service features like the Genius Bar or glitzy stores in the mall. In most cases, these attributes do not help the product function better but still make them more desirable, at least to some, than functionally equal competitors. 

How many people do you think fell in love with an iPhone but that person spent less than one hour with it? It is possible to appreciate many of the functional capabilities of such a product but you know many just loved the idea of having one. In many ways, the lackluster success of the Apple Watch could be attributed to the fact that the lack of functional features outweigh the nonfunctional sexy aspects of the device that Apple continues to bombard you with in their marketing attempts.

Quality, or the perception of it, is often one of the most powerful nonfunctional requirements in determining if a product is a success or a failure. Some less sexy attributes of nonfunctional requirements include security, scalability, availability, reliability and even attractiveness. As you might have guessed, nonfunctional requirements are more difficult to specify accurately and can equally challenging to test. This is because they often are measured differently by the individual making the specification, test or measurement. 

When writing the acceptance criteria for a nonfunctional requirement, you will want to include a description of it, how to measure it, the lowest acceptable value, the target value and the expected value. 

A popular example of nonfunctional requirement measurements comes from the technical arena in the form of a SLA (service level agreement). A good SLA will contain strong KPIs for a significant collection of nonfunctional requirements and is used as a core document for funding resources to ensure that nonfunctional requirements fall within acceptable parameters. 

Properly written acceptance criteria for nonfunctional requirements in a SLA should allow leadership to effectively manage and optimize the product/service to meet the spirit of those expectations.