Part of this is a separation of concerns between people in different roles. The person designing the thing may be different than the person engineering particul

Part of this is a separation of concerns between people in different roles. The person designing the thing may be different than the person engineering particular parts or getting parts in the supply chain. Take something like a radio. The person building the electronics to meet the design and sourcing the parts may need to know the requirements around the temperature it needs to operate in. The person handling the internal electronics is very likely different from the person designing the product. The person designing the product will need to know where, when, and how it's used by whom. With software we often mash the roles into one or a few people. A developer may do all or many of the parts. If we look at other engineering disciplines, aside from software engineering, requirements often make sense. I was just reminded of someone who had to test PVC piping. It had to meet certain standards for handling pressure. The people do engineered the materials, the thickness of the pipe, and so forth had to know the requirements it needed to meet. They also needed to know the requirements for the size of the pipe so that it would mate with other things. They weren't designing the system the pipes would be used in. Requirements are often a way to take the design, break it up, and communicate it to others who aren't part of the design. They are also a way to create common interfaces. Both of these are things software designs are often bad at. Sometimes intentionally so (non-standard interfaces create lock-in).