[dasil003]

Well, first of all, in your example bridge building is not the only civil engineering discipline involved—traffic engineers absolutely would be involved in those other questions.

More to the point though, software is not like a bridge. With a bridge, the high-level requirements are easily defined in a way that any layman can understand (weight limits, lane count, etc). Failure of a bridge is also viscerally obvious. Obviously there may be extreme engineering challenges in actually building a given bridge, but at the end of the day no one involved ever runs a serious risk of losing their handle on the big picture.

Software, by contrast, is arbitrary logic full of leaky abstractions and unknown touchpoints. Even if we narrow down to the most vanilla business CRUD app, precise requirements can be frustratingly elusive. No matter how well thought out a project, there are always discoveries at build time of any non-trivial project which significantly impact the requirements.

For this reason, I consider it a core responsibility for senior engineers to help define requirements and not just be a passive recipient of them. Martin Fowler captures my viewpoint more eloquently: https://www.youtube.com/watch?v=4E3xfR6IBII