Software Requirements Engineering

Lecture 11 — Analysis Modelling & Use Cases

Simplified Slide-by-Slide Study Notes

Every slide from Lecture 11 explained in simple words with a clear example. Follow the same order
as your slides.

Slide 2 — Recap — Complete List of Everything Covered So Far

This is the full list of all elicitation topics covered across all previous lectures:
• Stakeholder Analysis · Interviews · Scenarios · Requirements Reuse
• Observation and Social Analysis · Prototyping · Questionnaires
• Brainstorming · Focus Groups · Collaborative Requirement Gathering · QFD
• Analysis (8-point checklist + interaction matrix) · Negotiation
■ Simple: All the above = how to GATHER requirements. This lecture moves to the next stage: how
to MODEL and REPRESENT those requirements using diagrams and use cases.

Slide 3 & 4 — Key Points — Summary of Elicitation Phase

These are the essential truths about requirements elicitation to remember:
• Elicitation covers 4 things: understanding the application domain, the specific problem, the
organisational needs/constraints, and the specific facilities needed by stakeholders.
• Elicitation, Analysis, and Negotiation are iterative — they repeat in cycles, not in a straight
line. You gather → analyse → negotiate → gather again.
• Many techniques exist — interviewing, scenarios, soft systems, prototyping, observation — use
the right one for each situation.
• Prototypes are highly effective — because stakeholders can actually experiment with
something real, which helps them discover their true requirements.
• Checklists organise validation — they remind analysts what to look for (ambiguity, gold
plating, testability, etc.).
• Negotiation is always needed — to resolve conflicts and overlaps. It involves: information
interchange → discussion → resolution.

Slide 5 — The Full Requirements Engineering Process — All 7 Stages

This slide shows the complete RE process as a cycle. Each stage feeds into the next:

1. Inception
The very beginning — figuring out if the project is feasible and what the rough idea is.
 ■ Example: Is it worth building a new library system? Who wants it? Is there a budget?

2. Elicitation
Gathering requirements from all stakeholders using all the techniques we studied.
■ Example: Interviews, scenarios, observation, brainstorming, etc.

3. Elaboration
Expanding and refining the gathered requirements — building models (use cases, diagrams) to
represent them clearly.
■ Example: Taking the rough requirements and drawing use case diagrams, class diagrams, etc.
THIS is the main topic of Lecture 11.

4. Negotiation
Resolving conflicts between requirements from different stakeholders.
■ Example: Students want 24/7 access; IT wants nightly downtime. Negotiate a compromise.

5. Specification
Writing the final, formal requirements document (the Software Requirements Specification — SRS).
■ Example: The official document that developers will use to build the system.

6. Validation
Checking the specification to make sure it is correct, complete, and consistent.
■ Example: All stakeholders review the SRS and sign off that it correctly represents what they want.

7. Requirements Management
Managing changes to requirements throughout the project lifecycle.
■ Example: A stakeholder requests a new feature after development has started — how do you
handle the change?

■ Key Point: Elaboration (Stage 3) is the main focus of this lecture. It is where you take raw
requirements and turn them into structured models like use cases and diagrams.

Slide 6 — Goals of Analysis Modelling — Why Do We Model?

Analysis modelling means creating diagrams and structured descriptions to represent the
requirements. Here is WHY we do it:
• First technical representation — The analysis model is the FIRST time the system is described
in a technical (not just verbal) way.
• Easy to understand and maintain — A good model is simple enough for everyone to read, and
easy to update when requirements change.
• Handles complexity by partitioning — Big systems are too complex to understand all at once.
Models break the system into smaller, manageable pieces.
• Uses graphics — Diagrams are clearer than pages of text. A picture really is worth a thousand
words here.
 • Separates essential vs implementation info — The model shows WHAT the system must do,
NOT how to code it.
• Helps track interfaces — Shows how different parts of the system connect and communicate.
• Goes beyond text — Provides tools other than narrative text (like flowcharts, state diagrams) to
describe logic and policy.
■ Example: Instead of writing: 'When a user logs in, the system checks their credentials, and if valid,
shows the dashboard, otherwise shows an error' — you draw a simple flowchart. The diagram
communicates the same thing in 5 seconds instead of a paragraph.

