Ultimate Guide to Becoming a Business Analyst

Are you wondering what a business analyst is? Are you interested in becoming a business analyst?

You’ve come to the right place.

In this guide, you’ll learn all about this role on software projects: the business analyst. You’ll learn what they are, what they deliver, how they fit in with Agile software development, and how to become a business analyst.

What Is a Business Analyst?

A business analyst is a role on a software project.Ultimate Guide to Business Analysis

A business analyst is someone who analyses what changes are needed in a business, determines and documents the requirements of these changes, and works with the development team to implement these changes.

I often tell people that they set in between the business users and the development team to help clarify what both sides want.

A business analyst is often referred to as a BA, just because it’s shorter and easier to say. So if anyone refers to a BA on a software projects, then they mean a business analyst. In this article, I’ll use BA and business analyst interchangeably.


What Does a Business Analyst Do?

Their main role is to speak to the business representatives to find out what their requirements are for a project.

What’s a business representative?

They are the people involved in the project and those that work for the company in the area that the project is for.

They can also be referred to as subject matter experts, or SMEs, or stakeholders.

So, what does a business analyst do?

Here’s a list of the tasks that a typical business analyst would do:

  • Speak with stakeholders individually to gather requirements for a project
  • Attend (or run) workshops or large meetings to discuss or gather requirements
  • Read existing project or company documentation
  • Create Business Requirements Document from scratch or using a template, if the project uses a waterfall methodology
  • Assist with writing user stories and acceptance criteria (if using an agile methodology)
  • Confirm requests or questions from development team and get them answered by the stakeholders
  • Draw diagrams of business processes
  • Draw rough designs of user interfaces after working with stakeholders and development team (if there is no user experience representative on the team)
  • Assisting the project manager by setting up meetings, and other similar tasks
  • Assist with User Acceptance Testing, by coordinating tests and results with the users
  • Determining the issues with any defects found and discussing them with stakeholders and the development team

These are the major tasks that I’ve worked on in my experience as a business analyst. The role changes slightly with each project, and has changed quite a bit when working on Agile projects, but most of the work is still done.


Why Do Business Analysts Gather Requirements?

You might be wondering, why do business analysts gather requirements? Why do we even need business analysts? Can’t the developers talk to the stakeholders?

Well, that’s a good question.

The reason BA’s exist is because they have specialist skills. They have experience in working out the requirements for a project based on conversations with users and stakeholders, and have experience in the tools and methods that are used (user stories, diagrams, business requirements, etc).

In waterfall projects (projects that use a waterfall methodology), a business analyst plays a big role in the early stages (requirements gathering stage), a smaller role during design and development, and a bit more of a role in the testing phase.

In agile projects (e.g. Scrum), the business analyst plays a more continuous role. It’s often been mentioned that there is no place for a business analyst on an agile project! I’ll explain this in more detail shortly.

So, the role of a business analyst allows them to use their specialist skills to help a project team. This lets the developers focus on what they do best (design and develop software, write unit tests, and everything that’s involved), and helps the business users focus on their “day job” (the work they need to do outside of the project).


What Is A Technical Business Analyst?

You might have seen or heard of the role called the “technical business analyst”. What is this role?

A technical business analyst is one that has more of a technical background, or one who is more involved with the IT team during their role.

When you see the term “technical” or “technical background”, it refers to someone who has experience with development or testing. They have experience with software and code that a non-technical business wouldn’t have, and usually understand the software involved better.

I say usually, because there could be non-technical business analysts that have a lot of knowledge of the systems within a company, more than a relatively new technical business analyst could have.

So why do we (recruiters, companies, the industry overall) differentiate between technical business analysts and non-technical business analysts?

Mainly it’s due to the requirements of the position. Some projects and some roles in companies require a BA to be more technical and to have an understanding of the technical side. This may be the case on smaller projects where there is a smaller team to handle the development or implementation work.


What Is An Agile Business Analyst?

So, what about agile business analysts? Or, more specifically, business analysts on a team running an Agile methodology?

Traditionally, an Agile team does not have a role for a business analyst. Scrum teams have a Scrum Master, a Product Owner, and the development team.

So why do we see advertisements for Agile Business Analysts? And if you’re a business analyst, how can you work on an Agile team?

I had the same question myself a couple of years ago. I moved from development into business analysis, and then was moved on to a project running the Scrum methodology.

