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”
What matters is to have a common understanding and work together.
Google tells me that WBNI is a radio station. We Better Not Implement Soybeans?
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.
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".