personal<IT>y: "Analysis is not a document, but a process," says the analyst about finding needs, use cases and how a functional system is created from business requirements

Three worlds of analysis: business, data, and software

What does your job as an analyst actually look like?

Well, if I simplify it, I do analysis of software solutions, often custom-built systems. A customer comes with some vision, or at least an idea of what they would like. And then we transform that into a functional system. It’s mainly about communication. We talk a lot with the customer, trying to understand what they need, what will help them.

And then, together with the architect and programmers, we put together the solution design. During development, we consult things with the client so that the result—the final product—is not just something they have to use, but something that genuinely helps them.

Do you think people even know what you do?

Honestly? Most don’t. Most people think I just sit at a computer and type something. Even when I tell someone that I’m an analyst, the first reaction is often: “And what is that?” Most people can’t really imagine it.

Can analyses be divided in some way? Are there different types?

Definitely yes. There are several ways to divide them, but from my experience I most often encounter three types: business analysis, data analysis, and software analysis.

Business analysis is about going to the customer, looking at how their processes work, what their business looks like. Usually there is already some problem—something doesn’t work, something needs to be made more efficient. So you try to understand where the bottleneck is and propose a solution, whether it’s an adjustment of processes or the design of a system that will support it all.

Then there are data analysts—that’s a different league. I’ve never worked with data at that level of depth. A data analyst deals, for example, with data migration; they have to understand how data was structured before in order to transfer it correctly into a new system.

And then what I do is software analysis. I get business requirements from the customer and then transform them into functional and non-functional requirements. I design functionalities, sketch screens, specify system behavior. It’s already more technical, closer to the actual development.

So when we talk about “business,” we mean its processes, operations, and how things actually work?

Exactly. In our jargon, we call these “business processes,” meaning how a company has its operations set up. And when a problem appears, we address it. Either something is adjusted, or we design a completely new system.

From testing to analysis

How did you actually get into the job of an IT analyst?

I started as a tester-consultant. I studied at the University of Žilina, majoring in management information systems. We did some designs there, mainly database-related, but rather marginally. Overall, it was more focused on transport and logistics, not directly on software development.

My first job position was tester-consultant. That’s where I started learning all the basic things—how applications are tested, how user manuals are written, and so on. It was good for getting started. And there I had a colleague who gradually started pulling me toward analysis. At first, I helped him on projects as a junior analyst; later, I already had my own.

So it kind of “pulled you in” to the world of analysis?

Exactly. It wasn’t really that I explicitly said to myself, “I want to be an analyst.” It just naturally evolved. But I didn’t resist it at all—quite the opposite. I enjoyed it. I like that moment when a project starts. Because we do custom-built systems, every assignment is completely different—always a new world, a new topic. You’re constantly learning something new. And that feeling at the end, when you see the result, when what we created actually helps someone—that’s what I really enjoy about it.

How did that transformation from tester to analyst happen?

At first, I helped with various outputs that the lead analyst needed—documentation, workshop outputs, specifications. Gradually, he started giving me more space. And when the first project came where he told me, “Try to lead this yourself,” I went for it. I started preparing assignments for programmers on my own, consulting with the customer, discussing designs with developers… and suddenly I realized that it felt natural to me. I didn’t have a problem communicating, asking questions, connecting the dots. And that’s how it all gradually came together.

Did any skills transfer from testing into analytical work?

Definitely yes. Although sometimes it’s rather the other way around—when, as an analyst, I tested some parts of the system, I couldn’t always fully distance myself. I already knew how it was supposed to work, and as a result, I might not have tested it with a completely fresh perspective. But on the other hand, a tester also needs a certain analytical approach. When a problem appears, they have to break it down, understand where it arises, what is happening. They need to understand the system, know how individual parts work, and then be able to explain it to a programmer—in an ideal case in such a way that they already have an idea of where to look for the bug or what to fix.

So you work closely with programmers?

I work with everyone. Basically with the whole team—from the project manager, with whom we prepare the offer and estimates of complexity and effort at the beginning, all the way to testers and consultants who handle outputs at the end of the project. The software architect—the “designer,” as we call them—is also important. When I have a solution design, I discuss it with them. They tell me whether it’s technically feasible, whether there are any limitations, or they might suggest a better approach. This already happens during the project, but we’re in constant contact with the team.

Then, of course, I communicate with testers and consultants. When they find a problem during testing, we address whether it’s a bug or a misunderstanding of functionality, and whether something needs to be adjusted. And if something is unclear in the materials, we can discuss it right away. And last but not least, the customer. We keep them in mind throughout the entire project. And programmers? There it’s about clear assignments. When something is well prepared, development goes more smoothly too.

