Sometimes the requirement is perfectly clear. It is the problem behind it that nobody has understood.
The meeting was supposed to take thirty minutes.
The sales director had joined with a clear request. The CRM system needed a new field on the opportunity record. It was a small change, easy to explain and, as far as he was concerned, long overdue.
“Can we get this into the next release?” he asked. “The team needs to identify the important opportunities quickly. At the moment, we are wasting too much time trying to work out which deals deserve attention.”
The business analyst made a note. The development team could add the field, the sales director could confirm the values, and the requirement could be estimated before the end of the week.
Nobody in the meeting objected. The request made sense.
A few weeks later, the field was available in Dynamics 365. The team had tested it, the director had approved it, and the change had gone live.
Then, during a review meeting a month later, the sales director raised the same complaint.
“We are still spending too much time figuring out which opportunities matter.”
The analyst looked back at the requirement. It had been delivered exactly as requested.
So why was the problem still there?
The field was not broken. The development team had not misunderstood the specification. The testers had not missed a defect. Everyone had done what they were supposed to do.
The trouble was that the team had spent its time answering the question, “How do we add this field?” Nobody had spent enough time asking, “Why can't the sales team identify the right opportunities today?”
That is a much harder question. It is also the one that should have come first.
The request is not always the requirement
In a project, requests tend to arrive in the form of solutions.
A stakeholder asks for a dashboard, a new approval step, an automated notification or another field in the system. These are tangible things. They are easy to discuss in a meeting, estimate in a backlog and demonstrate at a sprint review.
The problem behind the request is often less tangible.
In the sales example, the director believed the team needed a new field. But there could have been several reasons for the difficulty:
Salespeople were not following a consistent process for qualifying opportunities.
Important information was scattered across CRM records, spreadsheets and emails.
Managers had different ideas about what made an opportunity valuable.
Existing reports did not provide a reliable view of the pipeline.
The team had the necessary information but no agreed way to use it when making decisions.
Each of these problems would lead to a different solution. A new field might help with one of them. It might do very little for the others.
This is where requirements gathering becomes more than documentation. The job is not simply to record what a stakeholder wants. It is to understand why they want it, what is happening today, and what needs to change.
That distinction sounds obvious when written down. In a busy project, with deadlines approaching and a backlog waiting to be filled, it is surprisingly easy to miss.
Why do we accept the first answer?
It is tempting to blame stakeholders for asking for the wrong things. In practice, the problem is usually more complicated.
A sales director sees the business through sales performance. An operations manager sees the delays created by a process. A finance manager sees the reporting gaps. Each person describes the problem from the part of the organisation they know best.
They are not necessarily wrong. They simply have a partial view.
There is also a practical reason teams move quickly to solutions: solutions create the impression of progress. A new feature can be demonstrated. A process diagram can be approved. A requirement can be marked complete.
Understanding the problem takes longer. It may involve speaking to users, examining existing data, watching how work is actually performed and challenging assumptions that senior stakeholders have held for years.
And sometimes, after all that investigation, the answer is uncomfortable. The business may not need the feature it requested. It may need to change the way it works.
That conversation requires judgement. A business analyst who immediately rejects the request risks appearing obstructive. One who accepts every request without question risks becoming a documenter of decisions that should have been examined more carefully.
The useful middle ground is to take the request seriously without assuming that the proposed solution is already correct.
What should the analyst have asked?
Return to the sales director's original request.
Instead of immediately documenting the new field, the analyst could have asked a few questions.
“Can you show me how the team decides which opportunities need attention today?”
That question moves the conversation away from the proposed feature and towards the actual work.
The director might explain that managers review a pipeline report every Monday. Salespeople update their opportunities at different times, and some use spreadsheets to keep track of information that is missing from the CRM.
The analyst could then ask:
“What information are you looking for when you decide which opportunities matter?”
Perhaps the answer is deal value, expected closing date, customer engagement, probability of closing and the time since the last interaction.
“Where does that information come from? Is it already in the system?”
Now the conversation is becoming more specific. Some information may already exist. Some may be incomplete. Some may be recorded inconsistently. The issue may not be the absence of a field at all.
One more question matters:
“If we solve this problem, what should become easier or better for the team?”
The director might say that managers should be able to identify at-risk opportunities more quickly, spend less time preparing for pipeline reviews and intervene before deals are lost.
That is a much more useful starting point than “add a field”.
The analyst still has not rejected the request. They have made it possible to evaluate it properly.
The moment a requirement changes direction
Suppose the investigation reveals that most of the information the sales team needs is already available in Dynamics 365. The difficulty is that it is not consistently maintained, the qualification criteria are unclear, and managers use different methods to interpret the pipeline.
Adding another field would give users one more thing to update without necessarily improving the decision they need to make.
The team now has several options.
It could improve the existing qualification process, clarify which information is mandatory at each stage, improve the pipeline view, or introduce a new field if a genuine information gap remains.
There may be a case for doing more than one of these things. The point is not to avoid adding fields or customising a system. The point is to choose the changes that address the problem rather than simply reproducing the original request.
This is also where the business analyst needs to bring the stakeholder along.
Instead of saying, “You don't need that field,” the analyst could explain:
“We looked at how the team identifies important opportunities. The main issue appears to be that the information is not being used consistently, rather than that it is completely missing. We can still add the field if it is needed, but I recommend we first address the qualification process and reporting. That should give us a better chance of improving the pipeline review.”
The conversation is now about an outcome. The stakeholder can challenge the findings, provide additional evidence or agree to test the alternative.
The decision is better because it is based on a clearer understanding of the problem.
What if the stakeholder insists?
Not every conversation will unfold so neatly.
Sometimes a senior stakeholder has already promised a feature to another team. Sometimes a deadline has been announced. Sometimes the person requesting the change has the authority to make the final decision and does not want to reopen the discussion.
In those situations, the analyst still has a responsibility to make the implications visible.
Explain what is known, what remains uncertain, what alternatives exist and what the likely consequences are. If the request must proceed, document the rationale and any assumptions that need to be tested.
There is an important difference between challenging a request and refusing to deliver it. Good analysis does not mean that every requirement must be debated indefinitely. It means the decision should be made with an appropriate understanding of the problem, the available options and the risks.
If the change is small and reversible, a limited implementation may be reasonable. If it is expensive, difficult to reverse or likely to affect several business processes, more investigation may be justified.
The amount of analysis should reflect the consequences of getting the decision wrong.
Turning a conversation into a usable requirement
Once the problem is understood, the team can document what needs to change.
For the sales example, the requirement might no longer be simply “Add a high-value opportunity field”.
It could instead describe the capability the business needs: sales managers must be able to identify opportunities requiring intervention using agreed qualification criteria and reliable information.
The team would then define the details. Which criteria matter? Who maintains the information? What happens when information is missing? How should the results appear in reports? Which users need access? How will the business evaluate whether the new process is working?
These questions turn a broad intention into something the team can design, implement and test.
They also make it easier to distinguish between the business need and the eventual technical solution. The need can remain stable while the team considers different ways to meet it.
For a Dynamics 365 implementation, that might mean using existing functionality, configuring a view or business rule, changing a process, extending the data model or combining several approaches. The correct choice depends on the findings and the constraints of the actual environment.
The important thing is that the technical decision follows the analysis, rather than replacing it.
A simple habit that improves requirements gathering
You do not need a complicated framework for every request. Often, a short conversation is enough to expose the difference between what someone wants and what they need.
Before writing the requirement, make sure you can answer four questions:
What is being requested? Record the stakeholder's request accurately, without assuming it is the final solution.
What problem does it address? Understand the current situation, the people affected and the consequences of leaving it unchanged.
What should improve? Define the expected business outcome and how the team will recognise progress.
What other options are worth considering? Examine whether the proposed feature is necessary, whether an existing capability could work, or whether a process change would be more effective.
These questions are not a substitute for interviews, workshops, process analysis or formal requirements management. They are a way to stop the team from moving into solution design before it has understood the problem.
For a small request, the answers may take ten minutes. For a major transformation, they may require substantial discovery. The discipline is the same.
The real work begins before the requirement is written
Go back to the sales director's request one last time.
The field was delivered. The requirement was signed off. The system behaved exactly as expected. Yet the business problem survived because the team had treated the requested solution as if it were the problem itself.
That is an expensive mistake, but it is also an avoidable one.
A good business analyst does not need to know the answer before entering the meeting. They need to recognise when the first answer is only a starting point.
Ask what is happening today. Find out who is affected. Understand what the business is trying to achieve. Test the assumptions. Only then decide what needs to be built.
Sometimes the investigation will confirm the original request. Sometimes it will lead to a different solution. Both outcomes are useful.
The objective is not to prove the stakeholder wrong. It is to make sure that when the team finally delivers the solution, it has a reasonable chance of solving the problem that brought everyone into the meeting in the first place.
The best requirements gathering often starts with a simple question: “Can you show me what happens today, and what you are trying to change?”