RADAR effectively uses the Review methodology in analyzing and tracking defects. In RADAR all types of verification activities are "Reviews".
A verification activity could be review of the design, design document, review of test specification and test cases, review of code, unit testing of executables, integration testing, system testing, document reviews, etc.

All organizations carry out most of these review activities i.e. reviews at different stages of the SDLC - starting right from the Requirements all the way up to warranty and support. However if any non-conformances (defects / issues) are found, they are just logged into a tracking tool. Review activity that actually discovered the non-conformance itself is not stored in most of the cases.

So what happens if we do not track any information about the review?
Say, you do a code review. And you find that to the best of your knowledge, it is perfect. So there will not be any issues logged into your tracking system. The fact that there were no defects found does not mean that the code was not reviewed. It was definitely done and some effort was involved. Moreover, the person or group that did the review is standing by the fact that they found no defects. Most of the tracking tools do not allow you to track the review activity itself. RADAR does. It brings in the notion of accountability on the part of the reviewer(s).

One might argue that (s)he would use any issue tracking tool which is defect based and perhaps customize it by adding a couple of attributes, like review name and type, to the defect profile.
On the surface, it may seem that it solves the previous problem we discussed. But this is identical to a Department-Employee scenario where it is structured at two levels. This represents that all employee should belong to a department in an organization.
Consider tracking employee and department information at the same level. In this case, if no employee exists for a particular department, then the department will not exist. Also, it would lead to redundancy where we will be storing department information tracked for every employee.

One obvious advantage is apparent from the previous two points. RADAR allows you to actually record the details of any review activity that was performed as part of the SDLC. You can track the actual effort, how many people were involved, when it was done, etc.
The "not-so-obvious" but extremely crucial advantages are very many. For Eg.. Considering a code review was done and no issues were found during code review. The review was closed with no defects entered. At a later stage, during System testing, a defect surfaces. You do research and find out that the defect was actually in the code that was previously reviewed. Further more, you may find that the code review failed to locate a glaring mistake in some logic. This indicates that the earlier review was not effective. Had the defect been found during code review, you could have, perhaps, reduced rework and the associated costs. By tracking reviews, RADAR gives you a means of monitoring the effectiveness of your review process. RADAR helps you "review" the "review" process in your project or organization.

RADAR goes one step further and allows you to define defect injection rates and defect find rates. You can get a report in the form of a control chart. This would help you to monitor a review process and objectively determine whether reviews were effective or not. This allows you to take proactive steps to improve their effectiveness and ensure higher quality products with, planned effort, time and cost.