When a product manager writes a market requirements document (MRD), she typically includes a section with use cases. Use cases describe how actors interact with the product to achieve goals.
Use cases typically come in one of two forms. A use case diagram merely depicts the actors and use case names without detailing individual interactions with the product. Text use cases are narratives that detail actor interactions with the product.
Since use cases come from the user perspective and treat the product as a black blox, they play a useful role in requirements documentation. But do use cases communicate requirements or design?
Craig Larman, in Applying UML and Patterns, answers that "use cases are not exactly requirements or functional specifications, but they illustrate and imply requirements in the stories they tell." I agree with Larman but would like to draw attention to some distinctions.
The names of the highest-level use cases of a product communicate functional requirements. Such names should reflect the highest-level goals that stakeholders are trying to achieve to overcome the problems they face. A functional requirement states what the product must do to solve or avoid a prospect problem. Since use case names imply what the product must do, or at least help the user do, to solve a prospect problem, it follows that the names of the highest-level use cases represent functional requirements. Therefore, use case diagrams that depict the highest-level use cases are appropriate in a requirements document.
However, text use cases do not represent pure requirements. When we describe how a user interacts with the product to achieve goals, we venture into product design. For example, if you specify that the user of a TV presses a button to turn it on, you have already gone beyond requirements and into solution space. Not only have you prescribed a particular solution for switching on the TV, you have assumed that turning on the TV is a necessary step in achieving the user's real goal, which is watching TV. Fleshed-out text use cases are not appropriate in requirements documents (except perhaps to provide background information about how customers currently achieve their goals without using the product, or perhaps to illustrate one possible way the product might meet the requirements).