Think of the scenarios as a way to put requirements into context.

Scenarios put the user requirements, system requirements and tech requirements into the context of a goal being performed.

I prefer to think in terms of scenarios and sub-scenarios. I also prefer to have a scannable list of requirements as well as a scannable list of the scenarios, but connected to the requirements. They support each others. If you have a requirement, but no scenario, you have to ask who’s it for or what’s it for. If you have a scenario, but you don’t know the requirements or tests for success, then you don’t know when you’re done.

A very good book on this with concrete examples is Writing Better Requirements by Ian Alexander.

Thanks in advance!

Sure … you can thin in terms of use cases:
* Browse product catalog
* Order products

The scenario part comes in when you have a specific instance of a use case. For example, “Customer x buys product Z.”

Having the specific instance is useful because you can now test against it. Can customer X buy product Z and does it pass the acceptance criteria? … etc.