Are these both the same issue? Sikander's issue sounds like for some reason client's show as they are connected to the wireless medium, but are not able to pass traffic. In Saiprasad's issue I see "disconnectivity issues to some extent". Does that mean clients are actually dropping off the network and then reconnecting again?
Troubleshooting intermittent issues is always difficult, especially with a medium that is invisible to our eyes such as 802.11. That is why it is helpful to get some diagnostics to see what is happening. It is also why starting off the troubleshooting by upgrading to the latest wireless infrastructure firmware and client driver / supplicant software is always the easiest first step. This upgrading is good because it adds new functions and also resolves known issues and is relatively quick and painless. The next step is to deep dive into troubleshooting.
First suggestion in "intermittent troubleshooting" is to get to users who are having issues and to have a dialogue with them to understand what happened to them ( ie a non technical user will thinks they have a wireless issue...wireless not working... because some client / server application had an issue, but they were actually connected to the wireless just fine ! ). You can actively go about the environment with your own equipment, using the network with your own equipment to hopefully catch something happening, or to conclude that the network is working pretty well ! If the opportunity presents itself to troubleshoot, then things to look for is to search for the problem client's mac on the controller gui reports, like reports->wireless clients by ap. Take a screenshot, it will show you what ap you are on, what signal the ap sees the client at, what radio you are on. Then you can navigate to that ap under the wireless aps section, and enable remote capture. You can also get the aps current ip from the static tab under the aps config. Then you can point your wireshark and do a capture on wifi0 for 5ghz radio, wifi1 for 2.4ghz radio, and eth0 for the ap's wired Ethernet port. If you have time, best to capture the wireless and wired quickly while the client is doing something like pinging the default gateway, and something off the network like google, 8.8.8.8. AG posted the link to aid in using the fantastic realcapture tool previously.
You could also check for any messages for the client mac under controller->logs->station events, pasting the client mac in the search window.
You can collect the ap trace file, log->ap traces->select ap and retrieve trace.
For windows client's can check and verify that its drivers are updated and windows power management for the wireless interface is off for maximum performance.
For mac client's can use the wireless diagnostics utility to do wireless packet captures, and to monitor wifi connection. When there is an issue the monitor tool will generate a zip file with files that can help identify what the problem was.
Verify if all users on the ap are having issues, or just one client.
Also, under wlan, make sure the the pre/post and session timeouts make sense ( ie pre=5 post=30 and session=0 ), otherwise you'll have ton's of user sessions that are stale on the controller.
Use radio preference group to push 5ghz capable clients to use 5ghz, a much better band with more channels and less interference.
It can turn out that in 10 complaints, each case is different...ie one user connected hanging on to a far away ap with poor signal because the client decides not to roam to an ap closer. One case could be a client with pwr mgmt. enabled. One trace could show the client probe req, and probe rsp coming back but the client not proceeding to associate, etc. On the surface they would all look the same.