At my workplace, we face a challenge in that "agile" too often has meant "vague requirements, bad acceptance criteria, good luck!" We're trying to address that, as a general improvement effort.
So, as part of that, I am proposing that we generate design documents that, above and beyond the user story level, accurately reflect the outcome of preliminary investigations of the effect of a given feature within the system and including answers to questions that we have asked the business.
Is there an effective standard for this?
We currently face a situation where a new feature may impact multiple areas in our "big ball of mud" system, and estimates are starting to climb due to this technical debt. Hopefully more thoughtful design processes can help.
Best Answer
yup, this is the same kind of requirements that you get even if you try to nail them down too! (as an example, a 10,000 requirement document that took a government client 4 years to create was still full of inconsistencies, vagueness and even internally contradictory statements. If 4 years of requirements documentation can't get you a decent, exact, requirement, do you ever think you'll be able to get anything non-vague?)
So... the agile way was invented to understand that this sh*t happens and to work with it rather than try to work against it.
You start of by asking "what do you want" and the customer replies with "something kinda like this". You do some work and then go back to the customer and say "is this like what you wanted?", and the customer usually says "yes but..." whereupon you ask "what do you want".
Eventually you get exactly what the customer wanted, even if they don't know what that is! (hell, they never know what they want, not exactly).