In a perfect world, everything would be explicitly read by the author and peer reviewed by at least one other person, from requirements specs to user manuals to the test cases. But reviews, even simple desk checks, take time and cost money. This means that you need to choose what you should review and when you should review it.
I recommend prioritizing things to review, choosing how you want to review them, and trying to review as much as you can with the appropriate level of detail. Prioritiziation could be based on the type of artifact, such as stating that requirements must be reviewed, design and production code should be reviewed, and test cases can be reviewed. Within that, you can also specify that high risk or high value components receive a priority in review, or perhaps a more formal review.
As far as time, it all goes back to how high of a priority the component is. There have been times where I've spent 10-15 minutes reviewing, and other times when multiple people have read the code individually then went into a room to do a more formal inspection process that lasts 30-45 minutes (depending on the size of the module).
In the end, it's a balance between time, cost, scope, and quality. You can't have them all, so you need to optimize where you can.