I spent the better part of last year watching business analysts in my organization try to get useful work out of large language models. The results were all over the map. Some people got near-perfect requirement drafts in minutes. Others spent hours wrestling with gibberish that looked like a teenager's book report on a topic they'd skimmed once.
The difference wasn't the tool. It was the prompt.
Most BAs I've worked with start with something like "Write a user story for a login page." That's not a prompt. That's a wish. The model gives you back something generic and probably wrong because it doesn't know your context, your constraints, or your stakeholders.
One pattern that changed things for my team was what I call the constraint sandwich. You start by framing the role and the audience. Then you state the task. Then you list the hard constraints. For example: "You are a senior business analyst writing for a development team that has never built a payment system. Draft three user stories for handling failed credit card transactions. Each story must include an acceptance criterion for retry logic and a note about PCI compliance." That gives the model guardrails. It stops it from hallucinating features you don't need or skipping over regulations that'll bite you in audit.
Another pattern that saved a project from scope creep was the reverse question. Instead of asking for a solution, you ask the model what questions it would ask to understand the domain. I had a BA who needed to document requirements for a warehouse inventory system. She prompted the model to act as a domain expert and asked it to list the top ten questions a seasoned warehouse manager would ask before accepting a new system. That list became her interview guide. She walked into meetings with questions that showed she'd done her homework, and stakeholders opened up in ways they hadn't before.
There's also the iteration pattern, which sounds obvious but nobody does. You don't get a perfect requirement document in one shot. You get a draft, then you ask the model to critique its own work. "Identify the three weakest assumptions in this requirements document and explain why they're risky." That forces the model to surface its own blind spots. I've caught contradictory acceptance criteria this way more times than I can count.
The mistake I see most often is treating the model like it knows your business. It doesn't. It knows patterns from the internet. Your job is to feed it the specific context that makes those patterns useful. One team I consulted with spent three weeks trying to get a model to write a data migration plan. They kept adding more detail to the prompt. The breakthrough came when they pasted in the actual schema diagrams as text and said "Given these two schemas, list every field that has no direct match and propose a mapping." That's not a prompt trick. That's just giving the model the data it needs to do the work.
None of this requires fancy frameworks or prompt libraries. It just requires thinking about what a good BA already does: ask better questions. The model is the same way. Give it a vague question, get a vague answer. Give it structure and constraints, and it'll surprise you.