Essentially, a BA career isn't really difficult, but it's not easy either. The knowledge and skills required for a BA are quite broad, and if you list them out, it seems like you need... well, everything.
Unlike developers or testers who spend most of their time on the "technical" aspects of software, BAs have to work with both the technical side and possess domain knowledge in areas like finance, insurance, logistics, and more. Soft skills for BAs also range from personal skills like time management, critical thinking, and problem-solving to interaction and teamwork skills like communication, negotiation, and presentation. So it's understandable why many people feel lost about where to start or, even worse, go in the wrong direction.
Back to the main question, what do you need to get started with a BA career?
Firstly, for those transitioning from other fields, you need to understand what software is and how a software project works. Since a BA is a member of the software development team, you need to know who you are and what you'll be doing in that project. This is essential knowledge for those from non-technical backgrounds. However, you don't need to go too deep at the beginning; just understand the basics.
Next, it's necessary to learn the terminology used in BA and software engineering. Not only in the workplace, but even when you're Googling information or reading articles about BA, you'll encounter a lot of technical terms. Understanding these terms will help you grasp the information you read more accurately.
Now comes the part directly related to BA, where you need to understand the BA's requirement management process, from elicitation and analysis to documentation and verification. Understanding each step helps you know what to learn. For example, in the requirement elicitation process, you have various techniques like interviews, brainstorming, workshops, etc. To perform these tasks effectively, you'll need skills like communication, questioning, negotiation, and even analysis.
For those who have just been recruited as BAs, you'll notice that you won't be assigned all the tasks of a BA in a project right away. Depending on the company, you might participate in parts of requirement elicitation, analysis, and management. From there, you'll present the requirements in the form of documents, ranging from high-level ones like business requirement documents and user requirement documents to more detailed ones like SRS and functional specifications.
Then, you can explore analytical skills, using various techniques to thoroughly analyze a requirement and uncover what the client truly wants. Then there are modeling skills using UML. I don't recommend starting with BPMN, as it's not something you should be exposed to as a beginner. With UML, don't delve too deep either, as it includes many types of diagrams, and not all are commonly used. Based on my experience in working and training, I recommend you learn about cross-functional diagrams, activity diagrams, state transition diagrams, use case diagrams, and entity-relationship diagrams (ERDs). To understand ERDs thoroughly, you'll also need to learn the basics of databases and SQL – by this point, you'll have delved deeper into the structure and construction of software.
Finally, try presenting your learning outcomes in the form of a BA document. The most common is the SRS. You can find templates for these documents on the BA Times website – a great resource with a wealth of knowledge about BA worldwide.
This should hopefully answer some of your questions. If you still have any concerns, don't hesitate to PM me directly.
Comments