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

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.