Business and systems analysts stand between the people who run a business and the people who build its systems. This intermediate course teaches the core analyst toolkit with one running example: a public library that books its meeting rooms by phone and a paper diary. You will learn what analysts do and where the role sits, run a stakeholder interview, and draw an as-is process map; write user stories with Given/When/Then acceptance criteria, separate functional from non-functional requirements and prioritise with MoSCoW; and model the system with use cases, activity diagrams and an entity relationship diagram that you test with SQL, before writing a gap analysis and a to-be design. Each lesson has a short reading, curated videos and a practical task you can do on paper or in a free diagramming tool. It builds on Professional Communication and SQL Fundamentals and points to the IIBA certifications (ECBA, CCBA, CBAP).

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.

Discovery

Write one epic that describes the whole improvement in one sentence.

Split it into at least three user stories in the As a / I want / so that format, each for a real user role.

Check each story against INVEST and rewrite any that fail a letter. Note which letter it failed.

For one story, write a happy-path Given/When/Then scenario using concrete names, dates or numbers.

Add at least one failure scenario and one edge-case scenario for the same story.

Ask someone else to read the scenarios and say whether a given result would pass or fail. Fix anything they read differently.

## Why it matters

On agile teams most requirements arrive as **user stories**: short statements of something a user wants to do and why. A story on its own is a promise of a conversation, not a specification. What makes it buildable and testable is its **acceptance criteria**. Analysts spend a lot of their time writing and refining both.

## The story format

The common template is:

```text
As a <type of user>,
I want <some goal>,
so that <some reason>.
```

For Riverside Library:

```text
As a library member,
I want to see which rooms are free on a given day,
so that I can choose a time without phoning the desk.
```

Each part does a job. The **role** reminds the team who they are building for. The **goal** says what, not how ("see which rooms are free", not "a calendar widget"). The **reason** explains the value, and often helps the team find a simpler solution.

## Card, conversation, confirmation

Ron Jeffries, one of the creators of Extreme Programming, described a story as three Cs. The **card** is the short written statement, small enough to fit on an index card. The **conversation** is the discussion between the product owner, the analyst, developers and testers that fills in the details; it happens close to when the story is built, so it uses the latest knowledge. The **confirmation** is the set of acceptance criteria that shows the story is done. An analyst's job is to make sure all three exist. A story with no conversation gets built on guesses, and a story with no confirmation is never clearly finished.

## INVEST: what makes a good story

| Letter | Meaning | Library example of breaking it |
|---|---|---|
| I | Independent: can be built in any order | "Cancel a booking" written so it needs "edit booking" first |
| N | Negotiable: details agreed in conversation | A story that dictates the exact screen layout |
| V | Valuable to a user or the business | "Set up the database" (a task, not a story) |
| E | Estimable: the team can size it | "Improve bookings" (too vague) |
| S | Small: fits in one sprint | "Online booking system" (an epic) |
| T | Testable: you can tell when it is done | "Booking should be easy" |

A story that is too big is an **epic**. You split epics into stories, for example by workflow step (search, book, cancel), by user type (member, librarian) or by rule (single booking first, recurring bookings later).

## Acceptance criteria with Given/When/Then

Acceptance criteria are the conditions a story must meet to be accepted. The **Given/When/Then** format, from behaviour-driven development (BDD) and its Gherkin language, makes them precise:

- **Given** the starting situation (context),
- **When** the user does something (action),
- **Then** the result you can observe (outcome).

For the "see free rooms" story:

```gherkin
Scenario: Member sees free rooms for a day
  Given Room A is booked from 10:00 to 12:00 on 14 March
  And Rooms B and C have no bookings on 14 March
  When a member views availability for 14 March
  Then Room A is shown as unavailable from 10:00 to 12:00
  And Rooms B and C are shown as free all day

Scenario: Member picks a date in the past
  Given today is 10 March
  When a member views availability for 9 March
  Then they see the message "Choose today or a future date"
```

