Most small- to medium-sized projects include just one business analyst who works closely with the project team and business partners to manage the requirements discipline from start to finish. In this case, with a single business analyst, it's easy to know who's supposed to be working on what, and you will generally be engaged in all business analysis activities in sequence, one at a time. However, on larger projects the dynamic changes.
Mega-projects usually require a team of business analysts to accomplish massive amounts of requirements elicitation and management. It's more efficient and shortens the project timeline to have them work on separate tasks (or separate parts of the same task), rather than all work on the same requirements task together. The easiest and most common way to break up and assign requirements work is by functional decomposition—that is, by breaking higher-level business functions into smaller, manageable pieces like functions, sub-functions, business processes, sub-processes, etc.
To do this, start by creating a chart or matrix of the manageable requirements chunks, with input from the business stakeholders and project team. Keep the chunks organized under the business processes and sub-processes to which they belong. After you've broken the functions into manageable sub-processes, assign them to the business analysts in a manner that sequences them appropriately, and that balances the workload across the business analysts. The sequencing should be determined by any dependencies among requirements sets (i.e., a particular process area needs to be clearly specified and understood before another related process is tackled); by priority (the highest priority requirements areas should be fleshed out first, especially if the project may have to undergo some scope adjustment); and by skills and availability of subject matter experts (i.e., people with certain skills or experience need to do specific parts of the requirements work, so it must be sequenced to meet their availability).
You can add the decomposed chunks to a requirements traceability matrix in a way that shows what the various decomposed components are, which requirements are linked to or contained within them, who's working on them, when they will be released, their priority, etc. This information should also be captured in your requirements management plan.
Caution! One of the most dangerous pitfalls of breaking requirements down by functional composition is forgetting to consider the availability of business subject matter experts in the requirements space. If there are significantly fewer business resources than analysts, you'll need to stagger the requirements work to keep the business stakeholders from being overwhelmed.
Another common pitfall is getting so caught up in decomposition that you try to force all of the functions and sub-functions to be equal in size and/or importance. Some teams find themselves addressing requirements in an order that doesn't correspond to how much business value they contribute, or how well they meet the acceptance criteria for the project.
Be sure to decompose only those functions and processes that it's actually valuable to decompose for the purpose of splitting the work up logically among multiple analysts. Leave the rest at the highest level possible. Ensure that the business analysts' work assignments give primary attention to the sub-processes that the solution will impact most severely, with less attention to those less impacted by the solution, and minimal attention to the sub-processes that won't be impacted at all.