In my experience, when you want to communicate business requirements, you have to start by understanding the communication preferences of your stakeholders because stakeholders process information in different ways. It is also important to start off by 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:
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 or wireframe with a supporting data dictionary.
For databases, you can use 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 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 creating 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 enroll in The Business Analyst's Playbook. In it, you will get the proven steps that you can implement today while working on any project engagement.
Comments