Slide 7 — Analysis Rules of Thumb — Guidelines for Good Modelling

These are the golden rules to follow when creating an analysis model:
• Focus on the problem domain — Only model things that are visible to the user and business.
Don't drift into technical details.
• Keep abstraction high — Show the BIG PICTURE, not every tiny detail. Details come later in
design.
• Each element adds understanding — Every diagram or class you add should help explain:
information (what data?), function (what does it do?), or behaviour (how does it react?).
• Delay infrastructure decisions — Don't model databases, servers, or frameworks yet. Those
are design decisions, not requirements.
• Finish problem analysis first — Fully understand the problem BEFORE thinking about
solutions.
• Minimise coupling — Keep different parts of the model as independent as possible. Avoid a
web of connections where everything depends on everything else.
• Provide value to all stakeholders — The model should be useful to managers, developers,
AND end users — not just one group.
• Keep it simple — The simplest model that clearly communicates the requirements is always the
best model.
■ Example: Bad modelling: Creating a detailed database schema (tables, foreign keys, indexes)
during requirements analysis. Good modelling: Drawing a class diagram showing 'Student has many
Courses' — simple, clear, no implementation detail.

Slide 8 — Two Analysis Modelling Approaches

There are two main ways to build an analysis model:

1. Structured Analysis
Treats data and processes as two separate, independent things.
• Data is modelled by showing only its attributes (what information it holds) and relationships (how
pieces of data connect). No operations/functions are attached to data.
• Processes are modelled to show: (1) what data comes IN, (2) what transformation happens to it,
and (3) what data comes OUT.
 ■ Example: For a library system — Data model: 'Book has title, author, ISBN. Member has name, ID,
borrowed books.' Process model: Input = book search query → Transformation = search database →
Output = list of matching books.

2. Object-Oriented Analysis (OOA)

Focuses on identifying classes (objects in the real world) and how they collaborate with each other
to fulfil requirements. Data and behaviour are combined into one class.
■ Example: For a library system — Class 'Book' has attributes (title, author) AND methods/operations
(checkOut(), returnBook(), reserve()). Class 'Member' collaborates with 'Book' by borrowing it.

■ Note: Structured analysis = data and processes are separate. OO analysis = data and behaviour
are combined in classes. Both approaches ultimately produce the same system — just modelled
differently.

Slide 9 & 10 — Elements of the Analysis Model — The 4 Types of Models

An analysis model is made up of 4 types of elements. Two belong to Object-Oriented Analysis, two
to Structured Analysis:

OO Analysis — Element 1: Scenario-Based Modelling

Describes the system from the user's point of view — what the user does and how the system
responds.
• Use Case Text — written description of a use case
• Use Case Diagrams — visual diagram showing actors and use cases
• Activity Diagrams — flowcharts showing steps in a process
• Swim Lane Diagrams — activity diagrams divided by who does each step
■ Example: Use case: 'Student registers for a course' — shown as an oval in a use case diagram
with a stick figure (Student) connected to it.

OO Analysis — Element 2: Class-Based Modelling

Identifies the real-world objects (classes) in the system, their attributes, and how they interact.
• Class Diagrams — show classes, their attributes, and relationships
• Analysis Packages — groups of related classes
• CRC Models — Class-Responsibility-Collaborator cards
• Collaboration Diagrams — show how objects work together
■ Example: Class diagram shows: Student (name, ID) → enrolls in → Course (title, code, seats) →
taught by → Lecturer (name, department).

OO Analysis — Element 3: Behavioural Modelling

Shows how the system changes state in response to events.
 • State Diagrams — show all possible states of the system and what triggers transitions between
states
• Sequence Diagrams — show the order of messages/calls between objects over time
■ Example: State diagram for a library book: Available → [checked out] → On Loan → [returned] →
Available → [reserved] → Reserved.

Structured Analysis — Element 4: Flow-Oriented Modelling

