I'm new to Freelancer, but have been a technical writer for over 20 years, and have worked on SRS & FS docs in the past. 'Happy to discuss more when we speak.
I like to approach SRS documents from a process-design perspective, listing out the following, ideally, in order.
1. The application's objectives, its context, and target audience profile
2. Key terms and reference documents associated with the application and industry
3. Functional and technical constraints that may impact the application's functionality
4. The modules that make up the application and the interaction between them (flows & text)
5. The user roles that will access these module, and their access & responsibilities in each module
6. The tasks that users can perform in each module
7. Use cases and cross-references associated with each task
8. Detailed logical data model (drawn from tasks and use cases)
9. Security requirements
10. Any additional specifications
11. Features identified but planned for future releases
I hope this approach works for you. Personally, I have found the process-driven approach the most effective for SRS / feature specifications documentation. This approach allows one to drill down across levels much more effortlessly, helps create documentation that is more interconnected, and creates a more systemic image of the end product in the team's mind.
I look forward to discussing this in more detail when we speak.