Each scenario is a test. A tester, a developer and the sponsor can all read it and agree whether the software passes. Testers can later automate these scenarios with tools that read Gherkin.

## A second story

```text
As a librarian,
I want the system to refuse a booking that overlaps an existing one,
so that two groups never turn up for the same room.
```

```gherkin
Scenario: Overlapping booking is refused
  Given Room B is booked from 14:00 to 16:00 on 20 March
  When a member tries to book Room B from 15:00 to 17:00 on 20 March
  Then the booking is not saved
  And the member sees "Room B is already booked from 14:00 to 16:00"

Scenario: Back-to-back booking is allowed
  Given Room B is booked from 14:00 to 16:00 on 20 March
  When a member books Room B from 16:00 to 17:00 on 20 March
  Then the booking is saved
```

The second scenario catches an edge case that would otherwise be argued about later: does ending at 16:00 overlap starting at 16:00? Writing it down settles it.

## Tips for criteria

- Use **concrete examples** (real times, names, numbers), not "a valid booking".
- Cover the **happy path, at least one failure, and the edge cases**.
- Describe **behaviour, not the user interface**: "sees a message", not "a red toast appears top right".
- Keep each story to roughly 3 to 7 scenarios. More usually means the story should be split.

## Common mistakes

- **Stories that are tasks**: "As a developer I want a bookings table". Users do not want tables.
- **Missing "so that"**, which hides the value and blocks simpler ideas.
- **Criteria written after the build**, so they describe what was built instead of what was needed.
- **Vague outcomes**: "Then it works".

## Quick recap

- A story states who wants what and why; the acceptance criteria make it testable.
- Check stories against INVEST; split epics into small, valuable stories.
- Given/When/Then scenarios with concrete examples cover the happy path, failures and edge cases.

## Try it

Open the **Do** tab and write three stories with Given/When/Then criteria for your own process.


Write user stories that follow INVEST and give them testable Given/When/Then acceptance criteria.

User stories and acceptance criteria

What Is a User Story in Agile? (Examples + Template)

How to Identify Given-When-Then (Gherkin) Scenarios From Functional Requirements

## Why it matters

A system can do everything users asked for and still fail: it is too slow at 9 a.m. when everyone logs in, it leaks members' phone numbers, or it does not work with a screen reader. Those are not missing features; they are missing **qualities**. Analysts capture both kinds of requirement, because teams naturally focus on features and forget the rest until it is expensive to fix.

## The two kinds

- A **functional requirement** describes what the system must **do**: a behaviour, a calculation, a rule, a piece of data it must store or show.
- A **non-functional requirement (NFR)** describes how well the system must do it, or the constraints it must respect: speed, security, availability, usability, accessibility, compliance.

A quick test: if you can describe it as "the system shall [verb] [something]", it is usually functional. If it describes a property that applies across many functions ("every page", "all data", "at all times"), it is usually non-functional.

## Riverside Library examples

| Requirement | Kind | Category |
|---|---|---|
| A member can book a free room for up to 2 hours | Functional | Booking |
| The system sends a confirmation email when a booking is saved | Functional | Notifications |
| A librarian can cancel any booking and record a reason | Functional | Administration |
| The availability page loads in under 2 seconds for 95% of requests | Non-functional | Performance |
| Members' phone numbers are visible only to library staff | Non-functional | Security and privacy |
| Booking works with a keyboard alone and with common screen readers (WCAG 2.2 AA) | Non-functional | Accessibility |
| The service is available 99.5% of the time during opening hours | Non-functional | Availability |
| Booking data is deleted 12 months after the meeting date | Non-functional | Data retention and compliance |

Notice the privacy example: "only staff can see phone numbers" sounds like a rule, and some teams record it as functional. The label matters less than writing it down and testing it. Classify consistently within a project.

## Common NFR categories

