Unfortunately, many of us have been in situations where we are asked to produce work that is not up to our quality standards. Typically this is because of deadlines. We know that a lack of quality will cause us problems now (documents that are hard to understand, possibly misinterpreted, and documents that are hard to maintain). We’re also concerned about the foundation we’ve created for the next iteration of the requirements. We know it’s wrong, and may even argue against sacrificing quality with statements like “this is going to bite you in the future”.
Need a more tactful argument? Scott Sehlhorst’s article Code Debt: Neither a Borrower… is a great discussion on the cost of sacrificing quality in a development effort; the lack of quality is a debt you will eventually have to pay back. Although the article focuses on pressure to deliver code without quality, the points apply to requirements as well.
Scott summarizes with a great quote from Mishkin Berteig’s article Technical Debt: “In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. Which is lunacy.”
Give these articles a read; don’t get bitten.
