SAND6221 / INSY6211

Complete Study Guide

Systems Analysis and Design
All Learning Units · All Diagrams · Past Paper Patterns

This guide covers every topic tested across past papers 2021–2024. Each section includes
definitions, explanations, worked examples, and fully labelled diagram guides.

Topics marked [ALWAYS ASKED] appear in every past paper. Prioritise these first.
LU1 — Introduction to System Development

1.1 Systems Analysis vs Systems Design

[ALWAYS ASKED — appears in every paper]

Systems Analysis [WHAT & WHY] Systems Design [HOW]

• Investigate the current problem • Plan and create the solution to the
• Gather requirements from users and problem
stakeholders • Design the database, interfaces,
• Ask: what must the system do? architecture

• Produces requirement models and diagrams • Ask: how will the system be built?

• Analogy: doctor DIAGNOSING before • Produces design blueprints for

prescribing developers
• Analogy: doctor writing the TREATMENT
PLAN

Key rule to memorise:

You cannot design well without analysing first. Analysis = WHAT the system must do. Design =
HOW it will do it.

1.2 SDLC — Systems Development Life Cycle

[ALWAYS ASKED]

A structured set of guidelines for developing information systems from scratch to deployment.
Called a 'cycle' because systems are continuously improved after going live.

# Core Process What happens here Key outputs

1 Planning Define problem, assess System Vision

feasibility, get approval Document, Project
Plan

2 Analysis Gather and model requirements, Requirement

identify use cases models, diagrams

3 Design Design DB, UI, architecture, Design documents,

security prototypes

4 Implementatio Build, test, train users, deploy Working deployed

n the system system

5 Support Monitor, fix bugs, add Updated and

improvements maintained system

System Vision Document [DEFINITION] Project Plan [DEFINITION]

• Captures the BIG PICTURE before any work • The HOW and WHEN of the project
begins • Contents: timelines, resources, costs,
• Contents: problem definition, proposed responsibilities
solution, expected benefits • Purpose: guides how the project will be
• Purpose: gets everyone aligned on WHAT executed
and WHY • Also created during Core Process 1
• Created during Core Process 1 (Planning) (Planning)
1.3 Iterative Development

Iterative development builds the system in small, repeating cycles rather than all at once.
Each cycle (called an iteration or sprint) produces a working version that improves on the
last.

• Think of it like building a car: skateboard → scooter → bicycle → motorcycle → car.

Each version works and is usable.
• Feedback is gathered after each iteration and used to improve the next
• This is the foundation of Agile development
• Reduces risk because problems are discovered and fixed early

1.4 Three Types of Models

The 3 Generic Model Types [LU1] Textual Models [ASKED 2021]

• 1. Requirement Models — describe WHAT • Use Case Description — text describing

the system must do. Examples: use case one use case step by step
diagram, activity diagram • User Story — short informal description
• 2. Design Models — describe HOW the from the user's point of view
system will be built. Examples: class • User Story format: 'As a [user], I want
diagram, sequence diagram to [goal], so that [benefit]'
• 3. Implementation Models — describe HOW • Exam tip: know at least one example of
the system is deployed. Example: component each model type
diagram
LU2 — Systems Analysis

2.1 Functional vs Non-Functional Requirements

[ALWAYS ASKED — every single past paper]

Functional Requirements [WHAT the system DOES] Non-Functional Requirements [HOW WELL it does it]

• Actions or behaviours the system must • Quality constraints — not features

perform • e.g. System must be available 24/7
• e.g. The system must allow users to log • e.g. Page must load within 2 seconds
in
• e.g. All data must be encrypted
• e.g. The system must send a booking
• e.g. System must support 100 concurrent
confirmation
users
• e.g. Users must be able to submit a tax
• Categories: FURPS (see table below)
filing
• e.g. The system must register new client
profiles

FURPS Category What it covers Real example

Functionality Core features the system must have User can log
in, submit
form, register

Usability How easy and intuitive the system Intuitive UI,

is accessible
design, clear
menus

Reliability How often it works without failing 99.9% uptime,

auto-recovery
in 1 hour

Performance Speed, capacity, response time Loads in under

2 seconds,
handles 100
users

Security Data protection and access control Encrypted data,

MFA login,
access control

2.2 Stakeholders

