Each user story says what the requirement is and who or what situation it should be applicable to.
It should be very short (should fit on a sticky note in normal handwriting) and not attempting to go into more detail than is strictly necessary.
"As a accountant with no technical background I can find an invoice by its number."
"As a user I can find out which product version I am using."
"As a customer I receive an email notification when my order has shipped, allowing me to track it."
"When the application launches, it reopens any documents that were open when it was last quit."
User stories are:
- easy to write
- easy to maintain
- easy to read
- leaving room for interpretation
- thus tap the knowledge present at the developer level
This makes them particularly suitable for environments with unclear or frequently changing requirements.
They also have downsides:
- they are not able to specify details of an implementation in a waterproof way
- they put responsibility in the developer's hands
- they are not suitable to guide a single inexperienced developer
Iterative processes like Scrum are a good way of containing these risks. If the product owner finds the work has taken an undesirable direction, he can refine the user stories for the next iteration.
User stories are also commonly complemented with acceptance criteria which help to further specify the requirements that determine whether a solution is good. This approach also supports ongoing QA work later on.