Requirements have attributes that make up and define the requirement. These attributes ensure that the stakeholders in your business analysis get what they need from the requirements. Not every stakeholder needs to know all the various attributes, however. Categorizing requirements lets you help stakeholders access just the information they need from all the information that surrounds a requirement.
Consider how you search for recipes: You may look for all dishes that include chicken, all dishes that can be grilled, or recipes that received ratings of four starts or better. In each selection, you could find grilled chicken (the requirement), but you found it in different ways. Your recipes are like requirements.
By categorizing the requirements, you’re able to communicate the different levels of requirements to the appropriate audience. Business people can understand the requirements at their level, technical people at their own level, and so on.
If you’re a business person, you can choose to look only at the business requirements. If you’re an approver, you can choose to look only at requirements that are ready for approval. Additionally, you can show progression of how a particular requirement at the business level is being solved through the functional requirements with traceability.
How to start categorizing business analysis requirements
Although categorizing becomes intuitive after a while, it may seem confusing at first. After all, the stakeholders just keep talking and talking, and you may have a hard time making sense of it. Here’s a process to get you started:
Capture the requirements.
This idea may seem simple, but the first step is to elicit the requirements from the stakeholder.
Look for operative words.
Review your elicitation notes and look for key words that define the stakeholder’s statement. If a stakeholder mentions technology or a technical constraint, for example, you know it’s not a business requirement. Here are things to look for as you categorize:
Business and stakeholder requirements: Look for words and phrases that describe the what, such as “we need a way to” and “we need to be able to.” These requirements don’t mention technology or a solution, so you know they’re describing what needs to happen. You may find yourself extracting these from the functional requirements by asking “Why?” frequently.
Solution requirements (functional and nonfunctional): These requirements have solution-oriented language, such as “the system will.” These requests often contain a solution component.
Technical requirements: You hear technical language and jargon inside these requirements. For instance, “alphanumeric indicator” and “customer prospect table” are jargon-y terms that can tip you off to a technical requirement. Look for solutions of how the system is built.
Transition requirements: Because these requirements focus on the tasks needed to go from the current state to the future state, look for temporary requirements, such as “Migrate the data from the old system to the new.”
Clarify with the stakeholder.
Go back and have the stakeholder confirm her understanding of what you noted. This validation can prevent defects or misunderstanding later.
Put the round peg into the round hole.
Document the requirements appropriately, putting the requirement into the correct category.
How to choose the right category for business analysis requirements
Often, the challenging part for new business analysts is correctly identifying which category any particular requirement falls into. If you get tripped up as you sort through your requirements, think of them as building on each other to help you figure out where they go in the order.
Consider the process you use when you purchase a car. You first need to understand the mission of the vehicle. Are you looking to cart around your kids’ soccer team, or do you need an inexpensive commuter car? These needs are your business requirements.
Next, you look for a solution by examining the different vehicle options, choosing which ones have the features, color, and style (functional requirements) and performance (nonfunctional requirements) you need. Finally, the manufacturer delivers a car with an independent suspension rocker arm wishbone suspension riding on P205/R16 Z4 tires (technical requirement).
Another way to help yourself categorize requirements is to figure out who reviews and ultimately uses the contents of which category. Below is an example of a handy reference chart that outlines best practice standards, although the categorization can vary slightly from project to project.
| Requirement Type | Elicited and Documented By | Reviewed and Used By |
|---|---|---|
| Business and stakeholder requirements | Business analysts (BAs) | Subject matter experts (SMEs), technical team, and testing team |
| Solution (functional and nonfunctional) requirements | BAs and/or technical team | SMEs, technical team, testing team, and BAs if not involved in the creation |
| Transition requirements | BAs and/or technical team | SMEs, technical team, testing team, and BAs if not involved in the creation |
| Technical requirements | Technical team | BAs, developers, testing team |
