Avoiding responsibility with ambiguous and vague assignments
Many software development managers like to avoid talking details when handing out assignments. It's the perfect defense against responsibility. Escaping the concrete leaves an open window to claim that a given implementation is "all wrong and not at all what we agreed on". It's a powerful and versatile weapon against admitting mistakes, and you can readily expect to be scrambling for ways to parry if you're unprepared and your project is experiencing problems.
The trick is to not to accept ambiguous and vague defined projects, because you will be guaranteed trouble if your personal interpretations of how the work should be done goes out of sync with that of your manager, which it often will - happily sooner rather than later.
However, you need to be more than just determined about not getting set up by slick managers. Perception is paramount. Because when executed by a seasoned practitioner, the art of ambiguous and vague task assignment can easily spellbind the best into believing that all is good, when it's not, and install within you a false sense of security.
Fighting back aggressively is necessary. Early. Your weapon of choice should be the detailed requirements document. Be sure to write it in a language plain enough to fend of attacks of being too techie and unreadable. Force your manager to read it - thoroughly! Getting a sign off on an unread document is worthless.
Closing the window on ambiguity and vagueness in assignments won't happen quickly or without a lot hard work, though. You can be assured that trying to do so will attract heat from managers accustomed to its forgiven breeze.
So pick your battles and stack up on the persuasive arguments. Common sense is on your side, so there will be plenty to choose from.
Need a starting point for learning more about software development requirements? Read Ben Kovitz's excellent Practical Software Requirements.