Is this requirement:
The system is required to have an easier GUI to make it more usable by any kind of user (normal or disabled user)
a functional or non-functional requirement ? And Why ?
Functional requirements specify the features that a system must implement.
Non-functional requirements specify all the other requirements that the system must implement.
If your requirement about a simpler GUI does not add new features to the system, but only specifies how easy it must be to access those features, then it is a non-functional requirement.
On the other hand, the distinction between functional and non-functional requirements is fairly arbitrary. Knowing if a requirement is a functional or non-functional requirement doesn't really help you to implement it.
A functional requirement is about what the system shall do. The term "functional" comes from "function" meaning something that takes some input and produces some output.
A non-functional requirement is about how (well) the system shall do what it does. These are usually quality requirements, such as performance, reliability or ease of use, or general technical requirements that apply to the whole system (e.g. standards to be enforces, operating system compatibility, hardware limitations).
You may also be interested in the difference between functional and non-functional requirements.
Your requirement does not tell at all what the system does, but it tells how the system shall do it. It is hence without any doubt a non-functional requirement.
Edit: As you can see in the comments, it would be advisable to rephrase your non-functional requirement in order to make it objective, less ambiguous, and verifiable.
User friendliness can be tested on target groups and it would show. So I would say it is functional. Non-functional is more like you have to use this particular brand of equipment or you must use green energy to operate it.
As I already explained a few years ago, requirements are objective, and, as already stated by Robert Harvey in his comment, testable. It may not necessarily be possible to code a test in a way unit tests are done, but there should be a way to have a validation test which would definitively and unambiguously indicate whether the requirement is fulfilled or not.
The first bad sign is the use of “easier.” Adjectives such as “easy,” “simple,” “nice,” or “user friendly” have a strong subjective connotation. Unless we agree specifically—and it is very possible to do so—on the precise measurements of the easiness, simplicity, niceness and user friendliness of a piece of software, the presence of such terms indicates that we're in front of something which is not a requirement.
The second problem is “more usable.” There should be no comparisons without targets in requirements. More than what? “More, compared to our previous product” or “More than the version 3.0 of Our Competitor Inc.” makes sense, as soon as the comparison itself may be translated into a validation test. But just “more”? No, this wouldn't make it.
If heavily reformulated (and by that, I mean removed completely and replaced by a real, correctly written requirement), it could become a non-functional requirement. Accessibility, already mentioned by Robert Harvey as well, is a very objective thing; for instance, a non-functional requirement for a website may specify a required level among Web Content Accessibility Guidelines (WCAG) three conformance levels: from then, either the website conforms to the required level and, thus, fulfills the requirement, or not.
But dreamy formulations about nice GUIs which are user-friendly? Keep it to the salespeople.
The goal of requirements is to make two companies or groups of persons agree on what the one entity wants the other to do. This is a contractual thing. Either you fulfill your contractual obligations, you get paid and everyone is happy, or you should prepare for litigation.
If requirements are objectively testable, there would be no litigation.
If requirements are flabby, you'll release the product, then the customer will claim that you haven't fulfilled your obligations, you'll reply that you did everything right, and he'll claim that you didn't, and your lawyers will waste months settling down. If I want to screw with your company, I'd do exactly that: draft a bunch of subjective requirements, and claim that I don't have to pay for your work, because the product you did is not the product I need. It doesn't have an easy GUI: I tested it on our disabled employee and he couldn't do anything with it. It's not fast enough, while I explicitly specified that I want it to be fast. It's not even user-friendly, although I clearly requested it to be.