What analysis contains

Do you also write those “analytical tomes” with several hundred pages?

Of course. That’s already a classic.

And how much text have you produced by now? That must be thousands of pages.

Ugh, since 2006 I’ve worked on a really large number of projects. I can’t even say how many, but certainly hundreds. The bigger contracts—that’s where it’s really a massive amount of documentation. 400 pages? Completely normal. But everything depends on the size of the project. If it’s a small project, then of course you don’t produce two hundred pages of documentation. Sometimes it’s just a smaller change in the system, something minor that needs to be added. But when it’s a large solution or a system for a large company, then yes, it can go into the hundreds of pages.

And user manuals? Do you write those too?

Yes, user manuals as well. And those can also be quite extensive—it depends on how robust the system is. Sometimes it’s just a simple portal where something is searched or recorded. Other times, you have a large system with many functionalities, an internal and a public part, and then the documentation really balloons.

How would you divide projects by complexity?

There are about three categories. First are the very small changes—when the system already exists and only something minor is adjusted. Then there are smaller projects, like simple registries or portals that display something, allow searching, or possibly store some data. And then there are the big, robust systems, often for large companies.

Is there even something like a typical working day for an analyst?

No, probably not. It really depends a lot on which phase of the project I’m currently in.

How good analysis is created

And what does such a beginning look like—the first meetings with the customer?

Either we already have some input materials available—documentation, an order, or at least a description of what the customer needs—or we’re only just working it out. It usually starts with a conversation. We ask questions, try to understand things, break the project down into smaller parts, depending on how robust the system will be. And the customer tells us what they need, how it works for them.

And who usually communicates on behalf of the customer?

It should be someone who knows the process well—a “business owner” or someone from operations. Sometimes it’s one person, sometimes several; it depends on the scope. For example, in one project, everything was overseen by a single person who was also able to explain it internally to their colleagues in their “language.” In that case, communication is much easier.

Does it happen that during analysis you discover things the customer themselves didn’t realize before?

Definitely yes. Sometimes during analysis we come across “bottlenecks” that they weren’t even aware of themselves. For example, during the migration of meters we found out that if a large number of requests are sent at once, their internal system can’t keep up. So we adapted it on our side—we changed the way we send requests so that it wouldn’t get overloaded. They didn’t have to change their whole process; it was enough that we were able to adapt it on our side.

Which parts of the analysis are the most essential?

The foundation is the business requirements—what the system should be able to do. These are divided into functional and non-functional requirements. Functional means specific functionality the system must provide, for example “the user can create a request.” Non-functional are technical or operational, for example that the system should be responsive, secure, scalable, or available 24/7.

How is it worked out further?

Each functional requirement should be covered by some “use case.” These describe what the system should do, who uses it, what the action flow is. Then we prepare screen prototypes—what the user interface will look like. These are more technical drafts for the team, showing which elements, buttons, and inputs will be where. It’s not the final design for the customer yet, but it serves as a basis for further communication with both the team and the customer.

And what else do you describe?

Also how the system will process a specific process—for example how an order or an invoice is processed, what states it can have, how they change. For that we also create state diagrams, entities, domain models, and then already detailed assignments for programmers.

Assignments for programmers? What should we imagine under that?

Those are specifications of what a particular functionality should do, how it should behave. So that developers know what and how they should program, what the limits are, what must be followed. Without a well-prepared assignment it wouldn’t work—it’s basically the bridge between what the business wants and what development creates.

Which part of your work do you find the most challenging?

At the beginning, understanding what the customer actually wants. Correctly identifying the requirements. The less we understand each other, the more problems can arise later. And the customer often can’t say exactly what they need—they only know what result they want. My job is to understand what has to happen in the system for them to get that result.

Is there any part of the work you would describe as easy?

Hard to say. In my opinion, it’s about how you approach it. If you tell yourself in advance that it’s complicated or that you can’t do it, then it will feel demanding. But when you break it down, analyze it, and gradually “work your way through it,” it can be managed. It’s not that something is completely easy—rather, it’s that you enjoy some things more.

Are you part of the project even after implementation?

Yes, on the projects I work on, I’m involved from the beginning all the way to deployment. It’s possible that on larger projects an analyst has only one role—they do the analysis, hand it over, and then return to it only if there’s a problem. But with us, it’s like this: we’re there through the whole thing until the end.

Analysis as a living process

So analysis doesn’t live “a life of its own”—you’re still with it?

Analysis isn’t just a document that gets sent somewhere and then forgotten. It’s a process that continues, is discussed, adjusted, adapted to reality. And the analyst is part of it up to the moment the system actually works. So it never completely “lives a life of its own.” Even when a project is closed, you can still return to it—for example when a request for change, adjustment, or a fix comes in.

