Sorting Through the Pile: Classifying Customer Requirements
Your customers won’t give you a tidy list of their requirements. Learn how to classify the input you hear into usable categories.
If you’re a business analyst, product manager, or product owner, don’t expect your customers to present you with a succinct and organized list of their requirements. Instead, you must organize the myriad bits of information you accumulate during requirements elicitation into various categories so you can record it appropriately and other people can work with it.
Figure 1 illustrates nine common categories of requirements knowledge. During elicitation activities, you can add indicators in your notes if you detect some bit of information of one of these types. For example, you might write “DR” in a little circle if you hear a data requirement whiz by during the discussion.
The information you encounter won’t all fit neatly into these nine buckets. You’ll have bits of information left over after this classification. Anything not in one of these categories might be:
- A transition requirement to help users migrate from an old system to the new one, such as the need to train users on the new system.
- A project constraint, such as a cost or schedule restriction (as opposed to a design or implementation constraint).
- An assumption or external dependency.
- Descriptive, background, or context-setting information.
- Extraneous information that doesn’t add value and can muddy the waters.
Elicitation participants won’t simply tell you, “Here comes a business requirement.” As a BA, you need to determine what type of information each statement you hear represents. Here are some cues to listen for that will help with this classification process.
Business requirements. Anything that describes business objectives or the financial or other benefits that customers or the developing organization hope to achieve is a business requirement. Listen…