If you were following a sequential process, the next step would likely be to design the product. There are different tools and notations that can be used for this, but if your process is expecting documents as outputs or evidence of completion, the document artifact would be a Software Design Description (SDD). IEEE Std 1016 IEEE STandard for Information Technology - Systems Design - Software Design Descriptions provides the outline for such a document. The latest revision of this document was published in 2009.
The standard does not mandate any specific design tools or methods, but Table 1 does provide examples of design languages that may be used to satisfy each of the viewpoints presented in the document, which range from various UML diagrams to IDEF models to IDL to decision tables. Additional examples of what may be expected are captured in the text of this standard.
Note that design is often an iterative process. The SDD format is designed to capture both high level (architectural) and low level (detail) design. In an iterative process, this would be a living document, especially the lower level detail design sections.
In my experiences, while the design and development team is off creating the SDD (and perhaps prototyping or even implementing some of the framework for the project), the SRS is also used by the test team to develop acceptance tests for the software. These are the requirements-based tests that will be used at the end of implementation to assert that the software meets the intended functionality. The development team will, throughout the design process, concurrently be working on the unit and integration level tests (perhaps in coordination with the test teams).