SOFTWARE ENGINEERING

C7-SEN-11 | Complete Study Guide

Covering All Four Assessment Sections

Botho University | Faculty of Engineering & Technology
Jan-Jun 2026 Semester

C7-SEN-11 Software Engineering Study Guide | Page 1

SECTION 1: System Modelling & Use Case Diagrams

1.1 What is System Modelling?

System modelling is the process of creating abstract representations of a system from
different perspectives before implementation. These models help engineers, designers, and
stakeholders understand, communicate, and reason about the system's structure and
behaviour.

Why System Modelling is Important Before Implementation

• Clarifies Requirements: Models force stakeholders to be precise, exposing
ambiguities and contradictions in requirements before any code is written.
• Reduces Cost: Errors caught at the design stage cost significantly less to fix than
errors discovered after implementation.
• Improves Communication: Visual models (like Use Case Diagrams and Class
Diagrams) are easier for both technical and non-technical stakeholders to understand
than plain text.
• Supports Complexity Management: Large systems are broken into manageable
views; each model shows a particular aspect of the system.
• Provides Documentation: Models serve as persistent documentation that can be
used for maintenance, testing, and future development.
• Enables Early Validation: Stakeholders can validate that the model matches their
expectations before development begins, reducing rework.

1.2 Types of System Models

Different models address different concerns about a system:

Model Type Description & Purpose

Context Model Shows how the system relates to its environment and external
entities. Defines the system boundary and identifies external
actors/systems that interact with it.
Use Case Model (Behavioural) Captures the functional requirements by showing interactions
between actors (users/systems) and the system. Expressed as Use
Case Diagrams.
Structural Model (Class Shows the static structure of the system: classes, attributes,
Diagram) methods, and relationships between objects.
Interaction Model (Sequence Shows how objects or components communicate over time through
Diagram) messages; useful for understanding process flows.
Data Flow Model Illustrates how data moves through a system — from input, through
processes, to storage or output.
State Machine Model Models system behaviour by showing states an object can be in
and the transitions triggered by events.

C7-SEN-11 Software Engineering Study Guide | Page 2

 EXAM For the ThutoLesedi scenario, the two most relevant models are: (1) Use Case Model —
TIP to capture what students and lecturers can do; and (2) Structural/Class Model — to
represent entities like Student, Course, Timetable, and Lecturer.

1.3 Use Case Diagrams — Complete Guide

A Use Case Diagram is a type of behavioural model from UML (Unified Modelling
Language). It shows the functional requirements of a system by describing interactions
between actors and use cases.

Key Components
Component Description
Actor A role played by a person, system, or organisation that interacts
with the system. Drawn as a stick figure. Can be primary (initiates
action) or secondary (supports the system).
Use Case A specific function or service the system provides. Drawn as an
oval/ellipse containing a verb phrase (e.g., 'Register for Course').
System Boundary A rectangle that encloses all use cases, representing the scope of
the system being modelled.
Association A solid line connecting an actor to a use case, showing which
actors participate in which use cases.
<<include>> A dashed arrow showing that one use case always includes the
behaviour of another. The base use case is incomplete without the
included one.
<<extend>> A dashed arrow showing that one use case optionally adds
behaviour to another under certain conditions.
Generalisation A solid arrow with a hollow triangle, showing that one actor or use
case inherits from a more general one.

Use Case Diagram for ThutoLesedi Online Course Registration System

Actors identified from the scenario:
• Student — logs in, registers for courses, drops courses, views timetable
• Lecturer (Academic Staff) — approves course registrations, updates course
information

Use Cases:
• Login (Student, Lecturer)
• Register for Course (Student)
• Drop Course (Student)
• View Timetable (Student)
• Approve Course Registration (Lecturer)
• Update Course Information (Lecturer)

C7-SEN-11 Software Engineering Study Guide | Page 3

 NOTE Login is shared by both actors. You can draw separate associations from each actor to
the Login use case, or use Generalisation with a generic 'User' actor that both Student
and Lecturer inherit from.

Textual Description of the Diagram (draw this in your submission):

