Stories should be independent in a way that allows the easy prioritization and not overlap each other, even though it is not always possible.
Story is viewed as an invitation for conversation capturing what is desired, not a contract for features. It may acquire notes, test ideas etc. in order to meet a customer needs.
Value of a story is based on customer needs, what is an important factor while prioritizing backlog. Value needs to be considered especially when splitting stories so each story brings a value to the customer.
A good story can be estimated, meaning that developers can understand it and be able to implement it. Based on that it is possible to rank and schedule implementation.
Stories tend to be small. Usually at most a few person-weeks of work or one iteration length. Smaller stories are easier to estimate and further details can be added later.
Common characteristic of good requirements is testability. This applies for stories as well. Testability is also an indication of understanding the goal of the story.