Transcription
Good afternoon, everyone present.
Could you please let me know if you can see the presentation screens? If you can see them, please put a plus in the chat. Also, if you can hear me, let's check that too—put a plus in the chat. I see that everything is visible; I hope you can hear me as well.
Good evening, Andrey. We'll start in a minute. Well, it's 8 PM in Moscow, so let's begin our open lesson, which today will focus on the specialization of system analysis. We will talk about who an analyst is, the role of an analyst in a project, and what skills a system analyst should possess to succeed in their profession.
Let's start, of course, with a brief introduction. Is it good that you can see and hear me? If you can see and hear me well, please put a plus in the chat so I know we can communicate and everything is working perfectly. I'll wait a minute.
Thank you, Ekaterina. Let's continue.
So, our open lesson topic is the important skills of an analyst. My name is Maria Krasavina, and I work as a system data analyst at Mate, a Bulgarian company. I deal with requirements analysis, design, and a bit of testing. I have been working in this field for about 2 years, but I have around 13 years of experience in analytics, and I teach courses on basic and advanced system analysis. So, if you make it to our courses, we will meet again multiple times.
The agenda for today's webinar will consist of nine parts. I will introduce myself and tell you a bit about OTUS, then we will move on to the functions of an analyst, who a system analyst is, their value for the project, and we will look at what is most important. After that, I will briefly talk about the course team that is involved in training and upskilling analysts at OTUS. I will also discuss career paths, focusing on what points to pay attention to when hiring juniors, and so on. At the end, there will be a reflection session.
After each logical block, we will have a short break so I can answer your questions if any arise. You can write your questions in the chat; I will see them immediately, but I will respond after completing each logical section to avoid disrupting the flow of the presentation.
We will have special slides where some interactivity is expected. I will ask you a question and wait for your response to have a more lively discussion. I think it’s just more interesting to participate in a lesson this way. In general, the analyst position is related to communication, so I see no reason to avoid it.
These are the rules for the webinar, and now we move on to the first part. I will briefly explain what OTUS is, who the instructors are, and what we represent.
OTUS is a company specializing in IT education. Our unique feature is advanced programs for experienced specialists and the quick launch of courses on new, rapidly growing technologies. Our clients are modern, tech-savvy companies. The training and open materials attract specialists of various levels: junior, middle, senior, etc. We have courses for those just starting their careers, for beginners, or for those looking to change fields. Naturally, we also have courses for upskilling those who have been in the profession for a while and want to advance their careers or organize their knowledge.
Personally, I joined OTUS for the latter reason. OTUS has an educational license, so our courses are professional development and retraining programs. The courses are designed considering the requirements for specialists in open vacancies at top IT companies at the junior, middle, and senior levels. Here, junior, middle, and senior refer to the levels of specialists, not the levels of the companies.
I would add that our courses always keep pace with the times; we teach what is relevant, unlike universities where the information can be outdated. All our instructors are active professionals, meaning we all work in the field, and we naturally keep up with all the trends, regularly updating the course content to avoid falling behind current technologies, frameworks, and practices.
That was a brief overview of OTUS. Currently, OTUS offers more than 130 courses and has over 600 instructors with up-to-date knowledge and real cases in demand in the industry. Since the company was founded six years ago, we have had over 20,000 students, and now we are approaching half a million IT specialists in our community who read our materials, learn, and communicate on our platforms.
I should mention that communication is very active both internally and externally. Instructors, mentors, and so on, we all participate and support our students in chats and outside of chats on a regular basis. So, there’s no situation where you are given an assignment and left alone without knowing whom to turn to. There is always some mentor or senior colleague who can help.
Now, I will pause here. If you have any questions about what OTUS represents, please write them in the chat. The chat has a slight delay, about 5-10 seconds, so I may not see them immediately, but as soon as I do, I will definitely respond. I’ll give you a minute—well, probably less than a minute—to formulate your questions. If there are no questions, you can put a minus in the chat, and then I will know we can move on.
I see that there are no questions. Well, let’s move on to the main part of our open lesson on the important skills of a system analyst.
Before we start discussing something quite important and filled with new information, it’s always good to set a goal for ourselves. What are we striving for? What is the purpose of this conversation?
In this webinar, our goals are as follows: after the session, it is desirable that those who are encountering the concept of a system analyst for the first time understand the role of a system analyst in a project among other development participants. They should understand who a system analyst is, what prerequisites are needed, and what qualities they need to develop to be successful in the profession.
Naturally, by the end, it should be clearer whether this is the right path for you, whether you want to be an analyst or someone else in IT, and so on.
So, who are we? When I say "we," I mean who we are as system analysts and what we do in a project.
Here’s a slide. It’s clear that the profession is called a system analyst. If you have any assumptions about what a system analyst does in a company, please write them in the chat. Let’s see what understanding of the profession you currently have.
Of course, it’s clear that they analyze systems, but it doesn’t stop there; there must be some responsibilities and duties. So, if you have any ideas, please write them in the chat.
I see that there isn’t a clear understanding. Let’s figure out together what a system analyst does in a project.
On the screen, we have a quote from a book by Irsa, which I have slightly modified. A system analyst is a role in a project team whose main responsibility is to work with stakeholders to identify, analyze, specify, validate, and manage requirements in a project.
A system analyst is also referred to as a requirements analyst, business analyst, requirements engineer, requirements manager, or business systems analyst. A knowledgeable person might tell me that a business analyst and a system analyst can essentially be the same role in a project. I would agree; it depends on the project. In some cases, a system analyst and a business analyst are the same role, while in others, they are distinct. I will discuss this a bit later.
To simplify what we just read in the quote, we can say that a system analyst in a project is, roughly speaking, a technical communicator who builds bridges of friendship and mutual understanding between the business and the technical development team.
The analyst communicates with business representatives or clients—this person or group of people—and gathers their wishes and various assumptions about how the system should work to generate profit or bonuses. Then, all this collected information is processed and delivered to developers as requirements, effectively turning business requirements and wishes into clear technical tasks, tickets, and so on.
So, to simplify, this is the role of an analyst in a project.
Let’s move on to the next slide and figure out where the analyst applies their knowledge in a project. Where are they most often involved?
We have a diagram on the screen showing the stages of a project. On the left, we have a light bulb, which represents the main idea—the starting point of a project, which naturally begins with some business need.
Next, we have BRQ, which stands for business requirements, functional requirements, user requirements, and non-functional requirements. It goes on to solution design, solution creation, programming, testing, and finally, the result.
If you are familiar with types of project development methodologies, this resembles a bit of the waterfall model, but it can also be applied to other development approaches. However, we won’t delve into project management right now.
I will ask you a question: at which stages in this diagram do you think a system analyst might be involved? You can write in the chat using letters. Do you think they participate in solution design, in gathering functional requirements, and so on?
I’ll give you a minute or two to think about it, and then we will figure out where the analyst is directly involved.
Denis thinks the analyst is involved at all stages. Denis is actually not far from the truth, but there are certain sections or stages of the project where the analyst is directly involved.
There are primary responsibilities and areas of accountability, and there are areas where the analyst is involved to a lesser extent. I suggest we determine at which stages the analyst is primarily engaged, spending about 90% of their working time.
I believe they are involved in solution design, and that’s correct. The analyst partially participates in design.
Others think the analyst is involved everywhere except testing, but in testing, the analyst is actually involved a bit. I will explain why.
In the solution design phase, if there is a division of roles between business and system analysts in the project, the business analyst collects business requirements at this stage. The business analyst looks at how the business is structured and what would be better.
Therefore, the role of the business analyst includes generating ideas. It is believed that a person working in business analysis is more business-oriented than technically oriented and can suggest solutions to business needs that the client may not have considered.
From my experience, I can say that more often than not, the roles of business analyst and system analyst are not separated. That’s why we see some overlap in the diagram, as system analysts often engage in business analysis as well.
When a client has an idea, the system analyst does not suggest the idea to the client. The analyst’s work begins at the moment the business idea arises. The analyst collects business requirements based on the business requirements, decomposes them into functional requirements, and based on those functional and business requirements, determines user requirements.
Then, assistance is required from programmers, developers, and architects because often, non-functional requirements—those that describe how the system should operate, the environment it should work in, how quickly it should respond to requests, system reliability, and so on—are the responsibility of the architect.
However, it often happens that there may not be an architect in the project. In that case, the system analyst, along with the programmer or developer, works on both non-functional requirements and solution design.
In this area, there can be anywhere from two to three or more people involved. Nevertheless, the analyst does not participate in development directly. The only way the analyst might be needed during the development phase is if the programmer suddenly needs to clarify some requirements.
This situation is, I would say, non-standard because before handing over requirements to development, they must be agreed upon and approved by all stakeholders, from the client to the programmer.
But we don’t live in an ideal world; sometimes clarifications are needed. In such cases, a request may be sent to the system analyst during the solution creation or programming phase. However, in an ideal world, in an ideal company, in an ideal project, the analyst does not delve into implementation details. They only specify what needs to be done without getting into how the programmer should solve it.
After the program is written and the code is developed, we move on to testing. Here, there is no direct connection, but there should be one. The connection should exist from requirements gathering to testing.
Why? Because the best analyst, who has communicated with the client and written the requirements, does not know how everything should look. The tester relies on acceptance criteria and various testing scenarios that the system analyst outlined during the requirements description phase.
The tester, along with the analyst, can develop a test plan for everything that the programmer has developed.
The system analyst rarely participates in deployment. It would be more accurate to say that sometimes they may present a demo version of a completed program to the client because, again, we remember that the analyst is the person who knows best what the client wanted.
So, sometimes, it is quite common for the analyst to participate a little at this final stage and demonstrate to the client how the system works. However, this is usually done more by project managers or product managers, who oversee all project stages and step in when something goes wrong or when everything is going well to encourage everyone to maintain a good spirit.
Those who said that the analyst participates at all stages of the project were correct. Those who said the analyst is involved at all stages except for solution creation and programming are also correct. The analyst does not participate directly in testing, but they help clarify how the functionality should work to make it easier for the testers.
This is our diagram. Thus, the analyst participates in development.
Please let me know if you have any questions. If you do, please write them in the chat, and I will answer them. If there are no questions, you can put a minus, and I will see it, and we will move on.
I see that there are no questions. If any arise, please don’t hesitate to write in the chat, and I will answer them after the next block about the skills needed for an analyst—what competencies an analyst should develop to be successful in their field.
So, daily work. The analyst wakes up in the morning, brews tea or makes coffee, takes a cup, and sits down at the computer. Perhaps some are going to the office; that’s not excluded.
What is the first and most important thing an analyst does at work after turning on the computer and taking the first sip of coffee or tea?
It all starts with stakeholder management. Stakeholders, in this case, are interested parties. Stakeholders can be anyone, but they should not just be passersby on the street; they must somehow participate in the development process.
It usually starts with clients who order the system and pay for the development. These important stakeholders always take priority.
These clients, sponsors, regulatory bodies, or legal departments are crucial because systems often need to comply with legal requirements, especially if you work in a regulated field like medicine or banking.
Next, we gather data from users. One thing is the idea of how the system should look; another is how convenient it will be for ordinary users to use this system.
So, it’s very important to talk to users as well. We need to communicate with developers to understand whether we can implement all the wishes and fantasies of the client and how convenient it will be for users to use it.
We also need to know how long it will take to develop a particular functionality, and developers can help us with this information since they work directly on the code and how the system will function.
This is the first thing an analyst does when they come to work: they look at stakeholders to see if there are any new requirements or wishes, if something has changed, and whether they need to schedule any meetings.
After figuring out the stakeholders, the analyst begins to write requirements. Requirements come in several types, starting with business requirements.
Here we have an example of a non-existent system. A client or sponsor wants to create a hypothetical information system that allows users to exchange unwanted items. They want not only a backend and frontend—meaning databases and interfaces—but also to connect analytics to sell advertising on this portal so that users can donate to the project’s development, and so on.
All these wishes, without technical details and implementation specifics, will be business requirements. This is one of the most important parts of the job: to gather as detailed business requirements as possible from stakeholders to understand how to proceed with the project’s development.
In fact, a business system analyst spends about 50% of their time on this. The rest of the time is spent decomposing these business requirements into functional, user, and non-functional requirements.
I should note that we can’t decompose user requirements from business requirements into non-functional requirements, but we can decompose business requirements into functional requirements.
Functional requirements describe how the system should work. For example, we have a portal that allows users to register, create a personal account, upload a list of unwanted items, and press a button to publish that list so that other users can see it and choose something.
In this case, registration in a personal account and uploading the list of unwanted items are functional requirements because they describe the functions of the system. The system must have a registration function, an upload function, and so on.
After we describe the functional requirements, we outline user requirements, which detail how users can interact with the system. For instance, a user might provide contact details, such as an address where anyone can come to pick up unwanted items, or leave a phone number.
A user might also register as a legal entity, like a project helping the homeless, which collects unwanted items from one area and distributes them to those in need. All of this will be user requirements for different types of users, such as individuals and legal entities.
Non-functional requirements describe the conditions under which the system should function. For example, the system should operate 24 hours a day and be accessible on computers, laptops, iPhones, and Android phones.
These requirements describe the conditions under which the system will operate and are functional requirements. This is all described by the analyst, and writing requirements takes up about 90% of a system analyst's time.
I will pause here and clarify if there are any questions. If there are, please ask them in the chat, and I will definitely respond. If there are no questions, I will move on. If they arise, please don’t hesitate to write, and I will answer them when I see them in the chat.
Next, the analyst understands that they need requirements, and they must gather them. It’s not common for a client to come in and tell them everything.
The analyst has several options for gathering requirements. The most common and my favorite is interviews because the work of an analyst is built around communication, and proper interactivity is essential.
So, what we do is call the client or, if possible, the users and conduct interviews, asking all necessary questions. Usually, interviews last no more than an hour. If more time is needed, they are typically split into several meetings because after an hour of continuous talking, focus tends to wane.
Therefore, from personal experience, I recommend limiting interview time or taking breaks if it’s going to be a long session.
The second method is workshops, which are great when we have more than one client or need to gather a focus group of users to interview many people at once.
To save time, we bring them all together and conduct a large brainstorming session to see how a large number of people respond to the same questions, and from this discussion, we can derive truths that can later be turned into requirements.
The third method is correspondence. I don’t think I need to explain this; correspondence can include anything from questions to a free-form inquiry or a pre-prepared questionnaire sent out to be processed later.
Observation is another method. In my personal experience, this has occurred when working on projects related to factories. For instance, if we need to develop a system for a machine, we simply go and observe how it works, or we watch how an operator uses a program to manage orders in a queue.
We make observations and draw conclusions, which can help us recommend improvements or understand how our observations can be turned into requirements that will enhance the system or meet the client’s needs.
Analyzing documentation, operational logs, and bug reports is another very useful method for gathering requirements, but it’s not always available. Sometimes documentation is not maintained, or the system has not been documented, or the project has just started, and there is simply no documentation.
However, if there is documentation in the project, especially if it is reasonable, you can consider that half the work is done, and then you can verify how accurate the documentation is and work from there.
This is how we gather requirements.
Gennady has a question that is slightly off-topic: was the role of task setter the same as a system analyst?
I wouldn’t say so. A system analyst can set tasks for developers and write tickets in Jira, etc. However, I wouldn’t say it was the same role. In my previous job at a bank, we had a separate task setter who specifically looked at the requirements we gathered as analysts and recorded tasks for developers based on them.
This was necessary because we had a very high volume of requirements, and our analysts couldn’t keep up with the workload. There simply wasn’t enough time to communicate with stakeholders, write documents, and then build tasks simultaneously.
So, we had a dedicated person who entered everything into Jira or another tracker, and then developers worked on programming based on those tasks.
I hope I answered your question, Gennady. If not, please clarify, and we can continue the dialogue.
This is how we gather requirements, and they can look like this.
Before you is a standard technical specification, which is one of the forms that requirements can take. This is more suitable for waterfall methodologies, and in our age of Agile and flexible development methodologies, many might say it’s outdated.
However, I wouldn’t say it should be completely disregarded. Many, at least in my experience, government companies prefer to work with technical specifications, especially if you are working with standards. They are all tailored to such documents.
I believe there is now an opportunity to update technical specifications. We can add a table at the top detailing what changes have been made, so it becomes a living document rather than a stone-carved one.
Technical specifications are one of the forms that requirements gathered by the analyst can take.
Does anyone know what notation is depicted on the left and what the magic of yellow sticky notes is?
The fixation of requirements in the form of a dialogue between the client and the user and the system. When we use yellow sticky notes, sometimes we use physical sticky notes, and sometimes we use a virtual board.
What are your options for answers? Let’s figure it out. If there are no options, you can always write that there are none.
I just want to avoid leaving it hanging.
So, I will answer myself to keep things moving. On the left, we have a User Story, and I apologize for the confusion.
In a user scenario, we describe how the system will interact with the user. User scenarios are always written in the form of a dialogue between users and the system, and they help the developer understand how the functionality they are developing will work—what its behavior will be.
On the right, the yellow sticky note hints at user stories that describe functionality from a business perspective. For example, as a client, I want to press a button to get a certain result.
Describing user stories and user scenarios is also part of the system analyst's responsibilities, and you should be prepared to engage in this on a regular basis.
Once all the requirements are gathered, you need to move on to development tasks.
Here, we can return to Gennady’s question. Task setting is also part of the analyst's responsibilities, and part of it involves fixing requirements.
We also add artifacts, such as mockups.
If interfaces are involved in the project, the analyst will often need to engage in prototyping. If interfaces are not used, then prototyping may not be necessary.
If the client says they want a program or a portal where users should register, the analyst gathers requirements and quickly sketches an interface in a tool like Balsamiq or Figma, which is a bit more complex.
This will then be attached to the development task, and based on that, the designer will create a working prototype that we will show to the client.
So, besides writing, gathering requirements, communicating with stakeholders, and turning requirements into user stories and cases, the analyst should also possess some artistic skills and occasionally engage in prototyping.
Yuri, the magic of the yellow sticky note lies in the fact that when we want to break a large project into smaller parts, it’s very easy to use yellow sticky notes to divide project stages.
Each sticky note represents an epic, meaning each project stage we will work on over the next three months. Under each sticky note, we can write related user stories.
The magic is that everything is very visual; we understand where our project stands, we see the workload ahead of us, and we can estimate how much effort will be needed from the development team and how many meetings will be required with the client to implement our plan.
I hope I answered your question, Yuri. If not, please clarify, and I will return to answer again.
What else does the analyst do? We model business processes.
On the screen, you see BP notation, which may look a bit complicated at first glance, but it is one of the simplest and most understandable notations that is clear to everyone, including business representatives, developers, and all participants in the process.
We also teach this at OTUS. The analyst will have to engage in this, especially in the early stages of the process, where we need to define the business logic of the system and how it will work.
Next, we have architecture. We have progressed a bit deeper through our diagram, which I showed at the beginning. We have gone through all the stages of gathering and formalizing requirements in the form of user stories and cases and reached the architecture.
Who knows the difference between the two integrations on this slide?
While you think, I will answer Yuri’s question about why yellow sticky notes.
In the industry, this is a common concept. The sticky note can be any color; it doesn’t have to be yellow. Each sticky note represents a project stage.
For example, we might have a sticky note for registration, another for the personal account, and another for creating a list of items. Under each sticky note, we write the user stories related to that stage.
If we have a sticky note for registration, below it will be a user story like, "As a client, I want to be able to enter my login and password on the website to create a personal account," and so on.
This visually breaks down the project into stages.
Now, regarding the two integrations on the slide, at the top, we have Module A passing data to Module B, while below, Module B passes data to Module A.
It all depends on how the connections are indicated on the diagram. This is a rough architectural solution, and the analyst can participate in designing the architecture, with help from developers and architects if there is one on the project.
After we have dealt with stakeholders, gathered requirements, decomposed them, figured out the architecture, described tasks, and added any necessary mockups or interfaces, we pass the tasks to development.
After development, we naturally move on to testing and delivery to the client. As I mentioned earlier, testing usually involves the system analyst to some extent, but they do participate because they created the tasks for development and know best how the tasks should be tested.
The final result of development is a rough sketch of the interface, not the final design. We indicate at a high level what should be on the interface, what elements should be present, and then the designer will turn this into a working interface, coloring buttons and making it interactive.
So, the main task of the analyst is to understand the needs of the business and users and communicate them to the development team. If the development team has questions or misunderstandings, the analyst should strive to understand the concerns of the development team and, if related to the client, discuss it with the client to convey that it might be better to do it this way rather than that.
However, different situations arise. It’s important to remember that the analyst is a technical communicator, and it’s crucial for the analyst to ensure that understanding between the client and the technical development team is high.
Why? Because a mistake made during the requirements gathering stage can be very costly. If we misunderstand the requirements, fail to agree on them, and send them to development, someone might misinterpret something, resulting in the development of something entirely different.
This leads to a loss of time and money, and it can backfire on both the client and the analyst. Therefore, we check, recheck, and check again.
Do analysts need programming knowledge for their work? I would say no because analysts describe what needs to be done.
Programming languages and developer functions are implementation details. We don’t delve into how things should be done.
I know SQL, but I don’t consider it a programming language. I know a bit of Python, Java, and JavaScript. Why do I know them? Because it makes it easier for me to communicate with developers when they tell me something is impossible because a variable doesn’t work that way, and it would be costly to change it or modify a piece of code.
I understand what they are talking about because I have worked with it a bit, and we share the same vocabulary.
However, a system analyst can and should perform their job without knowledge of programming languages to be closer to the client rather than the development side.
The money comes from the client, and the client’s desires are, if not law, then certainly very important.
Yuri believes that programmers should always be kept on a tight leash. I don’t know; I prefer to befriend programmers. They often come up with good ideas, and if something might go wrong, they will also alert us in time due to their experience and deep immersion in the product.
So, I generally like programmers and clients and wish for everyone in the project to coexist peacefully.
Now, back to our original diagram. Do you have any questions about the diagram and what the analyst does in a project and at which stage of development they might be needed?
I’ll wait a minute and then continue.
Alexey asks if all this applies to system development. Can analysts also work in larger firms for scaling and optimization, for example, at a provider or a company with a large IT infrastructure?
Are there separate positions for analysts in such companies?
It seems that I don’t see a significant difference between a company that develops software from scratch and one that focuses on scaling and optimization.
At a high level, the process is the same: gather requirements, process them, and pass them to development.
The system analyst profession originated, I believe, in the 1940s in America, and it evolved from engineering. Engineers were closer to programmers, while analysts are like engineers who may not have a development background but still describe how the system will work.
In response to your question, it’s often an engineer who is closest to what an analyst does.
Gennady correctly pointed out that a system analyst is like a system engineer who understands the internal structure and client wishes. They may not always need to know how a specific element of the system works, but they always understand the information structure and so on.
So yes, Gennady, you understood correctly that a system analyst is an offshoot of a system engineer who has moved a bit into the humanitarian field and become closer to the client than to the system itself.
However, in the situations described by Alexey, a system analyst is still needed to turn internal organizational needs into specific requirements.
I don’t think a technical director should handle this because it seems too high a position for the routine work that system analysis entails.
A system administrator, as far as I remember, does not engage in system development. The only time they might be involved is if they need to lay out a network or improve the state of the computer park.
I have a vague understanding of how a system administrator might engage in system analysis.
I would say that among all the positions you mentioned, an engineer is the closest to what an analyst does.
If I haven’t fully answered your question, please clarify, and I will add more information.
Now, let’s move on to the next slide.
So, system business analysts are roles in a project team whose main responsibility is to work with stakeholders to identify, analyze, and specify requirements in a project.
It’s important to note that an analyst is always a role in a team. The team is crucial, as they work with stakeholders.
The main functions of an analyst include identifying, analyzing, specifying, and validating requirements, as well as communicating and documenting data in a form accessible to the development team.
A system analyst should possess certain qualities and competencies. Here, I used some anglicisms; I apologize in advance.
Soft skills are qualities that relate more to a person’s character and can be learned, but they are difficult to measure.
Hard skills are everything else—programming skills, knowledge of mathematics, knowledge of standards, and so on. These are skills that can be measured and can also be learned.
An analyst should be a team player and communicative because 90%—I’m exaggerating a bit here—of their time is spent writing requirements and communicating with stakeholders.
However, writing requirements does not happen in a vacuum; it involves constant discussions, verifying requirements with the development team, the client, and so on.
So yes, 90% of the time involves communication, a systematic approach, and critical thinking. When writing requirements, you need to understand how to control yourself, ask questions, and ensure you are describing things correctly.
Management skills are also important because once we describe the requirements, we need to evaluate them and communicate with the client about whether we will meet deadlines. If we won’t, we need to figure out how to adjust the requirements to fit the development timeline.
The ability to explain things clearly is essential, especially when the client wants something impossible or when the development team cannot agree with the client’s wishes.
The ability to visualize is also important because sometimes a picture conveys more than three pages of text.
Naturally, knowledge of the subject area will help us gather requirements and understand user needs.
That covers our soft skills.
Hard skills involve working with documents, knowledge of technical details, and overall erudition, patience, and experience that accumulates over the years.
I should also mention that currently, especially for junior positions, knowledge of SQL is often requested. This is one of the most popular requests for junior positions, followed by system analysis and the ability to work with stakeholders and requirements.
All these skills can be developed over time to a sufficient level so that being an analyst brings you 100% satisfaction rather than stress.
Diana asks about career growth prospects for analysts.
The prospects are very bright. You can develop vertically or horizontally. Vertically, you can become a middle-level analyst, then a senior analyst, then head of the analytics and documentation department in a company, and move more into managerial roles.
You can transition to architecture roles, which are also related to development. There are options to move from a system analyst to a data analyst, which is a bit closer to development and less focused on management.
You can also move into product management, project management, and so on. The part of analysis that involves client communication tends to lean in that direction.
I know analysts who have transitioned to technical writing, but I wouldn’t say that’s the pinnacle of a career. It’s more of a downshift, not to offend technical writers, as I worked as one for five years.
However, technical writing is a much calmer job with less uncertainty.
So, if an analyst wants to transition to technical writing, why not?
The work of a system analyst is not contraindicated for introverts. An introvert can work as a system analyst if they are not afraid to ask questions.
A system analyst does not need to entertain everyone around them constantly. However, they need to be bold and assertive enough to work with stakeholders who may not want to communicate.
So, I would say an analyst should be an ambivert—not a super extrovert, as they need to listen, but not a super introvert either, as they need to be unafraid to ask questions.
Now, let’s talk about tools. Tools are what an analyst can learn.
We will repeat the options for gathering requirements: interviews, workshops, observation, documentation analysis, requirement descriptions, technical specifications, use cases, various modeling notations like BPMN, activity diagrams, and so on.
These diagrams describe integration options, system architecture, and so forth.
Jira is used for backlog tasks, and Gherkin is used for acceptance tests, which is just a template for describing tests according to a specific algorithm. There’s nothing complicated about it.
Documentation according to GOST 1734—I must admit I’m not strong in GOST because it’s a separate field of system analysis—but it can be learned if desired.
These are hard skills, and we teach most of this, except for GOST documentation and Gherkin, which we cover only superficially in our system analysis course.
So, what is the value of a system analyst? In rough terms, they bridge the gap between business and development, linking business needs with development.
This is, of course, a very rough outline. In reality, the team with an analyst makes the project more structured and eases the lives of both the client and the technical development team.
There is much less uncertainty and more confidence in what product is being developed. Why? Because when there is an analyst on the team, the requirements are clearly defined, and the client knows when they will receive the finished product.
The development team knows exactly what they need to do, and testers know how everything should be tested.
Everything works much more smoothly without any unpleasant surprises or situations. The uncertainty is replaced with satisfaction for both the client and the development team, which benefits everyone.
Let’s try again: if you have any questions, please put a plus or ask your question directly. If there are no questions, put a minus, and we will move on to the next part.
I see a minus in the chat. If any questions arise, please write them, and I will take another pause at the end to answer them.
Now, let’s get acquainted with the course team and program.
Let’s talk a bit about the learning process at OTUS.
I will pause to answer a question: what level of English is needed? It depends on where you plan to work. If you are working outside of Russian-speaking countries, I say Russian-speaking because it can include Belarus, Russia, Kazakhstan, Tajikistan, and so on, where Russian is used, then English is not necessary.
If you plan to work with foreign partners, clients, or in Europe or America, then naturally, it is needed.
I live and work in Europe, and my English is almost at a C2 level. So, it depends on the project. If you work outside of Russian-speaking countries, then English is certainly needed.
Now, back to our slide about the learning process.
At OTUS, the learning process is structured in the form of webinars, which are held in the evenings or on weekends, but more often on weekdays in the evenings at 8 PM Moscow time.
There are usually two webinars a week, and there are separate consultations for basic students with mentors. During consultations, you can discuss anything you didn’t understand, ask questions about homework, and so on.
All recordings and materials provided by instructors will remain available in your personal account even after the course ends. The chats we add you to for asking questions about homework or course materials will also stay with you.
We have homework assignments, which are checked by mentors and instructors who provide feedback. At the end of the course, there is a course project, which is essentially made up of all the homework completed during the course and can later be used as a portfolio.
Throughout the learning process, you will receive support from instructors and mentors, and you can always ask questions, and they will respond.
The time commitment for the course is four academic hours per session, totaling 48 hours for the course, plus homework.
Why 4-8 hours? Because homework varies in complexity; some take more time, while others take less.
The course curriculum is updated with each launch based on current demands in the IT field.
I will reiterate that all our instructors are active analysts working on real projects, not just theoretical instructors.
So please come and share experiences with colleagues; we are always happy to welcome you.
Now, let’s take a moment to review the system analyst program.
Can you please confirm if you can see the screen? Put a plus in the chat if the screen is visible.
I don’t see any pluses. I will ask again to put a plus in the chat.
Okay, thank you very much, Diana.
The system analyst ADV course is for those who are just entering the field of analysis. It is designed for people who are interested in mastering the profession of system analysis, providing a complete immersion in the software development process with a focus on system and business analysis.
Our instructor is Valery Lvov. If you want to know more about the instructor, I recommend checking out the OTUS channel, where you can find several of his lectures on various aspects of system analysis.
You can also find information about other instructors on the same page. Overall, the course is excellent because it is designed for unprepared individuals who want to learn everything from scratch.
The information is provided gradually, and I will send a link in the chat.
Next, we have the basic and advanced system analyst courses.
What distinguishes them? The advanced course is for analysts looking to enhance their qualifications or for those already working in IT.
Often, developers come to us for this course.
The advanced course is a bit more complex, starting with the basics of analysis, how to gather requirements, document them, and so on. Then we move on to more complex topics, as you can see on the screen, covering various technical aspects, how to describe APIs, a bit about data analysis, and so on.
The course developers are working professionals, and you can see them listed at the bottom of the page.
If you are interested, we also have lectures available on the OTUS channel.
So, please come and learn with us.
Now, let’s return to our presentation and discuss career information—what to expect for analysts in the near future and the current market situation.
In November, there are about 2,000 vacancies for mid-level system analysts in Russia and 2,200 for senior positions across the country. So, there are job opportunities available.
Employer requirements for system analysts include technical documentation preparation, project support, the ability to formulate clear thoughts, model, and test.
Knowledge of system analysis, web technologies, basic SQL, and development principles, as well as some data analysis, is also important.
I will repeat what I mentioned earlier: for some unknown reason, there is a high demand for SQL knowledge for these positions.
So, if you want to increase your chances, it would be beneficial to brush up on SQL, as it may draw attention to your resume faster than that of a competitor.
Here we see salary expectations, ranging from 81,000 to 237,000 rubles per month, with a median of 170,000 rubles.
We can also look at what types of vacancies are available.
Here we have an analyst position that is likely closer to senior level, judging by the required experience.
As we can see, the role involves gathering and analyzing requirements, describing business processes, and not many technical requests.
The only thing that might be missing is that there are mostly soft skills required, such as conducting interviews and gathering requirements.
This is a mid-level analyst position.
Here we see a more technical profession, which requires understanding how APIs work, knowledge of SQL, and experience with databases and data analysis.
This is the type of analyst I am—between a system analyst and a data analyst, with a significant amount of technical elements involved.
However, in principle, everything starts with formalizing and writing processes, gathering requirements, and detailing them.
Technical requests come later, such as the ability to read and understand SQL.
You can find various vacancies from employers on the Headhunter website, as they are sourced from there.
Now, let’s move on to our final slide for reflection.
The goals of the webinar were as follows: what functions does a system analyst perform? I think we have clarified that.
A system analyst is a communicator between the business and the client, helping clients better understand their requirements.
They help the development team better understand client needs. The analyst earns their salary directly from this activity—gathering data and requests from the client and turning them into requirements.
They assist with testing, support the team, and the most important functions for a system analyst include communication, the ability to ask questions, knowledge of the subject area, and technical skills like SQL.
We have clarified the goals of the webinar.
On this slide, we essentially repeat what I just said. If anyone has any questions or wants to add something, please feel free to do so.
If there are no questions, we will continue to wrap up our webinar today.
I don’t see any questions in the chat. If they arise, please write them down; there is still time, and I will be able to answer them.
The start of the system analyst specialization course is on November 28.
The next open lesson, which I will not be conducting, will be on November 21. Please come to chat and listen to a colleague who will share more knowledge from the field of system analysis.
I will send a link to a feedback survey in the chat. Your feedback is very important and helps us improve materials and make webinars and classes more engaging, interesting, and understandable.
I would greatly appreciate it if you could leave your feedback.
That’s all for today. Thank you all for coming, and I hope to see you in the OTUS courses. Goodbye, everyone!