Then, recently, when I was looking for a new job, I had to be able to answer the question of why Agile projects need business analysts.

So, why do they? What’s their role.

A lot of the time they are not needed. In an ideal world, the development team would talk to the product owner to confirm the requirements, or use the user stories that the product owner has already written.

However, I’ve noticed a few reasons that business analysts are needed on Agile projects:

  • The team, business unit, or organisation is new to Agile and isn’t quite used to the idea of getting rid of their business analyst
  • The product owner is too busy to work on the requirements by themselves, or doesn’t have the experience in Agile to know how to write effective user stories
  • There is a group of subject matter experts, along with the product owner, that need to be consulted to get their requirements.

So, if any or all of these situations are true for a team, then a business analyst can be valuable.

Lucky for me, as I’m a business analyst working on an Agile project! In my current role, I’d say that all three of the points above apply to the team.


How to Become a Business Analyst

Are you interested in becoming a business analyst?

A career as a business analyst can be rewarding. It combines the technical aspects of working with software, as well as communicating with people around the business to find out what they want, and help make it happen.

In this section of the article, I’ll go through the steps you could take to become a business analyst.


There’s No Real Set Path

I feel I should point this out up front. There isn’t really a set path to becoming a business analyst. There aren’t any (that I know of) degrees in becoming a business analyst.

Sure, there may be junior business analyst roles out there, but you still need some knowledge and probably some experience to be able to be a successful business analyst.

If you speak to business analysts you know through work or other connections, you’ll probably find that they started in one of two methods:

  • Started in a technical role (e.g. development) and moved into business analysis
  • Started in a business role (e.g. a business user or manager) and moved into business analysis

When I began business analysis, I was originally a software developer that moved into a more analysis role.

This doesn’t always need to be the case – you could work in networking or testing and make a similar move.

I have different sets of suggestions depending on if you work at a company already, are moving from a developer role, or looking for a new job.


Do you already work at a company?

If you already work at a company, here’s what I suggest you do.

1 – Speak to other BAs

A good way to get started is to speak to other people who are already doing this role. There’s a good chance you are working with another Business Analyst on your team or project, or you know one in your department.

Ask them about their role, what they like and don’t like about it, and if they have any advice for working as a BA in this company. Mention that you’re interested in becoming a BA.

They may offer similar advice to what’s mentioned on this page, but they will also have some company specific information to offer you, or some tips that are more focused on your department or company.

2 – Start reading project documents

Another thing to do when you’re looking to start as a BA is to get a hold of some project documents and start reading them.

Are you on a project already? If so, ask your team leader or project manager for the documents that were prepared for the project. On most projects, there’s a lot of documents prepared early on in the project, to get approval and to create a plan.

Reading these documents can help. The types of documents could be:

  • Project business case: this will detail the reason why you’re doing the project, what benefits it has, and what the cost is.
  • Project plan: this will give you an idea of the dates the project is aiming for.
  • Requirements document (if you’re not using Agile): this will tell you what the solution needs to do, and is usually written by the BA.

The reason you should read these documents is to learn about:

  • The reasons and benefits for the project, which can help in requirements gathering.
  • The format for the project documents
  • The language that is used
  • The diagrams that are prepared

If you’re not on a project or don’t have documents for it, you can ask some other teams you might know, or ask your team leader of some recent project documents.

3 – Ask your manager for advice

At this stage, if you haven’t done so already, you should mention to your manager that you’re interested in developing your BA skills or moving into a BA role.

They could have some advice for you and more than what you might get from others. They may be focused on the role of a BA role from a team leader’s perspective, and depending on how long they have been at the company, they could have some good advice about the company to you.

So, I would suggest speaking to your manager about your interest in moving into a BA role and if they have any advice.

Depending on your company, they could have a separate business unit that the business analysts work in. I’ve worked in companies where this happens and they had called it a Business Analyst Practice.

4 – Start doing some BA tasks and going to some meetings

This is the step where you would go from reading and talking to people to actually doing some BA work.

I suggest that the first thing you do here is to go to some meetings. Ask the BA in your project (and your manager too) if you can come along to some of the BA-related meetings that they have.

These meetings could be where the BA discusses the requirements with the users, or explains the UAT process to them, or gets feedback on a document or spreadsheet that has been prepared.

You don’t have to contribute anything, but just sitting and watching can be a big help to see how these things are done.