What is a Stakeholder? [DEFINITION] Internal vs External [DISTINCTION]

• Anyone who has an interest in the system • Internal: employees within the
being developed organisation
• Can provide requirements and information • Examples: manager, developer, office
• Different stakeholders have different assistant, clerk
needs and perspectives • External: people outside the
organisation
• Examples: clients, customers,
regulators, suppliers

2.3 Use Cases and How to Find Them

[ALWAYS ASKED — use case diagrams and descriptions carry 14-30 marks]
What is a Use Case?
A use case is a specific task or goal that an actor wants to accomplish using the system.

• Named as VERB + NOUN: e.g. Register Profile, Submit Tax Filing, Approve Request
• Actor = the person or system that interacts with the system (drawn as a stick figure)
• Use Case = a single goal or task (drawn as an oval inside the system boundary)

Event Decomposition Technique [ALWAYS ASKED] User Goal Technique [ALSO ASKED]

• Step 1: Identify all events the system • List all users and actors of the system
must respond to • For each actor, ask: what goals do they
• Step 2: Classify each event as External, want to achieve?
Temporal, or State • Each goal = one use case
• Step 3: Each event becomes one use case • Example: Parent wants to book nanny,
• External event: an actor triggers it track booking, make payment
(user submits a form) • Result: 3 use cases — Book Nanny, Track
• Temporal event: time triggers it Booking, Make Payment
(monthly report runs automatically)
• State event: a condition triggers it
(account balance drops to zero)

2.4 Use Case Description — Fully Developed

[ALWAYS ASKED — 14-15 marks in most papers]

Field What to write Example — Accounting System

Use Case Name Verb + Noun, specific Submit Tax Filing

and clear

Actor(s) Who triggers or Registered Client

participates in it

Preconditions What must be true BEFORE Client is logged in and

it starts identity verified

Trigger What event starts the Client selects Tax Filing

use case from the services menu

Main Flow Step-by-step normal path 1. Client selects service 2.

(numbered) System displays form 3.
Client completes and submits
4. System validates and
processes filing

Alternative What happens if 3a. Validation fails: system

Flow something goes wrong shows error message and asks
client to re-enter details

Postconditions What is true AFTER the Filing submitted

use case ends successfully, confirmation
sent to client
Brief Use Case Description [SHORT VERSION] Fully Developed Description [DETAILED VERSION]

• Just 1-2 sentences summarising the use • Complete table with all fields: name,
case actor, preconditions, trigger, main flow,
• Example: 'Submit Tax Filing: Client alternative flow, postconditions
selects a tax filing request from the • Used when a use case needs to be fully
services menu. System processes the understood before development
request and confirms submission.' • Worth significantly more marks in
assessments
Diagrams — How to Draw Them

Activity Diagram
[ALWAYS ASKED — 12-30 marks]

Shows the workflow of a process step by step. Uses swimlanes (vertical columns) to separate
who does what. Every actor gets their own swimlane.

Activity Diagram — Symbols & Structure

Actor A Actor B Actor C

← Start node (filled circle)

Arrow crosses lanes →

Activity (Actor A) Activity (Actor B)

← Rounded rect = activity

[yes] ← Diamond = decision

Alt activity Decision?

[no]

← Thick bar = fork/join

