There are three ways to categorize requirements that will work well more often than others. These approaches will work for most projects, but it's still good to remember that the unique needs of a project can spawn any number of "best" requirements categorizing approaches.
The first of these three time-tested approaches is to categorize according to the requirement levels. Note that if you decide to categorize by levels, you can usually sort the requirements into the three traditional levels described below. Notice also that the second and third levels trace back to the first:
- High-level requirements (also called vision requirements or business requirements). These are broad statements, usually general in nature, that address the business need from 50,000-foot altitude.
- User-level requirements. These are requirements that users say they absolutely must have in order to interact successfully with the system.
- System-level requirements. These requirements are very specific; system-level requirements are often the most detailed. They can include factors as fine-grained as the number and type of characters in a data field.
Another approach is to separate the functional and nonfunctional requirements.
(Nonfunctional specs are often called "supplemental" or "supplementary" specifications.) While dividing the specifications into two neat categories is an orderly way to write the documentation, remember that in the real world the functional and nonfunctional requirements are always tightly intertwined.
- Functional requirements address which functions the system must perform. Thus it's obvious which requirements fall in this category: those that state which functions the system must perform.
- Nonfunctional requirements address the degree to which the system must perform the requirements. Common examples of nonfunctional requirements are any that address usability, reliability, performance, or security.
A third way to organize the requirements is by requirement documentation type
. In this case, you would manage and organize the requirements by the tool used to document them. Some common tools/categories include: process maps, process-flow documents, use cases
, use-case models, diagrams (business-context or system-context diagrams
, state charts, etc.), and business rules. When you find yourself organizing the requirements by documentation type, consider using an electronic requirements management tool, which can help speed and formalize the process.