The name SRS for a "software requirements specification" is well established and depending on how it's understood it could be written by the customer or written by the supplier. Colloquially, both "requirements" and "specification" are regularly used to refer to such document. It is similar to calling a document that describes test instructions either a "test specification" or a "test procedure" -- different people/projects/companies, different conventions.
What matters is to have a common understanding and work together.
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.
Slight twist I learned from my wife: MoSCoW lists - Must, Should, Could, Won't.
The "Won't"s really tie down the boundaries of the system. If your PM is smart they probably won't call them "Won't"s, much more likely to bunch them into a column labelled "Phase 2".
Requirements are a precursor to the spec, and are a list of MUSTS, SHOULDS, and WBNIS which need to go into the feature/product.
The Spec is a description of how these requirements are/will be met.
An example for the ‘ls’ command:
Requirement: “the user MUST be able to include or exclude hidden files”
Spec: “by default hidden files are not shown. Including the optional argument ‘-a’ will cause hidden files to be listed alongside non-hidden files”