Shows how data flows through the system — what goes in, what transformation happens, what
comes out.
• Data Structure Diagrams — show the structure of data
• Data Flow Diagrams (DFDs) — show data moving between processes
• Control-Flow Diagrams — show decision and control logic
• Processing Narratives — text descriptions of each process
■ Example: DFD for library search: Student inputs 'search query' → 'Search Process' transforms it →
outputs 'search results' to Student.

Slide 11 & 12 — Developing Use Cases — Step by Step

A Use Case describes a specific interaction between an actor and the system to achieve a goal. Here
is how to develop them:

Step 1 — Define the Actors

An actor is anyone (or anything) that interacts with the system from the outside. Actors can be:
• People (users, admins, managers)
• Devices (a card reader, a printer)
• Other systems (a payment gateway, an email server)
Key rule: Actors are external to the system — they use the system but are not part of it.
■ Example: For a university portal: Actors = Student, Lecturer, Admin Staff, Email Server (external
system that sends notifications).

Step 2 — Write each Use Case by answering these questions:

• Who is the primary actor? (Who initiates the use case?) Secondary actor? (Who else is
involved?)
• What are the actor's goals? (What are they trying to achieve?)
• What preconditions must exist? (What must be true BEFORE the use case starts?)
• What main tasks does the actor perform? (The normal flow of steps)
• What exceptions might occur? (What can go wrong?)
• What variations are possible? (Are there alternative ways to do it?)
• What information does the actor give or receive?
• Does the actor need to inform the system about external changes?
 • Does the actor want to be notified about unexpected changes?
■ Example: Use Case 'Withdraw Cash' — Primary actor: Bank Customer. Goal: Get cash.
Precondition: Customer has a valid ATM card and PIN. Main task: Insert card → enter PIN → select
amount → receive cash. Exception: Wrong PIN → card blocked after 3 attempts.

Slide 13 — When to Use Use Cases

The short answer: Always. There is no situation in requirements engineering where use cases are
not useful.
• Use cases are an essential tool for requirements capture and for planning iterative projects.
• Capturing use cases is the primary task of the Elaboration phase.
• Every use case = a potential requirement. If you haven't written a use case for something, you
haven't captured that requirement yet — and you can't plan for it.
• Some teams list and discuss use cases first, then create models. Others model first. Both
approaches work.
• Use cases represent the external view of the system — what it does from the user's
perspective. Don't expect use cases to map directly to internal classes or code.
■ Watch Out: Use cases are NOT good for capturing non-functional requirements like performance,
reliability, or security. Use other techniques (like the quantitative requirements approach from Lecture
10) for those.

■ Example: For a banking system: You identify 20 use cases (Withdraw Cash, Check Balance,
Transfer Funds, etc.). Each one is a requirement. Until you've listed all use cases, you don't know
what you need to build — so you can't estimate cost or time.

Slide 14 & 15 — What is a Scenario? What is a Use Case? — The Difference

Scenario:
A scenario is a sequence of steps describing ONE specific interaction between a user and the
system — one particular path through the system.
■ Example: Online store scenario: 'Customer browses catalogue → adds items to basket → enters
shipping and credit card info → confirms sale → system checks credit card → confirms order → sends
follow-up email.' This is ONE scenario — the successful purchase path.

If the credit card is declined, that is a DIFFERENT scenario — a separate path.

Use Case:
A use case is a SET of scenarios all tied together by the same user goal. The main scenario
(happy path) is the primary scenario, and all the alternative/exception paths are additional scenarios
within the same use case.
■ Example: Use Case 'Buy a Product' contains: Scenario 1 (main/happy path — successful
purchase), Scenario 2 (credit card declined), Scenario 3 (item out of stock), Scenario 4 (customer
cancels). All serve the same goal: buying a product.
 ■ Simple: Scenario = ONE specific path through the system. Use Case = a COLLECTION of all
scenarios for the same goal. Think of a Use Case as a folder, and Scenarios as the files inside it.

Format: A use case is written as a primary scenario (numbered steps) + alternatives (variations noted
at the step where they branch off).

Slide 17 — Additional Sections in a Use Case

