Who Is a Business Analyst in IT: Tasks, Skills and How to Start

The role in short

A business analyst (BA) translates between the business and the development team. A client says "we need a CRM"; the analyst finds out why, which processes are breaking today, who will use it and what success looks like. The output is a set of requirements the team can estimate, build and verify.

The real value of a BA is not documents. It is making sure the team builds the right thing, not just builds the thing right.

What an analyst does day to day

• Interviews and meetings with stakeholders. Clarifying goals, constraints and who makes decisions.
• Mapping "as-is" and "to-be" processes. Often in BPMN notation, which makes manual work, delays and duplication visible.
• Writing requirements. Business requirements (why), user requirements (what people need), functional and non-functional requirements (what the system does and how well).
• User stories and acceptance criteria. The "As a , I want , so that " format plus conditions that define when the story is done.
• Backlog work. Prioritizing with the product owner and splitting large items into smaller ones.
• Answering the team. Developers and testers come with questions; the analyst removes ambiguity.
• Acceptance. Checking that what was built actually solves the original problem.

A story with acceptance criteria:

As a sales manager, I want to see deals with no activity for 7+ days,
so that I can follow up with the client in time.

Acceptance criteria:
- The deal list has a "No activity 7+ days" filter.
- Activity means a call, an email or a stage change.
- The filter shows only the current manager's deals.

How a BA differs from nearby roles

In small teams roles often overlap, and a BA may write both business and system requirements. The focus still differs: a business analyst is closer to people and processes, a system analyst to architecture.

Skills you need

Hard skills:

• writing requirements, user stories and acceptance criteria;
• process modeling: BPMN, plus basic UML diagrams (use case, activity, sequence);
• understanding how web and mobile apps work: API, database, client and server;
• basic SQL to check data yourself;
• tools: a task tracker, a wiki, a diagram editor, wireframes in Figma.

Soft skills:

• asking clarifying questions and hearing what sits behind a request;
• structured writing: short, unambiguous, no "etc.";
• facilitating meetings and negotiating when interests conflict;
• critical thinking: spotting contradictions and gaps.

How to start: first steps

1. Learn the basics of software delivery. How a project goes from idea to release; what Scrum, a sprint and a backlog are.
2. Learn the notations. Draw a BPMN diagram of a familiar process: ordering in a cafe, requesting vacation.
3. Build a practice project. Take a real-world app (delivery, doctor booking) and write a process map, 10–15 user stories with acceptance criteria and a simple prototype. That is your portfolio.
4. Improve your SQL and English. Much of the material, tooling and job market is in English.
5. Use your current experience. People often move in from QA, support, sales or an industry (banking, logistics, retail). Domain knowledge is a strong advantage.
6. Look for internships and junior BA roles, and adjacent jobs such as support analyst or CRM implementation specialist.

Bodies of knowledge like BABOK are useful as a map of the profession, but a certificate is not required at the start. Employers usually care more about how you think and write.

Common beginner mistakes

• Recording the solution instead of the problem. "We need an export button" is a solution; find out why export is needed.
• Writing vaguely. "The system must be fast" cannot be tested.
• Talking only to the client. End users often describe the process differently.
• Disappearing after handing over requirements. The analyst's job continues until acceptance.