Changes are usually implemented based on the original materials. It doesn’t have to be the same analyst who created them, but it’s important that the documentation is high-quality and understandable even for someone else, in case the analyst leaves the project or leaves the company. Continuity is key. Changes that impact functionality must also be reflected back into the documentation. Analysis as such therefore remains part of the project throughout its entire life cycle.

What do you think are the ideal skills for a good analyst?

Communication is the foundation. Then analytical thinking, the ability to ask why things work the way they do. And definitely a feel for language too—being able to explain and write things clearly, so they carry meaning and are well-structured even for others.

Does it happen that someone misunderstands what analysis is?

Sometimes yes. We use various standards, languages, and notations like UML or BPMN. And sometimes it happens that when someone uses more complex elements, the diagram can seem incomprehensible to the customer.

That’s why we always add a textual description as well—an explanation of how the process works. The goal is that the customer can connect the scheme with reality. If they process it together—text and diagram—they should understand what it’s about.

So BPMN is a modelling language?

Yes. BPMN is used by analysts and software architects to describe processes. UML is used more to describe functionality, for example through “use cases.” These models enable everyone—analysts, architects, programmers—to “speak the same language.” Based on them, the system can then be programmed.

Are there any myths about the work of an analyst, in your opinion?

I think ordinary people often have no idea what we do. Sometimes they confuse us with data analysts—they imagine we just sit in spreadsheets and calculate. Or they think we’re just consultants who sit in meetings and talk. Even between companies there are differences in terminology; somewhere the same role is called a “business analyst,” or a “consultant,” or a “process specialist.” So if you compare job descriptions in different companies, you find that there isn’t one universal standard.

Analysis even outside of work

Do you sometimes take things home with you, in your head?

Yes, sometimes that happens. When I have something in progress, I think about it at home too. I tell myself: “Tomorrow I have to write that down.” Or something becomes clearer to me when I’m doing a completely different activity. But it’s not like I’m dealing with work nonstop. More in those phases when something is starting up, when I need to get oriented, understand connections, prepare for a meeting with the customer. That’s when it “grinds” more in my head.

And how do you relax?

By sleeping. When I can. But with kids it’s not always easy. Kids are the priority, and when I’m with them, I try to be fully present, not overdo it with work, not mix it in.

Does your work affect parenting? Can you fully “switch off”?

Probably not completely. Sometimes it happens that with school homework—especially math—I start analysing things too much. The child looks at it and just solves it straight away. I’m already thinking about what the author of the task wanted to say. And that’s not always an advantage. Maybe it’s how I think. I try to solve things, understand why a problem happened, what’s behind it—even at home, in everyday situations. But there it’s more like “emotional analysis.” Sometimes, though, it’s better to just pause things and not go into depth right away.

And where do you find the greatest satisfaction in your work?

Probably in the fact that it all works. When the team understands each other, when communication flows naturally, there’s no tension. That’s a big plus. Sometimes the documents are long—300-page outputs—but if the team atmosphere is good, it’s easier. And then, of course, feedback from the customer is nice too—when they say they’re satisfied, that what we prepared makes sense to them. That’s a small “win.” Even if the document isn’t finally approved yet and more adjustments await us, it’s a moment when you think, okay, we’re on the right track.

So satisfaction comes even earlier than after deployment?

Definitely. I don’t have to wait for the final signature to tell myself I feel good about it. For example, when I put together a document that is clear, understandable, has a head and a tail, and we’re just fine-tuning it. Then I feel like I’m done. Even though I know comments will still come, it’s an important milestone for me.

What would you recommend to someone who wants to become an analyst? What should they know?

It’s definitely important to have domain knowledge, to know modeling languages like UML, to be able to read and create process diagrams. And then, very importantly, to ask questions. Why does it work like this? How does it work? And what does the customer actually mean by that?

What motivates you?

Because I do analysis for custom-built information systems, I get into different areas—each project is a bit different. You get to know different worlds. For example, I learned how the magazine ordering system at the post office works, or how those display cases are distributed—where there are books, toys, and similar things. Maybe I won’t use it in everyday life, but I enjoy it—suddenly I know something I didn’t know before.

And do you use analytical thinking in everyday life too?

I guess yes, but not intentionally. When we’re renovating at home or planning something, I naturally compare prices, make lists, weigh options. But lots of people do that, not just analysts. I’m not recording it in a database yet (laughs).

What stereotypes exist about analysts?

Well, they’re not as strong as the ones about programmers in plaid shirts. But yes, sometimes people see us just as the ones who make spreadsheets or draw diagrams. But that’s only part of what we do. And above all—we’re people too.