Over several years, a company developed a multi-disciplinary (firmware, software, hardware) product. No SRS (Software Requirements Specification) was ever written. A prospective customer now wants a SRS.
Any ideas how to approach writing one? Read the code? Write a user manual and convert it into requirements?
The end-user isn't interested in the source code. There's no need to go down into the weeds like that. They are interested in the product as a whole.
Ask yourself "what does the product do?" Working with someone who knows it well, find all the things it does, and write a requirement or two for each thing.
Wherever possible, requirements should be testable. Consider how you will demonstrate that the product does what the requirement says it does. Test "by inspection" should only be a last resort.
If you are specifically after a software requirements document, then you need to work out the overall requirements first, and that should tell you what the software needs to do.
I would question why a customer is asking for a Software Requirements Specification to be written for existing software. Requirements are typically used to drive design and test - you create a design that satisfies the requirements and then use tests that trace to the requirements to confirm that the design actually does satisfy the requirements.
For existing software (or any kind of off-the-shelf purchased products), I'd recommend a Software Design Description (SDD) of some kind. Tests - especially those written in BDD style - can describe the characteristics (functional and some quality attributes) of the software system in a way that can be understood by stakeholders. This can serve as one part of an SDD, with appropriate graphical, tabular, and textual models serving as another component. The level of detail greatly depends on the type of product you are making and the agreements and relationships with the clients who receive the documentation.
If an SDD isn't appropriate or suitable, you would have to work with the customer to understand exactly what concerns they are trying to alleviate and work with them to find the best ways to address them. That may mean reverse engineering a SRS from an SDD or the code or a running system.