How to Translate Business Requirements into Code
How does one take business requirements and translate them into technical requirements? If you’re a new team lead or an aspiring team lead, this is something you might think about. As a leader in the development world, you will be asked to attend meetings to receive high-level requirements. Your job will then be to take those high-level requirements and turn them into technical requirements that your developers can then work on. I don’t claim to be the absolute authority on this topic, but I will take you through what has worked for me.
Knowing the Code Base
As the team lead, you should know the code base, or your part of the code base, well enough to think of what needs to be done before actually getting into the code. This will help your think of technical requirements before actually writing them out. If you’re coming into a new project the first thing you should do is get really familiar with it. See if you can pull aside a really knowledgeable team member to take you through the application. This one is not 100% necessary but makes your life a whole lot easier.
Being a Good Writer
You have to be a good writer to give good technical requirements. Think about this; you’re the only thing between the business requirements and the code. You have to split up work accurately, summarize what needs to be done, and make sure that everything is clearly explained. If you miss any of these things, it could spell disaster for your developers. Writing requirements is a lot like writing documentation. How many times have you been reading the documentation for programming language/library/API and have been frustrated by how poorly written it is? It’s the same situation with technical requirements. It can be a good idea to periodically pull your team aside to get their feedback on the current technical requirements or send out an anonymous poll. Don’t underestimate the power of feedback, it will help you improve. That being said, you may have to put your ego aside because not all feedback is going to be good and you have to take it in stride if it isn’t.
Make sure you have all the information upfront
This is really important to me. Often the business will come and say something like “we need this done ASAP” and give you about half of the information you need. As a team lead, it’s your job to push back on that. If you don’t have everything you need you have to clearly communicate that back. What I mean by that is not to get upset at people, but you want to let them know that you can’t do your job with the information provided. Tell them the information that is missing and that you can’t do anything until you have it. As a team lead you’re going to get a lot of pressure to complete things as quickly as possible. It can get overwhelming so you have to manage your time and expectations. You also have to manage the expectations of the people who are giving you the requirements. That means being very honest about what you and your team can and can’t do.
You’re also going to have to start asking a lot more questions when you get high-level requirements as well. Having more information will usually work in your favor because you can work through it and decide what goes into the technical requirements and what doesn’t.
Stay Organized
You’re going to have a lot of information thrown at you, so it pays to keep yourself organized. I like to use Trello boards to keep track of all the iron I have in the fire. If you want to write things on paper or on a tablet, use post-it notes or some other digital medium do what works best for you. Your goal should be to be able to see at a glance what you need to do, what’s in progress, and what is already done. You’re going to need that information if you're in meetings and trying to give status updates about various projects. Having all this information also helps to keep things from slipping through the cracks. I’ve been in situations where I’ve just forgotten to do something because there was so much stuff to do. After that I re-organized myself and it hasn’t happened again.
Learn from your mistakes
You’re not going to be perfect, I know I’m not. Making mistakes sucks, but you need to approach them as something to learn from. I mentioned getting feedback from your team, that’s a really great way to get feedback. You can do this however you want. I find it useful to have one-on-ones with team members, you can do retrospective meetings if that works, or send out an anonymous poll. Sometimes team members will feel more comfortable giving more honest feedback anonymously. I’m not going to presume to know you or your team so my ultimate advice is to do what works best for you.
If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!
If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!
