Classifying Requirements?
What are the various types of classifications?

While the various classifications may make it easier to understand, there is no need to have long drawn out debates on whether or not a requirement should be part of the “Place Order” package or part of the “Register User” package.

I have seen several completed “Business Requirement” documents with so many classifications and sections that it was actually more confusing.

Requirements can be classified in various ways.

Functional vs Non-Functional

Probably the most frequently used means of classification is Functional vs Non-Functional This classification helps identify whether a requirement will affect the functionality of the system (Functional) or whether it will constrain the system (Non-Functional). This classification is probably the most beneficial in that it helps defined what system functions are being considered.

There are some people who want to further classify the Non-Functional requirements into various categories such as “Design Requirements” or “Performance Requirements”. This may add benefit for the simple reason it helps provide them with a checklist. But again, I don’t see a major benefit.

• Functional
• ”The customer must be able to place an order, within two minutes of registering”
• ”The sales person must be able to view company products, one day prior to general release”
• Non-Functional
• ”The system must use existing software and hardware”
• ”The solution must have the same look and feel as the other systems”

Domain

Another way of classifying requirements is by areas of interest or Domain. It may be useful to group requirements under various domains or packages that could then be assigned to various people or teams for consideration. For example, the “Check Credit” and “Complete Application” requirements could be grouped under a package “Customer Application”.

Remember, the main objective of the Requirements Management Process is to ensure that the Business Requirements are clearly defined and agreed to so that they can be used for the basis of the scope for the project. Making sure that ALL the requirements have been captured is more important than the type of classification.

Requirementing, from Clearly Put, uses a simple straight forward means of Classifying Requirements.

Summary

Classify requirements for clarity. The only real classification that is beneficial is Functional and Non-Functional. Provide further classification if there is a benefit but don’t get hung up on which requirement goes where.

Requirementing Steps