Diving Deeper Into Requirements
Photo by Milos Prelevic on Unsplash
Welcome to Business Analysis
A business analyst intern joins a company, looking forward to making stakeholders happy. A manager comes to the intern with a list of new fields for the account object. The intern takes the list and says he’ll get right on it. When he shows the list to the system administrator, she asks him a litany of questions about the new fields, such as:
“What’s the actual requirement?”
“Why do they need the fields?”
“What business process do they drive?”
Flustered, the intern writes down all the questions. He finds the manager and starts reciting the questions. The manager interrupts him, saying that a regulatory agency requires the account fields for compliance. Wanting to answer all the questions, the intern asks the manager, “What business process do these new fields drive?” Taken aback by the question, the manager replies, “The process of staying in business. If we don’t report the account information in these new fields to the agency, they could shut us down.” The manager advises the intern to ask one question at a time and listen for answers to other questions.
The intern wished he had asked the manager the questions when he got the list of account fields. The experience gave him a sense of what questions to ask to identify a business need. He later learns that some answers provide openings for follow-up questions. In the case of the new account fields, he asks who will enter data into the fields and which fields should require input.
Exploring Uncharted Waters
In No One Expects the Requirements Inquisition: Asking Next-Level Questions, Dr. Karl Wiegers encourages asking questions to help stakeholders think through their needs.
He lists questions that encourage stakeholders to look beyond a use case’s “happy path,” where everything goes as expected:
Is there any other way someone might perform that task?
Would a user ever want to <do something>?
Could <some condition> ever occur? What happens then?
What else could happen that we haven’t already discussed?
Follow-up questions like these open up opportunities to fill gaps in a use case, improve its definition, and even uncover additional requirements.
Open-ended questions elicit richer responses than yes/no or multiple-choice questions. For example, the first question in the list above could be reworded as, “What other ways might someone perform that task?” This is particularly useful when stakeholders hint at alternative approaches to a task or process.
“Why” or “what for” questions help a business analyst connect a need to its value. The system administrator asked the intern why the manager needed new account fields. The manager could have replied, “To store data,” an accurate but dismissive answer. A savvy business analyst would respond, “Help me understand what the data is for. What business purpose will it serve?” Starting a question with “Help me understand…” makes a question less confrontational.
What Else?
In Exploring Requirements 1: Quality Before Design, Donald Gause and Gerald Weinberg introduce the concept of a metaquestion, a question about questions. They recommend wrapping up a discovery session with the metaquestion, “Is there anything else I should ask you?” Stakeholders typically answer “No,” so a better metaquestion would ask, “What else should I have asked but didn't?”
They also pose another metaquestion, “Is there anything you would like to ask me?” While this gives the stakeholder an easy way out by saying “No,” a better metaquestion would ask, "What would you like to ask me?" This offers an opportunity to exchange ideas about how the solution will fit the business needs.
Testing the Waters
Donald Gause and Gerald Weinberg recommend starting discovery with “context-free” questions like these:
What problems do you expect this system to solve?
What problems could it create?
What’s a highly successful solution worth to the customers?
These questions focus stakeholders on the problem rather than the solution, perhaps surfacing crucial assumptions that business stakeholders take for granted. The business could have unwritten rules known by all its stakeholders for decades. It’s better to discover the rules as a requirement than to break them with a solution that didn’t account for the rules.
The Deep End
Dr. Wiegers excerpted No One Expects the Requirements Inquisition: Asking Next-Level Questions from his book More About Software Requirements: Thorny Issues and Practical Advice. He points out that trying to get all the details at the beginning of discovery could be as bad as asking vague questions, such as “What do you want?”
Elicitation requires multiple cycles of refinement, clarification, and adjustment as the participants move from high-level concepts to specific details.
Discovery can go a few rounds to cover the scope of requirements completely.
When discovery begins, stakeholders cover the “happy path,” where the solution works as expected. As they get deeper into the business needs, they should explore the unexpected, finding opportunities to improve business processes and potential pain points.
A business analyst can help by asking why requirements are needed, what value they bring to the business, and who needs them. Motivating Specific Requirements provides more detail about these questions.
Asking the right questions at the right time clarifies requirements, leading to a successful solution.