1 – Be a user, use the system
We are developers, and most times, we say bad things about users. But the truth is, we are users too! It’s a big mistake to think we should not use the system. How are you going to understand the process? Reading the code? It can be possible, but it will take time more time for doing it!
So, use the system, see what happens, and check how the information is changed.
Read the menu of the system, navigate, do some actions, insert, update, delete, and search for information!
See what happens on the main flows of the system!
2 – Test queries based on the business requirements
Do you know the main Database Tables from the project you are working on? What happens if you don’t know the Tables? You won’t be able to use your creativity and use the best solution. Maybe you will do unnecessary things to achieve your goal. You will use a lot of unnecessary Join commands and the chance of getting bugs will be very high! Why? If you don’t know what you are doing exactly, how can you guarantee you are not making a mistake?
You won’t. Before you have unnecessary stress, just test Queries, and see how they work with the main business requirements. Use Join, Group by, Left Join, Union, and everything you know to test and understand what is happening.
You can grab these queries on the main services of the project, and get and test them!
3 – Talk to Solution/Business people
If you are working with Solution/Business people, ask them!
Mainly, if you work with SCRUM, one of its principles is to work together with all members of the team. Everyone has to help each other to achieve the goal. If you are not working with SCRUM, no problem, even so, ask them to get your answer!
If you don’t understand the system as a whole, you will have bugs and unnecessary stress.
4 – Create a Wiki (internal site)
Wiki! Create a Wiki! Very important! How new developers will know about the business requirements? They will need to ask other about everything to other developers.
It shouldn’t be the solution. The business requirements should be in an easy and central place so that new developers would be able to learn and understand what is happening.
If you have a Wiki, new and more experienced developers in the company will produce more because they won’t be obligated to stop and explain everything.
The company will earn more money for sure!
Ask your team members to write the core business requirements, database, and so forth!
You can’t learn business requirements at home, so we must have a source of information to learn them in an easier way!
5 – Read the interfaces (API)
Read the interfaces (API) of the project you are working on, read the comments (if present) or simply the method signature
If you don’t have Business/Solution people on your project or developers don’t want or don’t have time to explain how the business requirements work, you must read the code.
I know it’s very complicated when the code was written using Go Horse process but it’s the only option.
If the code is unreadable, just see how the query works, and try to identify the most important Database Tables from the system you are working on.
The most important thing is, don’t stop your work! Make your way to learn the business requirements using all of these techniques.
Don’t keep on waiting for a magic solution to happen, you must use these techniques and solve the problems!
[…] than no methodology at all. No methodology might make sense when the project is small and all the requirements knowledge is under the control of the developers but things get very hard when the project and team […]