How to handle more than 4000 requirements?

You talk about applications. How many products are there? Is each application a product? Can groups of applications be considered a product? Is the whole set of applications a single product?

Are all of these requirements functional requirements? There may be requirements that can be more easily satisfied by including them in a Definition of Done or considering a platform. Non-functional requirements and some regulatory requirements may fall into this category. You may actually have far less than 200 requirements to satisfy.

Do you need to use stories? Nothing says that your Product Backlog needs to consist of stories or even that those stories need to be user stories. There may be better ways to represent the functional and non-functional characteristics of the system or products.

The challenge you describe appears to be complicated, but not necessarily complex. There are 17,000 requirements which you appear to be quite confident of. If so, I suppose you might reasonably just accommodate them all within a project plan. I'm not sure why you would need Scrum in this situation or why you would even benefit from having a backlog at all.

Define a product vision, identify what is important first. Not all applications needs everything simulataneously. We need to identify critical user storis , and thats the crux of managing 4000+ requirements.

Organize planning workshop to identify most important , business viable , maximum value delivering user stories, as per Pareto principle 80% of value delivered by 20% of user stories. So even for intergtation project, we just need to identify those 20 percentage of stories.

No one can add/deliver 4000+ requiremetns in board. That will be done gradually

1. Identify important stories with MoSCoW

2. Use planning workshop to identify stories required by customer to deliver business value

3. Identify story roadmap

4. Identify less dependent or resolved dependency stories 

5. Plan for release - quarterly, monthly or as per customer need

6. Identify candidate stories as per the user story roadmaps for initial relase (ideally those having 0 or minimal dependency)

7. Gradually work on impediments, dependency resolution and work on user story map, refinement of user stories and release planning and execution and delivering user stories to end customers.

Thank you all for comments.

@Thomas, yes they are separate products and multiple applications cannot be clubbed as different products. They are all functional requirements. There are non functional ones too. If not for stories, what else can product backlog consist of? set of tasks perhaps?

@Ian, We want use scrum because we want to deliver it for each iteration and plan release accordingly. We want to track and estimate what is team velocity to plan further integration activities. We do have a project plan as well to track and maintain gaps, dependencies and risks. But without a backlog, it seems arbitrary start integration with multiple applications. 

@Jaya, Thank you for the detailed steps on how we can breakdown. Pareto principle is something we can consider initially. I'm having planning sessions with team to understand how we can represent these requirements better so we can track and organize it. Release cadence is something we are still planning. But these steps are something I will keep in my radar during planning. 

I'd argue that EVERY product has 17,000 + requirements in them, it's more than you're looking at the entire "iceberg" rather than just the stuff above the water. Just focus on what is the most important first, raise epics for the other areas and wait for them to eventually rise to the top of your backlog...