When I grow up I will become a Systems Analyst
In this article I will analyze the role of a systems analyst in a team, as well as the problems and tasks about which it is impossible to remain silentь which are relevant at the moment.
I'll start with two facts:
In my experience, I and almost all my colleagues perform many completely different tasks that definitely go beyond writing technical specifications and working with requirements.
Every time I mention systems analyst testing or writing code, I get a lot of questions about whether it should be the analyst's business.
The truth lies somewhere in the middle ground between these two facts.
A systems analyst is a specialist who not only understands the operation of a system from a technical point of view. He knows how to work out the logic of the system, build scenarios for its behavior, think through all the options and take into account a large number of aspects. This is a specialist who analyzes and designs complex systems based on many aspects, including business problems, system constraints, architectural requirements, and much more.
When I was in a developer role, I often had questions about the process, restrictions, conditions, or unexpected errors that cropped up. I contacted an analyst who with a magical wave of the hand worked through emerging problems and was able not only to analyze a business process, but also to describe them in technical language.
The systems analyst, unlike other roles, is the most immersed in each of them. He knows not only the business processes themselves, but at the same time their technical implementation. Of course, he may not know how the code is written. But he knows what this code does. What results should we expect and what should we not? after which the sales will drop.
Business Analysis
A systems analyst is now very deeply immersed in business processes. He knows not only the processes themselves, but also the business goals of his tasks and the product as a whole.
This is due to the complexity of systems at the moment. In order to clearly build a scenario for the behavior of the system and work out the interaction with related processes, it is not enough for an analyst to understand only the technical side. He works through all scenarios for the implemented functionality, based on established existing as well as new business processes. In addition, he looks at the system not only from the point of view of implementing functionality, but also from the user’s side, which makes it possible to deeply study the process.
Understanding the business goal helps to avoid discrepancies between technical implementation and customer expectations. As the level of complexity of systems increases, business requirements may imply implementation variability, which may lead to divergence from customer expectations.
In this case, the implementation largely depends on the systems analyst. It depends not only on quality; undeveloped requirements will lead to reworking of functionality, loss of time and resources.
Development
A systems analyst does not write code. But very often he is immersed in technical implementation almost on the same level as the developers. The complexity of systems means that a superficial understanding of the system may not be enough to develop the requirements. The analyst not only speaks the same language with the development team, but also very often works with the code.
In addition, a large number of microservices require competent integration development, and most integration tasks require high-level technical skills.
There are separate areas where analysts perform development tasks. In my experience, almost all analysts can write a good sample, and many write database scripts. They also work with Python, even using it for integration tasks.
If we list the hard skills and tools that middle and senior level analysts use, we can say that they interact extremely closely with the development sector and solve problems not only in terms of requirements.
Testing
Analysts do not write tests and do not take over the testing phase themselves. But in my experience, they very often perform testing of their functionality.
Testing can be performed by an analyst in parallel with this stage to verify the described implementation. This is almost always not the analyst's direct task, but it can help identify unprocessed errors that arise.
In my practice, up to a certain point, as a developer and analyst, I believed that my responsibility was to implement the functionality. His verification was not my stage. Of course, I tested myself, but I did not look for many cases and did not test all work scenarios.
Later I realized that my responsibility is always there. Testers or business analysts who perform testing are not always immersed in the process as deeply as possible, since they do not see the system from exactly the same “angle” from which developers or analysts look at it.
In any case, double-checking yourself and making sure that what you made with your hands works correctly is good practice. Our common goal is to implement a quality product, and not to relieve ourselves of responsibility at a certain stage.
In addition, analysts very often work with support, performing tasks on the second or third line. They work through errors and look for their cause. This cannot be done without testing, finding cases and reproducing problems.
How to find an approach to problems
If we talk about tools and skills, there are a huge number of them that can be listed. The main thing is to give yourself the opportunity to grow. Tasks that at first glance go beyond the scope of responsibilities or existing skills are primarily an opportunity for growth. I didn't have a single skill that wouldn't be useful to me again.
It is very important to develop systems thinking. It helps you work through problems on a different level. The deeper I dive into elaborating the processes of the current task, the higher the quality of elaboration of the requirements for the next task.
Let's sum it up
Becoming a systems analyst is not just about being able to write functional and non-functional requirements. This means becoming a high-level technical specialist with a large number of skills and the ability to solve various analytical problems when working with complex systems.
I am sharing a small selection of literature that may be useful:
“The art of systems thinking. Essential knowledge of systems and creative problem solving” Ian McDermott, Joseph O'Connor
“Book of Solutions. 50 models of strategic thinking” Mikael Krogerus, Roman Tscheppeler
“Clean architecture. The Art of Software Development Martin Robert
“User stories. The Art of Agile Software Development by Jeff Patton
I wish you good luck in systems analysis and more!
