System analyst 100 lvl – development roadmap
Must-have skills for a systems analyst
Points 1–3 are the basis that all system analysts, including junior specialists, should have.
1. Methods of working with requirements and documentation skills
Let's start with fundamental knowledge. Any systems analyst – not only in the IT industry, but also in any other field – must be able to collect and identify requirements, bring them into a single form, decompose and classify data, detail requirements, determine quality criteria, prioritize tasks and document all customer wishes so that the team can correctly understand and implement them. Actually, this is precisely the work of a systems analyst: to process a set of input data, conduct an in-depth analysis and “translate” the requirements from the language of business into the language of performers, in particular developers. When the product is not yet in sight, the systems analyst must imagine in detail how this product will work.
Here we can recall the American management consultant William Deming, who argued that every specialist should have a system of in-depth knowledge, understand the general theory of systems and the theory of variability.
Anyone who wants to develop in the profession should have this foundation and well-developed systems thinking.
2. Modeling and design of processes and systems
Another block of basic knowledge for an analyst of any level concerns methods and tools for requirements modeling.
What everyone needs to know:
fundamentals of analysis and modeling of processes and systems;
hierarchy of models, methods for identifying, analyzing and documenting the state of the system As Is and To Be;
process modeling using flowcharts;
description of processes and systems in UML notation: state diagrams, sequences, classes, activities and use cases;
features of the implementation of web, desktop and mobile applications, cross-platform development.
What would be good to know:
modeling of business processes in BPMN (Business Process Model and Notation) notation;
advanced knowledge of BPMN and UML notation;
other notations, standards and frameworks: IDEF0, IDEF3, EPC, DMN, VAD, SIPOC, BABOK, etc.;
application of component and deployment diagrams.
3. Working with databases
This block of knowledge includes:
main types of databases – relational, object-relational, non-relational, columnar, text, as well as popular database management systems (DBMS) for each type;
structured, unstructured and semi-structured data;
Query languages - SQL;
theory of relational database design;
rules for designing non-relational databases;
for Senior level and above – object-relational mapping (ORM);
approaches to data migration – “extract, transform, load” (Extract, Transform, Load, ETL);
data marts, OLAP systems, design of data warehouses, data marts and reporting forms.
First of all, any systems analyst must be able to write simple SQL queries in order to understand which tables are used and what data is stored in them. Why is this important? Input documentation is often not entirely up-to-date, and we need to understand how the system works at the moment. This skill may not be needed on every project, but everyone needs to have it in their arsenal. True, depending on the system used, analysts can use other tools to understand the current state of the system, including logging, APIs, or specialized analytical systems.
At the entry level, it is enough to master relational databases, at the middle level – to know the varieties of NoSQL, and seniors should not only understand how different types of databases differ and how exactly data structures are processed and stored in them, but also be able to choose an approach and design complex solutions.
Now we move on to more advanced competencies.
4. Architecture
What you need to know:
main types of architectures and their features: local, monolithic, client/server/database, service-oriented and microservice architecture;
architectural patterns: client-server, multi-tier, mediator pattern, Model–View–Controller pattern;
“choreography” and “orchestration” patterns;
CAP theorem, also known as Brewer's theorem;
for Senior level and above – event-driven architecture, including event sourcing and Command Query Responsibility Segregation (CQRS);
the Component-Connector-Container model and the C4 approach by Simon Brown;
basic frameworks for describing software architecture: 4+1 and, optionally, TOGAF;
basics of building enterprise architecture in Archimate.
At all levels, the analyst must understand the basic architectural components. Distinguish between synchronous and asynchronous requests, develop design skills to isolate microservices, have sufficient knowledge to read architectural diagrams for subsequent solution specification.
Deeper knowledge is necessary for seniors who interact more with architects at the decision-making stage. A senior analyst must understand that the logic of the application being developed will be built depending on the architecture.
5. Integrations
This block of knowledge includes:
types of information system integrations: API, data bus – ESB/MOM/MQ, common database, file exchange;
pull and push models;
web services and webhooks;
synchronous and asynchronous interactions;
system integration protocols and interfaces: SOAP, JSON:API, GraphQL, gRPC, as well as APIs of native libraries, which are often used when integrating with software libraries or services that work locally and not over the network;
a general understanding of data formats and methods of describing them: JSON, YAML, WSDL, XML, XSD and others;
JSON and XML syntax basics;
HTTP protocol;
API documentation and testing tools: Postman, Swagger, SoapUI, cURL, as well as popular cloud platforms for API management such as Apigee;
principles of REST architecture and REST API;
Data Flow Diagram (DFD), which can be complemented by Sequence Diagrams, for a more detailed representation of data flows in synchronous and asynchronous interactions.
When developing integration, it is necessary to show how architectural components interact with each other, including what types of data are transferred and what integration protocols are used. It’s also time for Junior specialists to start studying integration issues, accumulating practical experience and skills at the Middle level. And Senior analysts must calmly navigate the topic and understand in which case what kind of integration is needed, and also take into account the various functional requirements of the customer, which can have a significant impact on the decisions made.
6. Basics of information security
It is now quite obvious that every person should have a basic understanding of information security, and even more so everyone who works in the IT field. Even junior analysts must have an understanding of the basic authentication schemes and protocols: basic authentication, digital certificate, key authentication, OpenID/OAuth, JSON Web Tokens, etc. If we are talking about a junior who gets a job in a company after university with specialized education, most likely he already knows all this. If we are talking about a person who got into IT from another industry, then he may have to study all these issues separately. The main thing is that the system analyst understands the basics: the main vulnerabilities and methods of compromising information, methods of authentication and authorization.
By the way, authentication and authorization are often confused. From my experience conducting interviews, I will say that not even every Senior Analyst understands how these concepts differ and how it all works in detail. If at the initial level it is enough to know the basic concepts of access control, role policy and use standard approaches and tools, then the senior must have more extensive knowledge, including studying what data encryption mechanisms exist and how their choice affects the solution being developed. In other words, not only understand the tasks of ensuring information security, but also be able to correctly design all this for each specific case, if necessary, turning to narrow specialists in this field if the customer places high demands on the level of protection.
7. UX/UI Basics
Design is a non-core area of knowledge for a systems analyst, but basic skills in this area will not be superfluous for specialists of any level. It is enough for entry-level juniors and mids to understand that for a solution it is necessary to define a set of layouts, that it is built in accordance with the customer journey (Customer Journey Map, CJM) and that there are generally accepted guidelines and rules for building interfaces in the industry. The ability to read the customer journey helps system analysts better define functional requirements for the system and take into account use cases, determining how and at what stage the user interacts with the system.
Often minor changes to interfaces are required, and an analyst can handle this task without a UX/UI specialist if he masters the basic tools and principles.
8. Software Development Life Cycle Fundamentals
The “older” a specialist is, the more of his responsibilities can be attributed to management and monitoring the execution of tasks. A middle analyst must understand which methodology – Waterfall, RUP, Scrum, Kanban, Lean, FDD, XP, etc. etc. – his team works, and build communication based on this. A senior specialist must have a deep knowledge of industry standards regarding the software development life cycle, types of project documentation, features of the use of various development methodologies and configuration and change management (Git version control system, CI/CD pipeline). And also understand which approach will be most effective for a particular project, and participate in its selection. All this helps to establish effective communication between different members of the IT team.
9. Software Testing Basics
Another non-core, but important area of knowledge for a systems analyst. These areas related to the analyst – design, development and testing – are good if the team leader cultivates T-shaped specialists in his team who are deeply versed in one area, but at the same time have knowledge, competencies and soft skills in other areas. Fundamentals of design, development, and testing help the systems analyst better and more clearly provide colleagues with the information they need to do their jobs well.
What is important to know:
features of testing at various stages of the project life cycle;
various types and tools of testing;
testing functional and non-functional requirements;
management of software quality criteria;
defect management and the role of the analyst in this process.
10. Object-oriented approach
This block of knowledge includes:
object approach – basic definitions, objects and their relationships, classes, instances, attributes, functions and events;
principles of object-oriented programming: abstraction, encapsulation, modularity, hierarchy, inheritance and polymorphism;
object-oriented analysis and design.
Understanding the object-oriented approach helps any level of analyst structure requirements even under conditions of high uncertainty. In addition, this approach allows you to set a task for an object-oriented programming language without additional effort, which contributes to the efficient work of the analyst and developer. The object-oriented approach is the basis for building a solution of any complexity.
As a “translator” from the language of business to the language of performers, a systems analyst must be able to speak the same language as designers, programmers and testers, despite the fact that each of them lives in his own world and they do not always understand each other.
Reference Systems Analyst Competency Map
So that all the competencies listed above can be assessed at a glance, we have created a special diagram – the Systems Analyst Competency Map.
You can download and save this map for yourself in PDF format follow the link.
How to develop as a systems analyst: certification and bottlenecks on the Competency Map
Certification can give you an understanding of what competencies you are lacking. This is a useful thing: as I already said, often specialists themselves do not realize where they are “swimming”. Certification is an effective tool for assessing and improving professional skills. It helps to adapt to new conditions and challenges by identifying areas of expertise necessary for development.
In 2023, we launched a domestic certification for systems analysts. There were several reasons for the start of the program. Firstly, the IBS Training Center has formed a theoretical basis for improving the qualifications of system analysts and there are expert practitioners involved in training specialists. Secondly, we have been preparing for certification from Western vendors for a long time. And thirdly, over the past two years, most foreign companies have left Russia, and it has become difficult to pass an independent competency assessment. However, employers and specialists themselves still have a request for this.
The IBS Certification Center has several levels of system analyst certification: “Basic”, “Specialist” and “Professional” (in development). Before deciding on the level of certification, you can take a free test and find out in 30 minutes which exam is relevant at the moment. Certification takes place every two weeks in online and offline format. The certification result becomes known immediately: the specialist is given statistics on how well he knows the topics included in the test. Each certification level has a different test length, number of questions, and passing score.
I collected statistics on certification of IBS employees at the “Basic” and “Specialist” levels over the past year and received the following picture.
Level “Basic”
Aimed at beginners. The passing score here is 70. At the same time, the average score of those passing the “Basic” level is 68.5. Topics from the Competency Map in which specialists score the least: “Object-oriented approach” (average score – 57) and “Modeling and design of processes and systems” (average score – 62). This may be due to the fact that systems analysts often focus on analyzing requirements and the relationship between business processes and IT systems, rather than on a deep understanding of the technical details of programming or design. Their education may have focused on other aspects of information systems, and they have not received much knowledge of object-oriented approaches or modeling. In addition, new professionals may not have enough practical experience to help them better understand and apply these concepts.
Level “Specialist”
Designed for practicing professionals. To pass certification at this level, you need to score a minimum of 75 points, with the average score of those passing being 72.92. In our experience, it is more difficult for specialists to pass the “Basic” level certification. Perhaps this is due to the fact that it is taken by novice specialists who have an insufficient level of observation and practical experience.
As for the weak topics at the “Specialist” level, these are “Modeling and design of processes and systems” (average score – 64), “Fundamentals of UX / UI” (average score – 65) and “Fundamentals of information security” (average score – 68 ).
What to do after certification?
If you are a systems analyst, pay attention to the competencies with the lowest scores. As practice shows, when drawing up individual development and training plans, these skills are given less time and attention than they deserve.
What granites should you chew to become a systems analysis guru?
I will share a list of resources that we usually provide to our employees along with the certification results:
“Body of Knowledge on Business Process Management: BPM CBOK 3.0” ed. A. A. Belaichuk and V. G. Eliferov;
“BABOK.” A Guide to the Business Analysis Body of Knowledge;
Documentation of the BPMN Notation Standard Development Organization from the Object Management Group;
Craig Larman “Using UML 2.0 and Design Patterns”;
James Rambo, M. Blaha “UML 2.0. Object-oriented modeling and development”;
Martin Fowler “Enterprise Software Application Architecture”;
Bobby Wolf, Gregor Hop “Enterprise Application Integration Patterns”;
Sam Kaner, Jack Faulk, Yong Kek Nguyen “Software Testing. Fundamental concepts of business application management”;
Karl Wiegers “Software Requirements Engineering”;
Alistair Coburn “Modern methods for describing functional requirements for systems”;
Jeff Patton User Stories. The Art of Agile Software Development”;
Daniel Rosenberg “UX Magic”;
Sergey Konstantinov “API Design”;
“OpenAPI 3.0. Specification”;
Jim R. Wilson, Eric Redmond “Seven Databases in Seven Weeks”;
Jim Arlow, Isla Neustadt “UML 2 and the Unified Process”;
“ISO/IEC/IEEE 42010: Defining “architecture””;
Ron Patton “Software Testing”;
Federal Law of July 27, 2006 No. 149-FZ “On information, information technologies and information protection”;
“ISO/IEC IS 27001:2013 Information technology. Security techniques. Information security management systems. Requirements”;
Ilya Kornipaev “Requirements for software: recommendations for collection and documentation”;
Dean Laffingwell, Don Widrig “Principles of working with software requirements. Unified approach”;
John Jablonski “The Laws of UX Design”;
Brian Cooksey “Introduction to API”;
Designing Web APIs by Laure Arnault;
Jim Kalbacha “The Jobs To Be Done PlayBook”;
Joshua Ponelat, Lucas Rosenstock “Designing APIs with Swagger and OpenAPI”;
Ildar Khabibullin “XML Self-Tutorial”;
Valery Bondarev “Introduction to information security
automated systems”;
Chris Richardson Microservices. Development and refactoring patterns”;
Baron Schwartz, Vadim Tkachenko, Petr Zaitsev “MySQL to the maximum”;
Thomas Connolly, Caroline Begg “Databases”.
Conclusion
Of course, our statistics do not mean that every systems analyst lacks these competencies. But this “average temperature” still shows certain patterns, which are confirmed by individual examples.
Consider different ways to deepen your knowledge on these topics: perhaps take a course, seek mentorship from experienced colleagues, or study on your own on a topic that interests you. You can choose several paths at the same time – the main thing is to start taking action.
