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 should be identified early on.
At the highest level, requirements may 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 may be others as well. For instance, your organization may have regulatory requirements to
fulfill.
Some projects may also need to capture business rule requirements, report specifications, and so on.
When a requirement is first captured, it should 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.
Tools allow the analyst 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.
|