I think a part of this is that engineering concepts are not often introduced in a lot of CS courses. It is more often introduced in software engineering courses

I think a part of this is that engineering concepts are not often introduced in a lot of CS courses. It is more often introduced in software engineering courses... of which there seem to be few? In my experience it's not well known that requirements are different than specifications and what those differences are. Knowing the difference makes understanding why planning is useful but "plans" are useless. Requirements state the desired properties of a system that affect our world. They are written from the perspective of humans interacting with a desired system to achieve some goal. It's useful to know that we need a system that does X so that we can Y. We need to ensure that Y eventually happens when the user initiates X. If the system cannot succeed at Y within Z minutes we need to notify the user so that they can initiate procedure J and halt the process manually. Requirements don't have to tell us how to implement such a system. They're more like the end state. It's the job of specifications to tell us, technically, how such a system operates. We, the developers building the system, don't have to write the full specifications up front. That's a bit of a mistake. Because the gap, as the GP points out, is quite large from the starting point and the end result. It's quite normal to start with the bare minimum specification and iterate towards an ideal one. As you learn about the problem space we can build more certainty about how such a system can be implemented. We can update the specifications, verify the code implements the specification, and hopefully in the end arrive at a system that fulfills our original requirements. It's rare that one can write the full, complete specification and leave it up to the developers to implement it.