A checklist helps because nobody volunteers these in interviews:

- **Performance**: response times, throughput, peak load.
- **Scalability**: growth in users or data.
- **Availability and reliability**: uptime, recovery time after failure, backups.
- **Security and privacy**: who can see and change what, logging, data protection law.
- **Usability and accessibility**: task completion, WCAG level.
- **Compatibility**: browsers, devices, other systems it must talk to.
- **Maintainability and supportability**: logging, monitoring, who supports it.
- **Compliance**: legal, regulatory and policy rules.

Many teams use a model such as ISO/IEC 25010, which lists software quality characteristics, as a fuller checklist.

## Writing requirements that can be tested

Bad: "The system must be fast."
Better: "The availability page shows results within 2 seconds for 95% of requests, with 50 members using it at once."

The better version has a **measure** (seconds), a **threshold** (2), a **percentile** (95%) and a **condition** (50 concurrent users). A tester can check it. The same applies to functional requirements: "the system handles cancellations" becomes "a member can cancel their own booking up to 24 hours before the start time; after that, only a librarian can cancel".

A few writing rules:

- **One requirement per statement.** "Members can book and cancel rooms" is two requirements.
- **Use "must" or "shall" consistently** for mandatory items.
- **Avoid vague words**: fast, easy, user-friendly, flexible, robust, as appropriate.
- **Give each requirement an ID** (FR-07, NFR-03) so it can be traced to stories, tests and goals.
- **Record the source**: who asked for it and why.

## Where they live

On a traditional project, requirements go into a **specification** document, often called a business requirements document (BRD) or software requirements specification (SRS). On agile teams, functional requirements become user stories with acceptance criteria, while NFRs usually become **constraints that apply to every story**, often written into the team's **Definition of Done** ("every page meets WCAG 2.2 AA") or as separate technical stories. Either way, a **traceability matrix** linking each requirement to its goal and its tests shows nothing has been lost.

## Common mistakes

- **Forgetting NFRs** until a performance or security problem appears in testing or, worse, in production.
- **Unmeasurable NFRs** ("secure", "scalable") that nobody can test.
- **Gold-plating**: demanding 99.999% availability for a library booking system. Every extra nine costs money; ask what the business really needs.
- **Solutions disguised as requirements**: "must use database X" is a constraint only if there is a real reason.

## Quick recap

- Functional requirements say what the system does; non-functional requirements say how well, or under what constraints.
- Use a category checklist to find NFRs, because stakeholders rarely mention them.
- Make every requirement measurable, single, identified and traced.
- On agile teams, NFRs often live in the Definition of Done.


Tell functional from non-functional requirements, write both so they can be tested, and organise them in a specification.

Functional and non-functional requirements

Functional and Nonfunctional Requirements - Georgia Tech - Software Development Process

What are Non-functional Requirements and How Do They Work?

List at least eight requirements or stories, each with an ID.

Write the timebox you are prioritising for (for example: first release in eight weeks).

Give each item a rough size (S, M or L) and the goal it supports. Flag any item that supports no goal.

Sort every item into Must, Should, Could or Won't (this time), writing one reason per item.

Check the Musts: treat S as 1, M as 3 and L as 5 points and make sure Musts are no more than about 60% of the total. If they are more, re-test each Must and move some down.

Explain your list to someone else acting as sponsor and let them change at least one decision. Record what changed and why.

## Why it matters

Every project has more requests than time and money. If nothing is prioritised, the team builds whatever is loudest or easiest, and the most valuable work is still unfinished at the deadline. Prioritisation is a decision the business makes, but analysts set it up: they make the options, values and costs visible so the decision is informed and agreed.

## MoSCoW

**MoSCoW** comes from the DSDM agile method. It sorts requirements into four groups for a given release or timebox:

