[NLips]

I disagree with the author.

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”

[okl]

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.

[dxdm]

What does WBNIS mean?

Google tells me that WBNI is a radio station. We Better Not Implement Soybeans?

[remkop22]

Probably some variation of WBNTH? (would be nice to have)

[m0d0nne11]

Further evidence (along with the coy little content-free clickbait headline) that somebody's just a bit too precious...

[NLips]

“Would Be Nice If”. Often used even when the “if” expansion doesn’t really make sense.

[irjoe]

Would Be Nice Ifs, maybe?

[groestl]

To me, you last paragraph is just more refined requirements

[okl]

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.

[groestl]

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.

[NLips]

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.

[JohnCClarke]

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".