Top-down refers to the presentation of facts starting from a high level of abstraction (few details) step by step to concretization and refinement (more details). Readers of your documentation will love to be picked up when you explain your requirements top-down.

At the same time, the (top-down) structure of your documentation should never dictate a particular way of working or sequence for creating and/or specifying your product requirements. Especially in the agile environment, we want to add just-in-time details only to requirements where the business value is particularly high. And you could start collecting low level requirements as soon as you hear them. But in the end you have to structure them into a top-down hierarchy.

It is important for readers to have the overview understood first before discussing details. Therefore, you should always organize the communication and documentation of results top-down! req42 supports this advice by strict top-down organization, starting with visions and goals in chapter 1, setting the scope in chapter 3 and organizing the product backlog by large epics, containing smaller features, containing very detailed user stories.