Different terms for the same concepts. You could call it high- and low-level requirements, customer/supplier requirements or requirements and specification. While the form is important, a common understanding is core to be able to work together.

I agree, but I think one key distinction here is that I for my part tend to avoid classification. It's a spectrum of refinement, not two distinct classes IMHO.

The concept I use is that the next stage is all about how you implement the previous one: the spec is how you implement the requirements, the design is how you implement the spec, the code is how you implement the design.

As okl said, it’s arguably terminology, and maybe high and low level requirements would work for you? I prefer to separate out the terms though, so that “requirements” are the thing that the engineering team can’t unilaterally change without upsetting the stakeholders. If I can change a spec item mid-delivery and it doesn’t matter to the customer, then it wasn’t a requirement. If I can’t change it, then it’s a requirement.