Feel free to help out the BA where you can, even if it’s things like taking notes. Actually, taking your own notes would be a good idea in any case. People tend to learn and retain information better if they write it down.

You can also start doing some BA tasks. Some ideas are:

  • Review and write some requirements. This could be as user stories or BRD requirements. Think of the reason behind the requirement and all of the different possibilities or outcomes, and see if they have been covered.
  • Create a template for a document, spreadsheet, or wireframe. You could use company templates, look for one online, or create it from scratch.
  • Ask the BA if there is anything they need help with. They might have an idea on what you can do.


Are you moving from a developer to a business analyst?

If you’re a developer who’s interested in becoming a business analyst, then there are some unique tips that are relevant.

Having a developer background is an advantage in my opinion. You have an understanding of how software is built, what the capabilities are, and likely have the ability to focus on the details and see different “what if” situations (e.g. what if the user accesses this screen without completing the other screen).

Here are some tips for moving from a developer to a business analyst:

1 – Work on your communication skills.

Being a BA is very focused on communication. Listening, writing, and speaking are all important. I know it’s easy for me to say “improve your communication”, but this is something that will come with practice.

Some specific tips I can offer are:

  • Learn to listen more.
  • Repeat back to the business user what they have explained. This helps confirm your understanding and see if you have gotten anything wrong.
  • Write shorter emails.
  • Don’t be afraid to use the phone.


2 – Focus on the requirements, not the solution

Software developers are great at looking at what needs to be built and working out how to build it. They focus on the “how”.

But, a business analyst focuses on the “what”. They try to understand what needs to be done, and the “why” behind it.

One of the hardest things about moving from a developer to a business analyst is changing your thinking from thinking about “how” something can be done to “what” needs to be done.

This takes time and experience. A BA should be able to work out what the users want (or at least suggest something if they are not sure), and leave it up to the developers to work out how.

For example, a common requirement I see is to select a single value from a specific range of values. A user might say “I want to choose from these ten radio buttons”, but what the BA needs to know is that they want to select only one value from these ten values. The radio button concept is not something that the BA needs to communicate. The developers should be able to decide if it is to be done with a set of radio buttons, or a drop-down box, or something else.

3 – Find out more about the company

Learning more about the company you work for can help you become a better BA.

It can help by understanding what the company is doing and what their priorities are.

For example, if they are looking to grow, then they might be looking for features that will help them get more sales or customers. If they are looking to save money or make something more efficient, they might be looking for different features.


Don’t have a job at the moment?

If you don’t have a job and are looking to get into a business analyst role, here’s what you can do.

Many BA roles ask for experience working on projects or doing BA tasks. If you don’t feel you can do this job yet, or don’t have the skills or experience, then there is something you can do.

In this case, I would suggest looking for some BA-related roles, such as a Project Co-ordinator. This role is kind of like a mini Project Manager or BA but more of an assistant role. It can help you get experience working on projects, which may involve building software, and working with business analysts. The requirements for a project co-ordinator role are usually less, as well.

From there, after you have some experience, you can look at moving to a BA role. It’s easier to move within a company to a role, as people know you and you can easily demonstrate your skills and experience.


Starting a New Role or Project

So, you’ve got a new role as a business analyst, or you’re starting a new project in your company as a business analyst.

Where do you start?

There are a few things I usually do and that I would suggest if you’re in this situation:

  1. Get the first steps from your manager. They will likely know where you can start, such as who to talk to or what you can read. They may also know when the first meeting is with the project team.
  2. Prepare a document. You may be required to create a document for your project. This could be some kind of requirements document, or a collection of user stories if your project is running agile. If you’re not sure, don’t create one for now.
  3. Organise your notes. You’ll be taking a lot of notes as a business analyst. I would suggest setting them up now. This could be a notebook with a pen (which is often the best option as you might not have a computer yet), or electronic (such as OneNote or Word documents).
  4. Contact those you need to speak to. Get a list of people you need to speak to, and send them an email. Introduce yourself, mention the work you’ll be doing, and ask for a time to meet up and talk about the project if they have any input.


What Skills Does A Business Analyst Need?

There are many skills that are useful for a business analyst to have. Learning more about these skills and improving them will help you become a better business analyst.



Communication is the foundation of a business analyst role. They spend a lot of time speaking with people and documenting things, so the better you can be at it, the better you’ll be at your role.

