The job is bigger than writing requirements
Business analysis is often reduced to a list of documents: BRD, FRD, user stories, process maps and so on. Those artifacts matter, but they are outputs of a much larger thinking process.
A strong BA helps an organization move from “something is not working” to a shared understanding of the problem, the desired outcome, the options available, and the requirements that make a solution possible.
Start with the decision that needs to be made
When a stakeholder says, “We need a new dashboard,” the first useful question is rarely “What should the dashboard look like?” It is “What decision are you trying to make that is difficult today?” That question changes the conversation from features to outcomes.
PMI describes business analysis as work that identifies needs, recommends viable solutions, manages stakeholder requirements and supports successful implementation.
BA and PM are connected, not interchangeable
| Question | Practical answer |
|---|---|
| Business analysis | What problem are we solving? What should the solution accomplish? |
| Project management | How do we organize people and work to deliver the agreed outcome? |
| Product management | What should we build, for whom, and why does it create value? |
| Engineering | How can we build the solution safely and effectively? |
What good BA work feels like
Try it
Take any familiar app or website. Write one feature request. Then ask “why?” three times. Your final statement should sound more like a business outcome than a feature.
What the BA is actually producing
The visible output may be a BRD, a process map or a set of user stories, but the deeper output is shared understanding. Before a developer starts, the team should understand the business problem, the user or process affected, the important rules, and the outcome being pursued. That shared understanding reduces the expensive kind of rework: building the wrong thing correctly.
In practice, the BA also creates decision clarity. When two stakeholders disagree, the BA can separate facts, assumptions, preferences and constraints. That makes the disagreement discussable instead of personal.
A practical example from eCommerce
A retailer says, “We need Shopify subscriptions.” Do not jump straight into selecting an app. First understand why recurring revenue matters, which products can recur, how customers pause or cancel, how fulfillment works, what payment rules apply, and what happens to existing customers. The implementation becomes much clearer once those questions are answered.
Common trap: becoming the “requirements typist”
A BA can become busy and still add little value if every meeting ends with a longer feature list. A better habit is to ask what decision the new information enables. If a requirement changes, what assumption changed? If a stakeholder adds a feature, what outcome does it support? If a defect appears, which earlier ambiguity allowed it through?
Take a feature request you have received in real life. Write the request, the underlying problem, the affected people, the business outcome and one assumption you would want to validate before the team estimates it.