I’ve been mentoring and sharing Business Analysis best practices on an ad-hoc basis for most of my career. Colleagues and friends have been the primary audience, on everything from BA 101-level stuff, like “How do I write good requirements?” to more delicate and complex topics like how to navigate tricky political waters on a project.
There’s been much ink spilled over the nuts and bolts of documenting requirements. And we could talk about that, but that’s not terribly interesting for me.
How I would answer the question of “How do I write good requirements” gets a little philosophical. I’m also going to make a quintessentially BA-like move to make everyone rewind and examine their assumptions before answering the question, so that’s what’s going to happen up in here. I’m going to talk about how to BE as you do requirements elicitation, analysis and validation as a Business Analyst.
Stay tuned for posts on:
- Requirements as Art (not Science)
- These Aren’t Your Requirements
- Requirements are Never Done
- People Problems, Not Technology Problems
- The Question Behind The Question