Discover what a business really needs and turn it into clear requirements, process maps, user stories, data models and a gap analysis.

Business & Systems Analysis

## 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:

1. **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".
2. **Identifies stakeholders.** Who uses the process, who pays for it, who is affected by changing it.
3. **Elicits requirements.** Interviews, workshops, observation and document review.
4. **Models the current and future state.** Process maps, use cases, data models.
5. **Writes and manages requirements.** User stories, acceptance criteria, rules, non-functional requirements, and how they trace back to goals.
6. **Supports delivery.** Answers developers' questions, reviews test cases, helps with user acceptance testing.
7. **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](https://www.iiba.org/business-analysis-certifications/). 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.


How business and systems analysts bridge the people who run a business and the people who build its systems.

The analyst's role

Business Analysis Explained in Under 10 Minutes

Business Analyst vs System Analyst

Write a one-sentence interview goal, for example: understand how a court booking happens from first request to the game itself, and where it goes wrong.

Write a question guide of 8 to 10 questions grouped by theme, starting with "Walk me through the last time you...".

Run the interview for about 20 minutes. Ask at least three probing follow-ups ("What happened next?", "How often?") and finish with "What should I have asked that I did not?".

Within a day, write up your notes in four headings: process steps, problems (with frequency if known), rules and numbers, and open questions.

Mark each statement from your notes as fact, opinion or proposed solution. For every proposed solution, write the underlying need in one sentence.

Send or read a short summary back to the person and note anything they corrected.

## Why it matters

Requirements are rarely sitting in someone's head ready to be written down. People describe symptoms, jump to solutions and forget the steps they do automatically. **Elicitation** is the skill of drawing out what people actually need. The word is deliberate: you *elicit* requirements, you do not just *gather* them like apples.

## Elicitation techniques

| Technique | Good for | Watch out for |
|---|---|---|
| Interview | Depth with one person or a pair | One view; schedule several |
| Workshop | Agreement across a group | Loud voices dominating |
| Observation (job shadowing) | Seeing the real process and workarounds | People behave differently when watched |
| Document analysis | Rules, forms, policies, old specs | Documents are often out of date |
| Survey | Many people, simple questions | Shallow answers, low response |
| Prototype | Reactions to something concrete | People fix on colours, not flow |

The interview is the workhorse. Almost every analysis starts with a handful of them.

## Planning an interview

1. **Pick the right people.** For Riverside Library: the head librarian (sponsor), two front-desk librarians (users), one member who books often, and whoever looks after the library's IT.
2. **Set a goal.** "Understand how a room booking happens today, from first call to the meeting itself, and where it goes wrong."
3. **Do your homework.** Read the paper diary, any booking rules and complaint emails. Do not waste the interview on facts you could look up.
4. **Write a question guide**, not a script. Group questions by theme and keep it to about ten.
5. **Book 30 to 45 minutes** and say why you are there and how the notes will be used.

## Asking good questions

Start broad and open, then narrow down.

- **Open questions** get stories: "Walk me through the last booking you took."
- **Probing questions** dig into the story: "What happened next?", "How often does that happen?", "What do you do when the diary is not at the desk?"
- **Closed questions** confirm facts: "Is the maximum booking two hours?"
- **The magic wand question** surfaces goals: "If you could change one thing about bookings, what would it be?"
- **The final question** catches what you missed: "What should I have asked you that I did not?"

Ask about **real recent examples**, not general opinions. "Tell me about Tuesday's double booking" beats "Are there problems with bookings?"

### A worked fragment

> **Analyst:** Walk me through the last booking you took.
> **Librarian:** A lady from the knitting group rang. I checked the diary, Room B was free on Thursday, so I pencilled it in.
> **Analyst:** What happens after you pencil it in?
> **Librarian:** I am supposed to ring back to confirm, but if it is busy I forget.
> **Analyst:** How often would you say that happens?
> **Librarian:** Maybe once a week. And then they turn up and someone else is in there, because my colleague took a call for the same room.

In two minutes you have found two problems (no confirmation, two people writing in one diary) and a rough frequency. Notice the analyst never suggested a solution.

## Listening and noting

- **Listen more than you talk.** Aim for the stakeholder speaking 80 percent of the time.
- **Capture their words.** "I forget to ring back" is better evidence than your paraphrase.
- **Separate facts, opinions and solutions.** "We need text reminders" is a solution; the need underneath is "members must know their booking is confirmed".
- **Note rules and numbers** as you hear them: opening hours, room capacities, how far ahead people can book.

## After the interview

Within a day, write up the notes and **send a short summary back** for confirmation: the process as you understood it, the problems, the rules and any open questions. This catches misunderstandings early and shows the stakeholder their time mattered. Then compare interviews: where two librarians describe the same step differently, you have found something to investigate.

## Common mistakes

- **Leading questions.** "Would an app make this easier?" invites yes.
- **Interviewing only managers.** They describe the process as designed, not as performed.
- **Taking solutions at face value.** Always ask "what would that let you do?"
- **No confirmation step.** Unconfirmed notes become requirements nobody agreed to.

## Quick recap

- Elicitation draws out needs; use interviews, workshops, observation and documents together.
- Prepare a goal and a short question guide; ask about real recent examples.
- Move from open to probing to closed questions; end with "what did I miss?"
- Write up and confirm within a day.

## Try it

Open the **Do** tab and run a real 20-minute interview with someone about a process they use.


Plan and run a stakeholder interview that uncovers real needs, then confirm what you heard.

Eliciting requirements

Requirements Elicitation – What Questions to Ask

Essential Questions to Ask during stakeholder Interviews and Workshops - Business Analyst Techniques

Write the process name and its start and end boundaries in one sentence.

Draw one swimlane per role (for example Customer, Staff, System).

Add the happy path as 5 to 12 verb-noun tasks, from a start event to an end event.

Add at least two gateways for decisions or exceptions, with labelled yes/no flows.

Mark at least three pain points (delays, rework, errors) and add a number or frequency to any you know.

Count the hand-offs between lanes and write the number on the map.

Walk the map through with someone who does the process and correct anything they say is wrong.

## Why it matters

Interview notes are a pile of stories. A **process map** turns them into one picture that everyone can check. It shows who does what, in what order, where decisions happen and where the work goes wrong. The **as-is** map shows the process as it really runs today, workarounds included. You cannot design a better process until people agree on the current one.

## The building blocks

Most process maps today use a simplified form of **BPMN** (Business Process Model and Notation), an open standard maintained by the Object Management Group. You only need a handful of shapes:

| Shape | BPMN name | Meaning |
|---|---|---|
| Thin circle | Start event | What triggers the process |
| Rounded rectangle | Task | A piece of work someone does |
| Diamond | Gateway | A decision or a split |
| Arrow | Sequence flow | What happens next |
| Thick circle | End event | Where the process finishes |
| Horizontal band | Lane (swimlane) | Who does the tasks inside it |

Lanes are what make a map useful. Each lane is a role (member, librarian, system), so a glance shows every hand-off. Hand-offs are where delays and mistakes hide.

## Worked example: Riverside Library today

From the interviews, the booking process looks like this, written as text before you draw it:

```text
Lane: Member
  (start) Member wants a room
  Phone the front desk
Lane: Librarian
  Check paper diary
  <gateway> Room free at that time?
     no  -> Offer another time -> back to Member: accept? (yes -> continue, no -> end: no booking)
     yes -> Pencil booking in diary
  Ring member back to confirm        [PAIN: often forgotten, ~1 per week]
Lane: Member
  Arrive for meeting
Lane: Librarian
  <gateway> Room actually free?      [PAIN: double bookings, two people write in one diary]
     yes -> (end) Meeting happens
     no  -> Find another room or apologise -> (end)
```

Drawn as a diagram, the member and librarian lanes run across the page and the arrows zig-zag between them. Even before you finish, two things stand out: the member cannot see availability without a phone call, and nothing stops two librarians from booking the same slot.

## How to build an as-is map

1. **Name the process and its boundaries.** "Meeting-room booking, from a member wanting a room to the meeting starting." Boundaries stop the map from growing forever.
2. **List the roles** and draw a lane for each.
3. **Write the happy path first**: the steps when everything goes right, as verb-noun tasks ("Check diary", not "Diary").
4. **Add decisions and exceptions** with gateways: what happens when the room is not free, when the member does not answer.
5. **Mark pain points** with a note or a red marker: delays, rework, errors, frustration. Add numbers if you have them.
6. **Walk it through with the people who do the work.** Ask "is this what really happens?" Expect corrections.

Sticky notes on a wall are perfect for a first draft. Free tools such as draw.io (diagrams.net) or the free tiers of online whiteboards work for a clean version.

## Map what is, not what should be

The most common trap is drawing the official procedure. If the policy says librarians ring back within an hour but they actually forget once a week, the as-is map shows "ring back (often forgotten)". The point is to make the real problems visible. Resist fixing things while you map them; that is the to-be design later in this course.

## Level of detail

Pick one level and stay there. A high-level map has 5 to 15 tasks and fits on one page. If a task hides a lot of work ("Process invoice"), give it its own detailed map rather than squeezing 40 boxes into one diagram.

## Common mistakes

- **No lanes**, so hand-offs are invisible.
- **Mixing levels**: "Run the library" next to "Click Save".
- **Only the happy path**, when exceptions cause most of the pain.
- **Mapping alone** and never validating with the people who do the work.
- **Vague task names** such as "Booking" instead of "Pencil booking in diary".

## Quick recap

- An as-is map shows the current process honestly, workarounds and pain points included.
- Use a few BPMN shapes: start, task, gateway, flow, end, and lanes for roles.
- Build the happy path, add exceptions, mark pain points, then validate.
- Keep one level of detail per map.

## Try it

Open the **Do** tab and map a real process from your interview, or from your own daily life.


Draw an as-is process map with swimlanes, decisions and pain points, using basic BPMN shapes.

Mapping the current process

How to Create a Simple Process Map (With Examples)

BPMN diagram tutorial

What analysts do, how to draw requirements out of stakeholders, and how to map the process as it works today.