Requirement categorization is important, because requirements in different categories usually have different
stakeholders, reviewers, and approvers, and they behave differently throughout the project lifecycle. Categorization
also allows a team better control and organization over a large set of requirements.
The requirement categories or types needed for the project need to be identified early on.
At the highest level, requirements can be categorized as business requirements and system requirements. Business
Requirements would consist of the stakeholder needs and features. System requirements are usually broken into
functional (use cases and other system-wide functional requirements) and non functional requirements. These in turn can
be categorized as Usability, Reliability, Performance, and Supportability (URPS). These (URPS) are the most common
categories, but there might be others as well. For instance, your organization might have regulatory
requirements to fulfill.
Some projects might also need to capture business rule requirements, report specifications, and so on.
When a requirement is first captured, it needs to be analyzed to ensure that it is categorized correctly. The
exact mechanism for categorizing requirements will vary based upon how the requirements are documented and organized,
and whether a requirements management tool is used. If documents are used to capture the requirement set, a simple
method of categorization is to have a separate document for each requirement category, and a different document section
for each requirement type. A larger, more complex requirement set needs a more sophisticated method of categorization.
The analyst can use tools to assign a category when each requirement is created. Information can be sorted and
filtered by requirement type, and tools can ensure that all requirements of a certain type behave the same way. An
example would be to ensure that all use cases have a matching set of test cases.
|