Having followed the discussion in the context of your previous post, I want to make a few points.
Use Case vs. Functional Requirement
The bullet points in your question, intended as examples referring to eBay, are not Functional Requirements by themselves. "Add Product to Cart" is not a Functional Requirement. It is, however, a potential title for a Use Case. A fully specified Use Case is a Behavioural Requirement. Functional Requirements can be derived from Behavioural Requirements.
In other words, one Use Case often represents several requirements, and several Use Cases often share a common subset of Functional Requirements. E.g. "The system shall provide an authentication mechanism for users" is a Functional Requirement, and there will certainly be several Use Cases which refer to it.
In your earlier Q, you indicated that you think that requirements which can be tested are Functional Requirements. This is not exactly true. Non-Functional Requirements can also be tested, the worst case being methodology / process audits, code reviews and the like. But there are also Non-Functional Requirements which can be observed while the system is used, and hence, they can be tested.
Derivation of Requirements From Use Cases
Functional or not, do you have to derive requirements from your Use Cases? It depends. Do you want to derive requirements from your Use Cases? Maybe.
Do your Use Cases cover all aspects of your system?
Let's say your system has a user interface with authentication mechanism and different access rights. Would you accept a solution where rights must be set per user, or would you want groups or roles to define the rights and add users to groups? Would you be willng to accept a system where roles / groups are fixed, or would you want to be able to add roles / groups? -- Yes, you can write Use Cases for that.
However, already here, we're touching the question: When is a specification ready?
In reality, it's never ready. In reality, it's inefficient to strive for a perfect specification. In reality, specifications stop at a level of "common sense" (with developers, suppliers etc).
So since role and rights models are common for decades, and since the administrator is not your valued customer to whom you want to present a flawless user interface, would you net be able to finish your specification earlier if you switched from Use Cases to Functional Requirements?
Taking it one step further, would you be willing to live with a system where a change of the access rights becomes valid only the next calendar day?
If not, you're going to have a requirrement such as "The system shall perform each operation applying the relevant settings which are valid at the respective point in time."
Clearly a Functional Requirement. And now, if you have only Use Cases, you'll have to expand each of them textually. If you have UML Use Cases, you might want to cover this by an include, but this requires that you place a kind of a "basic operation" there which starts by checking the current access rights.
This is not what Use Cases are for. This is not their strength. You want them to be comprehensive and concise. Use Cases are not the place to describe detailed operations or functionality. And the access rights checks are very basic. You want to specify it in a single prominent place.
Much depends on the context.