I spent the first few months using LLMs like a glorified search engine. Ask a question, get an answer. Rinse and repeat. It worked fine for simple stuff, but when I tried to get a coherent business requirements document or a process flow out of the model, the results were either too vague or too detailed in the wrong places.

Then I started paying attention to prompt patterns that actually worked for business analysts. Not the generic "act as an expert" stuff, but structural approaches that map to how we think about requirements and processes.

The first pattern that changed everything for me is what I call the role-plus-constraint pattern. Instead of saying "write a requirements document for an inventory system," I started saying "you are a business analyst who has interviewed three warehouse managers. Write a requirements document for an inventory system. The system must handle FIFO and LIFO costing. The warehouse managers have conflicting opinions on whether barcode scanning should be mandatory." That conflict point forced the model to surface trade-offs instead of glossing over them.

The second pattern is the iterative scope fence. Business analysts know that scope creep kills projects. So I started using prompts that explicitly define what is in scope and what is out. For example: "List the functional requirements for a customer portal. Include only features related to order tracking and returns. Exclude anything about payment processing, user authentication, or mobile app behavior." The model respected those boundaries surprisingly well, and I could chain multiple scope-fenced prompts together to build a complete picture.

The third pattern is the stakeholder filter. LLMs love to give generic answers that try to please everyone. But a requirements document for a CFO looks very different from one for a warehouse supervisor. So I started adding a stakeholder context line: "Summarize these requirements from the perspective of the operations team. Emphasize throughput, error rates, and training needs. Ignore budget and timeline concerns." The shift in output was dramatic. The same model, same base information, completely different emphasis.

I made a mistake early on that taught me the fourth pattern. I asked the LLM to generate user stories from a list of features, and it gave me fifty stories that were all variations of "as a user, I want to do X." They were useless. So I switched to the constraint-first pattern: "Generate user stories for a payroll system. Each story must include a specific business rule, a data validation requirement, and an error condition. No story should be longer than three sentences." The quality jumped because I forced the model to think in terms of business rules, not just feature titles.

There is a fifth pattern I use less often but it saves me when I am stuck. I call it the reverse perspective. Instead of asking for what the system should do, I ask for what could go wrong. "If this requirements document were implemented as written, what are the top five ways it would fail in production?" That prompt uncovers edge cases and integration risks that the model would never volunteer in a forward-looking prompt.

None of these patterns are magic. They are just structured ways to communicate context that business analysts already carry in their heads. The difference is that without the pattern, you spend your time rewriting model output. With the pattern, you spend your time reviewing and refining something that is already 80 percent there.

I still get caught off guard sometimes. The model still hallucinates compliance requirements or invents regulatory bodies that do not exist. But I have learned to treat those as data points, not failures. Each hallucination tells me where my prompt was too loose or where my context was missing. The patterns are not a substitute for domain knowledge. They are a way to apply that knowledge more efficiently.