Guideline: Categorizing Requirements |
Assign requirements to different categories in order to manage them better.
Relationships
Related Elements | Organize Requirements Packaging Requirements Plan Requirements Management Strategy Requirements
Main Description
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.
More Information
Guidelines | Packaging Requirements
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.