| Group | Meaning | Test question |
|---|---|---|
| **Must have** | Without it the release is useless, unsafe or illegal | "If this is missing, do we cancel the launch?" |
| **Should have** | Important and valuable, but there is a workaround | "Is there a painful but possible way round it?" |
| **Could have** | Nice to have; small impact if left out | "Would anyone complain much if it slipped?" |
| **Won't have (this time)** | Agreed out of scope for this release | "Can we say no now and revisit later?" |

The lower-case o's are just there to make the word pronounceable.

Two rules make MoSCoW work:

1. **Must haves are a minority.** DSDM guidance suggests no more than about 60% of the effort goes on Must haves, leaving the Shoulds and Coulds as contingency. If everything is a Must, nothing is.
2. **Won't is a real category.** Writing "Won't have this time" manages expectations and stops scope creeping back in.

## Worked example: Riverside Library, first release

The requirements list after elicitation, with rough sizes from the team (S, M, L):

| ID | Requirement | Size | MoSCoW | Why |
|---|---|---|---|---|
| FR-01 | Member sees room availability by day | M | Must | Core of the problem |
| FR-02 | Member books a free room online | M | Must | Core of the problem |
| FR-03 | System refuses overlapping bookings | S | Must | Double bookings are the top complaint |
| FR-04 | Confirmation email on booking | S | Should | Phone confirmation still possible |
| FR-05 | Member cancels own booking | S | Should | Librarians can cancel by phone meanwhile |
| FR-06 | Recurring weekly bookings | L | Could | Few groups need it; book week by week |
| FR-07 | Online payment for room hire | L | Won't (this time) | Rooms are free today; revisit next year |
| NFR-02 | Keyboard and screen-reader accessible | M | Must | Legal duty and library policy |

The Musts are about half the effort. If the build runs late, FR-06 drops first, then the Shoulds, and the release still solves the main problem.

## Backing choices with evidence

MoSCoW answers "how important", but stakeholders still argue. Help them with:

- **Value**: link each requirement to a goal ("cuts staff phone time"). If it links to no goal, ask why it is there.
- **Cost or size**: a small Should may be worth doing before a large Could.
- **Risk and dependencies**: something that unblocks other work, or tests a risky assumption, may go earlier.
- **Simple scoring** where there is disagreement: rate value and cost 1 to 5 and look at value divided by cost. Frameworks such as RICE (reach, impact, confidence, effort) and WSJF (weighted shortest job first, used in SAFe) formalise this.

## Running a prioritisation session

1. Share the list, goals and sizes before the meeting.
2. Agree the timebox: "first release, end of June".
3. Start by agreeing the Musts using the "do we cancel the launch?" test.
4. Sort the rest, discussing only the ones people disagree on.
5. Check the Must total against capacity. Too many? Push back and re-test each one.
6. Record decisions and reasons, and who made them.

The **sponsor or product owner decides**; the analyst facilitates and records. Stakeholders accept a "no" far more easily when they saw the trade-off being made.

## Common mistakes

- **Everything is a Must.** Ask "what happens on launch day if this is missing?"
- **Prioritising without sizes**, so a huge Could quietly eats the Shoulds.
- **No timebox.** "Should have" only means something relative to a release.
- **Never revisiting.** Priorities change as you learn; review them every release or sprint.

## Quick recap

- MoSCoW sorts work for a timebox into Must, Should, Could and Won't (this time).
- Keep Musts to a minority of effort so the rest acts as contingency.
- Back choices with value, size, risk and dependencies; the sponsor decides.
- Record decisions and revisit them.

## Try it

Open the **Do** tab and run a MoSCoW session on your own requirements list.


Prioritise requirements with MoSCoW, back the choices with value and cost, and get stakeholders to agree.

Prioritisation

What is MoSCoW Prioritization Method? Definition, Overview, and Best Practices

Agile in Practice: Prioritisation using MoSCoW

Write user stories with testable acceptance criteria, separate functional from non-functional requirements and decide what comes first.

Requirements

