As functionality is not a quality requirement, can quality of software be judged based on functionality only?

No, functional testing alone cannot be a benchmark to justify a product's quality. However, it is one of the most significant factors that define a product to meet quality goals. For instance, a product that is justified for its functionality and is not meeting the compatibility or performance aspect of the product tends to struggle with the use.

Moreover, functional testing is aligned to ensure that a product developed is made to meet the pre-defined requirements related to features. However, load, performance, compatibility, etc. Are other important factors that cannot be ignored when saying a product is a quality.

Software quality measures whether requirements are satisfied or not. Requirements can be both functional or non-functional.

Functional requirements meaning what software should do. It would include functionalities to identify how a system is working with respect to what application is meant to accomplish.

While Non-functional requirements meaning how software should work. It would include performance, security, usability, maintainability, stability, disaster recovery, portability, privacy, reliability, and supportability.

Can software quality be evaluated based on functional requirements only?

A simple answer would be - No. One cannot measure software quality just by evaluating functional requirements.

I agree that most factors used to evaluate software quality fit into the non-functional requirements category. But bare minimum one can expect is software functions what it is built for.

So, I would rather rephrase it as “Yes, Software functional quality can be evaluated based on functional requirements.

I think you have missed one of the 7 main principal of software testing" The absence of error fallacy"

Finding and fixing defects does not help if the system build is unusable and does not fulfil the user's needs & requirements

https://www.guru99.com/software-testing-seven-principles.html

So it doesn't make sense if the requirement doesn't meet the actual user intentions that sometimes user itself has missed.

For example user may say I want to drive a car at 200 km/hr, but missed to mention about breaks.

And you as quality personal should bring in your thoughts and ensure that the car is designed with a break. Else it's just a junk

So what is quality

Quality is user experience and risk minimization.

It's not a single point that you can focus on, quality is a consolidated result of accessibility, usability, security, visual appearance, performance, reliability, adaptability, learnability, portability and so on.

That's why we have different kind of quality tests.

The concept of shift left for testing is there to avoid "error fallacy " and ensure that quality and focus are ensured in the requirement itself.

This is a difficult question to answer because quality alone doesn't make much sense, it's always quality to someone. And different people look for different things, therefore they judge what quality means based on various characteristics.

Some generalization could perhaps be achieved, or the following model can at least guide you towards what to look for or what to consider. The idea is based on the Maslow's hierarchy of needs, that is the lower levels have to be present in order to consider the higher levels.

This idea is somerhing I found in this book, and I think you might take it into consideration here when asking these questions.

To sum it up:

• functionality is the basis for everything else, I think this would be something the most of us can agree on; if it doesn't work, I don't really care it's fast etc.
• then when it works, you start looking for how well you can actually use it, so you consider e.g. performance
• then you consider usability
• and usefulness - products should be in one way or the other useful; it doesn't always mean they should address some serious problem, making you laugh is useful as well :)
• finally successful refers to business objectives, how successful people who use the product are with the product, an if it brings some measurable benefits to them as well as to those who created the product

To answer your question then:

Can software quality be evaluated based on functional requirements only?

Hardly. Unless all people involved consider this to be the only thing they care about.

When we test sofware and find functional defects, we say the quality is bad.

I wouldn't say it like this. Obviously there're different levels of impact a (functional) defect can have. And since quality is dependent on people's perception, it might be decided that some defects are simply not worth focusing on/fixing.