The closest you get to a bug-free application, the more expensive it gets. It's like targeting 100% code coverage: you spend the same amount of time and money getting from 0% to 95%, from 95% to 99% and from 99% to 99.9%.
Do you need this extra 0.1% of code coverage or quality? Probably yes, if you're working on a software product which controls the cooling system of a nuclear reactor. Probably not if you're working on a business application.
Also, making high quality software requires a very different approach. You can't just ask a team of developers who spent their life writing business apps to create a nearly bug-free application. High quality software requires different techniques, such as formal proof, something you certainly don't want to use in a business app, because of the extremely high cost it represents.
As I explained in one of my articles:
Business apps shouldn't target the quality required for life-critical software, because if those business apps fail from time to time, it just doesn't matter. I've seen bugs and downtime in websites of probably every large corporation, Amazon being the only exception. This downtime and those bugs are annoying and maybe cost the company a few thousands of dollars per month, but fixing it would be much more expensive.
Cost should be the primary focus, and should be studied pragmatically. Let's imagine a bug which is affecting 5 000 customers and is so important that those customers will leave forever. Is this important? Yes? Think more. What if I say that each of those customers is paying $10 per year and that it will cost almost $100 000 to fix the bug? Bug fixing now looks much less interesting.
Now to answer your questions specifically:
why do bugs get reported even after going through so much testing? Is it our requirements issue? Our client doesn't seem happy for anything we provide? are we doing something incorrect?
Lots of things can go wrong. By testing, do you mean actual automated testing? If not, this is a huge problem on itself. Do testers understand the requirements? Do you communicate with the customer on regular basis—at least once per iteration, at best the customer representative is immediately reachable on-site by any member of your team? Are your iterations short enough? Are developers testing their own code?
Similarly to They write the right stuff article linked above, take a bug report and study why this bug appeared in the first place and why was it missed by each tester. This may give you some ideas about the gaps in your team's process.
In important point to consider: is your customer paying for bug fixes? If not, he may be encouraged to consider lots of things to be a bug. Making him pay for the time you spend on bugs will then considerably reduce the number of bug reports.
Has anyone developed any application that were totally bug free? What is the process? Why can't we deploy the application with minor bugs? Are we supposed to be perfectionist?
Me. I've written an app for myself the last weekend and haven't found any bug so far.
Bugs are only bugs when they are reported. So in theory, having a bug-free application is totally possible: if it's not used by anyone, there will be nobody to report bugs.
Now, writing a large-scale application which perfectly matches the specification and is proven to be correct (see formal proof mentioned above) is a different story. If this is a life-critical project, this should be your goal (which doesn't mean your application will be bug-free).
Is the current scenario the correct process of development and testing? If not what is an efficient way where developers,testers and client gets the maximum benefit together?
In order to understand each other, they should communicate. This is not what happens in most companies I've seen. In most companies, project manager is the only one who talks to the customer (sometimes to a representative). Then, he shares (sometimes partially) his understanding of the requirements with developers, interaction designers, architects, DBAs and testers.
This is why it is essential either for the customer (or customer's representative) to be reachable by anyone on the team (Agile approach) or to have formal communication means which authorize a person to communicate only with a few other persons on a team and to do it in a way that the information can be shared to the whole team, ensuring that everyone has the same information.
There are many processes to do development and testing. Without knowing precisely the company and the team, there is no way to determine which one should be applied in your case. Consider hiring a consultant or hiring a project manager who is skillful enough.