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 for statements about the value that buyers or users of the software will receive, such as these:
- “Increase market share in region X by Y percent within Z months.”
- “Save $X per year on electricity now wasted by inefficient units.”
- “We’ll save $X per year on license fees if we can retire that legacy package solution we’re using.”
User requirements. Statements of user goals or business tasks that users need to perform are user requirements. You’ll most typically represent these as use cases, scenarios, or user stories. A user who says, “I need to <do something>” is probably describing a user requirement:
- “I need to print a mailing label for a package.”
- “As the lead machine operator, I need to calibrate the pump controller every morning so the readings are accurate.”
Business rules. When a customer says that only certain users can perform an activity under specific conditions, that might be a business rule. These aren’t software requirements as they stand, but you might derive some functional requirements to enforce the rules. Phrases such as “Must comply with…,” “If <some condition is true>, then <something happens>,” or “Must be calculated according to…” suggest that the speaker is describing a business rule. Here are some examples:
- “A new client must pay 50 percent of the consulting fee in advance.”
- “Time-off approvals must comply with the company’s HR vacation policy.”
Functional requirements. Functional requirements describe the observable behaviors the system will exhibit under certain conditions and the actions the system will let users take. Here are some examples of functional requirements as you might hear them from users:
- “If the pressure exceeds 40.0 psi, the high-pressure warning light should come on.”
- “The user must be able to sort the project list in forward and reverse alphabetical order.”
These statements illustrate ways users typically present functional requirements, but they don’t necessarily represent good ways to write those requirements. You’ll need to craft these into more precise, complete, and actionable statements at the right time to ensure developers build the right thing.
Quality attributes. Statements that describe how well the system does something are quality attributes. Listen for words that describe desirable system characteristics: fast, easy, user-friendly, reliable, secure. You’ll need to work with the users to understand precisely what they mean by these ambiguous and subjective terms so you can write achievable, verifiable quality goals. The following examples suggest what quality attributes might sound like coming from users:
- “The mobile software must respond instantly to touch commands.”
- “The shopping cart mechanism has to be simple enough that my new customers don’t abandon the purchase.”
External interface requirements. Requirements in this category describe the connections between your system and the rest of the universe. A rich requirements document template includes sections for interfaces to users, hardware devices, and other software systems. Phrases such as “Must read signals from…,” “Must send messages to…,” “Must be able to read files in <format>,” and “User interface elements must conform to <a standard>,” indicate external interface requirements:
- “The manufacturing execution system must control the wafer sorter.”
- “The mobile app should send the check image to the bank after I photograph the check I’m depositing.”
Constraints. Design and implementation constraints restrict the options available to the developer. Physical products often must respect physical constraints such as size, weight, and interface connections. Phrases that reveal a design or implementation constraint include: “Must be written in <a specific programming language>,” “Cannot exceed <some limit>,” and “Must use <a specific user interface control>.” Here are some examples of constraints that a customer might present:
- “Files submitted electronically cannot exceed 10 MB in size.”
- “The browser must use 256-bit encryption for all secure transactions.”
As with functional requirements, don’t simply transcribe the user’s statement of a constraint. Ask why the constraint exists, confirm its validity, and record the rationale for including it.
Data requirements. Customers are presenting a data requirement whenever they describe the format, data type, allowed values, or default value for a data item; the composition of a complex business data structure; or a report to be generated. These are examples of data requirements:
- “The ZIP code has five digits, followed by an optional hyphen and four digits that default to 0000.”
- “An order consists of the customer’s identity, shipping information, and one or more products. Each product ordered includes the product number, number of units, unit price, and total price.”
Solution ideas. My consulting clients often complain that many “requirements” they get from users are really solution ideas. Someone who describes a specific way to interact with the system to perform some action is suggesting a solution. You’ll need to probe below the surface of a solution idea to get to the real requirement the speaker has in mind. Asking “why” the user needs it to work this way a couple of times likely will reveal the true need. For instance, passwords are one to implement a security requirement, but there could be others. Two other examples of solution ideas are:
- “Then I select the state where I want to send the package from a drop-down list.”
- “The phone has to allow the user to swipe with a finger to navigate between screens.”
In the first example, the phrase from a drop-down list describes a specific user interface control — that’s a solution idea. You might ask, “Why from a drop-down list?” If the speaker replies, “That just seemed like a good way to do it,” then the real requirement could be, “The system shall permit the user to specify the state where he wants to send the package.” But maybe the speaker says, “We do the same thing in several other places and I want it to be consistent. Also, the drop-down list prevents the user from entering invalid data.” These are legitimate reasons to specify a specific solution.
Recognize, though, that embedding a solution in a requirement imposes a design constraint on that requirement. It limits the developer to implementing the requirement in only one way. Design constraints aren’t wrong or bad. Just make sure each there’s a solid reason for each constraint and that they aren’t imposed prematurely or unnecessarily.
Classifying the customer input is just the beginning of the process to create good requirements. You still need to assemble the information into clearly stated and well-organized requirements collections. An essential role for a business analyst, product manager, or product owner is to sort through the pile of random customer input and turn it into actionable requirements.
This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources. Karl’s latest book is The Thoughtless Design of Everyday Things.