Requirements have attributes that shape and define the requirement. These features ensure that the stakeholders in your business analysis have the requirements they need. However, not every stakeholder needs to know all the different traits. Classification requirements allow you to help stakeholders access only the information they need from all the information surrounding the requirement.
Consider how to search for recipes: You can search for all dishes with chicken, all dishes that can be grilled, or recipes with ratings of four starters or better. In each selection you can find grilled chicken (the requirement), but you’ve found it in different ways. Your recipes as requirements.
By classifying requirements, you can communicate the different levels of requirements to the right audience. Entrepreneurs can understand requirements at their level, technical people at their level, etc.
If you are an entrepreneur, you can choose to look at the business requirements only. If you agree, you can choose to only look at the requirements that are ready for approval. Additionally, you can show progress on how to solve specific business-level requirements through functional requirements with traceability.
How to Get Started Classifying Business Analysis Requirements
Although classification becomes self-evident after a while, it can seem confusing at first. After all, stakeholders keep talking and talking, and you may find it hard to understand. Here’s a process to get you started:
1. Capture the requirements.
This idea may seem simple, but the first step is to elicit the requirements from the stakeholder.
2. Look for operative words.
Review the extrapolation notes and look for keywords that identify the stakeholder statement. If a stakeholder mentions a technology or a technical limitation, for example, you know it’s not a requirement of the business. Here are things to look for while categorizing:
Business and stakeholder requirements: Look for words and phrases that describe what, such as “we need a way” and “we need to be able to.” These requirements do not refer to technology or solutions, so you know they describe what needs to happen. You may find yourself extracting these from the job requirements by asking “Why?” Often.
Solution requirements (functional and non-functional): These requirements have solution-oriented language, such as ‘will system’. These requests often contain the solution component.
Technical Requirements: You hear technical language and terminology within these requirements. For example, “alphanumeric indicator” and “lead table” are general terms that can direct you to technical requirements. Find solutions for how to build the system.
Transition requirements: Because these requirements focus on the tasks needed to transition from the current state to the future state, look for temporary requirements, such as “migrate data from the old system to the new system.”
3. 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.
4. 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
Oftentimes, the difficult part for new business analysts is to correctly identify which category any particular condition falls into. If you get stuck while you’re sorting through your requirements, think of them as building on each other to help you see where they go in order.
Consider the process you use when buying a car. First you need to understand the mission of the car. Looking to ride around for your kids’ soccer team, or do you need an inexpensive passenger car? These needs are the requirements of your business.
Next, you search for a solution by examining the various vehicle options, choosing which one has the features, color, style (functional requirements) and performance (non-functional requirements) you need. Finally, the manufacturer delivers a car with a swing-arm independent suspension mount that rides on P205/R16 Z4 tires (technical requirements).
Another way to help yourself categorize requirements is to see who reviews and ultimately uses the contents of any category. Below is an example of an easy-to-use reference chart that outlines best practice standards, although the rating can vary slightly from project to project.
Requirement Type Elicited and Reviewed and Used By
Documented By
Business and stakeholder Business analysts (BAs) Subject matter experts (SMEs),
requirements technical team, and testing team
Solution (functional and BAs and/or technical SMEs, technical team, testing team,
nonfunctional) requirements team and BAs if not involved in the creation
Transition requirements BAs and/or technical SMEs, technical team, testing team,
team and BAs if not involved in the creation
Technical requirements Technical team BAs, developers, testing team