What does communication mean for a business analyst?

  • Listening to business users explain their requirements, listening to developers explain the solution and ask questions.
  • Asking questions to business users to find out what they need.
  • Explaining complicated topics to business users in an easy to understand way.
  • Explaining the project and the requirements and what happens to the business users.
  • Writing emails that aren’t too detailed and extensive. Short is usually better.
  • Writing requirements in a format that is agreed by the project, understandable by everyone involved, and correctly communicates the requirements.


Industry Knowledge – Helpful but Not Required

Knowing about the industry that you’re working in can be helpful, but it’s not required when you start a role.

For example, I worked for a telecommunications company for about 6 years all together, spread over a few departments at different times. The first time I started there I had no idea about how the industry worked.

After a couple of years there, the second time I was there was a lot easier, even though I didn’t really know how the new department worked. I still knew how the company and industry worked, which helped when understanding the department and the project.

The third time was much easier, as I knew how the industry worked a lot better, and I even knew quite a bit about the actual department. If I didn’t know all of this, it still would have been possible for me to do my job, but might have been harder to start.

So, having knowledge of the industry is helpful for a business analyst, but it’s not required.


Having a Technical Background

Coming from a technical background (developer, tester) can be an advantage as a business analyst.

As I mentioned earlier, I moved from a development role into business analysis. I think this has helped as I have an understanding of how software is built and the challenges that developers face.

If you have a background as a developer or a tester, and are moving into a business analyst, it can be a good thing.

It’s a question I get asked in interviews, whether it’s a good or a bad thing, and I always say it’s a good thing.

The hardest part is separating the “what” from the “how”.


Separating the What from the How

Another skill which I think is important for business analysts, especially those coming from a technical background, is being able to separate the “what” from the “how”.

By this, I mean that as a BA, our job is to find out what the user wants. We need to know what their requirements are, what they want the solution to do, and what problem it solves.

We don’t need to know how it does this. This isn’t something that the business users should be providing. Sure, they may have ideas, but it’s not something that they will be dictating to the team.

As a business analyst, we may also have ideas on how something could be done. But, ultimately, we need to understand the requirement, and let the development team work out the solution and how it’s done.


Time Management of Yourself and Others

Being able to manage your time is a good skill for a business analyst to learn. This is important for many roles, but I think it’s especially important for business analysts.

Why is that?

Because you’ll be doing two different types of work:

  1. Speaking with other people – meetings, phone calls, workshops
  2. Working by yourself – writing requirements, reading documents, sending emails

It can be hard to manage your time between these activities at the start. It can sometimes leave you with some spare time with nothing to do, if you need to wait for your next meeting with a user in a few hours and all of your work is waiting on them.

What I try to do, and what I suggest, is scheduling the work you need to do with other people first. Send out meeting requests, send emails to work out times and dates, or make phone calls. This means that once you get this done, you’re not subject to anyone else’s calendar but your own.

All of the other work you need to do can be done around these meetings.

This is helpful because it’s harder to find times when you and other people are both available, especially if you work in an environment where business users have a lot of meetings.

If you can schedule your meetings and phone calls first, around everyone else’s free time, it leaves you free to do your solo work around them.

Also, another related point is to be mindful of other people’s time. If there’s a way you can do more of the work and get the business users to provide you with just the information you need, then it frees them up to do their own work, reduces the pressure on them to find the time to work with you, and gives them a more positive attitude towards the project.


Tools for Business Analysts

What are some of the tools that business analysts use? What software do we use to do our jobs and make our lives easier?


Microsoft Word

Microsoft Word is used for creating documents, which is a part of the business analyst’s role. It should come installed on the company’s computer – every place I’ve worked has Microsoft Office installed.

Word allows you to create the documents you need for the project, whether they are Business Requirements Documents, UAT plans, project charters or reports. Many documents will be created by other people, such as project managers and test managers, and having Word will allow you to open and read them.

At a minimum, you’ll need to know how to format your document, use tables, numbers, and bullets. Using the Track Changes/Review feature is helpful if you need to get feedback from others.

I’m finding myself using Word a little less these days, because I’m working on Agile projects where our requirements are written in user stories in online tools (which I’ll get to shortly).


Microsoft Visio (or a diagramming tool)

Visio allows you to create all kinds of diagrams. I’ve found this a very useful tool, and often use it more than Microsoft Word.