Draw the system boundary and list at least three actors, including one that is another system (email, payment, calendar).

Add at least five use cases named verb-noun and connect them to their actors.

Add one include and one extend relationship, and write a sentence explaining each.

Pick the most important use case and write its description: actor, preconditions, trigger, main flow of 4 to 7 steps and postconditions.

Add at least two alternate flows numbered against the main-flow step where they branch (for example 3a).

Draw an activity diagram for the same use case with guarded decisions and at least one fork and join for parallel work.

## Why it matters

User stories are great for planning work in small pieces, but they can hide the big picture: who interacts with the system at all, and how one goal flows step by step, including what happens when things go wrong. **Use cases** and **UML diagrams** give you that picture. Many systems analyst roles and certification exams expect you to read and draw them.

## UML in one paragraph

The **Unified Modeling Language (UML)** is a standard set of diagram types maintained by the Object Management Group. It has more than a dozen diagram types, but analysts mostly use a few: **use-case diagrams** (who does what with the system), **activity diagrams** (the flow of a process or use case), and sometimes **sequence** and **class** diagrams. You do not need to master all of UML; you need to draw these few correctly enough that others read them the same way.

## Use-case diagrams

A use-case diagram shows the **scope** of a system and the **actors** that use it.

- **Actor** (stick figure): a role outside the system that interacts with it. It can be a person (Member, Librarian) or another system (Email service).
- **Use case** (oval): a goal an actor achieves with the system, named verb-noun: "Book room", "Cancel booking".
- **System boundary** (rectangle): everything inside is the system you are building.
- **Association** (line): which actor takes part in which use case.
- **include** (dashed arrow labelled `<<include>>`): a use case that always runs as part of another. "Book room" includes "Check availability".
- **extend** (dashed arrow labelled `<<extend>>`): optional behaviour added under a condition. "Join waiting list" extends "Book room" when no room is free.

Riverside Library, in text form:

```text
[ Room Booking System ]
  Member     --- (Check availability)
  Member     --- (Book room)        (Book room) ..<<include>>..> (Check availability)
  Member     --- (Cancel booking)
  Librarian  --- (Cancel booking)
  Librarian  --- (Manage rooms)
  (Book room) --- Email service     (sends the confirmation)
  (Join waiting list) ..<<extend>>..> (Book room)
```

The diagram is deliberately simple. Its job is to answer "what is in scope and who is involved?" on one page.

## Use-case descriptions

The detail lives in a written **use-case description**. A practical template:

```text
Use case:        UC-02 Book room
Primary actor:   Member
Preconditions:   Member is signed in
Trigger:         Member chooses a free slot
Main flow:
  1. Member selects a room, date, start and end time.
  2. System checks the slot is free and no longer than 2 hours.
  3. System shows a summary.
  4. Member confirms.
  5. System saves the booking and sends a confirmation email.
Alternate flows:
  2a. Slot overlaps an existing booking:
      System shows the conflicting booking and suggests the next free slot.
      Use case returns to step 1.
  2b. Booking longer than 2 hours:
      System explains the limit. Returns to step 1.
  5a. Email service unavailable:
      Booking is saved; the system retries the email later.
Postconditions:  Booking is stored and visible to librarians.
```

The **alternate flows** are where analysts earn their keep. Each one is a question somebody would otherwise answer differently on their own.

## Activity diagrams

An **activity diagram** shows the flow of steps, decisions and parallel work. It looks like a flowchart with a few extras:

- **Initial node** (solid black dot) and **final node** (dot inside a circle).
- **Action** (rounded rectangle).
- **Decision and merge** (diamond) with guards in square brackets: `[slot free]`, `[slot taken]`.
- **Fork and join** (thick bar): actions that happen in parallel.
- **Partitions** (swimlanes) for who does each action.

The main flow of "Book room" as an activity diagram:

