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. 

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

12 thoughts on “Non-Functional Requirements: the "All-Other" classification”
  1. 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.  

  2. 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.

  3. 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.

  4. Hi Richard,

    That’s a quality metric requirement.

    I know of a company with just such a requirement.  They need to keep the Cost Per Transaction (CPT) very low, because their competition has a low CPT and they will lose business if they go much over.

    That is a requirement based on competitive position.

    If you look at my definition:

    "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."

    In my experience, there are really only three sources of requirements: customer expectations, business strategy, and business process.  This category covers the first two.  

    Why else would I need to be available 24/7 at 99.99%?  For either customer expectation or competitive position.  The fact that we call "availability" a quality attribute is besides the point.

    That is why I define the category like I do.

    Hope that helps,

    — Nick

  5. 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.

  6. 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.

  7. 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

  8. Even "quality requirements" doesn’t quite capture some of the distinctions of interest, as it simply relabels the classification group of "non-functional requirements" to something else. There are (at least) two quite distinct areas of quality we may care about, one of which is the operational side of things (relates to the execution of the software) and the other is the developmental side (relates to the code). See http://www.two-sdg.demon.co.uk/curbralan/papers/InsideRequirements.pdf

  9. 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.

  10. Hi Richard,

    The list of things wrong with ISO 9126 is longer than the list of things right with ISO 9126.  

    ’nuff said.

    — N

Leave a Reply

Your email address will not be published. Required fields are marked *

eight + seventeen =

This site uses Akismet to reduce spam. Learn how your comment data is processed.