...in their current form. Because no one ever reads them thoroughly. And I don't blame them. How many times has someone gone to the trouble of creating a detailed list of feature requirements, distributed them, gotten the requirements approved, implemented the feature and gotten a look of shock and horror when the feature isn't what the higher ups wanted.
Well, it's either that or the document is written so badly that the developer just has to make some guesses on how the feature should work without ever working with customers first-hand.
Either way it's one of those processes that has been decided by someone somewhere to work well and no one has ever reconsidered. Every problem (outside of pure incompetence) in a company - can find its roots in miscommunication. And the requirements document is the poster child for miscommunication. Which is ironic since it was designed to avoid that very problem.
So why is this scourge such a problem? It's boring. I don't mean waiting room boring. I mean the kind of boring where brains atrophy and desperate searches for utensils to impale oneself are commonplace. No wonder no one wants to read these weapons of mass ambivalence. But that's just the first and most important problem. If there's someone who has the wherewithal to push through this forcefield of apathy they are met with what, in my experience, are a series of loosely related bullet points with little or no context.
If I'm going to implement a feature I want to know when it's going to be used, why it's going to be used and most importantly how it's supposed to be used. You could argue (in vain) that that's exactly what requirements documents do. Not in my limited experience. All I want to see in a requirements document is a series of use cases in paragraph form - starting with the user actions followed by the applications reaction to that action followed by the user's reaction and so on.
Here's why. First of all, I think that the writer of the requirements document is forced to think about these things a little more than just writing a bunch of bullet points. That person has to understand the complete process and I guarantee he or she will realize many of the problems with some of the original thoughts laid down. This saves back and forth time and quite possibly, if there is no back and forth, forcing the developer to come up with a solution without any input from someone who has experience with customers. A solution that may ultimately be rejected very late in the process.
Second of all, it's much much easier to read something like that. You're telling a story which gives the requirements context and make it more interesting. The reader will not only get through it but will be able to have a complete understanding which, in turn, will hopefully start a dialog between the requirements writer, the developers and upper management.
tl;dr : Make requirements documents just a series of concise use cases in paragraph form with, optionally, a very brief list of requirement bullet points at the beginning. The requirements document should tell a story to engage the reader and make it more likely to get good feedback.
Comments [0]