```text
(start) -> Select room and time -> Check slot
   <decision>
     [slot taken]    -> Show conflict and next free slot -> back to Select room and time
     [too long]      -> Explain 2-hour limit            -> back to Select room and time
     [ok]            -> Show summary -> Confirm
   == fork ==
      Save booking            Send confirmation email
   == join ==
(end)
```

Activity diagrams and BPMN maps look similar. A common split: BPMN for business processes across an organisation, UML activity diagrams for the behaviour of one use case inside a system.

## Use cases or user stories?

They are not rivals. Use cases suit work where the flow is long, rules are complex or several systems are involved, and where an organisation needs a stable description to test against or to hand to a supplier. User stories suit planning work in small slices on an agile team. Many analysts use both: a use-case diagram and a few use-case descriptions give the big picture and the tricky alternate flows, and each flow is then split into stories for the backlog. For example, UC-02 Book room might become one story for the main flow, one for the overlap rule (2a) and one for the email retry (5a), each with Given/When/Then criteria taken straight from the description.

## Common mistakes

- **Use cases that are steps**, such as "Click Save" or "Enter date". A use case is a goal.
- **Actors inside the boundary.** Actors are always outside the system.
- **Overusing include and extend** until the diagram becomes a puzzle. Use them sparingly.
- **Only the main flow.** The alternate flows are the point.
- **No guards on decisions**, so readers cannot tell which way the flow goes.

## Quick recap

- UML is a standard notation; analysts mainly use use-case and activity diagrams.
- Use-case diagrams show scope and actors; descriptions hold main and alternate flows.
- Activity diagrams show the flow, with guarded decisions, forks and swimlanes.
- Name use cases as goals, keep actors outside the boundary and write the alternate flows.

## Try it

Open the **Do** tab and draw a use-case diagram and an activity diagram for your own system.


Draw a UML use-case diagram and an activity diagram, and write a use-case description with main and alternate flows.

Use cases and UML

UML use case diagrams: Everything you need to know

UML activity diagram tutorial: How to build your own with Lucidchart

## Why it matters

Processes and use cases describe what happens. A **data model** describes what the system must **remember**. If the model is wrong, every screen and report built on it is wrong too, and fixing a data model late is expensive. Analysts do not usually design the final database, but they sketch a **conceptual or logical model** from the requirements so the business can check it and the developers start from the right shape.

## The three building blocks

- **Entity**: a thing the business needs to keep information about. Usually a noun in the requirements: Member, Room, Booking.
- **Attribute**: a fact about an entity: a room's name and capacity, a booking's date and start time.
- **Relationship**: how entities connect: a member *makes* bookings; a booking *is for* a room.

Each relationship has a **cardinality**: how many of one can relate to how many of the other.

| Cardinality | Library example |
|---|---|
| One-to-many (1:N) | One member makes many bookings; each booking is made by one member |
| One-to-many (1:N) | One room has many bookings; each booking is for one room |
| Many-to-many (M:N) | A room has many features (projector, step-free access); a feature appears in many rooms |
| One-to-one (1:1) | Rare; for example a member and their single membership card |

## From requirements to entities

Read the requirements and underline the nouns, then ask which ones the system must store facts about.

> "A **member** can book a **room** for a **date** and **time** of up to two hours. Each room has a **capacity**. Librarians can **cancel** a booking and record a **reason**."

- Member, Room, Booking are entities.
- Date, start time, end time, status and cancellation reason are attributes of Booking.
- Capacity is an attribute of Room.
- "Booking" is the interesting one: it is both a verb in the story and an entity in the model. Events that the business needs to remember (bookings, orders, payments, loans) almost always become entities.

## Drawing the ERD

An **entity relationship diagram (ERD)** draws entities as boxes and relationships as lines. The most common style today is **crow's foot** notation: a "crow's foot" (three prongs) at the "many" end of a line, a single bar at the "one" end.

