Last year I sat in on a requirements workshop where a sharp business analyst decided to use a large language model to draft user stories. She typed in something like 'write user stories for inventory management' and waited. The tool spat out twenty generic stories that had nothing to do with the warehouse system we were replacing. The batch tracking was missing, the lot number validation was absent, and it suggested a mobile app feature for customers—completely irrelevant. She looked defeated. I realized then that business analysts don't need to become prompt engineers. They need patterns that fit into how they already think.
That moment stuck with me. I had been geeking out over chain-of-thought reasoning and few-shot examples but never translated any of it for the people actually doing the analysis. When I started coaching BAs, I saw the same mistake repeated: treating the AI like a search engine instead of a junior analyst who needs context. The first pattern I teach now is simply assigning a role. Before asking for anything, tell the model who it is. You are a business analyst with 10 years of experience in pharmaceutical manufacturing. That single sentence shapes everything that follows and cuts down on hallucinations.
Another pattern emerged from watching someone try to get a data flow diagram description. They kept asking for the diagram directly, and the model gave them mermaid code they couldn't use. I suggested they ask for a step-by-step breakdown of how data moves between systems first, then describe what the diagram should contain. This shift from 'generate' to 'explain then format' removed a lot of friction. It mimics how a senior BA would brief a junior: don't just produce the artifact, help me understand it so I can validate it.
I also noticed BAs getting lost in overly broad prompts. One analyst asked for risks in migrating to cloud. The response was a sprawling list of generic concerns—cost, security, vendor lock-in. When we narrowed it to risks specific to migrating our on-premise Oracle financials to Azure within a six-month window, the output became startlingly precise, flagging the custom invoice formatting module we had forgotten about. The pattern here is constraint stacking: start with the goal, then layer on platform, timeline, and known technical debt. It forces the model to engage with reality instead of spinning platitudes.
There's a subtle trap around output format that tripped me up early on. I assumed the model would give me structured requirements if I asked for them. Instead, I got prose. Now I end prompts with a format directive that mirrors what the BA already works with: Use the following structure: Requirement ID, Description, Acceptance Criteria, Priority. No markdown tables. It sounds trivial, but telling it explicitly to avoid markdown tables saved hours of reformatting when pasting into Confluence.
The biggest lesson for me, though, was that prompt engineering for business analysts is less about clever techniques and more about preserving their critical thinking. After a few sessions, that same BA who struggled with inventory stories started writing prompts that read like mini requirements specs. She didn't learn to be a prompt engineer; she learned to project her domain expertise into the tool. I think that's the goal—not to turn analysts into operators, but to give them a handful of patterns that let the AI meet them where they are, rather than the other way around.