Are you asking how to work things out using tables/flows/mindmaps, or are you asking how to work out things like tables, flows and mindmaps?
If it’s the former, then that’s a really big subject and it’s dependant on a whole lot of stuff. What are you there to do? What do you need to show that you’ve done? Who are you doing it for? Who are you doing it with? What resources do you have to help you? What are you doing it to?
You need a plan. A plan guides your project, using a strategy (how you’re going to test) with your logistics (the resources you have and how you’re going to use them to do your strategy).
So based on the context I’m working in, the challenges I have identified, for the mission that have and for the purpose of meeting the needs of the people involved and their requirements, I get myself a practical, informed, product-specific and risk-focused strategy.
One generic way to go about it is to start blurry and get sharper. Start with what the thing is supposed to do (why it exists at all). Follow up by learning what exists in the system - what is there to learn about? Then learn what those things are, what they are for and how they might fit together. Then you can think about all those things and problems they might have and how to look for those problems, or whatever other thing you’re expected to do.
It’s a question that needs scope. The question “How does this login page interface with the database?” and “How does Twitter work?” are both working things out, but at vastly different scopes. I can write a diagram of database calls in a timing diagram, and I can write an overview of Twitter’s tech stack at a high level, so written stuff is just representing some abstract, high or low level.
If it’s the latter - well those are artefacts written by someone. I’d ask whoever wrote it.