How business and systems analysts bridge the people who run a business and the people who build its systems.
Why it matters
Most failed IT projects do not fail because the code was bad. They fail because the team built the wrong thing: a feature nobody needed, a screen that did not match how staff actually work, a report that answered the wrong question. Analysts exist to prevent that. Their job is to understand a business problem well enough that the solution solves it, and to say it clearly enough that the people building the solution get it right the first time.
Business analyst vs systems analyst
The two titles overlap a lot, and many job adverts use them interchangeably. A useful way to tell them apart:
- A business analyst (BA) starts from the business: goals, processes, rules, pain points. The output is a clear statement of what the business needs, whether or not software is the answer.
- A systems analyst starts from the systems: how existing applications, data and integrations work, and how they must change to meet the need. The output is closer to a design: data models, interfaces, system behaviour.
In practice most analysts do both. The International Institute of Business Analysis (IIBA) defines business analysis as "the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders". Notice that the definition says nothing about software.
What analysts actually do
Across a typical change, an analyst:
- Clarifies the problem. "Room bookings are a mess" becomes "about one booking in ten is double-booked, and staff spend roughly six hours a week on the phone confirming bookings".
- Identifies stakeholders. Who uses the process, who pays for it, who is affected by changing it.
- Elicits requirements. Interviews, workshops, observation and document review.
- Models the current and future state. Process maps, use cases, data models.
- Writes and manages requirements. User stories, acceptance criteria, rules, non-functional requirements, and how they trace back to goals.
- Supports delivery. Answers developers' questions, reviews test cases, helps with user acceptance testing.
- Checks the outcome. Did the change actually fix the problem it was meant to fix?
The running example
This course follows one small project. Riverside Library lets community groups book three meeting rooms. Today a member phones the front desk, a librarian checks a paper diary, writes the booking in pencil and sometimes forgets to call back. The head librarian wants "an online booking system". An analyst's first move is not to choose software. It is to ask: what problem are we solving, for whom, and how will we know it is solved?
Where analysts sit
Analysts work with almost everyone:
| Who | What the analyst gets from them | What the analyst gives them |
|---|---|---|
| Sponsor (head librarian) | Goals, budget, constraints | Options, trade-offs, progress |
| Users (librarians, members) | How the work really happens | A voice in the design |
| Developers and testers | Technical constraints | Clear, testable requirements |
| Project manager | Plan and priorities | Scope, estimates input, risks |
| Data and security staff | Data rules, policies | Data needs, access rules |
On agile teams the analyst often works alongside the product owner, writing and refining backlog items. Sometimes the analyst is the product owner.
Skills that matter
- Questioning and listening. Most of the job is asking good questions and noticing what people did not say.
- Clear writing. Requirements that two people read the same way.
- Modelling. Drawing processes, data and behaviour so others can check them.
- Enough technical knowledge. You do not need to code, but you need to understand databases, integrations and what is easy or hard to build. That is why this course expects SQL Fundamentals.
- Neutrality. You represent the need, not your favourite solution.
Common mistakes
- Jumping to a solution. "We need an app" is a solution. Find the problem first.
- Talking only to the sponsor. The people doing the work know where it breaks.
- Writing requirements nobody can test. "Easy to use" means nothing until you say how you would check it.
- Disappearing after the requirements document. Questions come up in every sprint; analysts stay involved.
Beyond this course
Analyst roles usually ask for a bachelor's degree (information systems, computer science or business are common) or equivalent experience. The IIBA offers a ladder of certifications: ECBA for people starting out, CCBA for analysts with some experience and CBAP for senior analysts. Eligibility rules and fees change, so check the official pages at the IIBA certifications page. Checked on 2026-10-23. The IIBA's BABOK Guide is the standard reference for the techniques in this course.
Quick recap
- Analysts define needs and recommend solutions; software is only one possible answer.
- Business analysts lean towards the business, systems analysts towards the systems; most do both.
- The work runs from clarifying the problem through to checking the outcome.
- Questioning, clear writing and modelling are the core skills.