We use basic requirements at our work. They're of the normal "The system shall" style but not nearly so stringent. They don't read like a spec. They are pretty much "right sized" so they have that going for them. They also are fairly detailed as far as the "What".

When i say they have the "What" part, i mean they say things like "users must be able to click on a heading to sort the field"

So the "What" is this: "Must be able to sort"

and who needs to sort?

and why do they need to sort?

What's really missing from these type of requirements is the Who and the Why. These are very important and it's something built right into the "Card" part of the user story.

Remember, User stories are three things. They are

1. Card
2. Conversation
3. Confirmation

So the Who, What, and Why are the most basic and first part of the Card. (test objectives and size are also part of the card)

as a [Role] i want [feature] so that [business value]

or

as a [Who] i want [what] so that [why]

For example...

As a job hunting i want sorting on jobs so that i can find jobs by where they are located.

This represents the requirement.

IMPORTANT

This is NOT the requirement. It represents the requirement.

It's often confusing to people so i'm going to say it a third time for emphasis...

A user story is NOT the requirement. It simply represents the requirement for the purpose of estimating and planning.

So why is the Who and Why relevant to estimating and planning? Because again we're only concerned with a representation of the requirement for the purpose of planning (ok i said it 4 times, shoot me).

The who is important for planning and estimating because you're going to have to have a little bit of conversation with that person to figure out enough of the requirement to estimate it in size. Now i'm not saying you have to find out all of the details up front!

One of the agile mantras is "Delay decisions until the last responsible moment". This is so that we can give our customer the opportunity to change the requirements and turn on a dime! Now, this "responsible moment" is very subjective! For example, i might need to know if this sorting needs to be client side or can it be server side. If it's client side, that is architecturally significant and may impact the estimate.

The why is important because it gives us a chance to think creatively about the problem. The customer wants sorting so they can find jobs by region. Well, what about a search functionality? What about a filter? Are there alternatives to achieving their goal that may be easier? Better? More usable?

So why user stories?

They allow us to defer the details, to estimate, to provide options to our customer to achieve their goals and they give a concise description that represents a requirement for the purpose of planning and estimating.