About
RequirementsFirst is a site about the analytical work that sits underneath user stories — the conversations, the framing, the unglamorous bit where you figure out what is actually going on before anyone opens Jira. It is not a “BA tips and tricks” blog. There are enough of those already. It is also not a template library, a certification cheat-sheet, or a place to argue about whether stories should follow the connextra format. Those questions are downstream of the real one.
The real question is whether you understand the problem.
The thesis
Most BA content is template-fetishism. It optimises the wrong thing. It teaches you to write cleaner acceptance criteria, structure your stories in a particular way, run refinement sessions with a particular cadence — all of which are real skills, all of which are downstream of the work that actually decides whether a feature lands or quietly rots in production. The work that decides outcomes happens before the ticket is written. It happens in the conversation where a stakeholder hands you a solution and you have to figure out what problem they were trying to solve. It happens when you push back, politely, on a request that does not survive contact with the actual user. It happens when you write one paragraph in your own words describing the problem before you open the tool.
That is the work this site is interested in.
The other reason for the site is more practical. Most of the BA writing I read either treats the role as junior-PM-with-a-different-title, or treats it as a process function that exists to operate ceremonies. Neither matches the people I have worked next to who are good at it. The ones who are good at it spend their time thinking — about users, about systems, about what the request actually means — and the ticket-writing falls out of that thinking as a near-trivial step. The skill is the thinking. The ticket is the artefact.
Three things you will read here
Roughly: writing on the analytical craft itself, writing on using AI tools without outsourcing the judgement that makes a BA useful, and honest reviews of the tools that show up in our actual workflow. The split is roughly 40 / 30 / 30. The tone is direct, contrarian where the contrarian position is defensible, and free of the consultancy vocabulary that infects most writing in this space.
If a post on this site uses the word “leverage” as a verb, please file a bug.
Who is writing this
Arun Mehta. Senior Business Analyst, 8+ years across enterprise software, regulatory tech, and member platforms. Indian context, mostly IT services. Stories and examples on this site are synthetic — composite scenarios drawn from a long-enough career to recognise the patterns, anonymised so that nobody’s actual project gets paraded around the internet. The patterns are real; the names and numbers are not.
How to follow
RSS is in the footer and works today. A newsletter is coming soon for those who prefer email; the signup will appear here once it is live. Until then, the RSS feed or a bookmark is the way.
Comments are off, on purpose. If you want to push back on something, the email link in the footer is the right channel — that is also where corrections go.