I'm all for shielding people from crap, but is that really what you think of customer requirements? Are you building the software for your own enjoyment?
Make the requirements intelligible for developers so that at the moment she needs it they're crystal clear. Rewrite this "can we move that button a tad on the left and make it blue like your tie" into "Move button X on screen Y 3px to the left and make it #5544df".
There is often a difference between what the customer says they want (which they label "requirements") and what they actually need. Sometimes they need to be told no, and when they ask for the third time and nothing's changed, that's definitely crap that your developers should be shielded from.
Just a further point, often the both you and the customer agree that there is a problem that needs addressing, but the customer is not sure how it should be solved. Alice from accounting wants the system to do X, while Bob from compliance needs it to do Y, which directly conflicts with X. Finally Carol in management has determined that they are not going to pay for a solution anyway.
This is exactly the 'crap' that you need to shield your developers from. Shielding developers is a lot deeper than just ignoring requirements.
Comments
I'm all for shielding people from crap, but is that really what you think of customer requirements? Are you building the software for your own enjoyment?
Make the requirements intelligible for developers so that at the moment she needs it they're crystal clear. Rewrite this "can we move that button a tad on the left and make it blue like your tie" into "Move button X on screen Y 3px to the left and make it #5544df".
That makes more sense to me.
There is often a difference between what the customer says they want (which they label "requirements") and what they actually need. Sometimes they need to be told no, and when they ask for the third time and nothing's changed, that's definitely crap that your developers should be shielded from.
Just a further point, often the both you and the customer agree that there is a problem that needs addressing, but the customer is not sure how it should be solved. Alice from accounting wants the system to do X, while Bob from compliance needs it to do Y, which directly conflicts with X. Finally Carol in management has determined that they are not going to pay for a solution anyway.
This is exactly the 'crap' that you need to shield your developers from. Shielding developers is a lot deeper than just ignoring requirements.
http://steve-yegge.blogspot.com/2008/08/business-requirement...