• System boundary rectangle labelled: 'Course Registration System'
• Student (stick figure) on the left — connected to: Login, Register for Course, Drop
Course, View Timetable
• Lecturer (stick figure) on the right — connected to: Login, Approve Course
Registration, Update Course Information
• 'Register for Course' uses <<include>> to 'Login' (must be logged in to register)
• 'Approve Course Registration' may <<extend>> 'Send Notification' (optional
notification to student)

C7-SEN-11 Software Engineering Study Guide | Page 4

SECTION 2: Requirements Engineering

2.1 What is Requirements Engineering?

Requirements Engineering (RE) is the process of defining, documenting, and maintaining
the requirements for a software system. It is one of the most critical phases of software
development — poor requirements are the leading cause of project failure.

2.2 Stakeholder Identification & Analysis

A stakeholder is any individual, group, or organisation that has an interest in or is affected by
the system. Stakeholders can be direct users, indirect users, developers, regulators, or even
competitors.

Categories of Stakeholders
Category Description
Primary Stakeholders Directly use or operate the system (e.g., hotel customers, hotel
staff).
Secondary Stakeholders Indirectly affected by the system (e.g., hotel management, IT
department).
Key Stakeholders Have authority or significant influence over the project (e.g.,
investors, executives).
External Stakeholders Regulators, payment processors, third-party service providers (e.g.,
Visa, Mastercard).

Hotel Booking System — Stakeholder Analysis

Stakeholder Role Justification
Customers / Guests Primary users who search and Directly use the system; their experience
book rooms. determines success.
Hotel Staff Receptionists and managers Need reliable tools; their efficiency depends
who update availability. on system accuracy.
Hotel Management Business owners and Concerned with revenue, occupancy rates,
executives. and business performance.
IT / Development Developers and system Responsible for building, maintaining, and
Team administrators. securing the system.
Payment Processors Financial institutions handling Must integrate securely; they are affected
(e.g., Visa) payments. by any payment failures.
Data Protection Government/legal bodies (e.g., Ensure customer data is protected
Regulators GDPR authorities). according to the law.

C7-SEN-11 Software Engineering Study Guide | Page 5

2.3 Functional vs Non-Functional Requirements
Understanding the difference between these two types is critical for the exam.

Type Definition
Functional Requirements (FR) Describe WHAT the system must do — specific behaviours and
functions.
Non-Functional Requirements Describe HOW WELL the system must perform — quality attributes
(NFR) and constraints.

Hotel Booking System — Identifying Requirements

Requirement Type Justification
1. Search for rooms Functional This describes a specific action the system
must perform.
2. System must be very fast Non-Functional Speed is a quality attribute, not a function —
(Performance) it's how well the system performs.
3. Staff update room Functional This is a specific capability/action the system
availability must support.
4. Protect payment Non-Functional Security is a quality attribute constraining how
information (Security) the system handles data.
5. User-friendly interface Non-Functional Usability describes a quality of the system, not
(Usability) a specific function.

2.4 Problems with Requirements

The two main issues with the hotel booking requirements listed are:

Problem 1 — Vagueness / Lack of Measurability

