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

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.