← End node (bull's-eye)

SWIMLANE = one per actor | ROUNDED RECT = activity | DIAMOND = decision | THICK BAR = fork/join | BULL'S-EYE = end

Step-by-step: how to draw an activity diagram

• Step 1: Count the actors in the case study — each one gets a swimlane (vertical column)
• Step 2: Draw vertical lines to create the swimlanes, label each one at the top with the
actor name
• Step 3: Start with a FILLED CIRCLE (start node) in the first actor's swimlane
• Step 4: Add ROUNDED RECTANGLES for each activity or action performed
• Step 5: Use DIAMOND shapes for decisions. Write the condition inside. Add [yes] and [no]
on the outgoing arrows
• Step 6: Use ARROWS to show the flow between activities. Arrows can cross swimlanes when
control passes to another actor
• Step 7: End with a BULL'S-EYE (filled circle inside a larger circle) end node
• Step 8: Add a THICK HORIZONTAL BAR if multiple activities happen simultaneously (fork or
join)

Use Case Diagram

[ALWAYS ASKED — 20-30 marks]
 Use Case Diagram — Symbols & Structure

System Boundary
(labelled rectangle)

Log In <<include>>
(dashed = always occurs) View Report
Submit Request

Register

Oval = use case

User Admin
Stick figure
= actor

OVAL = use case | STICK FIGURE = actor (outside boundary) | RECTANGLE = system boundary | <<include>> = always | <<extend>> = optional

Step-by-step: how to draw a use case diagram

• Step 1: Draw a large rectangle and label it with the system name — this is the system
boundary
• Step 2: Identify all actors from the case study. Draw them as STICK FIGURES outside the
rectangle
• Step 3: Identify all use cases using the Event Decomposition or User Goal technique
• Step 4: Draw each use case as an OVAL inside the system boundary rectangle
• Step 5: Draw SOLID LINES connecting each actor to the use cases they are involved in
• Step 6: Add a DASHED ARROW with <<include>> for use cases that always trigger another
use case
• Step 7: Add a DASHED ARROW with <<extend>> for use cases that optionally extend another
use case
• Tip: every time an actor 'does something' to the system in the case study = one use case

Design Class Diagram

[ASKED IN 2024 EXAM — LU5]

Design Class Diagram — Structure & Symbols

Client Order
+email: String 1 places * +status: String

+name: String +date: Date

-clientID: int -orderID: int

+login(): bool +cancel(): void

+register() +place()

Top = class name

Middle = attributes
Bottom = methods
+ = public | - = private | # = protected | attribute: type | method(): returnType | 1 and * = cardinality
Structure of a design class diagram:
• Each class is drawn as a rectangle divided into 3 horizontal sections
• TOP section: the class name — bold and centred
• MIDDLE section: attributes — format is [visibility] attributeName: dataType
• BOTTOM section: methods — format is [visibility] methodName(params): returnType
• Visibility symbols: + = public - = private # = protected
• Example attribute: - clientID: int + name: String
• Example method: + login(): boolean + getDetails(): String
• LINES between classes show associations. Numbers at each end show cardinality: 1, *,
0..1, 1..*
• HOLLOW TRIANGLE arrowhead = generalisation/inheritance (a subclass extends a superclass)

CRC Cards
[ASKED IN 2023 THA — LU5]

CRC Card — Front (left) and Back (right)

FRONT — Class: Client BACK — Collaborators

RESPONSIBILITIES: COLLABORATORS:

• Store client details • ClientMgmtSubsystem

• Verify identity • ServiceSubsystem

• Select service • Database

• Manage profile

CRC = Class | Responsibilities | Collaborators

• FRONT of card: class name at the top, then a list of Responsibilities below
• A Responsibility = something the class DOES (a verb) OR something it KNOWS (an
attribute)
• BACK of card: list of Collaborators — other classes this class works with
• Example responsibilities for Client class: store client details, verify identity, select
service, update profile
• Example collaborators: ClientManagementSubsystem, ServiceSubsystem, Database
• To convert a class to a DB table: class name = table name, attributes = columns, add a
Primary Key column

ERD and Domain Model Class Diagram

 ERD / Domain Model Class Diagram — Entities & Cardinality

places
1* contains
** generates
11
Client Order Product Invoice

1 = one | * = many | 0..1 = zero or one | 1..* = one or more | Line = relationship | Label = relationship name

ERD (Entity Relationship Diagram) [OLDER Domain Model Class Diagram [MODERN APPROACH]
APPROACH] • Used in object-oriented development
• Used in structured/older development approaches
approaches • Classes instead of entities
• Entity = rectangle (represents a • Shows associations, generalisation, and
real-world thing) multiplicity
• Relationship line between entities with • Generalisation: subclass inherits from
cardinality superclass (hollow triangle arrow)
• Cardinality notation: 1, M, 1..*, 0..1 • Example: Employee generalised into
• Example: Client 1 ■■ * Order (one Manager and Developer
client places many orders)
LU3 — Systems Design

3.1 The 5 Design Activities

[ALWAYS ASKED — 10-15 marks]

# Design Activity What you do during this activity

1 Application Decide how the system components are

Architecture structured and how they interact. Choose the
deployment model: client-server, web-based,
cloud, 3-tier, etc.

2 User Interface (UI) Design all screens, forms, menus, and

navigation flows. Apply usability principles
including affordance and visibility.

3 System Interfaces Design how this system communicates with

external systems, APIs, databases, or
subsystems.

4 Database Design Design tables, relationships, and keys.

Convert class diagrams to a relational
schema. Ensure referential integrity.

5 System Security Plan access control (identification,

authentication, authorisation), encryption,
and all data protection measures.

3.2 Visibility and Affordance

[ASKED IN 2024 EXAM AND 2021 THA]

Affordance [DEFINITION] Visibility [DEFINITION]

• The quality of a design element that • Important functions are CLEARLY VISIBLE
HINTS at how it should be used — users should not have to search for them
• A button looks like it can be clicked — • Example: logout button always visible in
that is affordance the top right corner
• A text field with a cursor hints that • Example: save button always on screen
you should type in it while editing a document
• A door with a pull handle tells you to • Poor visibility: hiding the delete
pull it function under 5 nested menus
• Poor affordance: a clickable link that • Rule: the more important the function,
looks like plain text the more visible it should be

User-Centred Design (UCD) [LU3] UX vs UI [DISTINCTION]

• Design approach that keeps user needs at • UI (User Interface) = the actual visual
the centre of every decision elements: buttons, forms, menus
• Principle 1: Involve real users early • UX (User Experience) = the overall
and throughout the process feeling of using the system
• Principle 2: Test designs with real • UX is broader — UI is one component of
users and observe them using the system UX
• Principle 3: Iterate — continuously • Usability = how easy, efficient, and
improve based on user feedback satisfying the system is to use
• Principle 4: Design for the user's • A system can look good (good UI) but
goals, not the developer's convenience feel frustrating to use (poor UX)
LU4 — Methodology and Project Management

4.1 System Development Methodology

[ALWAYS ASKED]

Definition:
A system development methodology is a comprehensive set of guidelines for carrying out all
activities in the SDLC. It has three components:

• 1. MODEL — the overall approach or framework (e.g. Agile, Waterfall, RAD, Scrum)
• 2. TOOLS — software and instruments used (e.g. MS Visio, Jira, Azure DevOps, [Link],
StarUML)
• 3. TECHNIQUES — specific methods used to perform tasks (e.g. Event Decomposition, User
Goal Technique, CRUD Technique)

Predictive SDLC (Waterfall) [OLD / STRUCTURED] Adaptive SDLC (Agile) [MODERN / FLEXIBLE]

• Plan everything in full detail before • Flexible and iterative — build in small
building anything sprints
• Follow phases strictly in order: Plan, • Requirements can change between sprints
Analyse, Design, Build, Test, Deploy based on feedback
• Very little flexibility — changes are • Deliver working software frequently
expensive once a phase is complete (every 2-4 weeks)
• Good when: requirements are completely • Good for most modern software projects
clear and stable from the start • Core idea: respond to change rather than
• Bad when: requirements are likely to following a fixed plan
change during development

4.2 Agile Development

[ALWAYS ASKED — 4-6 marks]

The 4 Agile Values (Manifesto for Agile Software Development):

• 1. Individuals and interactions OVER processes and tools
• 2. Working software OVER comprehensive documentation
• 3. Customer collaboration OVER contract negotiation
• 4. Responding to change OVER following a plan
Note: the right side still has value — the left side is just valued MORE in Agile.
 Scrum Roles [AGILE FRAMEWORK] Agile Scope Management [ASKED 2021]

• Scrum Master: facilitates the team, • Scope = what is and is not included in
removes obstacles, ensures Agile process the project
is followed. NOT a manager. • Managed through the Product Backlog — a
• Product Owner: represents the client, living prioritised list
owns the product backlog, decides feature • Each sprint the team works on the
priority. highest priority backlog items
• Development Team: cross-functional team • Scope can change between sprints based
that builds the product. on stakeholder feedback
• Sprint: a short development cycle, • The Product Owner is responsible for all
typically 1 to 4 weeks. scope decisions
• Product Backlog: prioritised list of all
features still to be built.

4.3 PMBOK — 10 Knowledge Areas

[ALWAYS ASKED — describe at least 4 and relate each to the case study]

# Knowledge Area What the Project Manager manages here

1 Scope Management Defining exactly what is included and

excluded from the project. Prevents scope
creep.

2 Schedule Management Creating and controlling timelines,

milestones, and deadlines throughout the
project.

3 Cost Management Budgeting, estimating costs, and controlling

expenditure during the project.

4 Quality Management Ensuring all deliverables meet the required

standards. Testing and review processes.

5 Resource Management Managing the people, tools, and equipment

needed to complete the project.

6 Communications Keeping all stakeholders informed through

Management reports, meetings, and updates.

7 Risk Management Identifying potential risks, analysing their

impact, and planning responses.

8 Procurement Acquiring goods or services from outside the

Management organisation when needed.

9 Stakeholder Identifying all stakeholders and managing

Management their expectations and engagement.

1 Integration Coordinating all 9 knowledge areas together

0 Management into one cohesive project.
LU5 — Advanced Design and Development

5.1 Database Concepts

Key Terms [DEFINITIONS] Keys and Integrity [CRITICAL CONCEPTS]

• Database: an organised, structured • Primary Key (PK): uniquely identifies

collection of stored data every record in a table. Cannot be null or
• DBMS: software that creates, manages, duplicated.
and controls a database. Examples: MySQL, • Foreign Key (FK): a field that links to
PostgreSQL, MS SQL Server, Oracle a Primary Key in another table. Creates
• Relational Database: data stored in the relationship between tables.
tables (rows and columns) linked by • Referential Integrity: ensures that a FK
relationships always points to an existing PK. No orphan
• Table: stores data about one class or records are allowed.
entity • Example: an Order cannot reference a
• Record or Row: one single instance of Client that does not exist in the Client
stored data table

• Field or Column: one attribute or

property of the data

5.2 Converting a Class to a Database Table

[ASKED IN 2023 THA]

Steps to convert a class to a relational database table:

• Step 1: The CLASS NAME becomes the TABLE NAME (e.g. class Client becomes table: Client)
• Step 2: Each ATTRIBUTE becomes a COLUMN in the table
• Step 3: Add a PRIMARY KEY column (e.g. ClientID — usually an auto-generated integer)
• Step 4: Assign a DATA TYPE to each column: int, varchar, date, boolean, decimal
• Step 5: If the class is related to another class, add a FOREIGN KEY column to represent
that relationship
Example result: Client(ClientID [PK], Name varchar, Surname varchar, IDNumber varchar,
TaxNumber varchar)

5.3 Integrity Controls and Transaction Logging

[ASKED IN 2023 THA]
 Integrity Controls [LU5] Transaction Logging [ASKED 2023]

• Input controls: validate data as it • A transaction log records EVERY change

enters the system. Examples: required made to the database
fields, data type checks, range validation • Records who changed what, when, and what
• Output controls: ensure reports and the old and new values were
outputs are complete and accurate • Purpose 1: AUDITING — track all changes
• Processing controls: ensure data is for accountability and compliance
processed correctly. Examples: checksums, • Purpose 2: RECOVERY — restore the
batch totals database to its last consistent state
• Database controls: referential after a crash
integrity, backups, encryption • Critical in financial and accounting
systems where all transactions must be
traceable

5.4 Software Testing Types

[ALWAYS ASKED — name and describe at least 2 to 3]

Test Type What it tests Who per

forms
it

Unit Testing Individual components or functions Develop

tested in complete isolation from the ers
rest of the system

Integration Testing How multiple components or modules Develop

work together when connected as a ers and
group Testers

System Testing The complete, fully integrated system QA

tested end-to-end as a whole Testing
Team

User Acceptance Whether the completed system meets the Busines

Testing (UAT) original business requirements s stake
holders
and end
users

Performance and Stress How the system behaves under heavy Perform
Testing load or extreme conditions ance
Testers

Regression Testing That all existing features still work Develop

correctly after new changes or fixes ers and
are made Testers
Security Concepts

Access Control — 3 Elements

[ALWAYS ASKED — appears in almost every past paper]

The 3 elements that access control systems rely on:

• 1. IDENTIFICATION — Who are you? The user provides a username or ID to CLAIM an identity
• 2. AUTHENTICATION — Prove it. The system VERIFIES the claimed identity using a password,
biometric, token, or MFA
• 3. AUTHORISATION — What are you allowed to do? The system GRANTS permissions based on
the verified user's role
Memory trick: Identify (claim) → Authenticate (prove) → Authorise (access). Like hotel
check-in: give your booking name, show your ID card, receive your key card.

Encryption and Decryption [ALWAYS ASKED] Authentication Types [SECURITY]

• Encryption: converts readable data • Single-factor authentication: just a

(plaintext) into an unreadable format password — the weakest form
(ciphertext) using an encryption key • Multi-Factor Authentication (MFA):
• Decryption: converts encrypted requires 2 or more forms of verification
ciphertext back into readable plaintext • MFA example: password plus a one-time
using the correct decryption key PIN sent to your phone
• Why it matters: even if data is stolen, • Registered user: a person who has an
it cannot be read without the key active account in the system
• Used for: stored database data, backups, • Privileged user: a user with elevated
and data in transit over networks access beyond standard users, such as an
admin

Development Approaches

Top-Down vs Bottom-Up [ASKED 2021] Incremental Development [ASKED 2021]

• Top-Down: start with the high-level • Build and deliver the system in small,
system structure, then build the detailed usable pieces called increments
components. Testing begins from the top. • Each increment adds new functionality to
• Bottom-Up: start with individual the previous working version
low-level components, then integrate them • Users can start using early increments
into the full system. while later ones are still being built
• Top-Down advantage: tests the overall • Reduces project risk by catching
architecture and design early problems early in the process
• Bottom-Up advantage: individual • This is the core idea behind Agile and
components can be reused and tested in Scrum development
isolation

Subsystems
A subsystem is a self-contained component of a larger system that performs a specific set of
functions and communicates with other subsystems through defined interfaces.

• Why divide into subsystems? Reduces complexity, allows teams to work in parallel, easier
to maintain and update individual parts
• Example: an Accounting System might have: Client Management Subsystem, Services
Subsystem, Billing Subsystem, Reporting Subsystem

Technology Architecture [LU5] Application Architecture [LU5]

• Describes the hardware, networks, and • Describes how software components are
infrastructure the system runs on structured and how they interact
• Examples: cloud servers, physical • Examples: 3-tier architecture
databases, network configuration, hosting (presentation, business logic, data),
environment client-server, microservices, web-based
Past Paper Patterns — What to Expect

Topics in EVERY past paper 2021-2024:

• Q1: Systems Analysis vs Systems Design — always asked, 4-6 marks
• Q1: SDLC core processes — always asked
• Q1: Planning documents (System Vision Document and Project Plan) — always asked
• Q2: Functional vs Non-Functional requirements — always asked, 4-10 marks
• Q2: Activity Diagram — always appears, 12-30 marks
• Q2/Q3: Use Case Diagram OR Use Case Description — always appears, 14-30 marks
• Q2: Event Decomposition or User Goal Technique — appears most years
• Q3: The 5 Design Activities — always asked, 10-15 marks
• Q4: System Development Methodology (Models, Tools, Techniques) — always asked
• Q4: Agile values (all 4 of them) — always asked
• Q4: PMBOK knowledge areas — always asked, describe at least 4
• Q4/Q5: Access Control 3 elements — appears in nearly every paper
• Q5: Software testing types — always asked
• Q5: Database concepts and CRC cards — always asked

Exam technique tips:

• Finding requirements: scan for ACTIONS and VERBS = functional requirements. Scan for
quality words like 'fast', '24/7', 'secure', 'encrypted' = non-functional requirements.
• Finding use cases: every time an actor DOES something to the system in the case study =
one use case. Name it VERB + NOUN.
• Activity diagrams: count the actors first. That number tells you exactly how many
swimlanes you need.
• PMBOK questions: always RELATE each knowledge area specifically to the scenario in the
question. Generic answers score poorly.
• Design activities: memorise the order — Architecture, UI, System Interfaces, Database,
Security.
• Testing: Unit = one piece alone. Integration = pieces working together. System = whole
thing. UAT = user verifies it meets their needs.
• Use case descriptions: the more numbered steps you include in your main flow, the more
marks you earn.
• CRC cards: responsibilities are things the class DOES (actions) or KNOWS (data).
Collaborators are other classes it COMMUNICATES WITH.

SAND6221 / INSY6211 · Complete Study Guide · YOU GOT THIS ✦