In my experience, I’ve always tried to find out the communication preference of my stakeholders, because, stakeholders process information in different ways. It is also important to start off with identifying your stakeholders and mapping out their level of power and influence on the project. Some prefer high-level information, some prefer graphical representation and others might prefer the details.
Having said that, I have found that technical teams appreciate communication of requirements using the following:
A simple easy to understand requirements that are quantifiable, measurable, testable atomic and relevant. You may choose to use the traditional requirement style, use cases or user stories.
A supporting use case diagram to show at a high level, the various interactions that would be fulfilled by the requirements.
A level 3 process diagram that helps to understand the happy and unhappy paths, the hands-off to other users, as well as the start and end journey.
If it's a CRM or a web (and app) project, you need a screen navigation document/ wireframe, with supporting data dictionary.
An entity-relationship diagram, showing the interactions, keys and relationships between each entity (1-to-1; 1-to-many).
If you are more technically inclined, a state diagram to further explain the timing, start and stop event within the system.
Nevertheless, it is crucial to understand the project delivery framework that currently exists, is it a waterfall or an agile delivery framework? Then you need to speak to your technical team, to find out what is important to them, what they would like to see and what would add the most value. This way, you don't have to spend a ton of time coming up with documents, diagrams, etc that would not be relevant to your tech team.
If this resonates with you and you want to learn more about doing business analysis the right way, then I invite you to enrol in The Business Analyst's Playbook, where you get the proven steps that you can implement today, while working on any project engagement.