The kinds of diagrams a BA might create are:

  • Process diagrams, to help describe the steps that a business user takes to get something done
  • Screen mockups, to describe how a screen could look. This could be a simple as boxes with text, or their icons that represent a screen.
  • Swimlane diagrams, to help describe how different users interact with the system and each other.

The only bad thing about Visio is that it is often under a separate license, which means that not all companies have it available. And those that do, often have restricted licenses.

This means that whenever you create a Visio document, you might need to convert it to PDF in order for other people to see it.

Other than that, I get a lot of use out of Visio.


Balsamiq Mockups

Another tool that can be helpful for BAs is a dedicated wireframe or mockup tool. A popular one is Balsamiq.

It’s great because it has a lot of icons and templates for creating wireframes. It has a lot of other features such as sizing to specific resolutions, which is great to see how your solution would look on different sized screens.

I haven’t used this tool a lot (the last project I was one had a dedicate UX/UI specialist who used it), but it can be valuable for BAs.


Snipping Tool

Recent versions of Windows have a built-in screenshot tool called Snipping Tool. I have used this tool quite a lot since discovering it.

It allows you to take a screenshot of part of a screen, add lines or highlights to it, and then either copy or save the image.

It’s much easier than using the Print Screen key sometimes. If I wanted to get part of a screen using Print Screen, I would have to:

  1. Press Print Screen (or Alt-Print Screen to get just the active window)
  2. Open MS Paint
  3. Paste the image
  4. Select the part of the image I want to keep
  5. Copy it, create a new document, and paste the image
  6. Resize the background if necessary
  7. Save the image

I’ve used Snipping Tool to demonstrate parts of a solution to business users, to show them how to use different software, and to demonstrate bugs to the development team. It’s a great tool.

Agile Workflow Tool (Jira, TFS, Mingle, RTC)

If you’re working on a project that uses an Agile methodology, then your world will revolve around whatever Agile workflow tool the team uses.

These tools are designed to capture the work that the team does. The core features of these applications usually include:

  • Create/edit work items, often called user stories, product backlog items, tasks, epics, and features
  • Scrum and Kanban boards for monitoring team’s work
  • Adding attachments, images, comments, and estimates to work
  • Viewing progress charts such as burn down charts and velocity

Once the team uses these tools and knows how to use them properly, they should start working better together.

Which tool is the best? I don’t know enough about them to know which one is the best.

I have the most experience with Jira, having help set it up for one team, and using it quite heavily for a few years as the BA. I’ve had a little bit of experience with RTC. The team I have just started with has been using TFS and it seems quite good so far.

My personal preference would be Jira, but this would be a decision for your team and the business.


Pen and Paper

Sometimes, pen and paper can be useful in the world of software development.

It’s easy to draw diagrams to quickly show people your understanding or how things might work.

It’s good to capture notes in meetings where you don’t have a laptop – even if your handwriting is messy like mine.

It’s good to take notes and brainstorm if you want some time away from the computer.

It’s also good for when you start at a new company and you don’t have a computer or an account yet.

Using pen and paper is a good tool for business analysts for many reasons!


Task Management – Outlook

Having a task manager is a big help for a business analyst. It lets you keep track of all the things you need to do, everything you’re waiting for others to do, and ideas or suggestions you want to raise.

Ever since reading David Allen’s How To Get Things Done and learning about GTD, I have been all about task management. People have mentioned how efficient I am, and I feel that writing everything down ensures I get it all done and I don’t forget it.

So, I would suggest using a task manager to keep track of your work.

I use the Tasks section in Outlook to keep track of all of the tasks I need to do. This is helpful because it’s simple to use, available on my work computer, and it works well with emails in Outlook.

I know there are better apps out there for task management and GTD. I keep my personal tasks separate and currently use an app called Todoist, having used many in the past such as Remember the Milk and Asana.

So, if you want to keep track go tasks at work, I suggest using an app you already have on your computer, which is Outlook.



We’ve reached the end of this guide on becoming a business analyst. I hope you’ve found it valuable and can use this information in your career, whether you’re interested in becoming a business analyst or are already working as a business analyst.

For now, I’d like you to do a few things:

  1. Sign up to my newsletter. You’ll receive some bonus PDFs on improving your career, and emails on future articles I write.
  2. Share this guide with other business analysts or people you know or work with.
  3. If you have a blog or website, link back to the article.


Copyright: ammentorp / 123RF Stock Photo

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.