I know these aren’t exactly rare, but in spite of that fact, I’m ready to embark on writing yet another essay on the problem of requirements documents. I’m in good company with this kind of post, and I’ll give you a few quick links to my favorites.
So what can I add to the conversation about requirements documents? After all, from a BA’s perspective, requirements documents are basically our job right?
I’ve worked on projects where there were BA’s who thought like that, where long 45 page pdf’s came over the wall and any complaints were met with the attitude “I wrote the requirements document, now it’s your problem.”
What this misses, is that nobody cares about the document after the project. If you did things right, you can throw the requirements document away at the end because the customer’s happy. If not, then all that happens is the document gets used as a weapon, with everyone pouring over every sentance, trying to argue that their interpretation of what a specific spec means is obviously right, and anyone who interpreted it differently is a moron. So the doc is useless if the project goes well, and polarizing if it doesn’t.
What we’ve got to keep in mind is that a requirements document is a means to an end, and usually a pretty poor means at that. The BA’s job is not to make good requirements documents; it’s to contribute to making good software. It’s the job of everyone on the team, and you should expect to throw every skill you’ve got at that goal. Draw mockups, talk with the devs for 2 hours, draw pictures on the white board, write code if you know how, just make sure the software your team delivers is the best it can be. Don’t put the process (or your job title) over the product.
IT isn’t the only industry that suffers from this problem, where there are entire job functions that default to putting process over product. Most large organization suffer from the problem as they grow. And there are times where process over product is valid. If you work in an ineffectual organization, focusing on your part of the process is a good way to defend against attacks on your competency. But if you’re in that kind of organization, why stick around? It’s stressful frustrating, and in the long term your company will get their lunch eaten by somebody who’s got their priorities straight.