How to distill a Client-provided SRS into well formed Stories, fitted to be consumed in Sprints?

Why do you want to convert these requirements into user stories? To me, that seems like wasted effort. You have an expression of need from the stakeholders. Rather than turning them into user stories, I'd just try to get them out of a document form and into a better format for requirements management that will allow you to capture dependencies and start to order the work. Once you have an ordered backlog with enough work in it, you can start development when continuing to put the rest of the requirements in the backlog.

Since you're using Scrum, you'll have a Sprint Review at least once a month. At the review, use this to synchronize with the client's Business Analysts and show them what requirements have been completed this Sprint and what the top of the backlog looks like. If it's like the majority of software efforts, they are going to have opinions on what the next work should look like. Perhaps that means they'll come up with something that is not in the original requirements document. Perhaps they'll decide that something in the requirements document isn't truly needed and can be dropped. Agile methods like Scrum give them this advantage.

This Client is fairly new to Agile and want us to adopt Scrum to develop & deliver their product. The problem is that they have already come up with detailed SRS documents

That being the case, why do they want you to adopt Scrum to develop & deliver their product?

Have they expressed a desire for those requirements to be revised each Sprint, based on lessons learned?

Thanks @Thomas Owens for your suggestions!

I agree that Scrum doesn't dictate defining requirements in User Story format. However, that being said, we would need to find a way to break down the requirements sections and sub-sections in the SRS into small, estimable and well-sized chunks that can be worked upon within a Sprint and be delivered. We can call it User Stories or whatever else we wish to call.

On that note, I didn't quite understand your point of - 'Rather than turning them into user stories, I'd just try to get them out of a document form and into a better format for requirements management that will allow you to capture dependencies and start to order the work'. Isn't this similar to a Use Case/ User Story or a User Voice? Breaking them into manageable chunks would also, on the other hand, enable us to create a Backlog which we can then have prioritization discussions with the Client BAs during Refinements and Review sessions. 

I'm completely in-line with the your second paragraph of having those discussions and collaborating with the Client BAs to gain valuable feedback and knowledge of the shape of things to come next.

Regards.

Thanks @Ian Mitchell for your response!

The primary reason Client wants us to adopt Agile & Scrum is that they want to see working software at quick and regular intervals, so that they can make informed decisions upon the next set of priorities to work upon. They have provided us with an MVP/ MMF to work upon first wherein they'll evaluate their hypothesis on the basis of the minimal working solution and then decide on the 'pivot or persevere' decision.

Regards.

A detailed SRS doesn't sound like an MVP learning experiment; rather, it would indicate that a significant leap-of-faith is being taken before empirical results will be obtained.

My advice would be to start with a release-quality Definition of Done. Once that is understood and in place, a minimum viable product can perhaps be elicited -- the smallest thing which can be Done at all.

On that note, I didn't quite understand your point of - 'Rather than turning them into user stories, I'd just try to get them out of a document form and into a better format for requirements management that will allow you to capture dependencies and start to order the work'. Isn't this similar to a Use Case/ User Story or a User Voice? Breaking them into manageable chunks would also, on the other hand, enable us to create a Backlog which we can then have prioritization discussions with the Client BAs during Refinements and Review sessions. 

Possibly. Without seeing the SRS, it's hard to say for sure. I was mainly referring to getting them out of a document and into something else. If I had this problem, I'd probably turn to Jira because I know it has what I need. I could probably get what I needed out of a spreadsheet, too. There are also other requirements management tools that offer linking dependent requirements, decomposition, traceability, and other features like that.

In Jira, I'd use custom fields to reference parts of the SRS, issue linking to start to identify dependencies, and labels, components, and hierarchies (defaulting to Epic and Story, but can be modified) to decompose into related bodies of work rather than just the hierarchical tree of an SRS document. Then, work with the team to start to think through them all. The format you use to capture the decomposition of items isn't really relevant, as long as you get them to levels that are small enough to complete in a reasonable timeframe - at least within a Sprint, if not a couple of days. The linkage and references to SRS identification numbers can help when you complete work, you can relate what was done back directly to the relevant parts of the SRS.