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. 

steel_bucket

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.