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.