Why Categorize Requirements?

The most obvious reason for categorizing requirements is to keep them organized and easy to find. When a project generates a large number of complex requirements, the only way to manage them is to separate them into categories and uniquely identify them. To build consistency into the analysis process, the same categories should be used on every project. Any team member on any project will know the categories and be able to organize and review requirements quickly.

The second and maybe most important reason for categorizing requirements is to separate them by audience. Remember that the only reason why requirements are formally documented and presented is to communicate and confirm understanding (and to decrease reliance on people’s memories!). Different types of requirements will be reviewed and approved by different stakeholders. Business stakeholders review business requirements to make sure that the true business needs are understood and that nothing has been missed. Developers review detailed functional requirements. This points to the practicality of categorizing and presenting like requirements together. Using the same logic, technical requirements are rarely reviewed by business stakeholders and as such should be categorized separately and presented specifically to the technical team.

A third reason for categorizing requirements is reusability. True business requirements will outlive software applications and procedures. When business requirements are created from the what perspective, they can be used on other projects. Reusing requirements saves time and encourages enterprise-wide consistency. These are excellent results of the business analysis discipline. Functional requirements may be reused when enhancements are requested to existing software. The original functional design can be used to show the change. Technical requirements become important documentation for software implementers, support people, and the maintenance team. In addition, a successful technical design may be copied and reused for another application.

Finally, a reason to categorize requirements is to facilitate impact analysis for managing change requests. Impact analysis refers to the assessment made to determine the ramifications (impact) of a proposed change. Impact analysis relies on requirements traceability. After a solution system has been deployed and is being used successfully, changes are often requested. Maybe the business has decided to offer a new type of product or service. Business leaders will ask: “What is the impact of this change? How much will it cost to change our systems?” Impact analysis requires the analyst to review existing systems to determine what changes need to be made. Having requirements clearly categorized and organized provides the analyst with the material needed to quickly assess the impact of a change.

Deciding on categories is time consuming and challenging, so it is inefficient to develop a new set of categories every time you start a project. An organization will be most efficient if it decides on one general categorization scheme and uses it consistently. A consistent system will increase BA efficiency, even if it is not perfect. Review the system periodically to make adjustments. The following are some suggestions for setting up your own system.