I associate a set of requirements (in whatever format) with a releasable entity. So, my question would be: Are these submodules going to be independently released from the application?
If you are developing libraries or reusable components that you want to design, build, and version independently for traceability, then each component will need its own set of requirements. If you're using a requirements management tool, that could be just assigning a label or tag or some other kind of attribute to each requirement so they can be managed independently or in conjunction with others. If you're using documents, then separate documents would be the way to go.
However, if your sub-modules are simply logical pieces of code that are not independently built and released, then there's no need to split up your requirements at once. The overhead of managing multiple requirements sources is not necessary.
There are also two caveats here:
At a system level, you could make the argument that it doesn't matter what your underlying architecture is. The requirements are capturing what the system does without regard to how it's implemented. The set of requirements are levied against your system and it's a design decision on how to realize those requirements.
Planning for reuse too early is generally wasteful. If your implementation is only going to be used in one or two applications, then rewriting the implementation is usually safer. There's added complexity in making a robust, reusable component and you don't typically see value until at least 3, if not more, instances of reuse of the component. By that time, it may make more sense to refactor and extract.
My recommendation would be to start with one set of requirements. However, by appropriately labeling them and allocating them, you can be prepared to refactor your requirements. I would recommend using at least a spreadsheet application to manage requirements over a word processor, since there are some inherent sorting, filtering, and data analysis features that can make it easy to manage requirements over a long term project.
