Non-Functional Requirements: the "All-Other" classification

I've seen various taxonomies of requirements.  Like all taxonomies, any set of requirement types exists to classify or partition requirements into coherent groups for further analysis.  Most break down the list of requirements into things reminiscent of "who or where the requirement comes from."

For example, one taxonomy I've seen recently described:

• Business Requirements - high level business goals
• User Requirements - the user experience needs
• Functional Requirements - business process or functionality needs
• Non Functional Requirements - all other requirements (like quality attributes)

Another taxonomy may be:

• Information requirements - needs for information storage
• Functional Requirements - needs for functionality
• Non-functional requirements - all other requirements

I've seen others as well.  Most will have a category that contains "non-functional" requirements.  And there's where my heartburn lay. 

When creating classifiers of a type, whether in OO, or in taxonomy efforts, it is a very good idea to avoid creating a type called "All-Other."  If you create a type called "All-Other," that tells me that you don't really know enough about your domain, and you don't know why you have things in your domain that you cannot classify, but you do, so you create a category for "everything I cannot classify" and throw all elements in. 

How do you know you have one of these types in your taxonomy?  If the definition of the class contains a negative, as in Non-Functional or Non-Testable or Non-useful.

Basically, the category of 'non-functional requirements' is an "all-other" category.

Over the years, software development has matured to the point where we have categories for most requirements, and they are well understood, so the stuff that falls into the "non-functional requirements" category is very constrained.  We have a coherent set because we have identified all of the elements that don't belong there.  Yet the name remains.

I'd like to suggest that we kill off the classification of "non-functional" requirements, and replace the name with "quality metric requirements."  Basically, that's all that is left in the modern "All-Other" requirements class: those requirements that reflect a measurable goal of system quality, usually expressed as a metric.  For example: "the online store must be available for browsing of the product catalog 24 hours per day, reliably 99.99% of the time."  Availability is a notorious 'non-functional requirement.'

But if we replace the category of 'non-functional requirements' and call it a quality metric requirement, then we get three benefits:

1. We can make the statement that all 'quality metric' requirements are actually derived from a measurable goal, not a fiction.  The business should not say 'I want 2 second response time' without explaining why that is important.  A reasonable requirement, like a 2 second response time, can be connected to the customer expectations or the business competitive strategy. 
2. An less obvious relationship may be drawn when he business says "I need this system to be operating 99.999% of the time."   Anyone who has seen a requirement like this one knows that a "5-nines" requirement will definitely affect the cost of the solution, and probably the amount of time needed to test and deliver it.  If the customer needs this kind of reliability, they should be asked the answer "why."  By classifying this requirement as a quality metric, and by requiring that each quality metric must be defined, it should be much easier to catch those situations where the business has gold-plated their list of requirements.
3. By removing the 'All-Other' classification, we lose the temptation to use it to toss in "other" requirements that we have no real understanding of.  This forces a level of quality into the requirements gathering process.  

So my suggestion for a requirements type taxonomy would be:

• a) Business Ability Requirements-- high level or "one liner" requirements that identify the high level statements of functionality we can expect to come directly from a business user.
   
• b) Data Relationship Requirements -- the understanding of logical data entities and their relationships, expressed as software requirements to model and store information that matches those data entities.
   
• c) Reporting requirements - the understanding of the contents of documents, reports, and artifacts that are either generated by or consumed by the business processes themselves, often in the form of process artifacts.  Basically, any time your software facilitates communication between two people, or outward from a person to an external party, you would capture reporting requirements.
   
• d) Functional interaction requirements - the requirements most easily drawn from an understanding of the processes that a user or customer will use when interacting with the software, functional requirements specify conditions and behaviors that must be met.
   
• e) Quality Metric Requirements - the requirements that are drawn directly from business strategy or goals, including those that recognize customer expectations for software of a particular type, and those that establish or recognize a competitive position for the company in the marketplace.  This includes the software quality attributes like reliability, availability, usability, and flexibility.

It is time to get rid of the 'all-other' category of software requirements.

Comments

• Anonymous
  October 14, 2008
  Hi Nick. Agree completely. It is certainly a conceptual error to define an engineering concept in negative terms, in other words in terms of what it isn't. But in addition to being a conceptual error, it is also a psychological error, because it makes us believe that the concept is somehow unimportant. See http://rvsoapbox.blogspot.com/2008/10/so-called-non-functional-requirements.html

• Anonymous
  October 15, 2008
  The comment has been removed

• Anonymous
  October 15, 2008
  The "Outside-in Software Development" approach says to figure out what goal - and whose goal - you seek to satisfy for all requirements.  Even internal ones.  So a serviceability aid serves the goal of your support team to turn bugs faster / more productively.  

• Anonymous
  October 15, 2008
  Hi Nick, I have taken offense to "Non-functional" requirements for years. I have been calling them "Service Quality requirements", very similar to your proposal.

• Anonymous
  October 15, 2008
  Where do the commercial requirements go in your taxonomy - for example, the requirement that a given service should cost less than $x per transaction? You could regard this as a quality requirement, but most people don't seem to.

• Anonymous
  October 15, 2008
  The comment has been removed

• Anonymous
  October 18, 2008
  Nick - your 100% correct with this one, I prefer the term quality requirements normally. It's frustrating that too often I have to explain that by this term I mean 'non-functional requirements' though. I can't check right now, but in one of the SEI books on software archicture (either Documenting Software Architecture in Practise or Documenting Software Architectures) there's a side bar on the subject that comes to the same conclusion - and that's were I got my term from.

• Anonymous
  October 20, 2008
  I agree, for years I have tried to get the quality metric requirements defined as Service Level Agreement (SLA) they can then be tied to a specific busines user, class of users, vary depending on the needs of a particular group. If I use a requirements DB I can then print an SLA from teh requirements and everyone readily understands what you mean.

• Anonymous
  October 20, 2008
  Good point, Ed, In our IT Traceability model, Service level agreements are directly tied to Quality Metric Requirements.  We are doing the same things. Perhaps it is time to start calling this a 'best practice.' --- N

• Anonymous
  October 21, 2008
  The comment has been removed

• Anonymous
  October 22, 2008
  I'm happy you include cost as a quality metric. However there is a great deal of material in circulation that fails to mention cost (including ISO 9126), so I think it takes a constant effort to  make sure it stays visible.

• Anonymous
  October 22, 2008
  The comment has been removed