I don't like that your requirements appear to live in a Software Requirements Specification document instead of a requirements management tool. A document-based approach makes it more difficult to capture traceability between requirements and to reuse requirements across projects or products in a software product line. These may not necessarily be concerns for you right now, but it would be easier to start with a requirements management tool than try to manage documents and then import several documents into a tool and remove duplication and manage traceability after the fact.
Perhaps it's implied, but the process that you describe doesn't have any kind of iteration on the requirements. When the initial customer requirements come in from the business development executives, they probably won't be suitable for performing design, implementation, and test activities. At least some of the requirements will need to be clarified and rewritten. In addition, there will likely be other requirements that come from other sources - your test team may introduce testability requirements that you need to implement, there may be business or regulatory requirements that impact your product. These will also need to be captured in the SRS and reviewed with the customer to ensure they understand and can live with those requirements.
The concept of freezing an SRS is a little strange to me. Even in a sequential process, the client may want to change the requirements. There is a cost and schedule impact associated with a requirements change (especially late in a sequential process), but the process for receiving a change request, evaluating the request, and determining a response and disposition should probably be something that you want to define.
If you would like further guidance on working with software requirements and developing an approach, I would highly recommend getting a copy of Software Requirements (3rd Edition) by Karl Wiegers and Joy Beatty. A copy of IEEE Standard 29148-2011 may also be useful.