Beyond the basic use case, you can add extra sections to make it more complete. The most
important extra is preconditions:
• Preconditions — Things that must be TRUE before the use case can start. These are checked
BEFORE Step 1 of the normal flow.
■ Example: Use Case 'Withdraw Cash' — Precondition: 'Customer has a valid ATM card with a PIN'
and 'Customer's account has sufficient balance (or overdraft facility).' If the precondition is not met,
the use case cannot begin.

■ Note: The advice from the slide: Don't add every possible section. Only add sections that genuinely
help communicate the requirement. Keep use cases as simple as possible while still being complete.

Slide 18 — Use Case Diagrams — Two Ways to Draw a Use Case

In UML (Unified Modelling Language), there are two ways to represent a use case visually:

Way 1 — The Oval

Draw an oval (ellipse) with the name of the use case written inside it. This is the simple, standard
way.
Limitation: The oval doesn't have space for detailed sections (preconditions, flows, etc.).
■ Example: A simple oval labelled 'Withdraw Cash' connected by a line to a stick figure labelled
'Bank Customer'.

Way 2 — The Classifier Rectangle (for detail)

Draw a rectangle (like a class box) with the use case name inside and a small oval in the top-right
corner. This format allows you to add detailed compartments (preconditions, flows, exceptions, etc.).
Use the rectangle when you need to show more detail about the use case.
■ Key Point: For exam diagrams: Use the oval for simple use case diagrams. Use the rectangle
when asked to show a detailed use case with preconditions and flows.

Slide 20 & 21 — Actors — Everything You Need to Know

An actor is a role that someone (or something) plays in relation to the system. Important things to
understand about actors:

Roles, not job titles:

One PERSON can play multiple roles (be multiple actors). One ROLE can be played by many people.
■ Example: In a trading system, one senior trader might play the roles of both 'Trading Manager'
AND 'Trader'. Meanwhile, there may be 50 different people all playing the 'Trader' role. The system
sees them all the same way — they all perform the same use cases.

Actors and Use Cases:

• One actor can perform MANY use cases.
• One use case can be performed by SEVERAL actors.
• In practice: when facing a big system, it's easier to list actors first, then figure out what use
cases each actor needs. This is a good strategy for finding all use cases.

Actors don't have to be human:

An actor can be an external system that needs information from your system. Even though actors
are drawn as stick figures in UML, they don't represent people only.
■ Example: In a university portal, the 'Email Server' is an actor — it receives notifications from the
portal and sends them to students. It's a system, not a person, but it's still an actor.

Who to show as actors:

• Some people show ALL external systems and humans as actors.
• Others show only the actor who initiates the use case.
• Best practice (recommended): Show the actor who gets value from the use case — the
primary actor.

Slide 23, 24 & 25 — More on Actors — Tracking and External Events

When to track actors carefully:

• When the system needs to be configured differently for different types of users — each type
is a separate actor, and use cases show what each actor needs.
• Tracking which actors want which use cases helps you negotiate priorities — if two actors both
want the same use case, it becomes high priority.

Use Cases without clear actors — External Events:

Some use cases are triggered by external events rather than a human actor.
• Think about everything that happens in the outside world that your system needs to react to.
• An event may trigger a system reaction with no user involvement — or it may mainly involve
users.
■ Example: For a utility company: The use case 'Send Out Bill' is triggered by the end of a billing
period (an external time event) — not by any specific user pressing a button. The system
automatically generates and sends bills. Identifying such events helps you find use cases you might
otherwise miss.

■ Key Point: Strategy: List all external events → Each event that the system must react to →
Becomes a use case. This is a powerful technique for finding hidden use cases.
Slide 27 — System Boundaries
A system boundary defines exactly what IS your system and what is OUTSIDE it (i.e., what is an
actor).
In a use case diagram, the system boundary is drawn as a simple rectangle. All use cases go
INSIDE the rectangle. All actors go OUTSIDE the rectangle.

Why system boundaries matter:

• They define the scope of your project — what you are responsible for building and what you are
not.
• They prevent scope creep — if discussions start moving into territory outside your system, the
boundary diagram reminds you it's not your responsibility.
■ Example: ATM System boundary: INSIDE the rectangle = 'Withdraw Cash', 'Check Balance',
'Transfer Funds'. OUTSIDE (actors) = Bank Customer, Banking System (the back-end bank server).
The ATM system does NOT need to design the back-end banking system — that's a separate actor
outside the boundary.