Requirements like 'the system must be very fast' and 'the interface should be user-friendly'
are subjective and unmeasurable. They do not specify how fast (e.g., 'search results must
load within 2 seconds') or what user-friendly means (e.g., 'users must be able to complete a
booking within 3 clicks'). Without measurable criteria, developers cannot know when these
requirements have been met, and testers cannot verify them.

Problem 2 — Incompleteness
The requirements do not specify many important aspects of the system: What types of
rooms can be searched? What payment methods are accepted? What happens when a
booking fails? What access controls exist for hotel staff? These gaps mean the system could
be built without key functionality, leading to costly changes later.

2.5 Techniques to Improve Requirement Clarity

Technique Description

C7-SEN-11 Software Engineering Study Guide | Page 6

 Structured Interviews Analysts conduct in-depth conversations with stakeholders using
open and closed questions to extract detailed, precise
requirements. Follow-up questions help resolve ambiguities.
Prototyping A working prototype (mockup or early version) is built and shown to
stakeholders. Seeing the system visually helps users identify
missing features and clarify what they actually need.
Use Case Analysis Requirements are expressed as use cases with actors,
preconditions, main flow, and alternative flows. This structure forces
precision and reveals edge cases.
User Stories with Acceptance Requirements written as 'As a [user], I want to [do something], so
Criteria that [benefit]' — accompanied by measurable acceptance criteria
specifying exactly when the requirement is satisfied.
Scenarios / Walkthroughs Stakeholders walk through realistic day-to-day scenarios using the
system. This reveals implicit assumptions and requirements that
users take for granted but never mention.

2.6 Why Requirement Validation is Necessary

Requirement validation is the process of checking that requirements are correct, complete,
consistent, and achievable before development begins. It is necessary because:
• Cost of Fixing Errors Increases Exponentially: Changing a requirement during
implementation is significantly more expensive than correcting it during the
requirements phase. Studies show errors can be 100x more costly if caught in
production.
• Ensures Developer-Stakeholder Alignment: Validated requirements confirm that
developers and stakeholders share the same understanding, preventing mismatches
between what was built and what was wanted.
• Prevents Scope Creep: Clear, validated requirements form a baseline — any new
requests can be identified as scope changes rather than unmet requirements.
• Forms the Basis for Testing: Test cases are derived from validated requirements;
without them, there is no reliable way to verify the system is correct.

C7-SEN-11 Software Engineering Study Guide | Page 7

SECTION 3: Software Development Life Cycle
(SDLC)

3.1 What is the SDLC?

The Software Development Life Cycle (SDLC) is a structured process used by software
engineering teams to design, develop, test, and deliver software systems. It provides a
systematic framework that ensures quality, reduces risk, and meets user expectations. The
SDLC consists of well-defined phases, each with specific inputs, outputs, and activities.

3.2 Phases of the SDLC

Phase 1 — Planning
Purpose: Define the scope, objectives, timeline, cost, and feasibility of the project. This
phase answers the question: 'Should we build this system?'
• Feasibility Study: Technical, financial, and operational feasibility are assessed.
• Resource Planning: Budget, team, tools, and technologies are identified.
• Risk Assessment: Potential risks and mitigation strategies are identified early.
• Project Plan: A project schedule (often a Gantt chart) is produced.
Contribution to success: Projects that skip planning often overrun budgets and miss
deadlines. Good planning sets realistic expectations and resource allocation.

Phase 2 — Requirements Analysis

Purpose: Gather, analyse, and document what the system must do (functional) and how well
it must do it (non-functional). Stakeholders are interviewed and requirements are captured.
• Requirements are documented in a Software Requirements Specification (SRS).
• Functional and non-functional requirements are clearly defined and validated.
• Use case diagrams and user stories may be produced here.
Contribution to success: Clear requirements prevent costly misunderstandings between
developers and clients. They serve as the contract for what will be delivered.

Phase 3 — System Design

Purpose: Transform requirements into a blueprint for the system. This phase decides how
the system will be built. Design occurs at two levels:
• High-Level Design (HLD): System architecture, database design, technology stack,
and module breakdown.
• Low-Level Design (LLD): Detailed design of individual modules, algorithms, data
structures, and interfaces.
Contribution to success: A well-designed architecture prevents scalability and maintainability
problems later. Design flaws here are expensive to undo after coding.

C7-SEN-11 Software Engineering Study Guide | Page 8

Phase 4 — Implementation (Coding)
Purpose: Translate the design into working source code. Developers write code according to
design specifications using chosen programming languages and tools.
• Code is written in modules and units based on the design documents.
• Coding standards and guidelines are followed for consistency.
• Version control (e.g., Git) is used to manage code changes.
Contribution to success: Clean, modular, well-commented code is easier to test, debug, and
maintain. Poor implementation creates technical debt.

Phase 5 — Testing & Quality Assurance

Purpose: Verify that the system works correctly, meets requirements, and is free from critical
defects. Testing is conducted at multiple levels:
Test Level What is Tested
Unit Testing Testing individual components or functions in isolation.
Integration Testing Testing how multiple modules work together.
System Testing Testing the complete, integrated system against requirements.
User Acceptance Testing (UAT) End users test the system to confirm it meets their needs before
deployment.

Contribution to success: Testing ensures reliability and user satisfaction. Bugs caught here
are far cheaper to fix than bugs discovered in production.

Phase 6 — Deployment
Purpose: Deliver the tested software to the production environment where users can access
it. Deployment may be staged (gradual rollout) or full release.
• Deployment planning covers data migration, server configuration, and user training.
• A rollback plan is prepared in case the deployment causes unexpected issues.
Contribution to success: Proper deployment ensures minimal disruption and a smooth
transition from the old system (if any) to the new one.

Phase 7 — Maintenance & Support

Purpose: Keep the system operational after deployment. Maintenance is ongoing and
accounts for the majority of a system's total lifecycle cost.
Type Description
Corrective Maintenance Fixing bugs and errors discovered after release.
Adaptive Maintenance Modifying the system to work in a changed environment (e.g., new
OS, new regulations).
Perfective Maintenance Adding new features or improving performance based on user
feedback.

C7-SEN-11 Software Engineering Study Guide | Page 9

 Preventive Maintenance Refactoring and restructuring code to prevent future failures.

Contribution to success: Ongoing maintenance ensures the system remains relevant,

secure, and functional over its operational lifetime.

3.3 SDLC Models

Different projects use different approaches to organising the SDLC phases:
Model Key Characteristic Best Suited For
Waterfall Sequential — complete one phase Simple, well-documented projects with
before starting the next. fixed requirements.
Agile Iterative sprints — deliver small Projects with evolving requirements;
working increments regularly. emphasises collaboration.
Spiral Risk-driven iterations — each cycle Large, high-risk projects where risk
includes planning, risk analysis, management is critical.
engineering, and evaluation.
V-Model Each development phase has a Safety-critical systems (e.g., medical,
corresponding testing phase. aerospace) where validation is
paramount.
Incremental System built and delivered in Systems that need early delivery of
increments; each adds more core features while development
functionality. continues.

C7-SEN-11 Software Engineering Study Guide | Page 10

SECTION 4: Software Architecture

4.1 What is Software Architecture?

Software architecture is the high-level structure of a software system — defining the major
components (modules, services, or layers), their responsibilities, and how they interact. It is
the fundamental organisation of a system, embodied in its components and their
relationships to each other and the environment.

Software architecture is important because it:

• Determines system quality attributes such as performance, scalability,
maintainability, and security.
• Guides all subsequent design and development decisions, serving as the technical
blueprint.
• Enables communication among stakeholders — developers, managers, and clients
— using a shared structural understanding.
• Identifies risks early — structural weaknesses are far cheaper to address during
architecture design than after implementation.
• Supports system evolution — a well-architected system is easier to extend, modify,
and scale as requirements change.

Architecture involves decisions about: how the system is decomposed into components, how
those components communicate (APIs, events, shared memory), where data is stored, and
which technologies and patterns are used.

4.2 Architectural Patterns

An architectural pattern is a proven, reusable solution to a recurring architecture problem.
The following are the most important patterns to know:

Pattern Description, Pros & Cons

Layered (N-Tier) Organises the system into layers (e.g., Presentation, Business
Logic, Data Access). Each layer only communicates with the layer
directly below it. Common in web applications. Pros: Separation of
concerns, easy to maintain. Cons: Can be slower due to multiple
layer traversals.
Microservices Decomposes the system into small, independent services, each
responsible for a specific business function. Services communicate
via APIs (usually REST or messaging queues). Pros: Highly
scalable, independently deployable, fault-isolated. Cons: Complex
to manage; requires strong DevOps practices.
Client-Server A server provides services to multiple clients over a network. The
client handles the user interface; the server handles business logic
and data. Pros: Centralised data management, easy to update
server-side logic. Cons: Server is a single point of failure if not
replicated.

C7-SEN-11 Software Engineering Study Guide | Page 11

 Event-Driven Components communicate by producing and consuming events
(messages). A broker (e.g., Kafka, RabbitMQ) handles event
routing. Pros: Loosely coupled, highly scalable for real-time
systems. Cons: Harder to debug; eventual consistency challenges.
Repository (Blackboard) All components share a central data store (repository). Components
read/write to the shared store independently. Pros: Easy data
sharing. Cons: The repository can become a bottleneck and single
point of failure.
Pipe and Filter Data flows through a sequence of processing components (filters)
connected by channels (pipes). Each filter transforms the data.
Pros: Simple, highly composable. Cons: Not suitable for interactive
systems; each filter must be stateless.

4.3 Architecture Recommendation for the Global Shopping

Platform

Recommended Architecture: Microservices Architecture

Justification: The global online shopping platform must handle millions of users per day,
include multiple distinct capabilities (product browsing, payment, order tracking, inventory),
and be highly reliable and scalable. Microservices architecture is the most suitable choice for
the following reasons:

• Scalability: Each microservice (e.g., Product Service, Payment Service, Order

Service, Inventory Service) can be scaled independently based on demand. During a
sale event, the Product and Payment services can scale without scaling the entire
system.
• Reliability & Fault Isolation: A failure in one service (e.g., the Inventory Service) does
not crash the entire system. Other services continue to operate, protecting the core
user experience.
• Independent Deployment: Each service can be updated, tested, and deployed
independently without system-wide downtime. This supports continuous delivery.
• Technology Flexibility: Different services can use the most appropriate technology —
e.g., the Payment Service could use a highly secure framework while the Browsing
Service uses a fast caching layer.
• Team Scalability: Large engineering teams can work on different services
simultaneously without blocking each other.

4.4 Consequences of Poor Architectural Design

Consequence Detailed Explanation

Performance Degradation A poorly designed architecture (e.g., a monolith without proper
caching or a database that is a bottleneck) will fail under high load.
In a system handling millions of users, this causes slow response
times, timeouts, and eventual system crashes — directly impacting
revenue and user trust.

C7-SEN-11 Software Engineering Study Guide | Page 12

 Inability to Scale If the architecture does not support horizontal scaling (adding more
servers), the system cannot grow with demand. The global
shopping platform would be unable to handle traffic spikes during
promotional events, leading to downtime.
High Maintenance Cost Tightly coupled components make changes risky and expensive. A
change in one area can cause unexpected failures elsewhere.
Developers spend more time managing complexity than adding
features.
Security Vulnerabilities Poor architectural decisions — such as embedding payment
processing within the same service as browsing, or not separating
data access layers — create security weaknesses that can expose
sensitive customer data.

4.5 Security Measures for Safe Payment Processing

Security Measure Explanation

Encryption (TLS/SSL) All data transmitted between the user's browser and the server
must be encrypted using TLS (Transport Layer Security). This
prevents eavesdropping and man-in-the-middle attacks. Payment
pages must use HTTPS.
Tokenisation Instead of storing actual card numbers, the system replaces
sensitive payment data with a randomly generated token. The real
card data is stored securely by a certified payment processor (e.g.,
Stripe, PayPal). This limits exposure in the event of a data breach.
PCI-DSS Compliance The system must adhere to Payment Card Industry Data Security
Standards — a set of security controls required for any system that
handles card payments. This includes access control, network
security, and regular security testing.
Multi-Factor Authentication Require customers and administrators to verify their identity using
(MFA) two or more factors (e.g., password + OTP sent to phone). This
prevents unauthorised access even if credentials are stolen.
Input Validation & SQL Injection All user inputs must be validated and sanitised. Parameterised
Prevention queries must be used to prevent SQL injection attacks that could
expose the payment database.
Rate Limiting & Fraud Detection Limit login and payment attempts to prevent brute-force attacks.
Implement AI-based fraud detection to flag unusual transaction
patterns (e.g., multiple purchases from different countries).

4.6 Reliability and Scalability — Explained in Detail

Reliability
Reliability is the ability of a system to perform its required functions correctly and consistently
under stated conditions for a specified period of time. A reliable system minimises downtime
and produces correct results even under adverse conditions.

C7-SEN-11 Software Engineering Study Guide | Page 13

 • High Availability (HA): The system should target 99.9%+ uptime (three-nines
availability = less than 8.7 hours downtime per year). This is achieved through
redundancy — having backup servers, load balancers, and automatic failover.
• Fault Tolerance: The system continues to operate correctly even when individual
components fail. Techniques include replication, circuit breakers, and health checks.
• Data Consistency: Transactions (especially payment transactions) must be atomic —
either all operations succeed or none do (ACID properties for databases).
• Disaster Recovery: Regular backups and a tested recovery plan ensure the system
can be restored quickly after a catastrophic failure.

Scalability
Scalability is the ability of a system to handle increasing workloads by adding resources
without degrading performance. For a global shopping platform handling millions of users,
scalability is non-negotiable.
Technique Description
Horizontal Scaling (Scale Out) Adding more servers to distribute the load. More appropriate for a
global platform as it provides near-unlimited growth capacity and
avoids single server bottlenecks.
Vertical Scaling (Scale Up) Upgrading the capacity (CPU, RAM) of existing servers. Limited —
eventually you cannot add more to a single machine.
Load Balancing A load balancer distributes incoming requests across multiple
servers, ensuring no single server is overwhelmed.
Database Sharding Splitting a large database across multiple servers (shards), each
responsible for a subset of data. Allows the database layer to scale
with user growth.
Caching Frequently accessed data (e.g., product listings) is stored in a fast
cache (e.g., Redis) to reduce database load and speed up
responses.
Content Delivery Networks Static assets (images, CSS, JS) are distributed to servers
(CDN) worldwide, reducing latency for global users.

C7-SEN-11 Software Engineering Study Guide | Page 14

QUICK REFERENCE: Key Definitions

Term Definition
System Modelling Creating abstract representations of a system from different
perspectives before implementation.
Use Case A description of how a user (actor) interacts with a system to
achieve a specific goal.
Actor A role played by a person, system, or organisation that interacts
with the system.
Functional Requirement Specifies WHAT the system must do — a specific behaviour or
function.
Non-Functional Requirement Specifies HOW WELL the system must perform — quality attributes
like speed, security, usability.
Stakeholder Any individual, group, or organisation with an interest in or affected
by the system.
Requirements Validation Checking that requirements are correct, complete, consistent, and
feasible before development.
SDLC Software Development Life Cycle — a structured process for
planning, designing, building, testing, and delivering software.
Software Architecture The high-level structure of a system defining components, their
responsibilities, and how they interact.
Microservices Architectural pattern where the system is decomposed into small,
independently deployable services.
Scalability The system's ability to handle increased load by adding resources
without performance loss.
Reliability The system's ability to perform correctly and consistently under
stated conditions over time.
Tokenisation Replacing sensitive data (e.g., card numbers) with a non-sensitive
token to improve security.
TLS/SSL Transport Layer Security — a protocol for encrypting data
transmitted over a network.
Fault Tolerance The ability of a system to continue operating correctly when one or
more components fail.
Load Balancing Distributing incoming network traffic across multiple servers to
ensure no single server is overwhelmed.
PCI-DSS Payment Card Industry Data Security Standard — required security
controls for systems that handle payment cards.
Use Case Diagram A UML behavioural diagram showing interactions between actors
and the system's use cases.
<<include>> UML relationship where one use case always includes the
behaviour of another.
<<extend>> UML relationship where one use case optionally extends another

C7-SEN-11 Software Engineering Study Guide | Page 15

 under certain conditions.

Harvard Referencing Reminder

All sources must be cited in Harvard format. Examples:

Book:
Sommerville, I. (2016) Software Engineering. 10th edn. Harlow: Pearson Education.

Journal Article:
Author Surname, Initial(s). (Year) 'Title of article', Journal Name, Volume(Issue), pp. page–
page.

Website:
Author Surname, Initial(s). (Year) Title of page. Available at: URL (Accessed: Day Month
Year).

KEY Ian Sommerville's 'Software Engineering' (10th edition, Pearson, 2016) is the standard
BOOK textbook for this module. Reference it for architecture, requirements engineering, and
SDLC topics.

C7-SEN-11 Software Engineering Study Guide | Page 16