```text
MEMBER                 BOOKING                   ROOM
---------              ---------------           ----------
id (PK)   ||------<|   id (PK)        |>------|| id (PK)
name                   member_id (FK)            name
email                  room_id (FK)              capacity
                       booking_date
                       start_time
                       end_time
                       status
```

Read it aloud: "one member makes many bookings; one room has many bookings". The **primary key (PK)** uniquely identifies each row. The **foreign keys (FK)** in Booking point to the member and the room.

### Many-to-many becomes a bridge

A room can have many features, and a feature can be in many rooms. Relational databases cannot store M:N directly, so the model adds a **bridge (junction) table**:

```text
ROOM ||------<| ROOM_FEATURE |>------|| FEATURE
               room_id (FK)
               feature_id (FK)
```

## Test the model against the requirements

A model is only right if it can answer the questions the business will ask. Take each report or screen in the requirements and check that the data is there:

- "Show availability for a day" needs bookings with room, date and times. Yes.
- "How many confirmed bookings did each room have last week, including rooms with none?" needs status and date on Booking, and every room. Yes.
- "Which groups have accessibility needs?" There is nothing for that. Either the requirement is out of scope or the model is missing an attribute. Raise it.

This is where SQL helps an analyst. A quick query against sample data shows whether the model really answers the question, before anyone builds screens. Note the trap in the second question: an inner join drops rooms with no bookings, so you need a `LEFT JOIN` and must put the date and status filters in the `ON` clause rather than in `WHERE`.

## Common mistakes

- **Storing a list in one field** ("features: projector, whiteboard") instead of a related table.
- **Missing the event entity**: modelling Member and Room but no Booking.
- **Duplicated facts**: the room name copied onto every booking, which drifts out of sync.
- **Ignoring history**: overwriting a booking's status when the business needs to know when and why it was cancelled.
- **Never testing the model** against the actual reports people want.

## Quick recap

- Entities are things to remember, attributes are facts about them, relationships connect them.
- Find entities from nouns and from events the business must remember.
- Crow's foot ERDs show cardinality; M:N relationships need a bridge table.
- Test the model by checking it can answer every required question; SQL makes that concrete.

## Try it

Open the **Do** tab. The library's model is already built as three tables. Write the query that checks it can answer the sponsor's weekly report.


Find entities, attributes and relationships in requirements, sketch an ERD, and test the model with a SQL query.

Data models for analysts

Entity Relationship Diagram (ERD) Tutorial - Part 1

Entity Relationship Diagrams

Write one measurable goal for the change, with a number and a time frame.

Build a gap table with the columns Area, Current state, Future state, Gap, Action and Owner.

Fill in at least five rows, covering at least three different areas from: process, people, technology, policy and data.

Check that every future state is measurable; rewrite any that are not.

Draw the to-be process map using the same lanes and shapes as your as-is map, and circle every step that changed.

Make sure the to-be map keeps a path for users who cannot use the new system, and note who supports them.

Write a short recommendation: two or three options, the one you recommend and why, and how and when success will be checked.

## Why it matters

By now you know how the process works today (the as-is map), what the business needs (requirements and priorities) and what the system must do and remember (use cases and data model). A **gap analysis** puts these side by side: where are we, where do we want to be, and what exactly has to change to get there? It turns a pile of analysis into a plan that a sponsor can approve and a team can deliver.

## The structure of a gap analysis

A gap analysis answers four questions:

1. **Current state (as-is):** how does it work today, with evidence?
2. **Future state (to-be):** how should it work, and how will we measure it?
3. **Gap:** what is the difference?
4. **Actions:** what will close each gap, who owns it, and when?

The gaps are not only about software. They can be in **process** (steps, hand-offs), **people** (skills, roles, training), **technology** (systems, data, integrations), **policy** (rules) and **data** (missing or poor-quality information).

## Worked example: Riverside Library

Goal agreed with the sponsor: *cut double bookings to zero and staff phone time on bookings by 75% within three months of launch.*