■ Simple: The system boundary rectangle says: 'We build what's inside this box. Everything outside
is someone else's job — we just need to communicate with it.'

Slide 29 — 33 — Use Case Relationships — Include, Generalisation, Extend

When multiple use cases share common steps or variations, you don't repeat yourself. Instead, use
one of these three relationships:

1. «include» Relationship
Use include when the SAME chunk of behaviour appears in TWO OR MORE use cases and you
want to avoid repeating it. Extract it into its own use case and include it from the others.
• The included use case is always executed — it's not optional.
• Notation: A dashed arrow with «include» label pointing TO the shared use case.
■ Example: Both 'Analyse Risk' and 'Price Deal' require a step called 'Rate the Deal'. Instead of
writing that step in both use cases, create a separate use case 'Rate the Deal' and draw include
arrows from both use cases to it.

2. Generalisation Relationship
Use generalisation when one use case is similar to another but does a bit more — like a child class
inheriting from a parent.
• The child use case inherits all the steps of the parent, then adds or overrides some.
• This is a casual, informal way to handle alternative scenarios.
■ Example: 'Pay by Cash' and 'Pay by Credit Card' are both versions of 'Make Payment'. 'Make
Payment' is the general use case. The two specific payment methods are specialised versions of it —
they inherit the general payment steps and add their own specific steps.
3. «extend» Relationship
Use extend when one use case can optionally add behaviour to another use case — but ONLY at
specific declared points called extension points.
• The base use case declares 'extension points' — places in its flow where extra behaviour MAY
be added.
• The extending use case adds behaviour at those points — but only when certain conditions are
met.
• The base use case is complete without the extension — the extension is optional.
• Notation: A dashed arrow with «extend» label pointing FROM the extending use case TO the
base use case.
■ Example: Base use case 'Buy Product' has an extension point at step 6 'Apply Discount'. The
extending use case 'Apply Loyalty Discount' only triggers at that extension point, and only if the
customer is a loyalty member. The base use case works fine without it.

Quick Decision Guide — Which Relationship to Use?

• «include» → You are repeating the same steps in 2+ use cases. Extract and share them.
• Generalisation → One use case is a variation of another. Describe it casually without strict
rules.
• «extend» → One use case optionally adds to another at declared extension points. Strict and
controlled.
■ Key Point: Generalisation and extend both let you split a use case that is getting too complicated.
Include helps you avoid repeating yourself.

Slide 34 — 39 — Full Use Case Template — All Sections Explained

This is the standard format for writing a complete use case document. Learn each section and what
goes in it:

Use Case ID A unique identifier for this use case.

Example: UC-1.2.1 (follows a numbering scheme so use cases can be referenced

easily)

Use Case Name A short, active verb phrase describing what the actor does.

Example: 'Withdraw Cash' / 'Register for Course' / 'Search Book Catalogue'

Actors List all actors: primary (who initiates it) and secondary (who else is involved).

Example: Primary: Bank Customer. Secondary: Banking System (validates account).

Description One or two sentences explaining the PURPOSE and OUTCOME of this use
case.

Example: 'This use case allows a bank customer to withdraw cash from their account
using an ATM machine.'
Trigger The event that STARTS the use case — what causes it to begin?

Example: 'Customer inserts their ATM card into the machine.' OR 'End of billing
period is reached.'

Preconditions Conditions that MUST be true BEFORE the use case can start. If any
precondition fails, the use case cannot begin.

Example: 1. Customer has a valid ATM card with an active PIN. 2. Customer account
has available balance.

Postconditions The state of the system AFTER the use case ends. Include: (a) success
guarantees — what happens when the goal IS achieved, and (b) minimal
guarantees — what must still happen even if the goal is NOT achieved.

Example: Success: Customer receives cash, account balance reduced. Minimal:

ATM card is always ejected, even if transaction fails.

