It's crucial to separate requirements from design.
Requirements are about what the system does, while the design is about how the system does it. You typically need some kind of requirement, whether that's a formal requirement in the sense of IEEE 830 or ISO/IEC/IEEE 29148 or an informal requirement in the sense of a representation of a stakeholder need or expectation, to perform design. That is, you need to know what the system must do to figure out how the system is going to do it.
Depending on your life cycle model, it is highly likely that you will have feedback from the design activities back into requirements activities. In iterative and incremental life cycle models, you will likely revisit all of the different activities at multiple points throughout the effort. Some requirements activities may come after design work happens. Strictly sequential work where the requirements are frozen before design and not revisited typically doesn't work out very well.
There's nothing wrong with graphical and tabular models in requirements. There's a whole book on the effective use of visual models in software requirements engineering. Among others, it includes the use of business objective models, objective chains, feature trees, organizational charts, process flows, ecosystem maps, decision trees, data flow diagrams, state diagrams, and more. I don't think that there's a comprehensive list of diagrams suitable for requirements engineering, since it depends on the context and information needs of the people performing the design and construction activities.
If you should include diagrams and what diagrams to include as part of requirements specification activities depends on the context in which you are working. If the diagram describes what the system must do or how the system must fit into an existing process or workflow, that falls into the domain of requirements engineering. In my experiences, this best aligns with software that is designed to fit into an existing business process or workflow, and understanding the workflow is important to design and construct the software effectively.
Most of the time that I've seen model checking employed (which isn't often, due to the level of detail and rigor needed) has been in design activities rather than requirements activities. However, I don't think I'd preclude the use of model checking tools in requirements engineering.