Chapter 4 doesn't give enough detail on various methods to make clear how they are actually used, but it does give an overview, showing why such methods are needed, what they can do, and (to an extent) how to choose among them. A more detailed overview and comparison of certain methods is given in Techniques for Requirements Elicitation.
For expert reviews, it is important to clarify what kind of expert you have: domain experts will be useful in a completely different way than interface design experts. For example, expert cognitive walkthroughs may have little value in evaluating how new users will respond, but they can still be useful.
Usability labs are exceptional facilities not available for most projects. The thinking aloud method has serious problems with tacit knowledge, and also produces unnatural discourse that can be hard to analyze (for details see Techniques for Requirements Elicitation, where this method is called "protocol analysis"). Analyzing videotapes is hard work but can be worth while for some problems if it is done well. Paper mockups are often a good idea, because they are so easy. The limitations of usability testing mentioned on p.132 are important.
The advice on surveys is good but too vague, and the suggested questions on p.133 are also too vague; Table 4.1 is better. As Shneiderman admits, "If precise - as opposed to general - questions are used in surveys, then there is a greater chance that the results will provide useful guidance for taking action" (p.134). Statistics should really be used to analyze the results of surveys, and this requires rather sophisticated knowledge. Acceptance tests are really part of the contracting process, but user interface professionals may become involved in their design.
Interviews and focus groups are highly recommended (at least by me). Continuous data logging raises serious privacy issues; moreover, the information you really want may not be available from such a source. Bulletin boards, newsletters, online help, etc. can be important. As Shneiderman says, "Every technical system is also a social system that needs to be encouraged and nurtured" (p.149). Controlled psychological experiments are a lot of trouble and unlikely to be very useful in most cases. Maybe the sentence on p.150, "If you are not measuring, you are not doing human factors!" is left over from a previous edition, as there is little in this book that argues for the value of measurement. In any case, human factors in this traditional sense is at most a small part of what user interface designers do today.
The paper Techniques for Requirements Elicitation was written for a conference in the area of software engineering that is called requirements engineering, concerned with determining the properties that a system should have in order to succeed when it is built. Obviously, the user interface is one area of concern for requirements, and in fact, everything in this paper applies to user interface design as a special case; in general, you can just substitute the phrase "user interface design" for "requirements engineering" to get a paper that reads as if it were written for this course. The paper goes much deeper into the theories behind interviews, questionaires, focus groups, etc. than does chapter 4 of Shneiderman, and in particular, it provides theoretical tools for understanding why various techniques are unlikely to work in certain situations.
One concept of particular relevance to user interface design is that of adjacency pair, because it can be used in exploring the naturalness of many dialogue-like featues of interactive systems, such as login and logout procedures for operating systems. Moreover, the related notion of noticeable absence can be used to explain why an interaction with a computer system seems unnatural when the systems fails to produce second part of an adjacency pair after the user has produced the first part. Note that login-logout is not an adjacency pair, because a logout is not necessarily expected after a login, and even if it does occur, may be separated by a very large time lapse; in particular, the lack of a logout is not a noticeable absence, thus confirming its non-participation in an adjacency pair.
The paper On Notation was written as a keynote address for a large conference with a very broad audience that included many non-specialists. Consequently it is not very deep, and in fact, my goal was more to entertain the audience with some nice examples and pictures, than to challenge their intellects. Nevertheless, there is a good deal of information about semiotics in the paper, and the examples are very directly relevant to user interface design.