Normal Flow The step-by-step description of WHAT HAPPENS when everything goes right —
the 'happy path'. Number each step clearly.

Example: 1. Customer inserts ATM card. 2. System prompts for PIN. 3. Customer
enters PIN. 4. System validates PIN. 5. System prompts for transaction type... etc.

Alternative Flows Legitimate branches from the normal flow — special conditions that change the
path but still result in a valid outcome.

Example: Step 4a: If customer is not in the bank network → System prompts to
accept a network fee → Customer accepts → resume from Step 5.

Exceptions Error conditions — things that go WRONG. How does the system respond to
each error?

Example: Step 2a: If customer enters invalid PIN 3 times → Card is blocked → Use
case ends.

Includes List any other use cases that are always called/executed as part of this use case
(using the «include» relationship).

Example: 'Authenticate User' is included in all ATM transactions.

Special Any non-functional requirements specific to this use case (performance, security,
Requirements accessibility).

Example: 'The PIN validation must complete within 2 seconds.' 'The screen must be
readable in direct sunlight.'

Assumptions Things assumed to be true when writing this use case.

Example: 'The Bank Customer understands either English or Spanish language.'

Notes & Issues Any open questions or things still to be decided (TBDs).

Example: 'What is the maximum cash withdrawal amount per transaction? TBD.'
Slide 26 — Summary — What This Lecture Covered
Lecture 11 covered the transition from gathering requirements to modelling them:
• The 7-stage RE process — Inception → Elicitation → Elaboration → Negotiation →
Specification → Validation → Management
• Goals and rules of analysis modelling — why we model and how to do it well
• Two modelling approaches — Structured Analysis (separate data/processes) vs
Object-Oriented Analysis (combined classes)
• 4 model element types — Scenario-based, Class-based, Behavioural, Flow-oriented
• Scenarios vs Use Cases — scenario = one path; use case = all paths for one goal
• Actors — roles (not people), can be human or system, find them first to discover use cases
• Use Case Diagrams — ovals or rectangles, inside a system boundary rectangle
• 3 Use Case Relationships — «include» (shared steps), Generalisation (variation, casual),
«extend» (optional addition at extension points)
• Full Use Case Template — ID, Name, Actors, Description, Trigger, Preconditions,
Postconditions, Normal Flow, Alternative Flows, Exceptions, Includes, Special Requirements,
Assumptions, Notes

■ Quick Reference for Exam

Stage 3 of RE — expanding raw requirements into structured models like
Elaboration Phase
use cases and diagrams

First technical representation of system — uses graphics, separates WHAT

Analysis Model Goal
from HOW

Models data and processes SEPARATELY — data has

Structured Analysis
attributes/relationships, processes have inputs/transformations/outputs

Models classes that combine data AND behaviour — classes collaborate to

OO Analysis
fulfil requirements

4 Model Elements Scenario-based · Class-based · Behavioural · Flow-oriented

A sequence of steps describing ONE specific path through a user-system

Scenario
interaction

Use Case A SET of scenarios all tied together by a common user goal

A ROLE played by a person, device, or external system that interacts with

Actor
the system from outside

The actor who gets value from / initiates the use case (recommended to
Primary Actor
show on diagram)

List actors first → then find use cases for each actor OR list external events
Find Use Cases Strategy
→ each event = a use case

Rectangle that separates what IS your system (use cases inside) from what
System Boundary
is outside (actors)
 Shared behaviour used in 2+ use cases → extracted into a separate use
«include»
case, ALWAYS executed

Child use case inherits parent use case and adds/overrides — casual
Generalisation
variation handling

Optionally adds behaviour to base use case at declared extension points —

«extend»
base works fine without it

Preconditions Conditions that MUST be true before the use case can start

State of the system after the use case ends (success guarantees + minimal
Postconditions
guarantees)

The happy path — step-by-step description of what happens when

Normal Flow
everything goes right

Alternative Flows Legitimate branches from the normal flow for special conditions

Exceptions Error conditions — what goes wrong and how the system responds

Non-functional requirements (performance, reliability, security) — use

Use cases NOT good for
quantitative methods instead

Good luck on your exam! ■