ah yes. Because there is a direct and clear road ahead from requirement to implementation. Requirements don't change and if they do it doesn't have any impact on existing parts of the software. /s
My favorite is when stakeholders don't talk to devs to determine whether something is actually possible given the data we collect, but instead go off the recommendation of a technical manager who has never actually worked on the system or its data.
An assertive dev will look at the requirements, try to figure out how that fits, and then reply back to stakeholders if it's unfeasible. Everyone else will sit there for a week bashing their brains out against a keyboard and have continually increased anxiety because they've been assigned an impossible task. The time for a dev to be involved in the process is during requirements gathering as a partner to the process, not after a contract for work has been signed by the client.
An assertive dev will look at the requirements, try to figure out how that fits, and then reply back to stakeholders if it's unfeasible. Everyone else will sit there for a week bashing their brains out against a keyboard and have continually increased anxiety because they've been assigned an impossible task. The time for a dev to be involved in the process is during requirements gathering as a partner to the process, not after a contract for work has been signed by the client.