| Area | Current state | Future state | Gap | Action | Owner |
|---|---|---|---|---|---|
| Availability | Members must phone; only staff see the diary | Members see availability online 24/7 | No public view of bookings | Build availability page (FR-01) | Dev team |
| Double bookings | About 1 per week; two staff write in one diary | Zero; system refuses overlaps | No single source of truth | Online booking with overlap check (FR-02, FR-03) | Dev team |
| Confirmation | Phone call back, often forgotten | Automatic email on booking | No automated notice | Confirmation email (FR-04) | Dev team |
| Staff time | About 6 hours a week on booking calls | Under 1.5 hours a week | Manual handling of every booking | Online self-service; staff handle exceptions only | Head librarian |
| Skills | Staff use the paper diary | Staff manage bookings and rooms in the system | No training | Two 1-hour training sessions before launch | Analyst + head librarian |
| Policy | Booking rules exist only in staff memory | Rules published and enforced by the system | Rules not written down | Write booking policy; sponsor approves | Head librarian |
| Data | Existing bookings only in the paper diary | All future bookings in the system at launch | Migration needed | Enter the next three months of bookings by hand | Front-desk staff |

Two things to notice. First, several gaps have **non-software actions**: training, a written policy, a manual data migration. Leave those out and the system launches into a library that is not ready for it. Second, every future state is **measurable**, so you can check after launch whether the gap really closed.

## The to-be process

The **to-be map** shows how the process will run once the gaps are closed. Draw it with the same lanes and notation as the as-is map so the differences jump out:

```text
Lane: Member
  (start) Member wants a room
  View availability online
  Choose room and time
Lane: System
  <gateway> Slot free and within rules?
     no  -> Show conflict and next free slot -> back to Member: choose again
     yes -> Save booking
            Send confirmation email
Lane: Member
  (end) Arrive for meeting, room is free
Lane: Librarian
  Handle exceptions only (phone bookings for members without internet, cancellations with a reason)
```

Compare it with the as-is map: the phone call, the paper diary, the forgotten call-back and the double-booking check have gone, and a new System lane does the checking. Keep one path for members who cannot or will not book online. Designing them out is a common and costly mistake, and for a public library it is also an accessibility and fairness issue.

## Turning gaps into a recommendation

Sponsors want options, not just problems. A short recommendation usually covers:

- **Options considered**: for example (A) a shared online calendar with clear rules, (B) an off-the-shelf room booking product, (C) a custom build. Give the cost, time, risk and fit of each.
- **Recommended option and why**, linked to the goals.
- **What stays out of scope** (the Won't haves).
- **How success will be measured** after launch and when you will check.

For a three-room library, an off-the-shelf product may close most gaps faster and cheaper than a custom build. Saying so is part of the analyst's job, even when it means less work for the IT team.

## Common mistakes

- **Only technology gaps**, ignoring training, policy and data.
- **Unmeasurable future states** ("better booking experience").
- **A to-be map in a different notation**, so nobody can compare it with the as-is.
- **No owner or date** on actions, so gaps stay open.
- **Never checking after launch** whether the gap actually closed.

## Quick recap

- A gap analysis compares current and future states, names each gap and assigns actions with owners.
- Look for gaps in process, people, technology, policy and data.
- Draw the to-be map in the same notation as the as-is so the changes are visible.
- Recommend an option, define success measures and check them after launch.

## Try it

Open the **Do** tab and write a gap analysis and to-be map for the process you have analysed through this course.


Compare the current and desired states, write a gap analysis with actions, and sketch the to-be process.

Gap analysis and to-be design

Gap Analysis in 5 Steps.

Business Process Analysis

Model behaviour with use cases and activity diagrams, model data with an ERD, and close the loop with a gap analysis and a to-be design.

Business & Systems Analysis

About this course

Course content

Discovery

Requirements

Modelling Systems

Where this course leads

Next course on the path

Careers that use it