Let's start by defining what exactly a use case is. A use case is a list of visible steps that a system goes through in order to complete a user initiated task. They are typically given names that imply the task will complete. For instance, you should use the name 'Reserve a Room' instead of 'Reserving a Room'. You also want to avoid using the words 'and' and 'or' in the name as this implies that the use case is doing too much and should be broken up into smaller parts. For example, 'Search and Replace' could probably be separated into 'Search For String' and 'Replace String With Something Else' use cases. 
For each use case that you write you'll probably want to write a second one that will undo it. For instance if you have a 'Make a Room Reservation' use case you'll probably also want a 'Cancel Room Reservation'. This recommendation, however, does not apply for use cases that are just about obtaining information, like 'Check Room Availability'. 
In his book Agile Principles, Patterns, and Practices in C#, Robert C. Martin recommends writing use cases on index cards, but in my opinion that doesn't sound like a good idea. For starters you'll probably have to use many index cards in order to capture all the steps needed to accomplish a single use case. Secondly, since use cases are meant to be flexible, you're probably going to be doing a lot of erasing and re-writing each time a change occurs. And as Mr. Martin would tell you, change is inevitable. Therefore I'd recommend using a word processor to write use cases. 
Notice that I said you write use cases, not draw them. That's because use case diagrams don't really tell you anything about the system. They don't tell you how the user is supposed to initiate the task nor how the system is supposed to respond to that request. The only thing use case diagrams are good for are giving an overhead view of all the tasks that a system can perform. 
User stories, on the other hand, should be written on index cards. That's because user stories are typically short sentences that follow the form "As a ____, I want to ____". For example...
As a homeowner, I want to read reviews written by members of our site about service companies so that I can decide who to hire to do some work on my house. It's also much easier for the customer to prioritize the implementation of system features using user stories than it is using use cases. 
To summarize, use cases are much more detailed than user stories.
Compare the following use case...
Replace String With Something Else
- The user executes a command to replace a given string with something else.
- The system responds by presenting the user with a window to enter what string to look for and what string it should be replaced with.
- The user fills in this information and clicks the Find button.
- The system responds by highlighting the first occurrence of the given string.
- The user clicks the Replace button.
- The system responds by replacing the found string with the second specified string.
As a writer, I want to be able to replace a given string with something else.There's just a few more things to say about use cases that the above example highlights so well. For starters, notice how the user always initiates the chain of events. The system is only responding to the user's actions.
Something else to take note of is that I used the present tense form of the verbs. For instance, I used executes instead of executed (past tense) or shall execute (future tense). That's because each step is supposed to represent the current state of the system. 
- youtube.com, Wyyzzk, "User Stories vs Use Cases"
- "Chapter 17: Use Cases" of Robert C. Martin's Agile Principles, Patterns, and Practices in C#
- UML 2 For Dummies by Michael Jesse Chonoles and James A. Schardt, specifically "Part 3: The Basics of Use-Case Modeling"
- "Chapter 9: Acceptance TDD explained" of Lasse Koskela's Test Driven: Practical TDD and Acceptance TDD for Java Developers