Categorizing requirements

I mentioned in a prior blog post that at the RE 06 conference I attended a session where the academic leaders in requirements assembled to try to hammer out a consistent nomenclature for requirements. I say try because even this group of esteemed experts made no progress on this effort. From my point of view there were two main blocks, the semantics of the actual categorizations themselves and the why behind categorizations. In this post I will focus on the second.


Since we create requirements for a living it is natural to ask why for everything. In this particular case, why categorize requirements, what is the purpose of segmenting requirements into categories, what are the use cases?


There are two very practical reasons for categorization, the first is to aid in training new people how to think about requirements, the second is as an aid in the discovery/review of requirements.


The most common nomenclature divides requirements into functional and non-functional requirements. Some call the non-functional requirements quality of service requirements. Regardless of the name, the non-functional requirements are further divided into a host of specific types of requirements such as reliability, availability etc. These subcategories are actually reasonably good at guiding a designer as to what types of requirements are missing. However the catch-all category of functional requirements is almost useless. When we do audits of requirements documents, inevitably this area of functional requirements causes the most trouble as no one seems to know what goes here.


Unfortunately I don't have the answers, but I do recognize that the gap exists. Please go over to the messageboard and participate in our discussion of types of requirements.