SOFTWARE DEVELOPMENT PRACTICES YEAR ONE COURSE NOTES

IN THIS COURSE
A practical introduction to building software systems with people, process, and quality
in mind.

Contents

1 Understanding Software Systems . .

. . . . . . . . . . . . . . . . . . . . . . 1
1.1 Introduction to Software Systems . . . .
. . . . . . . . . . . . . . . . . . . . . . 2
1.2 Programs and Software Systems . . . . .
. . . . . . . . . . . . . . . . . . . . . . 4
1.3 Software as an Engineered Product . . .
. . . . . . . . . . . . . . . . . . . . . . 6
1.4 Software as Part of Society . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 10
1.5 Why Software Systems Become Complex . . . . . . . . . . . . . . . . . . . . . . 13
1.6 Scale, Users, and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7 Managing Complexity Through Structure . . . . . . . . . . . . . . . . . . . . . . 22
1.8 Why Software Needs Systematic Development . . . . . . . . . . . . . . . . . . . 26
1.9 Running Case Study: CampusConnect . . . . . . . . . . . . . . . . . . . . . . . . 31
1.10 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.11 Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2 Planning and Choosing How to Build . . . . . . . . . . . . . . . . . . . . . . 39

2.1 Introduction to Planning a Software System . . . . . . . . . . . . . . . . . . . . . 40
2.2 Understanding the Problem to Be Solved . . . . . . . . . . . . . . . . . . . . . . 42
2.3 Defining the Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.4 Feasibility Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.5 Understanding User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.6 Techniques for Gathering Requirements . . . . . . . . . . . . . . . . . . . . . . . 54
2.7 Types of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.8 Introducing Development Approaches . . . . . . . . . . . . . . . . . . . . . . . 63
2.9 Common Development Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

i
 0 CONTENTS CONTENTS
ii

2.10 Comparing Development Models . . . . . . . . . . . . . . . . . . . . . . . . . . 67

2.11 Choosing a Suitable Development Approach . . . . . . . . . . . . . . . . . . . . 68
2.12 Basic Project Planning Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.13 Running Case Study: CampusConnect Planning . . . . . . . . . . . . . . . . . . . 71
2.14 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.15 Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3 Working with Software Teams . . . . .. .

. . . . . . . . . . . . . . . . . . . 80
3.1 Introduction to Software Teamwork . . . .. .
. . . . . . . . . . . . . . . . . . . 81
3.2 People Involved in a Software Project . . .. .
. . . . . . . . . . . . . . . . . . . 83
3.3 Communication in Software Projects . . .. .
. . . . . . . . . . . . . . . . . . . 87
3.4 Software Engineering Process Frameworks . .
. . . . . . . . . . . . . . . . . . . 90
3.5 Core Framework Activities . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 92
3.6 Umbrella Activities in Software Projects . . . .
. . . . . . . . . . . . . . . . . . . 93
3.7 Project Management in Software Development . . . . . . . . . . . . . . . . . . . 95
3.8 Project Management Styles and Frameworks . . . . . . . . . . . . . . . . . . . . 96
3.9 Introduction to Agile Ways of Working . . . . . . . . . . . . . . . . . . . . . . . 98
3.10 Scrum in Simple Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.11 Kanban in Simple Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.12 Extreme Programming in Simple Terms . . . . . . . . . . . . . . . . . . . . . . . 102
3.13 User Stories, Acceptance Criteria, and Backlogs . . . . . . . . . . . . . . . . . . . 103
3.14 Planning and Tracking Team Work . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.15 Team Challenges in Software Projects . . . . . . . . . . . . . . . . . . . . . . . . 107
3.16 Running Case Study: CampusConnect Teamwork . . . . . . . . . . . . . . . . . . 107
3.17 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.18 Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4 Designing and Building Software . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.1 Introduction to Software Design and Construction . . . . . . . . . . . . . . . . . . 117
4.2 Understanding Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.3 Levels of Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.4 Principles of Good Software Design . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.5 Common Software Design Approaches . . . . . . . . . . . . . . . . . . . . . . . 124
4.6 Designing the Structure of a System . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.7 Designing the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.8 Designing Data and Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.9 Design Tools and Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.10 Introduction to Software Construction . . . . . . . . . . . . . . . . . . . . . . . . 130
4.11 Writing Clear and Maintainable Code . . . . . . . . . . . . . . . . . . . . . . . . 131
4.12 Coding Standards and Team Guidelines . . . . . . . . . . . . . . . . . . . . . . . 132
4.13 Error Handling and Input Validation . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.14 Debugging Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.15 Using Libraries, Frameworks, and Tools . . . . . . . . . . . . . . . . . . . . . . . 136
 0 CONTENTS CONTENTS
iii

4.16 Version Control in Software Construction . . . . . . . . . . . . . . . . . . . . . . 136

4.17 Documentation During Construction . . . . . . . . . . . . . . . . . . . . . . . . 137
4.18 Refactoring and Technical Debt . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.19 Secure Software Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.20 Running Case Study: Designing and Building a Library Management System . . . . . 139
4.21 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.22 Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

5 Connecting, Checking, and Improving Systems . . . . . .. . . . . . . . . . 147

5.1 Introduction to Connecting and Checking Systems . . . . . . . .. . . . . . . . . . 148
5.2 Understanding System Integration . . . . . . . . . . . . . . .. . . . . . . . . . 150
5.3 Integration Types and Strategies . . . . . . . . . . . . . . . .. . . . . . . . . . 151
5.4 Common Integration Problems . . . . . . . . . . . . . . . . .. . . . . . . . . . 152
5.5 Introduction to Software Quality . . . . . . . . . . . . . . . .. . . . . . . . . . 153
5.6 Quality Management, Standards, and Reviews . . . . . . . . . .. . . . . . . . . . 154
5.7 Verification and Validation . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 156
5.8 Testing the System . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 157
5.9 Test Planning and Test Cases . . . . . . . . . . . . . . . . . .. . . . . . . . . . 158
5.10 Defects and Defect Management . . . . . . . . . . . . . . . .. . . . . . . . . . 159
5.11 Preparing the System for Delivery and Deployment . . . . . . .. . . . . . . . . . 160
5.12 System Maintenance, Monitoring, and Improvement . . . . . . .. . . . . . . . . . 161
5.13 Closing a Software Project . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 162
5.14 Running Case Study: Checking and Deploying a Student Registration System . . . . . 163
5.15 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.16 Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
FROM THE EDITOR VOL. 1 / 2026

A Letter to the Reader

HIS COURSE is built for first‐year university students who are beginning to move from

T writing small programs to understanding real software systems. The aim is to make
software development practical, human, and clear from the start.

You will meet ideas such as requirements, product backlogs, sprint planning, sprint reviews,
testing, design, maintenance, and teamwork. These are not empty industry words. They are
everyday practices that help teams build software that people can actually use, trust, and im‐
prove.

Each chapter reads like a textbook but uses the rhythm of a magazine: clear objectives, ex‐
amples, sidebars, checkpoints, case studies, review questions, and practical activities. The ex‐
amples are intentionally close to student life and ordinary organizations: registration portals,
mobile money, learning platforms, clinic appointments, library systems, online shops, and cam‐
pus services.

As you read, keep asking one question: how does this help a team build the right software, for
real users, under real conditions?

Kasozi Vincent Weraaga

Software Development Practices

iv
CHAPTER NO. 1

1
Understanding Software
Systems

FOUNDATIONS FOR PRACTICAL SOFTWARE DEVELOPMENT

œ LEARNING OBJECTIVES
By the end of this chapter, you should be able to:

• Explain the difference between a small program and a software system.

• Describe why software development requires more than writing code.
• Identify the technical and human parts of a software system.
• Explain why real software becomes complex as users, data, rules, and time in‐
crease.
• Use simple examples to describe scale, users, interfaces, components, and system
behavior.
• Connect early software engineering ideas to practical work such as product back‐
logs, sprint planning, testing, and team communication.

1
 1 UNDERSTANDING SOFTWARE SYSTEMS Introduction to Software Systems
2

1.1 Introduction to Software Systems

1.1.1 Why Study Software Systems?

OST STUDENTS MEET SOFTWARE first as a program: a calculator written for class, a

M small web page, a script that adds numbers, or a form that stores a name. These
programs are useful for learning, but they are not the full story of modern software
development. In the real world, software is often part of a larger system involving people, data,
Think beyond code devices, rules, money, time, and risk.

Think about a university registration portal. At first glance, it may look like a website where a
student logs in and registers for course units. But behind that simple screen there are many
connected parts. The portal must know which student is logging in, whether fees have been
paid, which courses are available, whether timetable clashes exist, whether a department has
approved the registration, and whether records must be sent to other offices. A change in one
place can affect many people.

That is why this course begins with software systems. A student who only thinks about code
may ask, “Which programming language should I use?” A software developer who thinks about
systems also asks, “Who will use it? What problem are we solving? What data must be pro‐
tected? What happens when the network is slow? Who approves changes? How will we know
the software is working correctly?”

“A working program answers one question: can the

computer do it? A software system answers a wider
question: can people depend on it in real life?”
SOFTWARE DEVELOPMENT MINDSET

This chapter sets the stage for later topics. We shall not rush into advanced terms. Instead, we
shall build a practical way of seeing software. When students later learn requirements, agile
development, design, testing, deployment, maintenance, and project management, the ideas
will make more sense because they will be connected to real situations.
 1 UNDERSTANDING SOFTWARE SYSTEMS Introduction to Software Systems
3

1.1.2 Software in Everyday Life

Software is now found in ordinary activities. A student checks results on a portal. A shop
attendant records sales using a point‐of‐sale application. A patient receives an SMS reminder
from a clinic. A driver follows a navigation app. A customer pays using mobile money. A lecturer
uploads notes to a learning platform. A supermarket system updates stock when an item is sold.

In all these examples, software is not just a collection of instructions. It supports a real activity.
It changes how people work, communicate, and make decisions. If the software works well,
people may hardly notice it. If it fails, everyone quickly notices. A failed payment system delays
business. A broken hospital records system can affect patient care. A wrong examination record
can create stress for a student and extra work for administrators.

ʢ SIDEBAR | A familiar day with invisible software

Imagine a first‐year student called Amina. In the morning, she checks the university
timetable on her phone. She pays for lunch using mobile money. In the afternoon, she
submits an assignment on the learning platform. In the evening, she books a ride home.
Each action depends on software.
Amina may not see databases, servers, networks, security checks, error logs, or backup
systems. Yet all these parts may be working behind the scenes. Software systems often
become visible only when they fail: a login error, a missing payment, a delayed message,
or an incorrect record.

For this reason, the study of software development must be practical. Students need to un‐
derstand how software behaves in the world, not only how code behaves on a laptop. A small
program may run well for the person who wrote it. A real system must run for many different
people, under many different conditions, over a long period.

1.1.3 Chapter Overview

This chapter introduces the idea of a software system. We begin by comparing a program with
a software system. We then discuss software as an engineered product, meaning that it must
be planned, designed, built, tested, and improved carefully. Next, we look at software as part
of society because users, organizations, laws, and ethics shape what software should do.

The chapter then explains why software systems become complex. We shall examine compo‐
nents, connections, scale, users, time, and the consequences of failure. Finally, we discuss how
structure helps manage complexity and why systematic development is necessary. Throughout
the chapter, we shall use real‐world examples that first‐year students can understand: student
registration, mobile money, online shopping, clinic appointments, library systems, and simple
agile team activities.
 1 UNDERSTANDING SOFTWARE SYSTEMS Programs and Software Systems
4

1.2 Programs and Software Systems

1.2.1 Meaning of a Program

A program is a set of instructions written so that a computer can perform a task. A program may
be small or large, simple or difficult. For example, a program can calculate the average mark
of five tests. Another program can convert temperatures from Celsius to Fahrenheit. Another
can display a web page with a contact form.

When students start programming, they usually learn by writing small programs. This is im‐
portant because it teaches logic, variables, conditions, loops, functions, and problem solving.
However, a program used for learning normally has a limited purpose. It may receive input,
process it, and produce output.

Consider a simple program that calculates whether a student has passed a course unit:

® NOTE
If the final mark is 50 or above, display “Pass”. Otherwise, display “Retake”.

This program is useful for learning decision making. But it does not yet answer many real ques‐
tions. Where did the mark come from? Who entered it? Was the student registered for the
course? Has the mark been approved by the department? Can the student appeal? Should the
mark be hidden from other students? What happens if the database is not available?

The moment we ask these questions, we move beyond a simple program and start thinking
about a software system.

1.2.2 Meaning of a Software System

A software system is a set of connected software parts, data, people, procedures, and some‐
times hardware that work together to support a real activity. The software may include pro‐
grams, databases, user interfaces, reports, security rules, communication services, and links to
Systems support other systems.
work

A software system usually has a purpose beyond computation. It helps an organization or a

person do something. A banking system helps manage accounts and transactions. A school
management system helps handle students, fees, marks, timetables, and communication. An
e‐commerce system helps customers find products, pay, and receive deliveries.
 1 UNDERSTANDING SOFTWARE SYSTEMS Programs and Software Systems
5

The word system reminds us that the parts are connected. If one part changes, another part
may be affected. If the payment part of an e‐commerce system fails, orders may remain incom‐
plete. If the timetable part of a university system is wrong, students may register for clashing
course units. If a hospital appointment system sends reminders late, patients may miss ap‐
pointments.

Í Program or system?
A program can often be understood by reading one file or one small group of files. A
software system may require understanding users, rules, data, screens, reports, security,
testing, maintenance, and the environment where it runs.

1.2.3 Difference Between a Program and a Software System

The difference between a program and a software system is not only size. A small system can
still be a system if it connects several parts and supports a real process. A large program can
still be mainly a program if it does not interact with many people, rules, or external services.

A program is usually described by what it calculates or displays. A software system is described

by the activity it supports. A program may answer, “What should the computer do next?” A
software system must also answer, “What should happen in the organization? Who is respon‐
sible? What information is trusted? What happens when something goes wrong?”

Aspect Program Software System

Main focus Instructions and output Real activity supported by con‐

nected parts
Typical user Often the programmer or one Many users with different roles
user
Data Small or temporary Important, shared, protected,
and stored over time
Failure impact Usually limited May affect people, money, op‐
erations, or trust
Change Often easy to change alone Changes require coordination
and testing
Example Calculate a grade University results management
system

This comparison is not meant to reduce the value of programs. Programs are the building blocks
of software systems. But in software development practice, programmers must learn to think
beyond a single block. They must understand how their work fits into the larger whole.
 1 UNDERSTANDING SOFTWARE SYSTEMS Software as an Engineered Product
6

1.2.4 Example: From a Simple Program to a System

Suppose a student writes a program that stores names of books borrowed from a small class
library. The first version may be very simple:

• Enter the student’s name.

• Enter the book title.
• Save the borrowing record.
• Display all borrowed books.

For a class exercise, this is enough. But imagine the same idea is used by a real university library.
The problem changes. The library needs student accounts, book categories, due dates, fines,
staff permissions, search tools, reports, barcode scanners, and backup. It may need to connect
with the university identity system so students can use one login. It may need SMS or email
reminders. It may need reports showing popular books.

The original program has become part of a system.

­ CHECKPOINT
Think about a food ordering app. Identify one feature that looks simple on the screen
but may involve several system parts behind the scenes. For example, what must happen
when a customer presses “Place Order”?

Behind that one button, the system may check the restaurant menu, confirm the price, calculate
delivery fees, request payment, create an order number, notify the restaurant, assign a rider,
update the customer, and store the transaction. The customer sees one action. The system
performs many coordinated actions.

1.3 Software as an Engineered Product

1.3.1 What Does It Mean to Engineer Software?

To engineer something means to build it carefully for a purpose, using knowledge, planning,
design, measurement, and testing. A bridge is not built by simply placing materials until it
looks right. Engineers consider weight, weather, safety, cost, maintenance, and future use. In
the same way, software should not be built by randomly adding code until something appears
Engineering means to work.
discipline
 1 UNDERSTANDING SOFTWARE SYSTEMS Software as an Engineered Product
7

Software engineering is the disciplined practice of developing software that solves real prob‐
lems and can be used, changed, tested, and maintained. It includes programming, but it is
bigger than programming.

When software is engineered, developers ask questions such as:

• What problem are we trying to solve?

• Who will use the software?
• What must the software do?
• What should it not do?
• What data must be stored?
• How will we know that it works?
• What can go wrong?
• How will the software be changed later?

These questions help prevent common failures. Many software problems do not happen be‐
cause developers cannot code. They happen because the team did not understand the real
need, did not communicate clearly, did not test properly, or did not prepare for change.

1.3.2 Why Software Is More Than Code

Code is central to software development, but code alone is not the whole product. A software
product may include:

• Requirements that describe what users need.

• Designs that show how parts of the system will work together.
• Source code that implements the system.
• Databases that store information.
• Tests that check whether the system behaves correctly.
• User manuals or help screens.
• Deployment scripts that place the software in its running environment.
• Monitoring tools that help the team notice failures.
• Support procedures for helping users.

A student may ask, “If the code works, why do we need all these other things?” The answer is
that real software must survive outside the developer’s laptop. It must be used by people who
did not write it. It must be corrected when bugs are found. It must be changed when rules
change. It must be understood by new team members. It must recover from mistakes.
 1 UNDERSTANDING SOFTWARE SYSTEMS Software as an Engineered Product
8

ʢ SIDEBAR | The laptop trap

A common beginner mistake is to think, “It works on my laptop, so it is finished.” In real
projects, this is only the beginning. A system must work for users, on the intended de‐
vices, with real data, under real network conditions, and with security controls in place.

For example, a clinic appointment application may work perfectly when a developer tests it with
three patients. But in a real clinic, the system may face hundreds of appointments, different
doctors, cancellations, emergency cases, wrong phone numbers, and patients who arrive late.
Good software development prepares for these ordinary realities.

1.3.3 Requirements, Design, and Testing as Engineering Activities

Three early activities show why software development is engineering: requirements, design,
and testing.

Requirements describe what the software should do and the conditions it should satisfy. Re‐
quirements may come from users, managers, laws, business rules, or technical constraints. For
a university registration system, a requirement may be: “A student must not register for two
course units that clash on the timetable.” This is not just a programming detail. It is a rule that
protects students and departments from confusion.

Design describes how the system will be organized to meet the requirements. Design may in‐
clude screens, data structures, system components, workflows, and interfaces between parts.
Good design makes the software easier to understand and change.

Testing checks whether the software behaves as expected. Testing is not only pressing buttons
after coding. It involves planning examples, checking normal cases, checking unusual cases,
and confirming that fixed problems do not return.

Ď TIP
In a practical project, requirements, design, and testing are connected. A clear require‐
ment gives the team something to design for and something to test against.

Suppose a product backlog item says:

As a student, I want to see course units available for my programme and year of
study so that I register for the correct units.

This backlog item leads to requirements, design, and testing. The team must clarify which pro‐
gramme the student belongs to, where the list of course units comes from, how the screen
 1 UNDERSTANDING SOFTWARE SYSTEMS Software as an Engineered Product
9

should display them, and what happens if no units are available. Testers must check exam‐
ples such as first‐year students, repeating students, elective units, and students in different
programmes.

1.3.4 Example: Engineering a University Registration System

Let us follow a small project team building part of a university registration system. The team
includes a product owner, two developers, a tester, and a student representative. The product
owner speaks for the university department and helps decide what is most important. Start with the need

During an early meeting, the student representative says, “Students need to know which course
units they are allowed to register for.” A developer may be tempted to start coding a course list
immediately. But the team slows down and asks practical questions:

• Should students see only required course units, or also electives?

• Should students with retakes see failed course units from the previous year?
• What happens if a student has not paid the required fees?
• Who approves the final registration?
• Can a student edit registration after submission?
• What report does the department need?

These questions show engineering thinking. The goal is not to delay work. The goal is to avoid
building the wrong thing quickly.

The team then writes product backlog items. A product backlog is a prioritized list of work
that may be done on a product. Each item should represent something valuable or necessary.
Example items may include:

• Student can view available course units.

• Student can select course units for registration.
• System prevents timetable clashes.
• Department administrator can approve registration.
• Student can download a registration confirmation.

During sprint planning, the team chooses a small set of items to complete in the next sprint,
such as two weeks. They discuss what can realistically be finished, what information is missing,
and how they will test the work. This is practical software engineering. The team is turning a
broad goal into manageable work.
 1 UNDERSTANDING SOFTWARE SYSTEMS Software as Part of Society
10

­ CHECKPOINT
Why would it be risky for the team to build the whole registration system without show‐
ing users small working parts along the way?

It would be risky because users may discover missing rules only after seeing the software. De‐
partments may disagree about approval steps. Students may find the screens confusing. Build‐
ing in small parts allows feedback before too much effort is spent in the wrong direction.

1.4 Software as Part of Society

1.4.1 Technical Parts of a Software System

A software system has technical parts. These are the pieces that developers usually work with
directly. They may include:

• User interfaces, such as web pages, mobile screens, menus, and forms.
• Application logic, which handles rules and decisions.
• Databases, which store records.
• Servers, which run software for many users.
• Networks, which allow parts to communicate.
• External services, such as payment gateways, email services, maps, or identity systems.
• Security mechanisms, such as passwords, permissions, and encryption.

These parts matter because they shape what the system can do. A system with a poorly de‐
signed database may become slow. A system with weak security may expose private informa‐
tion. A system with confusing screens may cause users to make mistakes.

However, technical parts alone do not explain the full system. A technically correct system may
still fail if it does not fit the people and organization using it.

1.4.2 Human Parts of a Software System

Software systems also have human parts. These include users, customers, managers, support
staff, trainers, administrators, and other stakeholders. A stakeholder is anyone who is affected
Many users, many by the system or has an interest in it.
needs
 1 UNDERSTANDING SOFTWARE SYSTEMS Software as Part of Society
11

For example, in a school fees system, stakeholders may include students, parents, bursars, ac‐
countants, school administrators, auditors, and bank partners. Each group may care about
different things. Students may want quick confirmation of payment. Accountants may want
accurate reports. Auditors may want a clear trail of who changed what. Administrators may
want the system to reduce queues.

If developers ignore stakeholders, they may build software that works technically but fails prac‐
tically. A system that requires a cashier to enter twenty fields for every payment may be accu‐
rate but too slow for a busy office. A system that uses technical language may confuse users.
A system that does not match existing approval rules may be rejected by management.

ʢ SIDEBAR | The user is not always one person

When someone says “the user”, ask: which user? A student, administrator, lecturer,
cashier, manager, auditor, and support officer may all use the same system differently.
Good software development tries to understand these roles clearly.

1.4.3 Software and Organizations

Most software systems live inside organizations. An organization may be a university, hospital,
bank, shop, government office, transport company, or small business. Organizations have goals,
rules, departments, budgets, and habits. Software must often support these realities.

Consider a hospital records system. Doctors may need fast access to patient history. Nurses may
need to record observations. Pharmacists may need prescriptions. Administrators may need
billing information. Managers may need reports. The system must respect confidentiality, but
it must also make information available to authorized staff at the right time.

This means software development is also about understanding work. Developers need to learn
how tasks are currently done, where delays occur, where mistakes happen, and what improve‐
ment is expected.

Sometimes software changes the organization itself. A paper‐based process may become dig‐
ital. A manual approval may become automatic. A manager may get real‐time reports instead
of monthly summaries. These changes can be helpful, but they can also create fear, resistance,
or confusion. People may worry about losing control, making mistakes, or being monitored.

Good software teams therefore communicate carefully. They do not treat users as obstacles.
They treat users as sources of knowledge about the real work.
 1 UNDERSTANDING SOFTWARE SYSTEMS Software as Part of Society
12

1.4.4 Why User Needs Matter

User needs matter because software is judged by whether it helps people achieve their goals.
A system can be technically impressive and still be unsuccessful if it does not solve the right
problem.

For example, imagine a team builds a mobile app for farmers to check market prices. The app
is beautiful and fast, but it requires constant internet access. Many farmers in the target area
have unreliable network coverage. The team has solved a technical problem but missed an
important user need. A better solution might allow offline viewing of recently downloaded
prices or SMS‐based access for basic phones.

Understanding user needs does not mean accepting every request without thinking. Users may
ask for features that are not practical, secure, or affordable. The development team must listen,
clarify, and negotiate. The aim is to understand the problem behind the request.

Ď TIP
When a user asks for a feature, ask what problem the feature is meant to solve. The first
request is often a proposed solution, not the full requirement.

Suppose a department administrator says, “I want an Excel export button on every page.” The
team should ask why. Maybe the real need is monthly reporting. Maybe the administrator
wants to share lists with heads of department. Maybe the system’s built‐in reports are not
trusted. Understanding the reason helps the team design a better solution.

1.4.5 Legal, Ethical, and Social Concerns

Software systems can affect privacy, fairness, safety, and trust. These are not advanced topics
reserved for later years. First‐year students should begin noticing them early.

A system that stores student marks must protect privacy. A banking system must prevent unau‐
thorized transactions. A recruitment system should not unfairly reject applicants because of bi‐
ased data. A health system must keep patient information confidential. A transport app should
not expose a customer’s location to unauthorized people.

Legal concerns involve laws and regulations. Ethical concerns involve what is right, fair, respon‐
sible, and respectful, even beyond the minimum law. Social concerns involve how software
affects people’s lives and communities.

For example, a university attendance system using facial recognition may seem efficient. But it
raises questions. Was consent obtained? What happens if the system fails to recognize some
students? Who stores the images? How long are they kept? Can the data be misused? A
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Systems Become Complex
13

responsible software developer should be willing to ask such questions.

­ CHECKPOINT
Choose one system you use often, such as mobile money, a learning platform, or a so‐
cial media app. What private information does it handle? What could go wrong if that
information were exposed?

1.5 Why Software Systems Become Complex

1.5.1 Size and Number of Components

Software becomes complex when it grows in size and when the number of connected parts
increases. A small program may have one file and one main task. A real system may have many
screens, services, tables, reports, user roles, and external connections. Growth creates
complexity

Complexity does not mean confusion only. It means there are many parts to understand and
many possible interactions. A large system may still be well organized, but no single person
may understand every detail.

Consider an e‐commerce system. It may include:

• Product catalogue.
• Search and filtering.
• Shopping cart.
• Customer account.
• Payment processing.
• Inventory management.
• Order tracking.
• Delivery assignment.
• Refunds and returns.
• Customer support.
• Promotions and discount codes.
• Reports for managers.

Each part may be understandable on its own, but the whole system becomes difficult because
the parts must work together. If inventory is wrong, customers may buy items that are not
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Systems Become Complex
14

available. If payment succeeds but order creation fails, the customer may be charged without
an order. If delivery status is not updated, customer support receives complaints.

1.5.2 Connections Between Components

A component is a part of a system that has a responsibility. A component may be a module, ser‐
vice, database table, screen, or external tool. Components are connected when one depends
on another.

Coupling

Coupling describes how strongly one part of a system depends on another. If two parts are
tightly coupled, a change in one part may require changes in the other. If they are loosely
coupled, they can change more independently.

For beginners, coupling can be understood through a simple example. Suppose a school system
has a report screen that directly reads the exact internal format of the marks table. Later, the
marks table changes to support coursework, exams, and retakes separately. If the report screen
was tightly tied to the old table format, it may break. A better design would allow the report
screen to ask for “final marks” through a clear interface without needing to know every storage
detail.

Tight coupling is not always avoidable, but too much of it makes systems difficult to change.

Interdependence

Interdependence means parts rely on one another to complete a larger process. In a food
delivery app, payment, restaurant confirmation, rider assignment, and customer notification
are interdependent. The order process is not complete until several parts cooperate.

Interdependence increases the need for coordination. A team working on payments must un‐
derstand how the order team expects payment results. A team working on notifications must
know when messages should be sent. In agile projects, such dependencies often appear during
sprint planning. The team may ask, “Can we complete this backlog item in one sprint, or does
it depend on another item?”

® NOTE
Dependencies are normal. The goal is not to remove every dependency. The goal is to
make important dependencies visible so the team can plan and test them.
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Systems Become Complex
15

1.5.3 Small Changes Can Have Large Effects

In small programs, a small change often has a small effect. In larger systems, a small change
can affect many people or parts. This is one reason software teams use careful change man‐
agement, testing, and reviews. Small change, wide
effect

Nonlinear Effects

A nonlinear effect happens when the size of the result is not proportional to the size of the
change. For example, changing one validation rule in a registration system may seem small. But
if the rule controls which students can register, it may affect thousands of students, department
reports, fee clearance, and graduation eligibility.

Another example is changing the format of phone numbers in a customer database. The change
may be only one field, but it can affect SMS notifications, login verification, customer support
searches, and reports.

Cascading Effects

A cascading effect happens when one problem causes another, which causes another. In soft‐
ware, cascading effects are common when systems are connected.

Imagine a mobile money payment gateway becomes slow. An online shop keeps waiting for
payment confirmation. Orders remain pending. Customers press the payment button again.
Duplicate payment attempts increase load. Customer support receives many complaints. The
original issue was slow payment confirmation, but the effects spread through the system.

This is why software teams test not only individual features but also important flows from be‐
ginning to end.

ʢ SIDEBAR | A sprint planning moment

During sprint planning, a developer says, “This is just a small change to the payment
status field.” The tester replies, “That field is used by order tracking, refund reports, and
customer SMS messages.” This discussion is valuable. The team has discovered that a
small change may have a wide effect.
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Systems Become Complex
16

1.5.4 Unexpected Behavior in Large Systems

Large systems can behave in ways that are difficult to predict. This does not mean software is
magic. It means that many interacting parts, users, and conditions can produce situations the
team did not think about.

Emergent Behavior

Emergent behavior is behavior that appears when parts interact, even if no single part was
designed to produce that exact result. For example, a social media platform may recommend
posts based on user activity. Each part may be simple: users like posts, the system counts
activity, and recommendations are shown. But together, the system may encourage certain
content to spread quickly, including content that is misleading or harmful. The larger behavior
emerges from interaction.

In a university system, each department may correctly update its course list. But if many depart‐
ments schedule courses without coordination, students taking course units across departments
may face timetable clashes. Each local action is reasonable, but the combined result creates a
problem.

Behavior Under High Load

Load refers to the amount of work a system is handling. High load may mean many users, many
requests, large files, or heavy data processing. A system that works for ten users may fail for
ten thousand users.

Consider online registration. On a normal day, only a few students may log in. On registration
deadline day, thousands may log in at the same time. Pages become slow. Students refresh
repeatedly. The system receives even more requests. Some students may submit the same
form several times. This is not just a coding problem. It is a system design, testing, and planning
problem.

Í Common high‐load moments

Systems often face high load during deadlines, sales promotions, salary payment days,
examination result release, ticket booking openings, and public application closing dates.
 1 UNDERSTANDING SOFTWARE SYSTEMS Scale, Users, and Time
17

1.5.5 Example: Complexity in an E‐Commerce System

Let us examine a simple online shop called CampusMart. It sells textbooks, stationery, and
electronics to students. In the first week, CampusMart has only a few users. The team builds
quickly. A customer can view items, add them to a cart, and pay on delivery.

As the shop grows, new needs appear. Students want mobile money payments. The store
wants stock reports. The delivery team wants location information. Customer support wants
order history. Management wants discounts during orientation week. Suppliers want alerts
when items are low.

Each request seems reasonable. But together they create complexity.

Suppose the team adds a discount feature. A discount affects the product page, cart, checkout,
payment amount, receipt, refund amount, and sales report. If the team changes only the cart,
the receipt may show a different amount from the payment record. Customers lose trust.

This is why teams use backlog refinement. Backlog refinement is the activity of reviewing and
improving product backlog items before sprint planning. The team asks what each item means,
what is missing, what risks exist, and how acceptance will be checked.

For the discount feature, a refined backlog item may include acceptance criteria:

• The discount is shown on the product page and cart.

• The customer pays the discounted amount.
• The receipt shows original price, discount, and final price.
• Sales reports show both gross sales and discounts.
• Refunds use the amount actually paid.

Acceptance criteria are conditions that help the team know whether a backlog item is com‐
plete. They make hidden expectations visible.

1.6 Scale, Users, and Time

1.6.1 Scale

Scale refers to how large a system’s work becomes. Scale can involve components, data, users,
transactions, locations, or time. A system that works at a small scale may need changes to work
 1 UNDERSTANDING SOFTWARE SYSTEMS Scale, Users, and Time
18

Scale changes at a larger scale.

behavior

Number of Components

As the number of components increases, coordination becomes harder. A student records sys‐
tem may start with student profiles. Later it adds course registration, fees, results, graduation
clearance, hostel booking, and alumni records. Each new component adds value, but also adds
more connections.

Good structure helps the team know where a change belongs. If fee rules are mixed into reg‐
istration screens, result reports, and clearance forms without organization, changes become
risky. If fee logic is placed in a clear part of the system, other parts can use it without copying
rules everywhere.

Amount of Data

Data growth changes system behavior. A search that is fast for 100 records may be slow for
1,000,000 records. A backup that takes one minute today may take two hours after years of
data. Reports may become slow when they process large histories.

Data also brings responsibility. Student records, health records, and payment records must be
accurate and protected. Losing or corrupting data can be more serious than temporarily losing
a screen.

Number of Users

More users mean more variety. Users have different devices, network speeds, languages,
habits, and levels of digital confidence. Some users read instructions carefully. Others click
quickly. Some have new phones. Others use old phones. Some have strong internet. Others
have weak connections.

Designing for users means expecting difference. A first‐year student may use a portal for the
first time and feel anxious. A registrar may use the same system daily and want speed. A
lecturer may need a simple way to upload marks without making errors. The same system
must support different levels of experience.
 1 UNDERSTANDING SOFTWARE SYSTEMS Scale, Users, and Time
19

1.6.2 Users

Users are central to software systems because they provide input, interpret output, and make
decisions based on the system. User behavior can be unpredictable, not because users are bad,
but because real life is messy.

User Errors

A user error occurs when a user enters wrong information, presses the wrong button, forgets
a step, or misunderstands the system. Good software design expects some mistakes and helps
users recover.

For example, a student may accidentally select the wrong course unit. A good registration
system should allow review before final submission. It should show course codes, names, credit
units, and timetable information clearly. It should not punish a simple mistake harshly.

Unexpected Inputs

Unexpected inputs are values the developer did not originally think about. A name may contain
an apostrophe. A phone number may start with a country code. A student may have a very
long surname. A user may paste text with spaces. A file upload may be too large.

Beginner programs often assume clean input. Real systems must validate input and give help‐
ful feedback. Validation means checking whether input is acceptable before using it. Helpful
feedback tells the user what to correct.

Different Patterns of Use

Different users use the same system in different ways. Some customers search carefully before
buying. Others add many items to a cart and remove them later. Some students register early.
Others wait until the deadline. Some administrators process records one by one. Others upload
spreadsheets.

These patterns affect design and testing. A team should not test only the easiest path. It should
test common paths, error paths, and busy periods.

­ CHECKPOINT
In a learning management system, what are three different ways students might use the
assignment submission feature? What could go wrong in each case?
 1 UNDERSTANDING SOFTWARE SYSTEMS Scale, Users, and Time
20

1.6.3 Time

Software systems live over time. This is one of the biggest differences between class exercises
and real projects. A class exercise may be submitted and forgotten. A real system may run for
years.

Changing Requirements

Requirements change because organizations change. A university may introduce new grading
rules. A shop may add delivery. A clinic may add online consultation. A government may
introduce a new reporting requirement.

Changing requirements are normal. The challenge is to build software that can change without
breaking everywhere. Agile development accepts that learning continues during a project. In‐
stead of pretending all details are known at the beginning, agile teams work in small steps, get
feedback, and adjust.

Changing Technologies

Technologies also change. A library, framework, operating system, browser, or payment service
may be updated. A system may need to support new devices. A hosting provider may change
pricing. Security standards may improve.

Students should understand that software maintenance is not failure. Maintenance is part
of the life of useful software. A system that is used will need correction, improvement, and
adaptation.

System Growth

System growth happens when more features are added over time. Growth can be healthy if
the system is structured. Growth can become painful if features are added carelessly.

Imagine a small business inventory system. At first, it records stock. Later it adds sales, suppli‐
ers, purchases, returns, branches, users, and reports. If each feature is added quickly without
design, the system may become hard to understand. Developers may fear changing anything
because they cannot predict the effects.
 1 UNDERSTANDING SOFTWARE SYSTEMS Scale, Users, and Time
21

1.6.4 Consequences of Failure

Software failure does not always mean the whole system stops. A failure may be a wrong cal‐
culation, a missing message, a security weakness, a slow response, a confusing screen, or a lost
record. The seriousness of failure depends on the context.

Financial Consequences

Financial consequences occur when failure causes loss of money. A payment system may charge
customers incorrectly. A stock system may show wrong inventory, causing a shop to sell items
it does not have. A payroll system may calculate salaries incorrectly.

Even small errors can become expensive when repeated many times. If a system undercharges
each transaction by a small amount, the total loss may become large.

Operational Consequences

Operational consequences affect daily work. If a hospital appointment system is down, staff
may return to paper lists. If a university portal fails during registration, queues may form in
offices. If a delivery tracking system fails, riders and customers may need phone calls to coor‐
dinate.

Operational failure often creates pressure on people. Staff may work longer hours. Users may
become frustrated. Managers may lose confidence in the system.

Legal and Ethical Consequences

Some failures break laws, contracts, or ethical responsibilities. Exposing private health records,
losing examination marks, or allowing unauthorized financial transactions can have serious con‐
sequences.

Ethical consequences may also occur when a system treats people unfairly or hides important
information. For example, an automated loan system that rejects applicants without clear rea‐
sons may create unfair outcomes.
 1 UNDERSTANDING SOFTWARE SYSTEMS Managing Complexity Through Structure
22

Loss of Trust

Trust is difficult to build and easy to lose. If users believe a system is unreliable, they may avoid
it even after problems are fixed. Students may print screenshots as proof because they do
not trust the portal. Customers may call support after every payment because they fear losing
money.

Good software development protects trust through accuracy, clear communication, security,
reliability, and honest handling of errors.

1.6.5 Example: A System That Outgrows Its Original Design

A small training institute begins with a spreadsheet for student records. One administrator
records names, phone numbers, fees, and course attendance. The spreadsheet works well for
40 students.

After two years, the institute grows to 1,500 students across three branches. Several staff mem‐
bers need access. Some students pay in instalments. Managers want reports by branch. Lec‐
turers want attendance lists. Students want SMS reminders. The spreadsheet becomes risky.
People overwrite each other’s changes. Some records are duplicated. Reports take too long.
There is no clear record of who changed what.

The institute now needs a software system, not just a file. It needs user accounts, permissions,
shared data, backups, reports, validation, and support. The original tool was not bad. It simply
outgrew its purpose.

n KEY TAKEAWAYS
• Software that is useful often grows.
• Growth brings more users, data, rules, and risks.
• A design that works today may need improvement tomorrow.
• Teams should expect change and structure systems so change is possible.

1.7 Managing Complexity Through Structure

 1 UNDERSTANDING SOFTWARE SYSTEMS Managing Complexity Through Structure
23

1.7.1 Why One Person Cannot Understand Everything

In a small class program, one student can understand every line. In a real software system,
this is rarely possible. Different people understand different parts. One developer may know
the payment module. Another may know the reporting module. A tester may know common
failure cases. A support officer may know user complaints. A product owner may know business
priorities.

This does not mean the team is weak. It means the system is larger than one mind. Good teams
create structure so people can work together without needing to know everything at once.

Structure helps answer practical questions:

• Where should this change be made?

• Which parts may be affected?
• Who should review this work?
• What tests should be run?
• What documentation should be updated?

1.7.2 Breaking Systems into Smaller Parts

Breaking a system into smaller parts is one of the most important ways to manage complexity.
It allows teams to focus on one responsibility at a time. Divide to
understand

Decomposition

Decomposition means dividing a larger problem into smaller, more manageable problems. For
example, a university portal can be decomposed into admissions, registration, fees, results,
timetable, and communication.

Decomposition helps planning. Product backlog items can be organized around parts of the
system or user goals. A team may decide that in the first sprint it will focus only on student login
and viewing available course units. Later sprints can add registration submission, approval, and
confirmation.

Modularity

Modularity means organizing software into parts that have clear responsibilities and can be
developed, tested, and changed with some independence. A module should have a clear pur‐
 1 UNDERSTANDING SOFTWARE SYSTEMS Managing Complexity Through Structure
24

pose. For example, a notification module may handle SMS and email messages for many parts
of the system.

Modularity reduces confusion. If notification rules are scattered across many screens, changing
a message format becomes difficult. If messages are handled in one clear module, changes are
easier.

® NOTE
A module is not just a folder. It is a responsibility. A folder with mixed responsibilities is
still confusing, even if it looks organized.

1.7.3 Organizing Systems in Layers

Many systems are organized in layers. A layer groups responsibilities at a certain level. A com‐
mon simple structure includes presentation, application logic, and data.

Presentation Layer

The presentation layer is what users see and interact with. It includes screens, forms, buttons,
menus, and messages. Its job is to make interaction clear and usable.

For example, in a registration system, the presentation layer displays available course units and
allows a student to select them. It should show helpful messages, prevent obvious mistakes,
and guide the user through the process.

Application Logic Layer

The application logic layer handles rules and decisions. It decides whether a student is allowed
to register, whether a timetable clash exists, whether fees are cleared, and whether approval
is required.

This layer is important because business rules should not be hidden only inside screen design.
If the same rule is needed by a web page, a mobile app, and an administrator report, it should
be handled consistently.
 1 UNDERSTANDING SOFTWARE SYSTEMS Managing Complexity Through Structure
25

Data Layer

The data layer stores and retrieves information. It may involve databases, files, or external data
services. Its responsibility is to manage data safely and reliably.

In a student system, the data layer may store student profiles, course units, registrations, pay‐
ments, and approval records. Good data design helps avoid duplicates and contradictions.

Layer Main question Example in registration

Presentation What does the user see and do? Student selects course units on a
form.
Application logic What rules must be followed? System checks prerequisites and
clashes.
Data What information is stored? Registration record is saved in the
database.

1.7.4 Defining Clear Interfaces

An interface is a clear way for one part of a system to interact with another. It describes what
can be requested and what result is expected, without requiring the caller to know every inter‐
nal detail. Clear boundaries
help

For example, a payment component may provide an interface that says:

• Submit payment request.

• Check payment status.
• Cancel pending payment.
• Generate receipt.

Other parts of the system can use these actions without knowing exactly how the payment
provider communicates with banks or mobile money services. This makes the system easier to
change. If the payment provider changes, the team may update the payment component while
keeping the rest of the system mostly stable.

Interfaces are also important between people. A product owner and developers need clear
ways of agreeing on backlog items. Developers and testers need clear acceptance criteria.
Users and support staff need clear ways to report problems.
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Needs Systematic Development
26

1.7.5 Hiding Internal Details

Hiding internal details means allowing people or parts of the system to use something without
needing to know how everything works inside. This is useful because it reduces the amount of
information each person must handle at once.

Encapsulation

Encapsulation means keeping data and behavior together and controlling how other parts ac‐
cess them. In simple terms, a part of the system protects its own internal details and provides
approved ways to use it.

For example, a bank account component should not allow any other part of the system to
directly change the balance without checks. Instead, it may provide operations such as deposit,
withdraw, and transfer. These operations can enforce rules.

Information Hiding

Information hiding means hiding design details that other parts do not need to know. This
helps reduce the effect of change. If a report only needs final marks, it should not need to
know exactly how coursework and exam marks are stored internally.

Information hiding is also a learning principle. A first‐year student does not need to understand
every detail of a database engine before using a database responsibly. The student needs the
right level of understanding for the task.

­ CHECKPOINT
In a school fees system, what internal details should be hidden from an ordinary student
user? What information should the student be allowed to see?

1.8 Why Software Needs Systematic Development

1.8.1 Problems with Informal Development

Informal development means building software without enough planning, communication, struc‐
ture, testing, or documentation. It may feel fast at the beginning, but it often creates problems
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Needs Systematic Development
27

later.

Unclear Requirements

Unclear requirements occur when the team does not properly understand what is needed. For
example, a manager may say, “Build a report for student performance.” This is too general.
Which students? Which semester? Which course units? Should retakes be included? Who can
view the report? What format is needed?

If the team codes immediately, it may build the wrong report. Clarifying requirements early
saves time.

Poor Design Decisions

Poor design decisions may not be obvious at first. A quick shortcut can work for one feature but
make future changes difficult. For example, copying the same fee calculation code into many
screens may be fast today. Later, when fee rules change, the team must find and update every
copy. One missed copy creates inconsistent results.

Hidden Defects

A defect is a problem in the software that can cause incorrect behavior. Hidden defects remain
unnoticed until certain conditions occur. A system may work during a demonstration but fail
when used by many people or with unusual data.

Systematic testing helps reveal defects earlier. It does not guarantee perfection, but it reduces
risk.

Difficult Maintenance

Maintenance means changing software after it has been built. This includes fixing bugs, im‐
proving features, adapting to new rules, and updating technologies.

Informal development often produces software that is hard to maintain. New developers can‐
not understand the code. There is little documentation. Tests are missing. The original devel‐
oper may have left. Every change becomes frightening.
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Needs Systematic Development
28

Poor Documentation

Documentation helps people understand the system. It does not need to be huge, but it should
be useful. Poor documentation means important knowledge exists only in someone’s memory.
If that person is absent, the team struggles.

Useful documentation may include a short description of features, diagrams, setup instructions,
decisions made, known limitations, and user guides.

1.8.2 From Programming to Software Engineering

Programming is the skill of writing instructions for a computer. Software engineering uses pro‐
gramming plus other practices to deliver dependable software. The movement from program‐
ming to software engineering is a movement from “Can I make it run?” to “Can we build the
From solo work to right thing, in a way that people can use, test, change, and trust?”
teamwork

This course does not reduce the importance of programming. A software engineer still needs
programming ability. But the engineer also needs communication, planning, design thinking,
testing discipline, teamwork, and ethical awareness.

In a sprint‐based project, this difference becomes visible. A team does not simply assign ran‐
dom coding tasks. It discusses user needs, breaks work into backlog items, estimates effort,
agrees on sprint goals, builds small increments, tests them, reviews progress, and learns from
feedback.

ʢ SIDEBAR | A beginner‐friendly sprint example

Sprint goal: Allow first‐year students to view available course units.
Possible sprint backlog items:

• Create a screen that lists course units by programme.

• Connect the screen to sample course data.
• Show a helpful message when no units are found.
• Test with two programmes and two years of study.
• Review the screen with a student representative.

This is not advanced project management. It is simply a practical way to focus the team
on a small useful result.
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Needs Systematic Development
29

1.8.3 Benefits of Systematic Development

Systematic development does not mean slow development. It means purposeful development.
A team can still move quickly, but it moves with better understanding and control.

Better Understanding of User Needs

Systematic development encourages interviews, observation, prototypes, feedback sessions,

and review meetings. These activities help the team understand real needs before and during
development.

For example, showing a simple registration screen to students may reveal that course codes
alone are confusing. Students may need course names, lecturers, credit units, and timetable
information. This feedback improves the product.

Improved Planning

Planning helps teams decide what to do first. Not every feature has the same importance. A
product backlog helps the team prioritize. Sprint planning helps the team choose a realistic
amount of work for a short period.

Good planning also reveals dependencies. If online payment is not ready, the team may decide
to first build registration viewing and later add payment‐based clearance.

Better Design

Design helps the team organize the system before and during coding. Good design reduces
duplication, clarifies responsibilities, and supports change.

Design does not always require large documents. A small diagram, a clear list of components,
or a short decision note can be enough for a small team. The important thing is shared under‐
standing.

Reduced Errors

Systematic development reduces errors through reviews, tests, checklists, and clear acceptance
criteria. For example, before completing a backlog item, the team may check:
 1 UNDERSTANDING SOFTWARE SYSTEMS Why Software Needs Systematic Development
30

• Does it meet the acceptance criteria?

• Has it been tested with normal and unusual data?
• Does it handle errors clearly?
• Has another team member reviewed it?
• Is any user‐facing text clear?

Easier Maintenance

Software that is organized, tested, and documented is easier to maintain. Future developers
can understand it faster. Bugs can be fixed with less fear. New features can be added with fewer
surprises.

Maintenance is especially important in organizations where software may outlive the original
development team. The system should not depend entirely on one person’s memory.

Improved Teamwork

Systematic development supports teamwork by making work visible. Backlog boards, sprint
Visible work is meetings, code reviews, test plans, and documentation help team members coordinate.
manageable

In a daily stand‐up meeting, each person briefly shares what they did, what they plan to do,
and what is blocking them. The meeting is not meant for long speeches. It helps the team
notice problems early. For example, a developer may say, “I cannot finish the registration form
because the course data format is still unclear.” The product owner can help clarify.

Higher Reliability

Reliability means the system works correctly and consistently over time. Systematic develop‐
ment improves reliability by encouraging careful requirements, good design, testing, monitor‐
ing, and maintenance.

No process can remove all risk. But a disciplined team is more likely to notice risks early and
respond responsibly.

1.8.4 Preview of the Rest of the Book

This chapter has introduced the foundation: software systems are connected, practical, human,
and changing. Later chapters will build on this foundation.
 1 UNDERSTANDING SOFTWARE SYSTEMS Running Case Study: CampusConnect
31

You will learn how teams work together, how requirements are discovered and organized, how
development processes guide work, how agile practices such as sprints and product backlogs
support learning, how software is designed, how testing improves quality, and how software is
maintained after release.

As you continue, keep returning to the central question: how does this idea help people build
software that is useful, dependable, understandable, and changeable?

1.9 Running Case Study: CampusConnect

1.9.1 The Situation

To make the ideas in this chapter practical, we shall use a running case study called Campus‐
Connect. CampusConnect is a proposed mobile and web system for first‐year students at a
university. Its purpose is to help students settle into university life. Case study thread

The first idea sounds simple: “Build an app for new students.” But that statement is too broad.
A software team must discover what students actually need. During early conversations, stu‐
dents mention several problems:

• They do not know where offices and lecture rooms are.

• They miss orientation announcements.
• They are confused about registration steps.
• They do not know which course units belong to their programme.
• They struggle to find contacts for help.

The team cannot build everything at once. It creates a product backlog. Early backlog items
include:

• Student can view orientation announcements.

• Student can search for campus offices.
• Student can view registration steps.
• Student can see course units for their programme.
• Administrator can post announcements.
 1 UNDERSTANDING SOFTWARE SYSTEMS Running Case Study: CampusConnect
32

1.9.2 A First Sprint

The team plans a two‐week sprint. Since the app is new, the product owner chooses one useful
goal: students should be able to view orientation announcements. This is small but valuable.

The sprint backlog includes:

• Create announcement list screen.

• Create announcement detail screen.
• Store sample announcements.
• Allow an administrator to add an announcement.
• Test announcement display on a phone screen.

During the sprint, the team learns that some announcements are urgent and should appear at
the top. Some announcements expire after a date. Some students want attachments, such as
PDF orientation schedules. The product owner decides that urgent announcements and expiry
dates are needed now, but attachments can wait.

This is a simple example of software engineering in practice. The team starts with a goal, builds
a small part, learns from details, and adjusts the backlog.

1.9.3 Questions Raised by the Case

CampusConnect helps us see the chapter’s main ideas:

• It begins as an idea but becomes a system when it involves users, administrators, data,
screens, and rules.
• It requires requirements because “announcements” can mean many things.
• It requires design because the team must decide how announcements are stored and
displayed.
• It requires testing because students may use different phones and network conditions.
• It raises ethical concerns because student information and communication must be han‐
dled responsibly.
• It will grow over time as new needs appear.

­ CHECKPOINT
Write two acceptance criteria for the backlog item: “Student can view orientation an‐
nouncements.” Keep them simple and testable.
 1 UNDERSTANDING SOFTWARE SYSTEMS Chapter Summary
33

Possible answers include: announcements are shown from newest to oldest; expired announce‐
ments are not shown to students; urgent announcements appear before normal announce‐
ments; tapping an announcement opens its full details.

1.10 Chapter Summary

Software development is not only about writing code. Code is essential, but real software ex‐
ists inside systems of people, data, rules, organizations, devices, and time. A program gives a
computer instructions. A software system supports a real activity through connected parts.

Software must be engineered because real systems need planning, requirements, design, test‐
ing, communication, and maintenance. A system that works on one developer’s laptop may still
fail when many users, real data, weak networks, changing rules, or security concerns appear.

Software systems become complex because they grow in size, connect many components, serve
different users, handle large amounts of data, and change over time. Small changes can have
large effects when parts are connected. Teams manage this complexity through decomposition,
modularity, layers, clear interfaces, encapsulation, and information hiding.

Systematic development helps teams understand user needs, plan work, design better struc‐
tures, reduce errors, maintain software, collaborate, and improve reliability. Practical activities
such as product backlogs, sprint planning, daily stand‐ups, reviews, and acceptance criteria are
not just management rituals. They are ways of making complex work visible and manageable.

n KEY TAKEAWAYS
• A program is a set of instructions; a software system is a connected solution used
in real life.
• Real software includes technical parts and human parts.
• Good developers think about users, data, rules, risks, and change.
• Complexity grows through components, connections, scale, users, and time.
• Structure helps teams understand and change systems safely.
• Systematic development makes software work more visible, testable, and depend‐
able.

1.11 Review Questions

 1 UNDERSTANDING SOFTWARE SYSTEMS Review Questions
34

1.11.1 Short Answer Questions

1. What is the difference between a program and a software system?

2. Give two examples of software systems used in everyday life.
3. Why is software development more than writing code?
4. What is a stakeholder? Give three examples from a university registration system.
5. Explain coupling using a simple example.
6. What is an acceptance criterion?
7. Why can a small change have a large effect in a software system?
8. What is the purpose of testing?
9. Why is user feedback important during software development?
10. What does it mean to maintain software?

1.11.2 Discussion Questions

1. A system can be technically correct but still fail in real life. Discuss this statement using
an example.
2. Why should software teams avoid building a large system for months without showing
users any working part?
3. Think about a mobile money system. What technical parts and human parts are involved?
4. In what ways can poor software design affect future maintenance?
5. Why is trust important in software systems used by students, patients, or customers?

1.11.3 Practical Activity

Choose one system that students commonly use, such as a learning platform, registration por‐
tal, mobile money app, library system, or food ordering app. Prepare a one‐page analysis with
the following:

• Name and purpose of the system.

• Main users and stakeholders.
• Three important features.
• Two examples of data the system stores.
• One possible failure and its consequence.
• Two product backlog items that could improve the system.
• One acceptance criterion for each backlog item.
 1 UNDERSTANDING SOFTWARE SYSTEMS Review Questions
35

1.11.4 Mini Sprint Exercise

In groups of four or five, imagine you are building CampusConnect. Your product owner gives
this goal: “Help first‐year students find important campus offices.”

Complete the following tasks:

1. Write five product backlog items for this goal.

2. Choose two items for a one‐week sprint.
3. Write a simple sprint goal.
4. Write two acceptance criteria for each selected item.
5. List two risks or questions the team must clarify before coding.

After the group work, compare your answers with another group. Notice that different teams
may choose different first steps. The important question is whether the chosen work is clear,
useful, and realistic.

CHAPTER REVIEW

SUMMARY REVIEW QUESTIONS

• Software systems combine programs, data, 1. How is a software system different from a
users, rules, interfaces, and organizational program?
processes. 2. Why do user needs matter?
• Real systems require engineering discipline 3. What makes software complex as it grows?
because they must be useful, dependable, 4. How do product backlogs and sprints help
secure, and maintainable. teams manage work?
• Complexity increases with components,
connections, users, data, and time.
• Teams manage complexity through struc‐
ture and systematic development prac‐
tices.
REFERENCE

CHAPTER 1 KEY TERMS

Plain‐language meanings for the foundation chapter.

Program

The planned organization of a system so that its

parts work together.
A set of instructions written for a computer to per‐
form a task.
Testing

Software System

Checking whether software behaves as expected in

normal and unusual situations.
Connected software parts, data, people, proce‐
dures, and sometimes hardware that support a
Product Backlog
real activity.

Stakeholder
A prioritized list of work that may be done on a soft‐
ware product.

A person or group affected by a system or inter‐

Sprint
ested in its success.

Requirement
A short fixed period in which a team works toward
a clear goal and produces a usable increment.

A statement of what the system should do or a con‐

Acceptance Criteria
dition it should satisfy.

Design
Simple conditions used to decide whether a back‐

36
 1 UNDERSTANDING SOFTWARE SYSTEMS Review Questions
37

log item is complete. Interface

Component

A defined way for one part of a system to interact

with another.
A part of a system with a particular responsibility.
Encapsulation
Coupling

Keeping data and behavior together while control‐

The degree to which one part depends on another ling access to internal details.
part.
Maintenance
Modularity

Changing software after release to fix, improve,

Organizing software into clear parts with clear re‐ adapt, or update it.
sponsibilities.
 1 UNDERSTANDING SOFTWARE SYSTEMS Review Questions
38

COMING UP NEXT

Working with Software Teams

The next chapter moves from systems to people: roles, communication, meetings, and practical
teamwork in software projects.
CHAPTER NO. 2

2
Planning and Choosing How to
Build

FROM A GOOD IDEA TO A WORKABLE SOFTWARE PROJECT

œ LEARNING OBJECTIVES
By the end of this chapter, you should be able to:

• Explain why software teams plan before they begin building.

• Describe how to understand a problem before proposing a software solution.
• Define project scope and explain why uncontrolled scope is risky.
• Carry out a simple feasibility study using practical questions.
• Explain functional and non‐functional requirements using real examples.
• Compare common development approaches such as waterfall, iterative, incre‐
mental, prototyping, spiral, RAD, and agile.
• Choose a suitable development approach for small student projects and larger or‐
ganizational systems.

39
 2 PLANNING AND CHOOSING HOW TO BUILD Introduction to Planning a Software System
40

• Prepare a basic project plan with tasks, responsibilities, risks, and communication
points.

2.1 Introduction to Planning a Software System

2.1.1 Why Planning Comes Before Building

SOFTWARE PROJECT OFTEN STARTS with excitement. Someone says, “Let us build an

A app,” or “We need a system,” or “This work should be automated.” These statements
may sound clear, but they are only the beginning. Before building, a team must un‐
derstand what problem is being solved, who is affected, what is possible, what is risky, and
Plan before coding what should be done first.

Planning does not mean delaying the project with unnecessary paperwork. Good planning
helps a team avoid building the wrong thing quickly. It helps the team ask practical questions
early, when mistakes are cheaper to correct.

Imagine a student group is asked to build a hostel booking system. If they begin coding imme‐
diately, they may create a form where students choose rooms. Later, they may discover that
hostel allocation depends on year of study, disability needs, payment status, gender, distance
from home, and availability of beds. The first form may be too simple. Some code may need to
be thrown away. A short planning stage could have revealed these rules earlier.

“Planning is not about predicting every detail. It is

about discovering enough truth to start responsibly.”
PLANNING MINDSET

First‐year students sometimes think planning is separate from software development. In real
projects, planning is part of development. The plan helps the team decide what to build, what
not to build, how to organize work, and how to learn from users.

2.1.2 The Purpose of Early Project Planning

Early project planning has several purposes. It helps the team understand the problem, de‐
fine the scope, check feasibility, identify users, gather requirements, choose a development
 2 PLANNING AND CHOOSING HOW TO BUILD Introduction to Planning a Software System
41

approach, estimate effort, and notice early risks.

A good early plan should answer questions such as:

• What problem are we solving?

• Who has the problem?
• What happens today without the new system?
• What should improve after the system is introduced?
• What work is inside the project?
• What work is outside the project?
• What skills, tools, time, and money are available?
• What can go wrong?
• How will users give feedback?

These questions are simple, but they are powerful. Many failed projects did not fail because the
team lacked programming ability. They failed because the team misunderstood the problem,
accepted an unclear scope, ignored users, underestimated time, or chose an unsuitable way of
working.

ʢ SIDEBAR | The class project version

Suppose your lecturer gives your group six weeks to build a simple library borrowing
system. Planning helps you decide what can realistically fit into six weeks. You may
include book search, borrowing, returning, and overdue alerts. You may exclude online
payment of fines because it is too much for the time available. That is not failure. That
is responsible scope control.

2.1.3 From an Idea to a Software Project

An idea becomes a software project when it is defined clearly enough for a team to work on it.
The idea “build a campus app” is too broad. The project “build a first version of CampusCon‐
nect that allows first‐year students to read orientation announcements and find key offices” is
clearer.

The difference is important. A broad idea can inspire discussion, but a project needs direction.
The team must know which users it is serving, which problem comes first, and what result
would count as success.

Turning an idea into a project usually involves these early steps:

1. Describe the problem or opportunity.

 2 PLANNING AND CHOOSING HOW TO BUILD Understanding the Problem to Be Solved
42

2. Identify stakeholders.
3. Understand the current situation.
4. Define the project scope.
5. Check feasibility.
6. Gather and organize requirements.
7. Choose a development approach.
8. Prepare a simple project plan.

These steps do not always happen in a perfect straight line. A team may learn something during
requirements gathering that changes scope. A feasibility study may show that a feature is too
expensive. A prototype may reveal a better way to solve the problem. Good planning allows
learning.

2.1.4 Chapter Overview

This chapter explains how software teams move from a vague idea to a planned project. We
begin by learning how to understand the problem. We then discuss scope and scope creep.
Next, we study feasibility, requirements, and techniques for gathering information from users.
After that, we compare development approaches and discuss how to choose a suitable one.
Finally, we prepare a basic project plan using practical examples.

2.2 Understanding the Problem to Be Solved

2.2.1 Identifying Problems in Existing Systems

Many software projects begin because an existing way of working has problems. The existing
system may be manual, slow, expensive, confusing, insecure, or difficult to monitor. Sometimes
Understand today the existing system is already digital, but it no longer fits the organization.
first

For example, a clinic may record patient appointments in a notebook. This method may work
when the clinic is small. As the clinic grows, staff may struggle to find records quickly. Two
patients may be given the same appointment slot. A patient may not be reminded before the
appointment. Managers may not know how many patients miss visits.

The problem is not simply “the clinic needs software.” The real problems are delays, double
booking, missing reminders, and poor reporting. Good software planning identifies these real
problems.
 2 PLANNING AND CHOOSING HOW TO BUILD Understanding the Problem to Be Solved
43

When studying an existing system, ask:

• What work is slow?

• Where do mistakes happen?
• Which information is difficult to find?
• Which users complain most often?
• Which tasks are repeated many times?
• Which reports are hard to prepare?
• Which risks are hidden?

These questions lead to better project decisions. A team that understands the current pain can
choose features that matter.

2.2.2 Recognizing Opportunities for Improvement

Not every project begins with a serious problem. Sometimes a project begins because there is
an opportunity to improve service, reduce cost, reach more users, or make work easier.

A university may already have a working registration system, but it may want to add self‐service
registration confirmation so students stop queueing at the department office. A shop may
already record sales, but it may want better stock alerts. A local restaurant may already take
phone orders, but it may want an online menu to reduce repeated questions.

An opportunity should still be examined carefully. “We can build an app” is not enough. The
team should ask what benefit the app will bring. Will it reduce waiting time? Increase accuracy?
Improve communication? Save money? Give better reports? Support more users?

­ CHECKPOINT
Think about a service at your university that works but could be improved. What is the
improvement opportunity? Who would benefit from it?

2.2.3 Understanding the Current Situation

Before proposing a new system, the team should understand the current situation as it really
is, not as people wish it was. This means studying the process, the users, and the challenges
together.

A process is a sequence of steps used to complete work. For course registration, the process
may begin when a student receives admission and may end when the student downloads a
 2 PLANNING AND CHOOSING HOW TO BUILD Understanding the Problem to Be Solved
44

confirmation form. Between those points, the student may pay fees, log into a portal, select
course units, submit registration, wait for department approval, correct mistakes, and return
for final confirmation. If the team only studies the screen where course units are selected, it
may miss payment clearance, approval, correction, and reporting.

The team must also identify the people involved in the current situation. Students, lecturers,
administrators, accountants, managers, customers, patients, or support staff may all experi‐
ence the same process differently. In a registration process, students may complain that in‐
structions are confusing. Department administrators may complain that students submit wrong
combinations of course units. Finance staff may complain that payment information arrives
late. Each view reveals part of the system.

Finally, the team should record current challenges in precise language. Avoid vague statements
such as “the system is bad” or “users are confused.” Instead, write statements that can guide
action:

• Students cannot see why registration was rejected.

• Administrators spend two hours each day checking payment status manually.
• Lecturers receive class lists late because approval reports are delayed.
• Students repeat the same questions because registration steps are not visible in one
place.

Clear problem statements make later requirements stronger. They also help the team avoid
solving symptoms while ignoring the real cause.

2.2.4 Defining the Need for a New or Improved System

After understanding the current situation, the team should define the need. A good need state‐
ment explains the problem, who is affected, and why improvement matters.

For example:

The clinic needs an appointment management system because reception staff cur‐
rently use a notebook, which causes double bookings, missing reminders, and dif‐
ficulty preparing weekly patient attendance reports.

This need statement is better than “build clinic software.” It identifies the users, the current
method, the problems, and the reason for change.

For student projects, a need statement can be short. What matters is that it is specific enough
to guide the project.
 2 PLANNING AND CHOOSING HOW TO BUILD Defining the Project Scope
45

Ď TIP
If your need statement could fit almost any organization, it is probably too general. Add
the users, current problem, and expected improvement.

2.2.5 Example: Identifying the Need for a Hospital Management System

Suppose a small hospital uses paper files for patient visits. Doctors write notes by hand. The
pharmacy receives handwritten prescriptions. Laboratory requests are carried by patients.
Billing staff calculate charges from paper forms.

At first, the team may say, “The hospital needs a management system.” But this is too large.
A hospital management system can include patient registration, appointments, consultation
notes, laboratory requests, pharmacy, billing, insurance, reports, stock, staff scheduling, and
more.

The team studies the current situation and finds three urgent problems:

• Patient files are sometimes missing when a patient returns.

• Prescriptions are hard to read, causing delays at the pharmacy.
• Managers cannot quickly see daily patient numbers.

The team may define the first project need as:

The hospital needs a first version of a patient visit system that records patient reg‐
istration, consultation notes, prescriptions, and daily attendance reports so that
staff can reduce missing files, improve pharmacy clarity, and prepare basic man‐
agement reports.

This does not solve every hospital problem. It creates a realistic starting point.

2.3 Defining the Project Scope

2.3.1 Meaning of Project Scope

Project scope describes what is included in a project and what is not included. It defines the
boundaries of the work. Scope helps the team, users, and managers share expectations. Scope sets
boundaries
 2 PLANNING AND CHOOSING HOW TO BUILD Defining the Project Scope
46

For example, if a student team is building CampusConnect, the scope for the first version may
include orientation announcements, office search, and registration steps. It may not include
course registration, online payment, chat with lecturers, or hostel booking.

Scope does not mean the excluded features are bad. It means they are not part of this version.
Clear scope protects the project from becoming too large to finish.

2.3.2 Why Scope Must Be Clearly Defined

Unclear scope causes confusion. Users may expect more than the team plans to build. Devel‐
opers may spend time on low‐priority features. Testers may not know what to check. Managers
may think the project is failing because they expected a larger system.

Clear scope helps with:

• Estimating time and effort.

• Prioritizing features.
• Assigning responsibilities.
• Managing user expectations.
• Testing the right things.
• Deciding what is complete.

In agile work, scope is often managed through a product backlog. The backlog may contain
many possible items, but the team still chooses what is included in a sprint or release.

2.3.3 What the System Will Include

The included scope should describe the main features, users, data, and processes covered by
the project. It should be clear enough for the team to plan and for stakeholders to understand.

For a student registration system, the first version may include:

• Student login.
• Viewing available course units.
• Selecting course units.
• Checking timetable clashes.
• Submitting registration for approval.
• Administrator approval.
• Downloading registration confirmation.
 2 PLANNING AND CHOOSING HOW TO BUILD Defining the Project Scope
47

This list is still high level, but it gives direction.

2.3.4 What the System Will Not Include

Excluding work is just as important as including work. A project plan should clearly state what
will not be handled in the current version.

For the same registration system, the first version may exclude:

• Online fee payment.

• Hostel booking.
• Graduation clearance.
• Lecturer workload planning.
• Mobile app version.
• Integration with national identity systems.

This protects the team from surprise expectations. If someone later asks, “Can we also add
hostel booking?” the team can say, “That is outside the current scope. We can add it to the
backlog for future discussion.”

2.3.5 Scope Creep

Scope creep happens when project work keeps expanding without proper review of time, cost,
risk, and priorities. It often begins with small requests that sound harmless.

For example, a team building an online learning system may be asked to add assignment sub‐
mission. Then someone asks for automatic plagiarism checking. Then video conferencing. Then
parent access. Then mobile notifications. Each request may be useful, but together they may
overwhelm the project.

Scope creep can be caused by unclear original requirements, users discovering needs late, man‐
agers adding requests without removing other work, developers adding interesting features
without approval, poor communication about project boundaries, or lack of a change control
process. In student projects, scope creep often happens because the team wants to impress
the lecturer by adding many features. The result may be many unfinished features instead of a
few reliable ones.

The effects are practical and painful. Scope creep can cause missed deadlines, poor quality,
team stress, incomplete testing, budget increases, and user disappointment. A system with
too many rushed features may be worse than a smaller system that works well.
 2 PLANNING AND CHOOSING HOW TO BUILD Feasibility Study
48

ʢ SIDEBAR | How to respond to a new request

When a stakeholder asks for a new feature, the team should not simply say yes or no. A
professional response sounds like this:

• What problem would this feature solve?

• Is it more important than the work already planned?
• What will be removed or delayed if we add it now?
• Can it be placed in the product backlog for a later sprint?

ʢ SIDEBAR | A sprint meeting moment

During sprint planning, a product owner asks the team to add SMS alerts to the regis‐
tration feature. The team checks the sprint goal and realizes SMS integration needs a
provider account, message templates, error handling, and testing. They agree to put
SMS alerts in the product backlog for a later sprint. This is not refusing progress. It is
protecting the sprint.

2.3.6 Example: Scope of a Student Registration System

Let us define a simple scope for a student registration system.

Í Sample scope statement

This project will allow registered students to view eligible course units, select units, sub‐
mit registration, and receive department approval. It will allow department administra‐
tors to review and approve submitted registrations. The project will not handle online
fee payment, hostel allocation, or examination results.

This scope statement helps everyone understand the first version. It also gives the team a basis
for requirements, backlog items, and testing.

2.4 Feasibility Study

2.4.1 Meaning of a Feasibility Study

A feasibility study checks whether a proposed project is possible and sensible before major
effort is spent. It asks whether the project can be done with available technology, money,
Can we do this? people, time, and rules.
 2 PLANNING AND CHOOSING HOW TO BUILD Feasibility Study
49

Feasibility does not only mean “Can we code it?” A system may be technically possible but too
expensive. It may be affordable but not accepted by users. It may be useful but illegal because
it mishandles private data. A feasibility study looks at the project from several angles.

2.4.2 Purpose of a Feasibility Study

The purpose of feasibility study is to support a decision. The decision may be:

• Continue with the project.

• Continue but reduce scope.
• Delay the project until resources are available.
• Change the approach.
• Stop the project because risk is too high.

For first‐year students, a feasibility study can be simple. It may be one or two pages. What
matters is that the team thinks practically before promising too much.

2.4.3 Technical Feasibility

Technical feasibility asks whether the team has or can obtain the technology needed to build
and run the system. This includes hardware, software, network access, external services, and
technical skills. A library system may need barcode scanners and receipt printers. A mobile app
may need phones for testing. A map‐based campus guide may need a map service. A payment
feature may need access to a payment provider.

The team should be honest about what is available. If no one on a student team has mobile
development experience, building a complex mobile app in four weeks is risky. The team may
choose a web application instead, or it may reduce the first version to a small prototype. This
is not weakness. It is good planning.

Technical feasibility should also check whether the technology fits the users. If most users have
low‐end phones and weak data bundles, a heavy application may be technically impressive but
practically poor. If an office has unreliable internet, the system may need offline forms, saved
drafts, or a simple backup process.

­ CHECKPOINT
For a campus office locator, what technical questions should the team ask before deciding
to use an online map service?
 2 PLANNING AND CHOOSING HOW TO BUILD Feasibility Study
50

2.4.4 Economic Feasibility

Economic feasibility asks whether the project makes financial sense. It compares expected
costs with expected benefits. Costs include development time, tools, training, equipment,
hosting, licenses, SMS charges, payment gateway fees, support, maintenance, and backups.
In a student project, the cost may mostly be time and internet data. In an organization, staff
time and long‐term operation costs can be much larger.

A useful feasibility study separates development costs from operational costs. Development
cost is what it takes to build the system. Operational cost is what it takes to keep it running.
A system may be cheap to build but expensive to operate. For example, an announcement
system that sends SMS messages to every student may be simple to design but costly every
semester.

Benefits may include shorter queues, fewer mistakes, faster reports, better service, increased
sales, reduced paperwork, improved accountability, or greater trust. Not all benefits are easily
converted into money. If a hospital system reduces missing patient files, the value includes
time saved, better care, and reduced stress for staff and patients.

­ CHECKPOINT
For a campus announcement system, list two possible costs and three possible benefits.

2.4.5 Operational Feasibility

Operational feasibility asks whether the system will work well in the real environment where it
will be used. A system can be technically possible and financially affordable but still fail if users
cannot fit it into daily work.

User acceptance is central. If reception staff at a clinic believe a new appointment system slows
them down during busy mornings, they may return to the paper notebook. If lecturers find an
online marks upload screen confusing, they may delay submitting results. If students do not
trust a registration portal, they may still queue at the department office for confirmation.

Operational feasibility also asks whether the organization is ready. Does it have management
support? Who will train users? Who will answer support questions? Who will correct wrong
data? Is internet reliable? Are policies clear? A system introduced without training, ownership,
or support may become abandoned even if the software itself works.

New software also changes daily work. Some tasks may disappear, some may become more
controlled, and some staff may need new skills. Planning should discuss these effects openly.
People are more likely to accept a system when they understand why it is being introduced and
 2 PLANNING AND CHOOSING HOW TO BUILD Feasibility Study
51

how it will help them.

2.4.6 Legal Feasibility

Legal feasibility asks whether the system can be built and operated within laws, regulations,
contracts, and licenses. Some systems must follow rules about finance, education, health, em‐
ployment, or government reporting. A hospital system must protect patient information. A
banking system must follow financial regulations. A school system must handle student records
responsibly.

Privacy and data protection are important even in class projects. Teams should avoid collecting
data they do not need. If a prototype does not require real student phone numbers, use sam‐
ple data. If a project stores names, registration numbers, marks, medical details, or payment
information, the team should ask who can see the data, where it is stored, how long it is kept,
and what happens if it is exposed.

Legal feasibility also includes software licensing. A team should not copy paid software, images,
fonts, or code without permission. Open‐source software can be useful, but its license should
be respected.

2.4.7 Schedule Feasibility

Schedule feasibility asks whether the project can be completed within the available time. Dead‐
lines may come from academic calendars, business needs, legal dates, funding periods, or pub‐
lic events. A registration system must be ready before registration begins. A ticketing system
must be ready before ticket sales open.

The team should not look only at the final deadline. It should ask whether users will be available
for interviews, whether developers have enough working time, whether devices and data can
be obtained early, and whether testing can happen before demonstration day. A team may
have three months on paper, but if key users are unavailable until the last week, progress will
suffer.

Time constraints should shape scope. If a student team has four weeks, it should choose a small
set of features and build them well. A realistic plan is better than a large promise.
 2 PLANNING AND CHOOSING HOW TO BUILD Understanding User Requirements
52

2.4.8 Example: Feasibility Study for an Online Learning System

A department wants an online learning system for course notes, announcements, assignments,
and quizzes. The team studies feasibility:

• Technical: The department has internet and students have phones, but some students
have weak data access.
• Economic: Hosting is affordable, but SMS reminders would cost money.
• Operational: Lecturers are willing to upload notes, but need training.
• Legal: Student data and grades must be protected.
• Schedule: The first version must be ready before the next semester.

The team recommends a first version with notes, announcements, and assignment submission.
Quizzes and SMS reminders are placed in a later release. This is a practical feasibility decision.

2.5 Understanding User Requirements

2.5.1 Meaning of Requirements

Requirements describe what a system should do and the conditions it should satisfy. Require‐
Requirements ments guide design, coding, testing, and acceptance.
guide work

A requirement should help the team understand user needs. For example, “students can view
available course units for their programme and year of study” is clearer than “make course
page.”

Requirements are not only about screens. They may include rules, data, performance, security,
usability, and reporting.

2.5.2 Why Requirements Are Important

Requirements are important because they reduce misunderstanding. They help the team and
stakeholders agree on what is being built. They also help testers know what to check.

If requirements are weak, the team may build software that works technically but does not
solve the right problem. For example, a team may build a beautiful complaint form but forget
that complaints need assignment, tracking, response deadlines, and reports.
 2 PLANNING AND CHOOSING HOW TO BUILD Understanding User Requirements
53

2.5.3 Stakeholders in Requirements Gathering

Requirements come from stakeholders. A good team listens to more than one voice.

End users directly use the system, so they understand daily tasks and frustrations. In a library
system, end users include students who borrow books and librarians who manage borrowing,
returns, and overdue records. Managers may not use every screen, but they care about reports,
control, policy, performance, and cost. They often define organizational goals.

System analysts help study the problem, organize requirements, and communicate between
users and technical team members. Developers help judge technical possibilities and risks,
but they should listen carefully before proposing solutions. External stakeholders may include
regulators, payment providers, parents, auditors, suppliers, or partner organizations. They may
affect requirements even if they do not use the system daily.

ʢ SIDEBAR | Different stakeholders notice different needs

In a student fees system, a student may care about quick payment confirmation. A
cashier may care about correcting failed transactions. An accountant may care about
reconciliation reports. An auditor may care about who changed a record. If the team
listens to only one group, important requirements will be missed.

2.5.4 Requirements as a Guide for Development

Requirements guide several activities:

• Product backlog creation.

• User interface design.
• Database design.
• Coding tasks.
• Test cases.
• User acceptance.
• Documentation.

In agile projects, requirements may be written as backlog items and refined over time. In more
formal projects, requirements may be written in a document before design begins. In both
cases, the team needs shared understanding.
 2 PLANNING AND CHOOSING HOW TO BUILD Techniques for Gathering Requirements
54

2.5.5 Problems Caused by Poor Requirements

Misunderstanding happens when the team hears words but misses meaning. A user may ask
for “reports,” but the team must know which reports, for whom, in what format, and how often.

Incomplete features happen when the team builds only part of a workflow. For example, al‐
lowing students to submit registration is incomplete if administrators cannot approve or reject
it.

Poor requirements often lead to rework. Rework means doing work again because the first
version was wrong or incomplete. Rework costs time and money.

Users become dissatisfied when the system does not match their needs. They may avoid using
it or create their own manual workarounds.

These problems are connected. If user needs are misunderstood, features are likely to be in‐
complete. If features are incomplete, the team must redo work. If users wait too long for a
useful system, trust is lost. This is why requirements work is not a formality. It protects the
project from expensive confusion.

2.6 Techniques for Gathering Requirements

2.6.1 Why One Technique Is Not Enough

Requirements gathering is the process of learning what the system should do, why it matters,
who will use it, and what limits must be respected. A beginner mistake is to use only one
technique and treat the result as the full truth. In real projects, one technique rarely shows the
Use more than one whole picture.
lens

Interviews may reveal deep stories, but only from a few people. Questionnaires may reach
many users, but they may not explain the reasons behind answers. Observation may reveal real
work, but users may behave differently when watched. Documents may show official rules, but
they may not show how work is actually done. Workshops may create shared understanding,
but some voices may dominate. Prototypes may help users react to a visible idea, but users
may mistake the prototype for the finished system.

Good teams combine techniques. For example, when planning a university registration sys‐
tem, the team may interview the registrar, observe students during registration week, study
existing registration forms, send a questionnaire to students, run a workshop with department
 2 PLANNING AND CHOOSING HOW TO BUILD Techniques for Gathering Requirements
55

administrators, and build a prototype screen for feedback. Each method adds a different kind
of evidence.

Í Requirement evidence
A useful requirement is stronger when it is supported by more than one source. If stu‐
dents complain about confusing course selection, administrators report many correction
requests, and observation shows students asking for help at the same step, the team has
stronger evidence than if only one person mentioned the problem.

2.6.2 Interviews: Learning the Story Behind the Work

An interview is a planned conversation with a stakeholder. It is useful when the team needs
depth: rules, reasons, exceptions, frustrations, priorities, and stories about what usually goes
wrong. Ask, then listen

An interview should not feel like an interrogation. The aim is to learn how the stakeholder
thinks about the work. A registrar may explain why certain students cannot register until fees
are cleared. A cashier may explain what happens when a mobile money payment is delayed.
A lecturer may explain why assignment deadlines sometimes need extensions. These details
may never appear in a simple feature list.

Good interviewers prepare questions, but they also listen for unexpected answers. If an admin‐
istrator says, “That only happens for repeating students,” the interviewer should pause and
ask, “What is different about repeating students?” Often, the most important requirements
are hidden in exceptions.

ʢ SIDEBAR | Sample interview questions for a registration system

• Walk me through what happens when a student registers successfully.
• What usually causes registration to fail?
• Which cases require a human decision?
• What information do students often misunderstand?
• Which reports do you prepare after registration closes?
• What should the system never allow?
• If this system saves you two hours per day, where would that saving come from?

Interviews have limits. One stakeholder may not know the whole process. A manager may
describe official work, while frontline staff know the practical shortcuts used on busy days. A
user may forget routine steps because they have become automatic. For this reason, interview
notes should be checked against other sources.
 2 PLANNING AND CHOOSING HOW TO BUILD Techniques for Gathering Requirements
56

Ď TIP
Do not ask only, “What features do you want?” Also ask, “What problem are you trying
to solve?” Users often suggest a solution before fully explaining the need.

2.6.3 Questionnaires: Hearing from Many Users

A questionnaire is a set of written questions answered by many people. It is useful when the
team needs broad feedback from a large group, such as many students using a learning platform
or many customers using a delivery service.

Questionnaires work best when the team already understands the topic enough to ask focused
questions. If the team knows nothing about the problem, interviews and observation should
come first. Otherwise, the questionnaire may ask the wrong questions and produce neat but
misleading numbers.

For example, a team improving a learning platform may ask 200 students about assignment
submission. A weak question would be:

Do you like the learning platform?

This is too broad. A student may like the notes but dislike assignment submission. Better ques‐
tions are more specific:

• How often do you fail to find an assignment before the deadline?

• Which device do you normally use to submit assignments?
• What is the most common problem you face during upload?
• Did you receive confirmation after your last submission?
• How clear are deadline dates on the assignment page?

Questionnaires can collect numbers that help planning. If 75 percent of students use phones,
mobile‐friendly design becomes important. If many students report poor internet, the team
may reduce file size or improve upload recovery. Numbers help the team avoid designing only
for the loudest users.

However, questionnaires also have weaknesses. People may misunderstand questions. Some
may answer quickly without thinking. Closed questions can hide important explanations. To
reduce this problem, include a small number of open‐ended questions such as, “Describe one
problem you faced when submitting an assignment.” Keep the questionnaire short enough that
users will actually complete it.
 2 PLANNING AND CHOOSING HOW TO BUILD Techniques for Gathering Requirements
57

­ CHECKPOINT
Write three questionnaire questions for students who use a campus food ordering app.
Make each question specific enough to guide a design decision.

2.6.4 Observation: Seeing What People Actually Do

Observation means watching users perform their work. It is valuable because what people say
they do and what they actually do can differ. This does not mean users are dishonest. It means
real work contains small steps, interruptions, and shortcuts that people forget to mention.

Imagine a team is building a small shop inventory system. In an interview, the shop attendant
says, “When stock arrives, I record it in the book.” During observation, the team sees more
detail. The attendant first checks the supplier invoice, counts items, separates damaged goods,
calls the owner if prices changed, writes quantities in a notebook, and later sends a photo of
the page through a messaging app. A simple “record stock” requirement is no longer enough.

Observation helps the team discover:

• Steps users forget to mention.

• Interruptions that affect work.
• Paper forms, notebooks, spreadsheets, or messages used as workarounds.
• Physical limits, such as a busy counter or weak network area.
• Repeated mistakes or delays.
• Informal approvals that are not written in official procedures.

Observation should be done respectfully. In sensitive settings such as clinics, finance offices, or
student records offices, permission is required and private information must be protected. The
observer should avoid blocking work or embarrassing users. The aim is to understand work,
not to judge people.

ʢ SIDEBAR | Observation note example

Context: Department office during course registration.
Observed issue: Students repeatedly ask why a course unit is missing from the portal.
User workaround: Administrator checks a printed curriculum sheet and manually ex‐
plains that the course belongs to semester two.
Possible requirement: The system should show unavailable course units with a simple
reason, such as “offered next semester” or “prerequisite not yet completed.”

Observation has limits. Users may act differently when watched. Some events happen rarely
 2 PLANNING AND CHOOSING HOW TO BUILD Techniques for Gathering Requirements
58

and may not occur during the observation period. Observation also takes time. It should there‐
fore be combined with interviews, documents, and user feedback.

2.6.5 Document Analysis: Learning from Existing Records

Document analysis means studying forms, reports, policies, manuals, spreadsheets, emails,
registers, and other existing records. Documents are useful because they show the information
an organization already collects and the rules it claims to follow.

For example, a student registration form may reveal required fields such as registration number,
programme, year of study, course code, credit units, and student signature. A department
report may reveal that administrators need totals by programme and year. A policy document
may reveal that registration closes two weeks after semester start. These details can become
requirements.

Documents can answer practical questions:

• What data must the system store?

• Which reports are already expected?
• Which approvals are official?
• Which terms does the organization use?
• Which rules are written down?
• Which records must be kept for auditing?

But documents are not always the full truth. A procedure may say that every form is approved
within two days, while staff know it often takes a week. A spreadsheet may contain columns
nobody uses anymore. A report may exist only because a former manager requested it years
ago. The team should ask users whether each document still reflects real work.

Document What it can reveal Question to ask

Application form Data fields and required attach‐ Are all fields still needed?
ments
Monthly report Management information Who uses this report and why?
needs
Policy document Official rules and deadlines Are there exceptions in prac‐
tice?
Complaint register Common problems and re‐ Which complaints repeat often?
sponse times
Spreadsheet tracker Current workaround and calcu‐ Which formulas or columns are
lations critical?
 2 PLANNING AND CHOOSING HOW TO BUILD Techniques for Gathering Requirements
59

2.6.6 Workshops: Building Shared Understanding

A workshop is a structured group session where stakeholders discuss needs together. Work‐
shops are useful when a process crosses several roles or departments. They help people hear
each other’s concerns and agree on priorities.

Consider student registration. Students want a simple process. Department administrators

want correct course selections. Finance staff want fee rules respected. The academic regis‐
trar wants official records. If the team interviews each group separately, conflicts may remain
hidden. In a workshop, the groups can discuss the whole process together.

A good workshop needs a clear agenda. Without structure, the loudest person may dominate.
A simple workshop plan may include:

1. State the problem being discussed.

2. Map the current process.
3. Identify pain points.
4. List desired improvements.
5. Separate must‐have needs from nice‐to‐have ideas.
6. Agree on unresolved questions.

Workshops are especially useful for resolving conflicting needs. For example, students may
want to edit registration many times, but administrators may need a final submission deadline.
The workshop can lead to a balanced requirement: students may edit before submission, but
changes after approval require department permission.

Á WARNING
A workshop is not successful just because many people attended. It is successful when
it produces clearer decisions, agreed priorities, or well‐defined questions for follow‐up.

2.6.7 Prototyping: Making Ideas Visible

A prototype is an early sample or model of a system. It may be a paper sketch, a drawing, a

clickable screen, a spreadsheet simulation, or a small working feature. Prototyping is useful
because many users understand their needs better when they can see and react to something.
Show early, learn
early

Suppose students are asked, “What should a registration page show?” Some may say, “Just
show the courses.” But when shown a prototype, they may notice missing details: course codes,
full course names, credit units, timetable slots, lecturer names, prerequisites, and whether the
 2 PLANNING AND CHOOSING HOW TO BUILD Techniques for Gathering Requirements
60

course is compulsory or elective. The prototype helps users move from general opinions to
concrete feedback.

There are two common ways to use prototypes. A throwaway prototype is built only for learn‐
ing and is discarded. For example, a paper sketch may help the team understand screen layout.
An evolutionary prototype is improved step by step until it becomes part of the final system.
Evolutionary prototypes must be built more carefully because weak prototype code can be‐
come a long‐term problem if reused carelessly.

When using prototypes, the team should explain what the prototype is and what it is not. Users
may think a neat screen means the system is almost finished, even when there is no database,
security, or business logic behind it. The team should say, “This is only a sample screen to check
the flow. We are not yet showing the final design.”

ʢ SIDEBAR | Prototype feedback questions

• What is clear on this screen?
• What is confusing?
• What information is missing?
• What action would you take next?
• Which mistake might a first‐time user make here?
• What should happen if the system cannot complete this action?

2.6.8 Choosing the Right Technique for the Situation

The best technique depends on what the team needs to learn. If the team needs deep rules,
interview knowledgeable stakeholders. If it needs views from many users, use questionnaires.
If it needs to understand real work, observe. If it needs official data and rules, analyze doc‐
uments. If several groups must agree, run a workshop. If requirements are unclear, build a
prototype.

Technique Use it when you need Be careful about

Interviews Detailed explanations and excep‐ One person’s view may be in‐
tions complete
Questionnaires Feedback from many users Questions may be misunder‐
stood
Observation Real workflow and hidden steps Users may behave differently
when watched
Document analysis Existing data, rules, and reports Documents may be outdated
Workshops Agreement across roles Strong voices may dominate
Prototypes Feedback on unclear ideas Users may think the prototype is
final
 2 PLANNING AND CHOOSING HOW TO BUILD Types of Requirements
61

­ CHECKPOINT
For a hostel maintenance request system, choose three requirement gathering tech‐
niques and explain what each one would help you learn.

2.7 Types of Requirements

2.7.1 Functional Requirements: What the System Must Do

Functional requirements describe what the system should do. They are about functions, ac‐
tions, services, and behavior. A functional requirement usually describes an action that a user
or another system can perform. What the system
does

A weak functional requirement is vague: “the system should manage registration.” A stronger
functional requirement is specific: “the system shall allow a student to select eligible course
units and submit them for department approval.” The stronger version tells the team what
action is expected and who performs it.

Functional requirements often describe workflows. In a registration system, one requirement

may lead to several related actions:

• Student views eligible course units.

• Student selects course units.
• System checks timetable clashes.
• Student submits registration.
• Department administrator approves or rejects the submission.
• Student downloads confirmation.

In a banking system, functional requirements may include checking balance, transferring funds,
viewing transaction history, changing PIN, and generating statements. In a clinic system, they
may include registering a patient, booking an appointment, recording consultation notes, send‐
ing prescriptions to pharmacy, and preparing daily attendance reports.

Ď TIP
When writing functional requirements, include the actor, the action, and the purpose
when possible. “Administrator can approve submitted registration so that official class
lists are accurate” is clearer than “approval feature.”
 2 PLANNING AND CHOOSING HOW TO BUILD Types of Requirements
62

2.7.2 Non‐Functional Requirements: How Well the System Must Work

Non‐functional requirements describe qualities or conditions of the system. They are not
How well it works about one specific function, but about how well the system should work.

Non‐functional requirements may concern speed, security, reliability, usability, maintainabil‐

ity, availability, or legal compliance. They often affect many features at once. For example, the
functional requirement may say that students can submit registration. Non‐functional require‐
ments may say that submission should complete within five seconds, only authorized students
can submit, records must not be lost if the network drops, and the form should be understand‐
able to first‐year students.

Beginners sometimes ignore non‐functional requirements because they do not look like visible
features. This is dangerous. A system may have all required features and still fail because it is
too slow, insecure, unreliable, confusing, or hard to change.

Quality Question it answers Example

Performance How fast or how much load? Registration page loads within
three seconds during normal use.
Security Who is allowed to do what? Only authorized staff can approve
registration.
Reliability Can users depend on it? A submitted record is not lost if in‐
ternet disconnects.
Usability Can users understand it? First‐year students can find regis‐
tration steps without training.
Maintainability Can it be changed later? Administrators can update course
lists without changing code.

Non‐functional requirements should be testable where possible. “The system should be fast”
is weak because different people will interpret “fast” differently. “The course list should load
within three seconds for 500 active users” is stronger because it can be checked.

2.7.3 Comparing Functional and Non‐Functional Requirements

Functional requirements describe features. Non‐functional requirements describe qualities.

Both matter.
 2 PLANNING AND CHOOSING HOW TO BUILD Introducing Development Approaches
63

Question Functional requirement Non‐functional requirement

Main concern What the system does How well the system works
Example Student submits registration Submission completes within
five seconds
Testing Check the feature works Check speed, security, usabil‐
ity, reliability
Impact Often visible as a feature Often affects many features

2.7.4 Example: Requirements for an Automated Teller Machine System

An automated teller machine system has functional requirements such as:

• Customer can insert card and enter PIN.

• Customer can withdraw cash.
• Customer can check account balance.
• Customer can print a receipt.

It also has non‐functional requirements:

• PIN must be hidden while typed.

• Cash withdrawal must be recorded accurately.
• The machine should respond quickly.
• The system should work even when many customers use ATMs across branches.
• Unauthorized users must not access account information.

2.8 Introducing Development Approaches

2.8.1 Meaning of a Development Approach

A development approach is a way of organizing how software work is done. It guides how the
team moves through requirements, design, coding, testing, delivery, and feedback. Choose how to
work

Different projects need different approaches. A small student prototype is not managed the
same way as a national tax system. A project with stable legal rules may use more upfront
planning. A project with unclear user needs may need prototypes and frequent feedback.
 2 PLANNING AND CHOOSING HOW TO BUILD Introducing Development Approaches
64

2.8.2 Why Different Development Approaches Exist

Different approaches exist because projects differ in size, risk, uncertainty, user involvement,
deadlines, and team experience. No single approach is best for every project.

The important question is not “Which model is fashionable?” The important question is “Which
approach fits this situation?”

2.8.3 The Relationship Between Requirements and Development Approach

When requirements are clear and stable, a more sequential approach may work. When require‐
ments are unclear or likely to change, iterative, incremental, prototyping, or agile approaches
may be better.

For example, building software for a well‐defined examination grading rule may allow careful
upfront requirements. Building a new student engagement app may require frequent feedback
because users may not know exactly what they want until they see examples.

2.8.4 Factors That Influence the Choice of Approach

Several factors influence the choice of development approach. Project size matters because
large projects need more coordination, documentation, and risk control, while small projects
can be more flexible. Requirement stability matters because stable requirements support more
upfront planning, while changing requirements need feedback cycles.

User involvement is also important. If users are available often, agile or prototyping can work
well because the team can show work and learn quickly. If users are rarely available, the team
may need more formal requirement approval before building. Risk matters too. A high‐risk
payment system, hospital system, or safety‐related system needs careful analysis, testing, and
decision points.

Time, budget, and team experience shape the choice as well. Short time and limited budget
require careful scope control. An inexperienced team should avoid overly complex approaches
and risky technology. Clear roles, simple planning, and frequent feedback help beginner teams
more than complicated project management rituals.

­ CHECKPOINT
A student team has six weeks, unclear requirements, and access to users every Friday.
Which approach would you recommend and why?
 2 PLANNING AND CHOOSING HOW TO BUILD Common Development Models
65

2.9 Common Development Models

2.9.1 Sequential Models: Waterfall and V‐Model

The waterfall model organizes work in sequential phases, commonly requirements, design,
implementation, testing, deployment, and maintenance. The basic idea is that the team un‐
derstands requirements first, designs the solution, builds it, tests it, and then delivers it. Wa‐
terfall can be useful when requirements are stable, the problem is well understood, and formal
documentation is important.

For example, if a government office needs a report that follows a fixed legal format, a sequen‐
tial approach may work because the rules are known and unlikely to change every week. The
team can document the requirements carefully, design the report, build it, and test against the
approved format.

The weakness of waterfall appears when users discover needs late. If feedback comes only
near the end, mistakes may be expensive. Imagine building a registration system for months
and discovering during final testing that repeating students follow different rules. The team
may need major rework.

The V‐model is also sequential, but it emphasizes testing from the beginning. Each develop‐
ment stage has a related testing stage. Requirements are connected to acceptance testing,
system design to system testing, and detailed design to integration and unit testing. The V‐
model is useful when correctness and verification are important, such as medical, financial, or
safety‐related systems.

2.9.2 Learning‐Based Models: Iterative, Incremental, and Prototyping

The iterative model builds software through repeated cycles. The team builds something, re‐
views it, learns from it, and improves it. Iteration is useful when the team expects learning. For
example, CampusConnect may begin with a simple announcement screen. After students use
it, the team may add urgent labels, expiry dates, search, and category filters.

The incremental model delivers the system in useful parts called increments. Instead of waiting
for the whole system, users receive value earlier. A registration system may first deliver course
viewing, then registration submission, then approval, then confirmation download. Each incre‐
ment should be tested and should fit the larger system.
 2 PLANNING AND CHOOSING HOW TO BUILD Common Development Models
66

The prototyping model uses early samples to learn requirements. A prototype may be thrown
away after learning, or it may evolve into the final system. Prototyping is useful when users are
unsure what they need. Its danger is that users may see a neat screen and assume the system is
almost complete, even though the database, security, error handling, and testing are not done.

ʢ SIDEBAR | Iteration and increments are related but not identical

Iteration means improving through repeated cycles. Incremental delivery means giving
users useful parts step by step. A team can use both: build a small increment, get feed‐
back, improve it, then build the next increment.

2.9.3 Risk and Speed Models: Spiral and RAD

The spiral model organizes development around repeated cycles with strong attention to risk.
Each cycle considers objectives, risks, development, and evaluation. This model is useful when
risk is high, such as when the system handles large amounts of money, private health records,
or unfamiliar technology.

For example, before building a hospital records system, the team may first study privacy risk,
then test whether staff can use tablets during consultations, then prototype patient search,
then evaluate data backup. The point is to address serious risks early instead of discovering
them after the system is nearly complete.

Rapid Application Development, often called RAD, focuses on fast delivery using user involve‐
ment, tools, and reusable components. It can work well for business applications with clear
screens and moderate risk, such as internal forms, dashboards, and simple workflow systems.
RAD is less suitable when the system needs deep safety analysis, complex algorithms, or strict
legal verification.

2.9.4 Agile Development

Agile development values short cycles, working software, user feedback, team collaboration,
Feedback drives and response to change.
agile

Agile teams commonly work with a product backlog, sprint planning, daily coordination, sprint
reviews, and retrospectives. A sprint is a short fixed period, such as one or two weeks, where
the team works toward a sprint goal. At the end of the sprint, the team shows completed work
and uses feedback to refine future backlog items.

Agile does not mean doing anything at any time. Change is managed through prioritization. If
a new request appears, the team asks whether it is more important than the current backlog
 2 PLANNING AND CHOOSING HOW TO BUILD Comparing Development Models
67

items. This keeps learning possible without allowing chaos.

Agile is especially helpful when requirements may change, users can give feedback regularly,
and the team can deliver in small pieces. It is not a replacement for thinking. Agile teams still
need planning, testing, design, documentation, and responsible decisions.

2.10 Comparing Development Models

2.10.1 Comparison by Flexibility

Waterfall and V‐model are less flexible because they depend on early agreement. Agile, itera‐
tive, incremental, and prototyping approaches are more flexible because they support learning
during development.

2.10.2 Comparison by User Involvement

Agile, RAD, and prototyping usually involve users often. Waterfall may involve users heavily at
the beginning and end, but less during coding.

2.10.3 Comparison by Risk Management

The spiral model is strongest for explicit risk management. V‐model is strong for verification.
Agile reduces some risks through frequent feedback, but high‐risk systems still need careful
controls.

2.10.4 Comparison by Documentation

Waterfall and V‐model often use more formal documentation. Agile uses documentation too,
but tries to keep it useful and lightweight.

2.10.5 Comparison by Speed of Delivery

Incremental, agile, and RAD can deliver useful parts earlier. Waterfall may deliver later because
phases are completed before release.
 2 PLANNING AND CHOOSING HOW TO BUILD Choosing a Suitable Development Approach
68

2.10.6 Comparison by Suitability for Changing Requirements

Changing requirements fit agile, iterative, incremental, and prototyping approaches better than
strict waterfall. However, even agile teams must control change through backlog prioritization.

Approach Best when Main strength Main caution

Waterfall Requirements are sta‐ Clear phases Late feedback can hurt
ble
V‐model Testing must be Strong verification Can be rigid
planned early
Iterative Learning is expected Improvement cycles Needs discipline
Incremental Value can be delivered Early delivery Parts must fit together
in parts
Spiral Risk is high Risk analysis Can be complex
Prototyping Requirements are un‐ User feedback Prototype may be mis‐
clear taken for final product
RAD Business app needed Fast components May not suit high‐risk
quickly systems
Agile Change and feedback Adaptability Needs active users and
are expected team discipline

2.11 Choosing a Suitable Development Approach

2.11.1 Matching the Approach to the Project

Choosing an approach means matching the way of working to the project situation. The team
should consider requirements, users, risk, deadline, team skills, and organization expectations.
Fit matters

There is no prize for choosing the most popular model. The best choice is the one that helps
the team deliver useful, reliable software under the real conditions of the project.

2.11.2 Decision Scenarios

If requirements are stable and well understood, waterfall or V‐model may be suitable. Examples
include systems based on fixed laws, fixed reporting rules, or well‐known processes. Even then,
the team should still communicate with users and test carefully.
 2 PLANNING AND CHOOSING HOW TO BUILD Choosing a Suitable Development Approach
69

If requirements are unclear or changing, agile, iterative, incremental, or prototyping approaches

are more suitable. These allow feedback and adjustment. CampusConnect is a good example.
First‐year students may not know exactly what they need until they see early screens, so short
feedback cycles are valuable.

High‐risk projects need stronger risk management. A hospital system, payment system, or
safety‐related system should not rely only on informal feedback. Such projects may use a hy‐
brid approach: upfront feasibility and requirements work, risk analysis, incremental delivery,
formal testing, user training, and management checkpoints.

Small student projects often fit a simple agile‐incremental approach. The team can create a
product backlog, choose a small sprint goal, build a working part, test it, and show it for feed‐
back. For a six‐week project, three two‐week sprints may be enough:

• Sprint 1: user login and basic data setup.

• Sprint 2: main feature workflow.
• Sprint 3: reports, testing, correction, and polish.

Large organizational systems may also use agile ideas, but usually with more structure. They
may need formal approval, procurement rules, security review, data migration plans, user train‐
ing, and support planning. Real organizations often mix practices. The goal is not to follow a
textbook model blindly. The goal is to manage complexity, risk, and learning.

2.11.3 Common Mistakes When Choosing an Approach

One common mistake is choosing a rigid approach when requirements are unclear. If users are
unsure what they need, a long upfront specification may create false confidence. Prototypes
and feedback are better.

Another mistake is ignoring user involvement. A team that does not involve users may build
software that users reject. User involvement should be planned, not left to chance.

A third mistake is underestimating risk. Security, data loss, legal issues, deadline pressure,
unfamiliar technology, and user resistance can damage a project. Risk should be discussed
early.

Finally, teams sometimes ignore their own experience. Learning is good, but too much new
technology can overwhelm a beginner team. It is better to build a smaller working system with
tools the team can manage than to promise a large system using unfamiliar tools.
 2 PLANNING AND CHOOSING HOW TO BUILD Basic Project Planning Activities
70

2.12 Basic Project Planning Activities

2.12.1 Preparing a Simple Project Plan

A simple project plan describes what will be done, when it will be done, who will do it, what
Make work visible resources are needed, and what risks exist.

For a first‐year project, the plan does not need to be complicated. It can include a goal, scope,
backlog items, timeline, roles, risks, and communication plan.

2.12.2 Estimating Work, Cost, and Resources

Estimation means predicting the effort, time, and resources needed for the project. Beginners
often underestimate time because they think only about coding. They forget requirements,
design, testing, fixing bugs, meetings, documentation, and demonstrations.

Estimate in small pieces. “Build system” is impossible to estimate well. “Create login screen,”
“write acceptance criteria for registration submission,” or “test course selection with three stu‐
dent records” is easier. Smaller tasks make progress visible.

Cost may include money and effort. In a student project, cost may be time, internet data,
hosting, printing, or transport for user interviews. In organizations, cost includes salaries, li‐
censes, equipment, hosting, training, and support. Resources include people, skills, tools, de‐
vices, data, rooms, internet, and access to users. A team should know what it needs before
promising delivery.

2.12.3 Assigning Responsibilities and Managing Risks

Responsibilities should be clear. A student team may assign roles such as coordinator, require‐
ments lead, developer, tester, and documentation lead. One person can hold more than one
role, but everyone should know who is doing what.

Risks should be listed and watched from the beginning. Examples include:

• Users may not be available for interviews.

• Team members may have limited experience with the chosen tool.
• Scope may be too large for the deadline.
 2 PLANNING AND CHOOSING HOW TO BUILD Running Case Study: CampusConnect Planning
71

• Test data may be unavailable.

• Internet access may be unreliable.

A risk list should include possible responses. For example, if users are unavailable, the team
may schedule interviews early and prepare questionnaires as backup.

2.12.4 Communicating and Monitoring Progress

Communication should be planned. The team should decide who needs updates, how often,
and in what format. For a student project, this may include weekly lecturer updates, a task
board, and one feedback session with users.

Monitoring progress means checking whether work is moving as planned. In agile teams, this
may happen through daily stand‐ups, task boards, sprint reviews, and retrospectives. Monitor‐
ing should reveal problems early. If a task is stuck for several days, the team should discuss it
rather than hide it.

ʢ SIDEBAR | A simple weekly planning rhythm

• Monday: agree on tasks for the week.
• Wednesday: check blockers and adjust.
• Friday: show progress, test completed work, and update the backlog.

This rhythm is simple enough for first‐year students, but it teaches professional habits:
visibility, feedback, and responsibility.

2.13 Running Case Study: CampusConnect Planning

2.13.1 The Project Idea

CampusConnect is a proposed system for first‐year students. The idea is to help them settle
into university life by giving them easy access to orientation announcements, campus office
locations, registration steps, and useful contacts. Plan the case

The first idea is broad. The team must turn it into a project.
 2 PLANNING AND CHOOSING HOW TO BUILD Running Case Study: CampusConnect Planning
72

2.13.2 Problem and Opportunity

The team interviews ten first‐year students and two student leaders. Students report that they
often miss announcements, do not know where offices are, and ask the same questions repeat‐
edly in messaging groups. Student leaders say they spend too much time answering repeated
questions.

The opportunity is to provide one reliable place for important first‐year information.

2.13.3 Scope for the First Version

The team defines the first version:

• Students can view orientation announcements.

• Students can search for key campus offices.
• Students can view registration steps.
• An administrator can post and expire announcements.

The first version will not include live chat, hostel booking, course registration, online payment,
or lecturer messaging.

2.13.4 Simple Feasibility

The team checks feasibility:

• Technical: A web application is realistic for the team. A native mobile app is too much
for the first version.
• Economic: The project can use free development tools and university hosting for demon‐
stration.
• Operational: Student leaders are willing to help review content.
• Legal: The system will not collect sensitive personal data in the first version.
• Schedule: The team has six weeks, so scope must stay small.

2.13.5 Requirements and Backlog

The team writes backlog items:

 2 PLANNING AND CHOOSING HOW TO BUILD Running Case Study: CampusConnect Planning
73

• As a student, I want to view orientation announcements so that I do not miss important

information.
• As a student, I want to search for campus offices so that I can find help quickly.
• As a student, I want to view registration steps so that I know what to do next.
• As an administrator, I want to post announcements so that students receive official up‐
dates.
• As an administrator, I want to set announcement expiry dates so that old information is
hidden.

One backlog item has acceptance criteria:

As a student, I want to view orientation announcements so that I do not miss im‐

portant information.

Acceptance criteria:

• Announcements are shown from newest to oldest.

• Expired announcements are not shown.
• Urgent announcements appear before normal announcements.
• Selecting an announcement opens full details.

2.13.6 Choosing the Approach

The team chooses a simple agile‐incremental approach. Requirements may change after stu‐
dents see the first screens, and the team has only six weeks. The team plans three two‐week
sprints:

• Sprint 1: Announcements.
• Sprint 2: Campus office search.
• Sprint 3: Registration steps, testing, and polish.

This plan is small, understandable, and practical.

2.14 Chapter Summary

 2 PLANNING AND CHOOSING HOW TO BUILD Chapter Summary
74

Planning helps software teams move from vague ideas to realistic projects. A team should
understand the current problem or opportunity before proposing a solution. It should define
scope so everyone knows what is included and what is not included. It should check feasibility
to decide whether the project is technically, economically, operationally, legally, and schedule‐
wise possible.

Requirements guide the team by describing what the system should do and the qualities it
should have. Requirements can be gathered through interviews, questionnaires, observation,
document analysis, workshops, and prototypes. Functional requirements describe system ac‐
tions. Non‐functional requirements describe qualities such as performance, security, usability,
reliability, and maintainability.

Different development approaches exist because projects differ. Waterfall and V‐model are
more sequential. Iterative, incremental, prototyping, RAD, spiral, and agile approaches support
different levels of learning, feedback, speed, and risk management. The best approach is the
one that fits the project situation.

n KEY TAKEAWAYS
• Planning helps teams build the right thing, not just build quickly.
• Scope defines the boundaries of the project.
• Feasibility checks whether the project is practical.
• Requirements connect user needs to design, coding, and testing.
• Development models are tools; choose them based on the project.
• Small student projects often benefit from simple agile and incremental planning.

2.15 Review Questions

2.15.1 Short Answer Questions

1. Why should planning come before coding?

2. What is a project scope?
3. Define scope creep and give one example.
4. What is a feasibility study?
5. Name five types of feasibility.
6. What is the difference between a functional and non‐functional requirement?
 2 PLANNING AND CHOOSING HOW TO BUILD Review Questions
75

7. Give two examples of requirement gathering techniques.

8. What is a prototype?
9. When might the waterfall model be suitable?
10. Why is agile useful when requirements may change?

2.15.2 Discussion Questions

1. A student team wants to build a complete university management system in six weeks.
What planning advice would you give them?
2. Why can a technically possible project still be a bad idea?
3. How can unclear requirements increase project cost?
4. Compare waterfall and agile using a university registration project.
5. Why should excluded scope be written clearly?

2.15.3 Practical Activity

Choose one project idea from the list below or create your own:

• Clinic appointment system.

• Campus lost‐and‐found system.
• Small shop inventory system.
• Student complaint tracking system.
• Hostel maintenance request system.

Prepare a short planning document with:

• Problem or opportunity statement.

• Main stakeholders.
• Scope: what is included.
• Scope: what is not included.
• Simple feasibility study.
• Five functional requirements.
• Three non‐functional requirements.
• Recommended development approach and reason.

2.15.4 Mini Sprint Planning Exercise

In groups, use your project idea to prepare a first sprint plan:

 2 PLANNING AND CHOOSING HOW TO BUILD Review Questions
76

1. Write a sprint goal.

2. Select three backlog items for the sprint.
3. Write two acceptance criteria for each item.
4. Identify two risks.
5. Assign responsibilities to team members.

CHAPTER REVIEW

SUMMARY REVIEW QUESTIONS

• Planning connects ideas to practical work. 1. What problem are we solving?

• Scope, feasibility, and requirements help 2. What is inside and outside scope?
prevent confusion and waste. 3. Is the project feasible?
• Development approaches should match 4. Which approach fits this project best?
project risk, uncertainty, users, and dead‐
line.
• A simple plan can make student projects
more realistic and successful.
REFERENCE

CHAPTER 2 KEY TERMS

Plain‐language meanings for planning and development choices.

Project Scope Whether costs are reasonable compared with ex‐

pected benefits.

Operational Feasibility
The boundary of what a project will and will not
include.

Scope Creep Whether the system can work in the real organiza‐
tion.

Legal Feasibility
Uncontrolled expansion of project work without
proper review.

Feasibility Study Whether the system respects laws, regulations,

contracts, and licenses.

Schedule Feasibility
A practical check of whether a project can and
should be done.

Technical Feasibility Whether the project can be completed in the avail‐

able time.

Requirement
Whether the required technology and skills are
available.

Economic Feasibility A statement of what a system should do or a con‐

dition it should satisfy.

77
 2 PLANNING AND CHOOSING HOW TO BUILD Review Questions
78

Functional Requirement Waterfall Model

A requirement describing what the system does. A sequential development model with phases
completed one after another.
Non‐Functional Requirement
Incremental Model

A requirement describing a quality such as speed,

security, or usability. A model that delivers the system in useful parts.

Prototype Agile Development

An early sample used to learn from users. An approach based on short cycles, feedback, col‐
laboration, and response to change.
2 PLANNING AND CHOOSING HOW TO BUILD Review Questions
79

COMING UP NEXT

Working with Software Teams

The next chapter focuses on people: roles, communication, meetings, coordination, and practical
teamwork in software projects.
CHAPTER NO. 3

3
Working with Software Teams

PEOPLE, COORDINATION, AND PRACTICAL WAYS OF GETTING SOFTWARE WORK DONE

œ LEARNING OBJECTIVES
By the end of this chapter, you should be able to:

• Explain why most real software is built by teams rather than by one person working
alone.
• Identify the main people involved in a software project and describe how their
roles differ.
• Describe why communication is central to software quality, speed, and teamwork.
• Explain what a process framework is and why teams use one.
• Distinguish between core development activities and supporting umbrella activi‐
ties.
• Describe basic project management work in a way that fits student and beginner
projects.
• Explain agile ideas in practical language and relate them to Scrum, Kanban, and

80
 3 WORKING WITH SOFTWARE TEAMS Introduction to Software Teamwork
81

Extreme Programming.
• Write simple user stories, acceptance criteria, and backlog items.
• Plan and track team work using visible, manageable, first‐year‐friendly methods.

3.1 Introduction to Software Teamwork

3.1.1 Why Software Development Is Team Work

HEN STUDENTS BEGIN PROGRAMMING, they often work alone. One student receives

W an assignment, writes code, tests it, fixes mistakes, and submits it. This is a useful
starting point because it helps build personal confidence. However, most software
used in the real world is too large, too connected, and too important to depend on only one
person. Software is team
work

Think about a university registration system, a banking application, a delivery platform, or a

hospital appointment portal. Each of these systems involves user screens, stored data, security
rules, reports, tests, deployment, documentation, support, and change requests. The work is
broader than coding. One person may understand one part well, but it is rare for one person
to do everything well, quickly, and safely.

Software development becomes teamwork because software serves real people in real orga‐
nizations. If many users are involved, then many perspectives matter. Someone has to un‐
derstand the users. Someone has to build the interface. Someone has to structure the data.
Someone has to test. Someone has to track progress. Someone has to answer operational
questions such as where the system will run and who will support it after release. Even in a
small student project, these responsibilities exist, though one student may hold more than one
role.

“In software, quality does not come only from clever

code. It also comes from people sharing understanding
at the right time.”
TEAM MINDSET

This does not mean teamwork is automatically easy. A team can be stronger than an individual,
but it can also be slower, more confused, or more frustrated if work is not coordinated. That is
 3 WORKING WITH SOFTWARE TEAMS Introduction to Software Teamwork
82

why software engineering pays close attention not only to building software, but also to how
people build it together.

3.1.2 The Need for Coordination in Software Projects

If five students are told to build a campus lost‐and‐found system, they may all start productively
on the first day. One creates login pages. Another designs a database. Another works on the
homepage. Another prepares slides for the lecturer. Another begins a search feature. Activity
is visible, but progress may still be weak. Why? Because activity is not the same as coordination.

Coordination means that people know what problem they are solving, what each person is
responsible for, how pieces connect, what rules guide decisions, and how unfinished work is
reported. Without coordination, teams duplicate effort, work at the wrong priority level, or
discover late that their pieces do not fit together.

In practical terms, coordination answers simple questions:

• What are we building first?

• Who is doing which task?
• What does “done” mean for this task?
• What should we tell the team if we are blocked?
• When do we show progress?
• How do we handle change requests?

These questions may sound ordinary, but they strongly affect project outcomes. A team that
coordinates well can still make technical mistakes, but it usually notices them earlier. A team
that coordinates poorly often discovers problems late, when the cost of correction is higher.

ʢ SIDEBAR | A familiar student‐team problem

Many student groups fail for reasons that are not purely technical. One member disap‐
pears for a week. Another assumes someone else wrote the report. Two people build
the same screen in different ways. The database design changes, but the programmer
writing forms is not told. Near the deadline, everyone is working hard, yet the project
feels stuck.
This is not unusual. It is a coordination problem. Good teamwork makes work visible
early enough for people to adjust.
 3 WORKING WITH SOFTWARE TEAMS People Involved in a Software Project
83

3.1.3 How Teams Help Manage Complexity

In Chapter 1, you saw that software systems become complex because they involve many users,
rules, interfaces, and changes over time. Teams help manage this complexity by sharing atten‐
tion across the work. Instead of one person trying to hold the entire system in mind alone, a
team distributes responsibility. Share the
complexity

This distribution can happen in several ways. Work can be divided by feature, such as announce‐
ments, payment, or reporting. It can be divided by specialty, such as interface, database, test‐
ing, or deployment. It can also be divided by stage, such as planning, designing, building, and
reviewing. The exact split depends on the project size and the maturity of the team.

Still, dividing work is only the first half of the story. The second half is reconnecting the work.
If one student builds the login page and another builds the user database, they must agree
on how usernames, passwords, and roles are handled. If one person writes user stories and
another writes tests, they must share the same understanding of expected behavior. Teams
reduce complexity when they combine division of labour with shared understanding.

­ CHECKPOINT
Why might a team still struggle even when tasks have been divided among members?
What else must happen besides division of work?

3.1.4 Chapter Overview

This chapter explores what it means to work with software teams in a practical and beginner‐
friendly way. We begin with the people involved in software projects and the roles they often
play. We then look at communication, because software work depends heavily on clear expla‐
nation, feedback, and shared meaning.

After that, the chapter introduces process frameworks and project management in simple terms.
The goal is not to overload you with methods, but to help you see why teams need structure.
The chapter then moves into agile ways of working, including Scrum, Kanban, and a brief in‐
troduction to Extreme Programming. Finally, we connect these ideas to user stories, backlogs,
planning, tracking, and a running case study based on a student project team.

3.2 People Involved in a Software Project

 3 WORKING WITH SOFTWARE TEAMS People Involved in a Software Project
84

3.2.1 Stakeholders in Software Development

A stakeholder is any person or group that is affected by the system or has an interest in its
success. Some stakeholders use the software directly. Others approve it, pay for it, support
it, regulate it, or depend on its reports. Teams that ignore important stakeholders often build
Different people, systems that work in a narrow technical sense but fail in practical use.
different needs

The easiest stakeholders to notice are end users. These are the people who use the system
during ordinary work. In a registration portal, students and academic staff may be end users.
In a small shop inventory system, the cashier and stock manager are end users. End users care
about whether the system helps them do their work with reasonable speed and clarity.

Customers or clients are the people or organizations that request the system, fund it, or define
what success looks like. In some projects the customer and the user are the same. In others
they are different. A university department may request a system that students will use. A
clinic manager may approve a records system that receptionists and nurses use every day. If a
team only listens to the customer, it may miss user frustrations. If it only listens to users, it may
miss management priorities such as compliance, cost, or reporting.

Managers and decision makers are also stakeholders. They care about budget, deadlines, risk,
and alignment with organizational goals. A dean may want quicker registration reporting. A
shop owner may want fewer stock losses. A project sponsor may want evidence that the soft‐
ware improves a service.

Some projects include regulators or external authorities. These may be government bodies,
professional boards, exam councils, or privacy regulators. A health system must respect con‐
fidentiality rules. A payment system may need strong security and record keeping. A student
information system may need to store official records correctly. Students do not need to be‐
come legal experts at this stage, but they should learn early that software does not exist outside
rules and accountability.

ʢ SIDEBAR | Different stakeholders notice different problems

Imagine a campus clinic booking system. A student may complain that the booking page
is confusing. A nurse may say appointments overlap. A clinic manager may care about
missed appointments. A regulator may care about patient privacy. All are describing the
same system, but from different responsibilities.
This is why software teams should ask, “Who is affected, and what does success mean
to each group?”
 3 WORKING WITH SOFTWARE TEAMS People Involved in a Software Project
85

3.2.2 The Software Development Team

The software development team is the group directly responsible for turning needs into work‐
ing software. In a large organization, this team may include many specialized roles. In a student
project, the same small group may share several responsibilities. The names can vary across
organizations, but the underlying work remains similar.

A system analyst helps investigate the problem, gather requirements, and connect business or
user needs to technical work. In a small student team, this may be the member who runs inter‐
views, documents user stories, and clarifies what the system should do before coding begins.

A software developer writes code, tests features, fixes defects, and helps integrate parts into a
working system. Developers are often the most visible role to beginners, but they are not the
only important role. Good developers also communicate clearly, ask practical questions, and
help improve the team process.

A software designer thinks about structure. This includes decisions about screens, compo‐
nents, data flow, module relationships, and overall organization. In beginner projects, design
may be simple sketches, rough diagrams, naming choices, and agreement on how data moves
through the system. Design does not need to be grand to matter. Even agreeing on folder
structure and database tables is a design decision.

A database specialist or database‐focused team member helps model, store, protect, and re‐
trieve data. Many beginner systems fail because the team focuses on screens while treating
the data casually. If the data model is weak, reports become inaccurate, searching becomes
awkward, and future change becomes harder.

A tester or quality‐focused member checks whether the system behaves as expected and helps
the team notice defects early. In small teams, everyone should test, but it still helps to as‐
sign responsibility for organizing test cases, tracking bugs, and making sure completed work is
genuinely checked.

A project manager or team coordinator keeps the work organized. This includes planning meet‐
ings, tracking deadlines, checking blockers, following up on responsibilities, and communicating
status. In agile teams, some of this coordination may be shared, but someone still needs to help
the work move.

Support and operations people matter too. A system may need installation, hosting, backups,
user training, password resets, and ongoing support. In a classroom project these may be light
responsibilities, but students should still learn that finished software needs care after coding.
 3 WORKING WITH SOFTWARE TEAMS People Involved in a Software Project
86

Í Common role patterns in small teams

Team size Likely role pattern

1 person One person performs every role, often informally.

3–5 people Members share several roles, but responsibilities should still be named.
Some specialization becomes useful, such as one member focusing on
Large class project
testing or documentation.
Roles may be more specialized, though collaboration still matters more
Professional team
than job titles alone.

3.2.3 Why Clear Roles and Responsibilities Matter

Teams do not need rigid hierarchy to work well, but they do need clarity. When roles are un‐
clear, several problems appear. Important tasks may be ignored because everyone assumes
someone else is handling them. Meetings become repetitive because no one knows who can
make decisions. Deadlines slip because progress is not owned.

Clear responsibilities do not mean one person controls everything. They mean each important
area has a visible owner. For example, one student may own the testing checklist, another the
database schema, another the user interview notes, and another the sprint board. Ownership
Make ownership improves accountability without removing teamwork.
visible

It is also normal for responsibilities to overlap. A developer may help test. A team lead may
help code. A person handling requirements may also assist with documentation. What matters
is that overlap should support teamwork, not hide responsibility.

­ CHECKPOINT
Why is it risky to say, “Everyone is responsible for everything,” without naming clear
owners for specific tasks?

3.2.4 Example: Roles in a Student Registration Project

Suppose a five‐member team is building a simple student registration support system for a
class project. One member leads user interviews and keeps the backlog updated. One member
focuses on interface screens. One focuses on the database and data rules. One takes lead on
testing and bug tracking. One coordinates meetings, deadlines, and lecturer communication.
All five still review each other’s work and help solve problems.

This arrangement is not perfect or permanent. It is simply practical. It gives the team a starting
structure. As the project develops, members can rebalance responsibilities based on workload
 3 WORKING WITH SOFTWARE TEAMS Communication in Software Projects
87

and skill growth.

3.3 Communication in Software Projects

3.3.1 Why Communication Matters

Software projects succeed or fail partly because of how well people communicate. Code can
be correct in one person’s mind and still fail the project if the understanding behind it is not
shared. Communication is how teams align expectations, reveal uncertainty, coordinate tasks,
ask for help, report blockers, and collect feedback from users. Talk early

Many beginners think communication is secondary to technical skill. In practice, weak commu‐
nication creates technical problems. If a requirement is misunderstood, the wrong feature gets
built. If a blocker is hidden, integration is delayed. If users are not consulted, the team may
polish the wrong screen beautifully.

Communication in software projects is not only about meetings. It also happens through task
boards, commit messages, notes, comments, test cases, interface mock‐ups, diagrams, status
updates, and bug reports. Any artifact that helps people share understanding is part of project
communication.

“Teams rarely fail because nobody worked. They often

fail because people worked from different
understandings.”
PRACTICAL TRUTH

3.3.2 Communication Between Developers and Users

Users do not normally describe their needs in technical language. They talk about delays, frus‐
tration, repeated work, missing information, and practical goals. A student may say, “I keep
missing deadline notices.” A receptionist may say, “I write the same patient details more than
once.” A lecturer may say, “The current report is always late and hard to read.”

The developer’s job is not merely to listen politely. It is to translate these experiences into
useful system behavior. That means asking follow‐up questions. When does the problem hap‐
pen? Who is affected? What happens now? What would good improvement look like? What
 3 WORKING WITH SOFTWARE TEAMS Communication in Software Projects
88

exceptions matter?

If developers speak only in technical terms, users may stop contributing. If users are treated as
though they are interrupting the project, the project becomes blind to real needs. Good teams
create communication that is respectful and practical. They ask users about work, not about
technology choices they are not expected to know.

ʢ SIDEBAR | User‐friendly question style

Instead of asking, “Do you want role‐based authorization with audit logging?” ask, “Who
should be allowed to change this record, and who should only view it?”
Instead of asking, “Should the system normalize these data fields?” ask, “Which infor‐
mation do you enter often, and where do mistakes usually happen?”

3.3.3 Communication Within the Development Team

Team communication is about visibility. Team members should know what work is in progress,
what is blocked, what changed, and what decision has been made. This does not require con‐
stant talking. It requires useful talking.

For example, a daily stand‐up in a sprint is not meant to be a long technical lecture. It is a short
coordination moment. A member might say, “I finished the announcement list page. Today I
am connecting it to the database. I am blocked because I still need the status field added to
the table.” That short statement helps the database‐focused member act quickly.

Teams also communicate through shared tools. A backlog shows planned work. A Kanban
board shows current flow. A shared folder or repository shows artifacts and version history.
Communication becomes easier when the team’s work has visible places to live.

3.3.4 Communication with Management, Lecturers, or Sponsors

Projects usually need updates beyond the team itself. A lecturer may need to know whether a
student group is on track. A project sponsor may want a short progress report. A department
head may want to know whether a trial version is ready.

These updates should be honest and focused. A weak update is one that says, “We are working
hard.” A stronger update says, “Login and announcement posting are complete. Search is de‐
layed because data categories changed. We have moved user testing to Thursday and updated
the sprint plan.”

Management communication is not about impressing people with busyness. It is about helping
 3 WORKING WITH SOFTWARE TEAMS Communication in Software Projects
89

decision makers see the real state of the work.

3.3.5 Common Communication Problems

Several communication problems appear repeatedly in software projects. Unclear instructions

are one. A student may be told, “Build the dashboard,” without knowing what information
should appear, who will use it, or how current the data must be. Misunderstood requirements
are another problem. Team members may use the same words but imagine different outcomes.

Poor feedback also causes damage. If a reviewer says, “This is not right,” the team gains little.
Better feedback explains what is wrong, why it matters, and what outcome is needed. Delayed
reporting is another common problem. A member may struggle for four days with a blocked
task and mention it only at the deadline. By then the team has lost options. Hidden blockers
hurt teams

Sometimes the problem is emotional rather than procedural. A team member may stay quiet
because they feel embarrassed. Another may dominate discussion so strongly that others stop
contributing. Communication is not just transfer of information; it is also shaped by trust, con‐
fidence, and team culture.

­ CHECKPOINT
Why is delayed reporting especially harmful in short sprint‐based work?

3.3.6 Improving Communication in Software Teams

Communication improves when teams use a few simple habits consistently. Regular meetings
help, but only if they are brief and purposeful. Clear documentation helps, but only if it is
actually read and updated. Shared tools help, but only if the team uses them honestly.

Useful habits include:

• short regular check‐ins;

• written task ownership;
• visible backlog and task board;
• agreed definitions of “ready” and “done”;
• timely feedback on work shown;
• early reporting of blockers;
• short records of important decisions.

One of the most helpful beginner habits is to say problems early without drama. A blocked task
 3 WORKING WITH SOFTWARE TEAMS Software Engineering Process Frameworks
90

is not a personal failure. It is project information. Mature teams treat blockers as work to solve
together.

3.4 Software Engineering Process Frameworks

3.4.1 Meaning of a Process Framework

A process framework is a structured way of organizing software work. It does not write the
code for the team, but it gives shape to how the work moves. It helps answer questions such
as when people talk to users, how planning happens, when review happens, how progress is
checked, and how completed work is recognized.

In simple language, a process framework is a way of preventing software work from becoming
Structure helps random. Teams still think, adapt, and make decisions, but they do so within a shared rhythm.

3.4.2 Why Software Teams Need Process Frameworks

Without a framework, teams often act only when a problem becomes painful. They interview
users only after building the wrong feature. They test only near the deadline. They discuss risk
only after a major delay. A framework helps the team remember important work before crisis
forces attention.

Frameworks are especially useful because software work contains both visible and invisible
tasks. Writing a feature is visible. Clarifying requirements, reviewing decisions, managing ver‐
sions, and tracking risk are easier to neglect. A framework keeps these activities in view.

This does not mean every project needs a heavy process. A two‐person student project does
not need the same level of formality as a national health platform. But even a small team
benefits from some structure. A backlog, a meeting rhythm, visible task tracking, and simple
review points already form a lightweight framework.

3.4.3 Process Frameworks and Development Approaches

In Chapter 2, you studied development approaches such as waterfall, incremental, and agile.
A process framework is related, but not exactly the same. A development approach describes
the overall way a project moves and learns. A process framework is the practical structure that
 3 WORKING WITH SOFTWARE TEAMS Software Engineering Process Frameworks
91

guides day‐to‐day work inside that approach.

For example, agile is an approach based on short cycles, feedback, and adaptation. Scrum is
one framework that helps teams work in that style. Kanban is another. Both support agile
thinking, but they organize work differently.

3.4.4 Common Elements of a Process Framework

Most frameworks include a few common elements, even if they use different names. They
include activities, tasks, roles, deliverables, milestones, and review points. Activities are broad
areas of work such as planning, coding, testing, or deployment. Tasks are smaller units of work
inside those activities. Roles describe who is responsible. Deliverables are outputs such as user
stories, screens, code, test results, or reports. Milestones are points where progress is checked.
Reviews help teams learn and correct direction.

Í What teams usually need from a framework

Element Practical question it answers

Activities What kinds of work must happen?

Tasks What exactly should be done next?
Roles Who is responsible for this work?
Deliverables What should exist when the work is complete?
Milestones When do we pause and check progress?
Reviews How do we learn whether the work is good enough?

3.4.5 Benefits of Using a Process Framework

Frameworks improve organization because they reduce guesswork about what should happen
next. They improve coordination because everyone can see the same work rhythm. They im‐
prove quality control because testing and review are planned rather than accidental. They help
monitoring because progress is measured against visible work items. They reduce risk because
warning signs appear earlier.

Of course, a framework does not guarantee success. A badly used framework can become
empty routine. Meetings can happen with no value. Boards can be updated dishonestly. Check‐
lists can be performed without real thought. The goal is not to obey process blindly. The goal
is to support useful work.
 3 WORKING WITH SOFTWARE TEAMS Core Framework Activities
92

­ CHECKPOINT
What is the difference between a helpful framework and a framework that has turned
into empty routine?

3.5 Core Framework Activities

3.5.1 Communication, Planning, Modelling, Construction, and Deployment

Many software engineering texts describe a set of core activities that appear in most projects,
regardless of the exact method used. These are communication, planning, modelling, construc‐
tion, and deployment. The names are simple, but the idea is powerful: real software work is
broader than coding alone.

Communication is the work of understanding needs, clarifying expectations, and collecting

feedback. It includes stakeholder meetings, user interviews, requirement discussions, demon‐
strations, and questions asked during development.

Planning is the work of deciding what to do, in what order, with what resources, within what
time. Planning can be detailed or lightweight. It may produce a formal schedule or a sprint
backlog. In both cases, it gives direction to the work.

Modelling means representing the system before or while building it. Models can be sketches,
flowcharts, wireframes, database diagrams, use cases, or simple descriptions of how parts con‐
nect. A model helps people think before they implement.

Construction includes coding and testing. The team turns ideas into working software, checks
whether behavior is correct, and improves the product through iteration.

Deployment is delivering the software or increment to users or reviewers. In a classroom,

deployment may be a demonstration environment or hosted prototype. In a real organization,
it may involve installation, migration, training, and support.

ʢ SIDEBAR | These activities are not strict boxes

In practice, teams move back and forth. A user demonstration may reveal a requirement
issue, which affects planning, which changes design, which changes code. The value
of the activity model is not that work happens in a neat line. Its value is that teams
remember all the kinds of work that matter.
 3 WORKING WITH SOFTWARE TEAMS Umbrella Activities in Software Projects
93

3.5.2 A Practical View of the Activity Flow

Imagine a team building a campus event notice system. First, they communicate with student
leaders and staff to understand the problem. Then they plan a first sprint around announce‐
ments and categories. They sketch the main pages and the data model. They build the feature,
test it, and deploy a working version for feedback. That feedback then influences the next
sprint. In this way, the activities connect in a cycle.

3.6 Umbrella Activities in Software Projects

3.6.1 Meaning of Umbrella Activities

Umbrella activities are supporting activities that stretch across the project rather than appear‐
ing only once. They do not replace planning or coding. Instead, they help protect project quality
and control while the main work continues. Support work
matters too

Students often overlook these activities because they seem less visible than screens or features.
Yet many project failures begin here. Teams lose track of versions, ignore risks, skip reviews, or
fail to document decisions. Umbrella activities keep the project from becoming fragile.

3.6.2 Project Tracking and Control

Tracking means checking whether the project is moving as planned. Control means taking ac‐
tion when it is not. This may involve reviewing the task board, checking completed backlog
items, comparing expected and actual progress, or noticing that one part of the system is falling
behind.

Good tracking is honest and calm. If a feature estimated for two days is still incomplete after
five, the team should discuss why. Was the task larger than expected? Was the requirement
unclear? Was someone blocked? Tracking is not mainly about blame. It is about keeping the
project realistic.

3.6.3 Risk Management

Risk management means identifying problems that might happen, thinking about how serious
they are, and preparing responses. In a beginner project, risks may include lost data, unavail‐
 3 WORKING WITH SOFTWARE TEAMS Umbrella Activities in Software Projects
94

able users, poor internet access, unfamiliar tools, missed deadlines, or uneven team participa‐
tion.

Many teams think about risk only when a problem becomes real. A better habit is to ask early,
“What could slow us down or damage the project, and what can we do now?” If users are hard
to reach, schedule interviews early. If a tool is unfamiliar, build a small trial before depending
on it fully.

3.6.4 Software Quality Assurance and Reviews

Quality assurance is broader than testing. It includes the habits and checks that reduce the
chance of defects. This can mean using coding standards, reviewing requirements before im‐
plementation, testing acceptance criteria, and checking whether the team is following agreed
practices.

Technical reviews are especially useful because they catch misunderstanding early. A require‐
ment review may reveal that two team members interpreted a story differently. A design re‐
view may reveal that the data model cannot support a report. A code review may reveal dupli‐
cation, security weakness, or unclear naming.

ʢ SIDEBAR | Review early, not only at the end

A five‐minute review of a user story before coding can save many hours of rework later.
The earlier a problem is found, the cheaper it usually is to fix.

3.6.5 Configuration Management

Configuration management means keeping project artifacts organized and controlled as they
change. In simple terms, it is version control plus change discipline. Teams need to know which
file is current, which branch contains the latest work, which document matches the software
Keep versions clear version, and who changed what.

For first‐year students, the most practical example is a shared Git repository used with disci‐
pline. Team members should avoid overwriting one another’s work carelessly. Commit mes‐
sages should communicate what changed. Important files should live in known places. If the
team cannot manage versions, collaboration becomes chaotic.
 3 WORKING WITH SOFTWARE TEAMS Project Management in Software Development
95

3.6.6 Documentation, Measurement, and Reporting

Documentation records important knowledge. This may include requirements, decisions, setup
steps, test cases, user guides, and meeting notes. Documentation should be useful, not exces‐
sive. A short and accurate note is better than a long forgotten file.

Measurement and reporting involve asking how progress or quality will be judged. Examples
include number of completed backlog items, number of outstanding defects, test pass status,
or whether a sprint goal was met. Reports should support decisions, not create paperwork for
its own sake.

3.7 Project Management in Software Development

3.7.1 Meaning of Software Project Management

Software project management is the work of guiding a software project so that people, time,
scope, risk, and communication remain under control. This sounds formal, but even a two‐week
class assignment involves project management. Someone must decide what to build first, who
does what, whether the work is on time, and how problems will be handled.

Project management is not only the responsibility of one official manager. In small teams, much
of it is shared. However, shared does not mean invisible. The work still needs attention.

3.7.2 Why Software Projects Need Management

Software projects need management because software work is uncertain. Requirements can
change. Estimates can be wrong. Team members can fall sick. A feature that looks simple can
turn out to involve hidden rules. Without management, these realities do not disappear; they
simply surprise the team later.

Management helps the team respond instead of react. It gives the group a way to notice when
scope is expanding, when deadlines are unrealistic, or when communication is weakening.
 3 WORKING WITH SOFTWARE TEAMS Project Management Styles and Frameworks
96

3.7.3 Main Project Management Activities

Most projects involve initiation, planning, execution, monitoring and control, and closure. Ini‐
tiation means agreeing on the problem, value, and starting direction. Planning turns that direc‐
tion into tasks, responsibilities, and milestones. Execution is doing the work. Monitoring and
control means checking progress and adjusting. Closure means finishing responsibly, handing
over outputs, and reflecting on lessons learned.

These are not only corporate words. They describe what thoughtful student teams already
need to do.

3.7.4 Managing Scope, Time, Cost, People, Risk, and Communication

Managing scope means controlling what is included and excluded. When a team adds features
casually, time disappears quickly. Scope discipline is especially important for students, because
beginner teams often want to build too much.

Managing time means estimating, sequencing, and checking work against deadlines. Good
time management does not mean every estimate is correct. It means the team notices schedule
pressure early enough to adjust.

Managing cost may be less visible in class projects, but it still exists. The team spends time,
internet access, hosting resources, printing costs, and sometimes transport for fieldwork. In
professional projects, cost is more direct and can shape major decisions.

Managing people means assigning tasks, balancing workload, resolving conflict, and support‐
ing collaboration. Strong people management is not about control; it is about enabling useful
contribution.

Managing risk means treating uncertainty seriously. Managing communication means ensur‐
ing the right people know the right things at the right time.

­ CHECKPOINT
Why might a student project still need project management even if there is no formal
budget and no full‐time manager?

3.8 Project Management Styles and Frameworks

 3 WORKING WITH SOFTWARE TEAMS Project Management Styles and Frameworks
97

3.8.1 Traditional and Agile Management Styles

Traditional project management tends to emphasize up‐front planning, clearer phase bound‐
aries, and stronger formal control. This can be useful when requirements are stable, approval
steps are strict, or change is expensive.

Agile project management tends to emphasize shorter work cycles, frequent feedback, and
flexible planning. This is useful when learning is expected, users can give feedback, or require‐
ments may change during the work.

Neither style is automatically superior in every situation. The practical question is which style
fits the project conditions.

3.8.2 A Brief Beginner View of PMBOK and PRINCE2

Students often hear names such as PMBOK and PRINCE2. At this stage, you do not need deep
certification‐level knowledge. It is enough to know that they are project management frame‐
works that help organizations manage work in a disciplined way.

PMBOK organizes project management knowledge into areas such as scope, schedule, cost,
quality, communication, risk, and stakeholders. It is broad and widely used as a reference for
good management practice.

PRINCE2 emphasizes continued business justification, clear roles, stage control, and manage‐
ment by exception. It is often associated with structured governance.

For first‐year students, the key lesson is simple: project management can be done informally
in small teams or formally in large organizations, but the underlying concerns remain similar.

3.8.3 Choosing a Suitable Style

Small student projects usually benefit from light structure, clear priorities, visible task tracking,
and frequent review. Heavy bureaucracy would waste energy. Large organizational projects
may need more formal reporting, approvals, and documentation. High‐risk systems may re‐
quire stronger control and verification. Projects with changing needs often benefit from agile
methods.

The best style is the one that helps the team stay clear, honest, and responsive without drown‐
ing in unnecessary process.
 3 WORKING WITH SOFTWARE TEAMS Introduction to Agile Ways of Working
98

3.9 Introduction to Agile Ways of Working

3.9.1 Meaning of Agile Development

Agile development is a way of working that values short cycles, frequent feedback, collab‐
oration, and adaptation. Agile does not mean random or rushed. It means the team expects
learning and change, so it organizes work to respond rather than pretend everything was known
Agile means perfectly at the beginning.
adaptive

In agile settings, teams often build in small increments, show work regularly, adjust priorities,
and reflect on how to improve their process. This makes agile especially useful when users
need to see something concrete before they can respond clearly.

3.9.2 Why Agile Was Introduced

Agile became popular because many teams were frustrated by slow, rigid projects where work‐
ing software appeared very late. In such projects, users sometimes saw the product only after
many months, when changes were expensive and disappointment was painful.

Agile responds to that problem by encouraging earlier delivery and earlier conversation. In‐
stead of waiting until everything is “finished,” the team aims to produce smaller useful pieces,
learn from them, and improve direction.

3.9.3 Main Ideas Behind Agile

Agile emphasizes delivering working software frequently, working closely with users, respond‐
ing to change, and improving continuously. These ideas matter because software development
includes uncertainty. When teams treat plans as useful but revisable, they are often better able
to handle real‐world change.

Agile does not remove the need for discipline. In fact, it requires discipline of a different kind.
Teams must keep backlogs current, attend meetings prepared, test incrementally, and speak
honestly about progress.
 3 WORKING WITH SOFTWARE TEAMS Scrum in Simple Terms
99

ʢ SIDEBAR | Agile is not ``no planning''

One of the most common misunderstandings is that agile means doing whatever feels
right in the moment. Real agile work still plans. It simply plans in shorter cycles and
updates plans more often.

3.9.4 Agile and Traditional Development Compared

Traditional approaches often plan more detail earlier and aim for greater predictability before
building. Agile approaches plan enough to start responsibly, then refine detail through feed‐
back. Traditional approaches may deliver larger chunks less often. Agile approaches prefer
smaller deliveries more often. Traditional approaches may resist late change. Agile approaches
try to manage and incorporate it.

Again, the lesson is not to treat one as always right. The lesson is to match the method to the
project reality.

3.10 Scrum in Simple Terms

3.10.1 Meaning of Scrum

Scrum is a lightweight agile framework that organizes work into fixed periods called sprints.
During each sprint, the team works toward a clear goal and aims to produce a usable increment
of software.

Scrum is popular in teaching because it gives beginners a visible rhythm. There is planning,
daily coordination, review, and reflection. This helps students learn that software development
is not only a coding burst before the deadline.

3.10.2 Scrum Roles

Scrum commonly describes three main roles: the Product Owner, the Scrum Master, and the
development team.

The Product Owner is responsible for clarifying value and prioritizing the product backlog. In
a student project, this might be the team member who stays closest to user needs and helps
decide what should be built first.
 3 WORKING WITH SOFTWARE TEAMS Scrum in Simple Terms
100

The Scrum Master supports the team’s process. This role helps remove blockers, protect the
team’s working rhythm, and encourage useful Scrum practice. In student teams, this may be
the person who facilitates sprint meetings and keeps work visible.

The development team builds the software. In modern practice, this usually means the people
who together turn backlog items into a working increment. In small student projects, everyone
may contribute across analysis, coding, testing, and demonstration.

3.10.3 Scrum Artifacts

The product backlog is the prioritized list of work that may be done on the product. The sprint
backlog is the selected work for the current sprint, together with the plan for doing it. The
increment is the usable outcome produced by the sprint.

These artifacts matter because they make work visible. Instead of carrying plans only in mem‐
ory, the team can point to a backlog and ask what is most important now.

3.10.4 Scrum Events

Scrum includes several recurring events. In sprint planning, the team chooses what it can take
on and agrees on a sprint goal. In the daily scrum or daily stand‐up, the team checks progress,
plans the day, and surfaces blockers. In the sprint review, completed work is shown for feed‐
back. In the sprint retrospective, the team reflects on how to improve its way of working.

Í A beginner‐friendly sprint rhythm

Event Purpose

Sprint planning Decide the sprint goal and select work.

Daily stand‐up Coordinate progress and reveal blockers quickly.
Sprint review Show working software and collect feedback.
Sprint retrospective Improve team habits for the next sprint.

3.10.5 Benefits and Limits of Scrum

Scrum can improve focus because the team commits to a short period of work. It can improve
feedback because users see progress more frequently. It can improve learning because retro‐
spectives encourage reflection.

However, Scrum does not solve everything. If backlog items are unclear, the sprint will still
 3 WORKING WITH SOFTWARE TEAMS Kanban in Simple Terms
101

struggle. If the team hides blockers, the daily scrum becomes a ritual with little value. If work
is not tested during the sprint, the increment may not truly be usable.

ʢ SIDEBAR | A sprint meeting moment

During sprint planning, a team proposes eight backlog items for a two‐week sprint. After
discussion, they realize three items depend on incomplete database changes and two
are still unclear after the user interview. They reduce the sprint to three well‐understood
items and one small technical task.
This is good planning, not weakness. Scrum works better when teams choose responsibly
instead of pretending they can do everything.

3.11 Kanban in Simple Terms

3.11.1 Meaning of Kanban

Kanban is a way of managing work by making it visible and controlling how much is in progress
at the same time. It is often shown using a board with columns such as To Do, Doing, and Done.

Kanban is helpful because many teams feel busy but cannot see why progress is slow. A board
reveals where work is piling up. If many tasks are stuck in Doing, then the problem may not be
lack of effort. It may be overload.

3.11.2 Visualizing Work and Limiting Work in Progress

When tasks are written visibly on a board, the team can quickly see the state of the work. A
work‐in‐progress limit means the team agrees not to start too many tasks at once. For example,
if the Doing column is limited to three tasks, then a fourth task should not begin until one of
the three moves forward. Finish before
starting more

This idea is powerful for students. Beginners often start many tasks because starting feels pro‐
ductive. But unfinished work creates hidden pressure. Kanban encourages the team to finish
current work before opening too many new threads.
 3 WORKING WITH SOFTWARE TEAMS Extreme Programming in Simple Terms
102

3.11.3 Continuous Flow of Tasks

Unlike Scrum, which often works in fixed sprints, Kanban can support a more continuous flow.
Work is pulled when capacity is available. This can suit support work, maintenance, or class
projects where tasks arrive unevenly.

3.11.4 Benefits of Kanban

Kanban improves visibility, reduces overload, and makes bottlenecks easier to spot. It is also
easy to begin with. A physical board, spreadsheet, or online tool can already support useful
Kanban habits.

­ CHECKPOINT
How can a team look busy but still make poor progress, and how does Kanban help reveal
this?

3.12 Extreme Programming in Simple Terms

3.12.1 Meaning and Purpose of Extreme Programming

Extreme Programming or XP is an agile approach that places strong emphasis on technical prac‐
tices and close feedback. It encourages teams to build software in a disciplined, high‐feedback
way so that change becomes easier to handle.

XP is useful in this chapter because it reminds students that teamwork methods are not only
about meetings. They also shape coding habits.

3.12.2 Common XP Practices

One well‐known XP practice is pair programming, where two developers work together at one
workstation. One writes while the other reviews, thinks ahead, and discusses alternatives. This
can improve learning and catch mistakes early, though it requires focus and cooperation.

Test‐driven development encourages writing tests around behavior in a deliberate cycle. Con‐
tinuous integration encourages teams to combine work frequently rather than waiting until
 3 WORKING WITH SOFTWARE TEAMS User Stories, Acceptance Criteria, and Backlogs
103

late in the project. Refactoring means improving code structure without changing its behavior.
XP also values simple design and frequent releases.

3.12.3 When XP Ideas Are Useful for Beginners

Student teams may not use full XP formally, but several practices are immediately useful. Pair
programming can help when one member is stuck or when a feature is risky. Frequent inte‐
gration prevents last‐minute merge disasters. Refactoring teaches students that code can be
improved after it works. Simple design reminds teams not to build unnecessary complexity too
early.

3.12.4 Limits of XP

XP practices require discipline and time. Pair programming can feel tiring if used without pur‐
pose. TDD takes practice. Continuous integration requires the team to keep the codebase
healthy. The lesson here is not to copy every XP rule mechanically. It is to notice that strong
technical teamwork depends on habits as much as on intentions.

3.13 User Stories, Acceptance Criteria, and Backlogs

3.13.1 Meaning of a User Story

A user story is a short description of a user need written from the user’s point of view. A
common pattern is:

As a type of user, I want to do something so that I gain a benefit.

For example:

As a student, I want to view urgent academic announcements so that I do not miss

deadline changes.

User stories help teams focus on purpose, not only features. A story reminds the team who the
work is for and why it matters.
 3 WORKING WITH SOFTWARE TEAMS User Stories, Acceptance Criteria, and Backlogs
104

3.13.2 Writing Better User Stories

Not every sentence in the story format is a good story. Good stories are clear enough to discuss,
small enough to plan, and meaningful enough to relate to user value. A weak story is vague,
huge, or written from a technical perspective only.

For instance, “As a system, I want to normalize tables” is not a user story. It may describe useful
technical work, but it is not written as user value. Technical tasks can still exist in the backlog,
but they should not be confused with user stories.

ʢ SIDEBAR | From feature language to user language

Feature language: “Build report export.”
User language: “As an academic officer, I want to export the registration summary so
that I can share it with the department meeting.”
The second version gives the team more context for decisions.

3.13.3 Acceptance Criteria

Acceptance criteria are simple, testable conditions that help the team know whether a backlog
item is complete. They turn a broad story into concrete expectations.

For the announcement story above, acceptance criteria might include:

• Urgent announcements appear at the top of the list.

• Expired announcements are hidden automatically.
• The user can open a full announcement detail page.
• Announcement dates are displayed clearly.

Acceptance criteria improve communication between users, developers, and testers. They re‐
duce the risk that everyone says “done” while imagining different results.

3.13.4 Product Backlogs and Prioritization

A product backlog is the ordered list of work that may be done on a product. It contains user
stories, technical tasks, defect fixes, improvements, and research tasks. Prioritization matters
Backlog means because teams never have unlimited time.
choices

High‐priority items are usually those that deliver value early, reduce major risk, or enable other
work. Lower‐priority items may still be useful, but they wait until the team has capacity or
 3 WORKING WITH SOFTWARE TEAMS Planning and Tracking Team Work
105

stronger reason.

Í Sample backlog slice for a library system

Priority Type Item

As a student, I want to search for a book by title so that I can find

High User story
it quickly.
As a librarian, I want to mark a book as borrowed so that records
High User story
stay current.
Medium Technical task Improve duplicate‐book validation in the database.
Medium User story As a student, I want to see due dates for borrowed books.
Low Improvement Add dark mode for the user interface.

3.13.5 Why Backlogs Help Teams

Backlogs help teams talk honestly about choice. They make visible that some work comes
first and some work waits. This is healthier than pretending every request can be addressed
immediately. A well‐kept backlog is also a communication tool. It helps users, sponsors, and
team members see what the product needs and how priorities are changing.

3.14 Planning and Tracking Team Work

3.14.1 Breaking Work into Tasks

Once backlog items are selected, the team often breaks them into smaller tasks. A story such
as “view announcements” may involve designing the page, creating the database table, writing
the list query, connecting the interface, adding expiry logic, testing, and preparing a demo.

Breaking work into tasks helps the team estimate more realistically. It also helps members see
where collaboration is needed. If a task depends on another, the team can discuss sequence
earlier.

3.14.2 Estimating Tasks

Teams estimate work in different ways. Some use simple time estimates such as hours or days.
Others use relative estimates, judging whether one task is smaller or larger than another. For
 3 WORKING WITH SOFTWARE TEAMS Planning and Tracking Team Work
106

beginners, the best approach is often the simplest one that still supports honest planning.

Estimates are not promises carved in stone. They are informed guesses. Their value lies partly
in the conversation they create. When one member says a task is half a day and another says
it is three days, the difference reveals uncertainty worth discussing.

3.14.3 Assigning Tasks and Tracking Progress

Tasks should have visible owners, even when teamwork is shared. A clear owner helps the team
know who is leading the work and who should report progress. Tracking can happen through
a Scrum board, Kanban board, checklist, or weekly progress note.

The key is visibility. A team should not discover at the end of the week that nobody knows the
state of a major feature. If a task is blocked, the board and the conversation should show that
fact.

ʢ SIDEBAR | A simple weekly tracking rhythm

• Start of week: agree on the most important tasks.
• Midweek: review blockers and unfinished work.
• End of week: demonstrate progress, test completed items, and update the back‐
log.

This rhythm is light enough for student teams and still teaches professional coordination.

3.14.4 Handling Delays and Change

Delays happen. What matters is the response. Teams should ask why the delay happened, what
work is affected, and what adjustment is sensible. Sometimes the right response is to reduce
scope. Sometimes it is to reassign work. Sometimes it is to split a backlog item into a smaller
delivery. Sometimes it is to ask for clarification instead of continuing blindly.

Change requests should also be handled deliberately. If a lecturer or user asks for a new feature,
the team should ask how important it is, what it displaces, and whether it belongs in the current
sprint or a later one.

­ CHECKPOINT
Why is it better to move a lower‐priority item out of the sprint deliberately than to quietly
keep everything and miss the sprint goal?
 3 WORKING WITH SOFTWARE TEAMS Team Challenges in Software Projects
107

3.15 Team Challenges in Software Projects

3.15.1 Common Team Challenges

Software teams commonly face poor communication, unclear responsibilities, unrealistic dead‐
lines, changing user needs, lack of feedback, unequal participation, and conflict between mem‐
bers. These are not signs that the team is uniquely broken. They are normal pressures that
require management.

Poor communication creates duplicated or misdirected work. Unclear responsibilities cause

work to fall through gaps. Unrealistic deadlines push teams into panic mode, where testing
and reflection disappear. Changing user needs can destabilize the backlog if priorities are not
reviewed carefully. Lack of feedback leads to confident mistakes. Unequal participation creates
resentment. Conflict can slow the work and damage trust.

3.15.2 Ways to Reduce Team Challenges

Teams reduce these challenges through clarity and rhythm. Clarify roles. Keep tasks visible.
Set achievable goals. Review priorities regularly. Invite feedback early. Speak about blockers
quickly. Use retrospective moments to improve how the team works. Improve the way
you work

Not every problem has a process solution. Some problems require honest conversation. If one
member is repeatedly absent, the team should not hide it. If two members disagree strongly
about direction, the team should define how decisions are made. If the scope is impossible,
the team should say so early and propose a smaller, stronger version.

3.16 Running Case Study: CampusConnect Teamwork

3.16.1 Project Background

In Chapter 2, CampusConnect was introduced as a project to help first‐year students access ori‐
entation announcements, campus office information, and registration guidance. The planning
stage produced a small scope and a three‐sprint idea. Now the team must work together to
turn that plan into a real project.
 3 WORKING WITH SOFTWARE TEAMS Running Case Study: CampusConnect Teamwork
108

3.16.2 Identifying Team Roles

The five‐member team agrees on shared ownership but also names leads for key responsibili‐
ties. Aisha coordinates user contact and backlog updates. Daniel leads interface work. Mercy
leads database and search logic. Joel keeps the testing checklist and bug list. Ruth facilitates
sprint meetings and lecturer communication.

This does not mean each person only does one thing. It means each area has someone watching
it carefully.

3.16.3 Preparing the Backlog

The team reviews its product backlog and rewrites some items more clearly. One story says:

As a first‐year student, I want to view orientation announcements so that I can stay

informed without depending on social media groups.

They add acceptance criteria:

• Announcements show title, date, and category.

• Urgent announcements appear first.
• Expired announcements do not appear on the student page.
• Clicking an item opens its full details.

3.16.4 Planning the First Sprint

For Sprint 1, the team chooses a narrow goal: students should be able to view announcements,
and administrators should be able to post them. The sprint backlog includes page layout, an‐
nouncement data storage, category handling, posting form, display list, detail page, and test
cases.

During planning, the team removes one extra idea: push notifications. It sounds attractive, but
it would stretch the sprint too far. This is a good example of scope discipline inside agile work.

3.16.5 Using a Task Board

The team sets up a simple board with To Do, Doing, Blocked, and Done. They decide that no
more than three tasks should be in Doing at once. After two days, they notice four tasks are
 3 WORKING WITH SOFTWARE TEAMS Chapter Summary
109

blocked because the announcement table still lacks an expiry field. Mercy fixes the schema,
and the blocked work begins moving again.

Without the visible board, that dependency might have remained hidden longer.

3.16.6 Holding Team Meetings

The team holds a short meeting each morning. Members say what they completed, what they
are doing next, and whether they are blocked. The meetings stay short because technical deep
dives happen afterward with the relevant people only.

At the end of the sprint, the team demonstrates the announcement feature to two student
leaders. One leader asks for filtering by category. The other asks that urgent items look visually
different. The team does not promise both immediately. Instead, they add them to the backlog
for prioritization.

3.16.7 Reviewing Progress and Improving the Plan

In the sprint retrospective, the team recognizes two strengths and two weaknesses. A strength
is that the task board helped them surface blockers quickly. Another is that acceptance criteria
made testing easier. A weakness is that one member worked alone too long before asking for
help. Another is that the team underestimated time needed for data setup.

They decide that in Sprint 2, any task blocked for more than one day must be raised to the whole
team. They also agree to break large tasks into smaller ones before sprint planning ends.

ʢ SIDEBAR | What this case study teaches

The CampusConnect team does not succeed because it avoids all problems. It succeeds
because it notices problems early, speaks about them, and adjusts its process.

3.17 Chapter Summary

Software development is team work because real systems are too broad and too important to
build well through isolated effort alone. Teams help manage complexity, but only when respon‐
sibilities, communication, and coordination are clear. Stakeholders include users, customers,
managers, and sometimes regulators, while the development team may include analysts, de‐
 3 WORKING WITH SOFTWARE TEAMS Review Questions
110

velopers, designers, testers, coordinators, and support roles.

Communication matters because software work depends on shared understanding. Process

frameworks help teams organize work through activities, roles, deliverables, milestones, and
reviews. Core framework activities include communication, planning, modelling, construction,
and deployment, while umbrella activities such as risk management, quality assurance, config‐
uration management, and documentation support the project throughout.

Project management keeps scope, time, people, communication, and risk under control. Agile
ways of working emphasize short cycles, feedback, and adaptation. Scrum, Kanban, and XP
provide different but useful teamwork practices. User stories, acceptance criteria, and backlogs
help teams describe and prioritize work. Visible task tracking, honest reporting, and regular
reflection help software teams improve.

n KEY TAKEAWAYS
• Real software projects depend on people coordinating, not just individuals coding.
• Clear roles help teams avoid confusion without preventing collaboration.
• Communication failures often become technical failures later.
• Process frameworks provide structure so important work is not forgotten.
• Agile methods still require planning, discipline, and visible priorities.
• User stories, acceptance criteria, and backlogs turn user needs into manageable
work.
• Task boards, stand‐ups, reviews, and retrospectives help teams see and improve
their work.

3.18 Review Questions

3.18.1 Short Answer Questions

1. Why is most real software built by teams rather than by one person alone?
2. What is a stakeholder?
3. Give three examples of people who may be stakeholders in a software project.
4. Why do teams need clear roles and responsibilities?
5. What is a process framework?
6. Name the five core framework activities discussed in this chapter.
7. What is the purpose of a sprint review?
8. What is a Kanban board used for?
9. What is a user story?
 3 WORKING WITH SOFTWARE TEAMS Review Questions
111

10. Why are acceptance criteria useful?

3.18.2 Discussion Questions

1. A student team says, “We do not need meetings; we will just code.” What risks do you
see in this approach?
2. How can poor communication create defects even when programmers are technically
capable?
3. Compare Scrum and Kanban for a small university project. When might one fit better
than the other?
4. Why is it important to distinguish customers from end users?
5. What team habits make it easier to handle changing requirements without losing con‐
trol?

3.18.3 Practical Activity

In a group, choose one of the following project ideas or use your own:

• Student club event system.

• Campus room booking system.
• Hostel repair request system.
• Small clinic queue system.
• Department notice board application.

Prepare a short teamwork plan that includes:

• Main stakeholders.
• Roles for each team member.
• Five backlog items.
• One sprint goal or one Kanban board setup.
• Meeting rhythm for one week.
• Two likely risks and your response to each.

3.18.4 Mini Sprint and Backlog Exercise

1. Write three user stories for your chosen project.

2. Add two acceptance criteria to each story.
 3 WORKING WITH SOFTWARE TEAMS Review Questions
112

3. Prioritize the three stories as high, medium, or low.

4. Break the highest‐priority story into at least four tasks.
5. Decide which tasks would be assigned first in a one‐week sprint.

CHAPTER REVIEW

SUMMARY REVIEW QUESTIONS

• Teams build software more effectively 1. Who are the key stakeholders in this
when roles, priorities, and communication project?
are clear. 2. How will the team keep work visible?
• Process frameworks give structure to plan‐ 3. What method will the team use to plan and
ning, building, reviewing, and improving review progress?
work. 4. How will blockers, change requests, and
• Agile teamwork depends on visible work, feedback be handled?
short feedback loops, and honest adjust‐
ment.
• Backlogs, user stories, and acceptance
criteria help turn ideas into manageable
tasks.
REFERENCE

CHAPTER 3 KEY TERMS

Plain‐language meanings for teamwork and agile software practice.

Stakeholder The main kinds of software work such as communi‐

cation, planning, modelling, construction, and de‐
ployment.

A person or group affected by a system or inter‐

Umbrella Activities
ested in its success.

Software Development Team

Supporting activities that continue across the
project, such as tracking, risk management, re‐
views, and documentation.
The group responsible for turning needs into work‐
ing software.
Project Management

Coordination

Guiding the project so scope, time, people, com‐

munication, and risk stay under control.
Organizing people and tasks so work fits together
properly.
Agile Development

Process Framework

An approach based on short cycles, feedback, col‐

laboration, and adaptation.
A structured way of organizing software work.

Scrum
Core Activities

A lightweight agile framework built around sprints,

113
 3 WORKING WITH SOFTWARE TEAMS Review Questions
114

roles, artifacts, and regular events.

Sprint Simple testable conditions used to decide whether

a backlog item is complete.

Product Backlog
A short fixed period in which a team works toward
a clear goal and produces a usable increment.

Kanban A prioritized list of work that may be done on a soft‐

ware product.

Sprint Backlog
A method of managing work visually and limiting
work in progress.

Extreme Programming The selected work for the current sprint and the
plan for completing it.

Increment
An agile approach that emphasizes strong techni‐
cal practices such as pair programming and contin‐
uous integration.
The usable outcome produced by a sprint or devel‐

User Story opment cycle.

Work‐in‐Progress Limit

A short description of a user need written from the

user’s point of view.
A limit on how many tasks may be active at the

Acceptance Criteria same time.

3 WORKING WITH SOFTWARE TEAMS Review Questions
115

COMING UP NEXT

Designing and Building Software

The next chapter moves from team coordination into design, coding, interfaces, data structures,
and the practical move from plans to working software.
CHAPTER NO. 4

4
Designing and Building
Software

TURNING REQUIREMENTS INTO STRUCTURE, INTERFACES, DATA, CODE, AND WORKING FEATURES

œ LEARNING OBJECTIVES
By the end of this chapter, you should be able to:

• Explain why software design comes before coding in serious projects.

• Distinguish between high‐level design and detailed design.
• Describe practical design principles such as modularity, abstraction, separation of
concerns, cohesion, coupling, and encapsulation.
• Explain how user interface design, data design, and system structure support one
another.
• Use simple examples to describe entities, attributes, relationships, modules, inter‐
faces, and data flow.
• Explain what software construction involves beyond simply writing code.

116
 4 DESIGNING AND BUILDING SOFTWARE Introduction to Software Design and Construction
117

• Write code in a style that is readable, maintainable, and team‐friendly.

• Describe the value of coding standards, validation, debugging, refactoring, version
control, and documentation.
• Recognize basic secure coding habits and understand why careless construction
creates long‐term project problems.

4.1 Introduction to Software Design and Construction

4.1.1 From Requirements to a Working System

N THE PREVIOUS CHAPTERS, you learned how software work starts with understanding prob‐

I lems, identifying stakeholders, gathering requirements, and organizing teamwork. At that

point, the project knows what it is trying to achieve and how the team plans to work. But
a gap still remains between an idea and a working system. That gap is filled by design and
construction. Design before code

Requirements describe what users need. Design decides how the system will be shaped so
those needs can be met. Construction then turns that design into running software. If the
team skips design and jumps directly into coding, the project may still produce screens and
features quickly, but the result is often hard to change, hard to test, and hard to trust.

Imagine a team building a hostel maintenance request system. The requirements may say that
students should be able to report a broken light, upload a photo, and see the status of the
request. The maintenance office should be able to assign tasks and mark work complete. These
requirements are useful, but they do not yet tell the team how many modules are needed, what
data should be stored, how the screens should flow, or how status updates should work safely.

Design creates that bridge. It helps the team move from a list of needs to a shape that can actu‐
ally be built. Construction then turns that shape into code, tests, fixes, and working behavior.

“Requirements tell us what matters. Design decides how

the pieces should fit. Construction turns those decisions
into working reality.”
BRIDGE FROM IDEA TO SOFTWARE
 4 DESIGNING AND BUILDING SOFTWARE Introduction to Software Design and Construction
118

4.1.2 Why Design Comes Before Coding

Some beginners feel that design slows them down. After all, writing code produces something
visible. A sketch, diagram, or design note may feel less exciting than a running screen. However,
design usually saves time because it helps the team make important decisions earlier, when
change is still cheaper.

Suppose a team begins coding a library system without thinking about how books, members,
borrowing records, fines, and staff roles connect. They may build a search page first, then
later discover that one book can have several copies, each copy can be borrowed separately,
and different staff members have different permissions. By that point, changing the code may
require rewriting several connected parts.

Design reduces that kind of rework. It helps the team think about structure, responsibilities,
data flow, and user interaction before too many assumptions have hardened into code. This
does not mean every project needs heavy documents. Good design can be lightweight. A
whiteboard sketch, a data model, a wireframe, and a few agreed rules may already prevent
many avoidable mistakes.

ʢ SIDEBAR | Design is not decoration

Students sometimes confuse design with making things look attractive. Visual appear‐
ance is one part of design, but software design is broader. It includes how modules
connect, how data is stored, how responsibilities are divided, how errors are handled,
and how users move through the system.

4.1.3 The Relationship Between Design and Construction

Design and construction are closely connected. Design influences what gets coded, but con‐
struction also teaches the team whether the design works well in practice. During construction,
developers may discover that a data model is awkward, that a screen takes too many steps, or
Design and code that one module is carrying too many responsibilities.
inform each other

Good teams do not treat design as a one‐time ceremony that can never be revisited. Instead,
they design enough to build responsibly, then refine the design as they learn. Construction
reveals reality. Design responds to reality. This back‐and‐forth is normal.

4.1.4 Chapter Overview

This chapter begins by explaining software design in plain, practical terms. It then introduces
the main levels of design and several important design principles that help teams control com‐
 4 DESIGNING AND BUILDING SOFTWARE Understanding Software Design
119

plexity. After that, the chapter explores three areas students meet very often: system struc‐
ture, user interface design, and data design.

The second half of the chapter focuses on software construction. It explains what it means
to turn design into code, how to write code that other people can understand, why standards
matter, how to validate input and handle errors, how to debug problems, how version control
supports teamwork, and how refactoring and documentation improve long‐term maintainabil‐
ity. Throughout the chapter, practical examples are used so that the ideas stay connected to
real software work.

4.2 Understanding Software Design

4.2.1 Meaning and Purpose of Software Design

Software design is the process of deciding how a software system should be organized so that
it can satisfy requirements effectively. It is not only about appearance and not only about tech‐
nical elegance. Its purpose is to help the team build a system that is clear, useful, changeable,
and dependable.

A useful way to think about design is as the arrangement of responsibilities. Which part of
the system handles login? Which part stores records? Which part applies rules? Which part
shows data to the user? Which part communicates with external services? Design answers
these questions before the system becomes too tangled.

Design also gives teams a shared mental picture. When several people are building one system,
they need more than individual good intentions. They need common understanding. A design
makes that shared understanding visible.

4.2.2 Design as a Blueprint, Not a Cage

People often compare design to a blueprint in construction work. The comparison is useful,
but only up to a point. A software design guides building, just as a blueprint guides physical
construction. However, software is easier to change than concrete, and projects often learn as
they progress. So design should guide the team without trapping it unnecessarily.

In practice, a strong design is one that gives clarity where clarity is needed, while leaving room
for reasonable adaptation. If the team learns from testing or user feedback that a screen flow
should change, the design should support that kind of change rather than collapse under it.
 4 DESIGNING AND BUILDING SOFTWARE Levels of Software Design
120

4.2.3 Characteristics of a Good Software Design

A good design should be clear enough that the team can explain it, simple enough that it does
not contain unnecessary complication, flexible enough to accept likely change, maintainable
enough that future developers can work with it, and reliable enough that important behavior
does not depend on hidden accidents.

Clarity matters because confusion spreads quickly in team projects. Simplicity matters because
unnecessary complexity creates more places for defects and misunderstanding. Flexibility mat‐
ters because real systems change. Maintainability matters because software lives beyond the
first demonstration. Reliability matters because users depend on the system behaving consis‐
tently.

­ CHECKPOINT
Why is a design that “works for now” not always good enough in a real project?

4.2.4 A Simple Design Example

Imagine a student registration support system. A weak design might place all code for login,
registration, approval rules, reporting, and data access into a few large files. The system may
appear to work at first, but changes become risky because every part touches every other part.

A better design would separate concerns. One part handles user authentication. Another han‐
dles course registration rules. Another stores and retrieves records. Another presents pages to
students and staff. This does not make the system perfect, but it makes it easier to understand,
test, and extend.

4.3 Levels of Software Design

4.3.1 High‐Level Design

High‐level design looks at the system from a broad perspective. It asks what the main parts
are, how they relate, and where major responsibilities belong. At this level, the team is not yet
worrying about every variable name or every exact query. It is deciding the overall shape of
See the big picture the system.

For a clinic appointment system, high‐level design might identify major parts such as patient‐
 4 DESIGNING AND BUILDING SOFTWARE Levels of Software Design
121

facing screens, staff‐facing screens, appointment logic, record storage, and notification ser‐
vices. It may also describe how these parts communicate. This level of design helps the team
avoid building a system as one undivided block.

4.3.2 Detailed or Low‐Level Design

Detailed design moves closer to implementation. It considers how a specific module works
internally, what data structures are used, how a function behaves, what validation happens on
a form, or how a class stores state and offers operations.

If the high‐level design says there will be an appointment module, the detailed design asks
what fields an appointment record should have, what rules apply when time slots overlap, and
how cancellation should be handled. This level helps construction proceed with fewer hidden
assumptions.

4.3.3 Logical and Physical Design

Another useful distinction is between logical design and physical design. Logical design de‐
scribes what the system must do and how information moves conceptually. Physical design
concerns the technologies, storage choices, deployment details, and implementation decisions
used to make that logic real.

For example, the logical design of a results portal may describe that lecturers submit marks,
heads of department approve them, and students view only approved results. The physical
design decides whether the system uses a web application, what database tables are needed,
how servers are arranged, and how authentication is handled.

Í Design levels in practice

Level Typical questions

High‐level design What are the main parts of the system, and how do they connect?
Detailed design How should this module, screen, or function behave internally?
Logical design What work should happen, and what information should move?
Which technologies, tables, files, or deployment choices will implement
Physical design
it?
 4 DESIGNING AND BUILDING SOFTWARE Principles of Good Software Design
122

4.3.4 Why These Distinctions Help Beginners

Students sometimes mix all design decisions together and become overwhelmed. Separating
levels helps because it allows the team to think in layers. First agree on the broad shape. Then
focus on specific parts. First understand the logic. Then choose the implementation details.
This makes the work more manageable.

4.4 Principles of Good Software Design

4.4.1 Modularity

Modularity means dividing a system into smaller parts, often called modules or components,
where each part has a clear responsibility. Modular design helps teams manage complexity
because people can focus on one part at a time without losing the entire system.

In a hostel booking system, one module might manage student details, another room availabil‐
ity, another allocation rules, and another payment confirmation. Each module can still interact
with the others, but the boundaries help the team reason about change.

Modularity also supports teamwork. If the modules are sensible, different developers can work
on different parts with fewer collisions. Without modularity, everyone edits the same area and
the project quickly becomes fragile.

4.4.2 Abstraction

Abstraction means focusing on the important behavior of a part while hiding unnecessary de‐
tails. People use abstraction all the time in ordinary life. When you use a phone, you do not
need to know every electrical detail inside it. You only need the relevant controls and expected
behavior.

In software, abstraction helps by allowing one part of the system to use another without de‐
pending on every internal choice it makes. A registration page may call a function such as
submitRegistration without needing to know every database step inside it. This reduces
Hide what others mental overload and allows internal improvement later.
do not need
 4 DESIGNING AND BUILDING SOFTWARE Principles of Good Software Design
123

4.4.3 Separation of Concerns

Separation of concerns means keeping different kinds of responsibility apart. A very common
example is separating user interface logic, business rules, and data access. If these concerns
are mixed badly, changes become awkward. A small rule change may require editing many
screens. A database change may break unrelated interface code.

When concerns are separated well, each part becomes easier to understand and test. For ex‐
ample, a course registration rule can be checked in the rule‐handling layer without needing to
run every page in the system.

4.4.4 Cohesion and Coupling

Cohesion refers to how strongly related the responsibilities inside one module are. High cohe‐
sion means the module does one connected kind of work. Low cohesion means the module
has scattered, unrelated jobs. High cohesion is preferred because it makes modules easier to
understand and maintain.

Coupling refers to how strongly different modules depend on one another. Tight coupling
means a change in one module is likely to force changes in another. Loose coupling means
modules can work together while remaining more independent. Loose coupling is usually pre‐
ferred because it lowers the cost of change.

ʢ SIDEBAR | A simple way to remember cohesion and coupling

High cohesion asks, “Do the things inside this module belong together?”
Low coupling asks, “Can this module do its job without knowing too much about other
modules?”

Suppose a single file in a library system handles user login, overdue fine calculation, book
search, and report export. That file has low cohesion because its responsibilities do not be‐
long tightly together. If several screens talk directly to raw database details in many places, the
system also has tight coupling because one schema change may force edits everywhere.

4.4.5 Encapsulation

Encapsulation means protecting a module’s internal details and exposing only what other parts
need to use. This principle is especially visible in object‐oriented programming, but the under‐
lying idea is broader than objects.

For example, a payment module may expose an operation that confirms a transaction status,
 4 DESIGNING AND BUILDING SOFTWARE Common Software Design Approaches
124

while hiding the exact internal checks it performs. Other parts of the system should rely on
the interface, not on secret internal behavior. Encapsulation protects the system from careless
interference and makes future change safer.

4.4.6 Reusability and Maintainability

Reusability means designing parts that can be used again in more than one place when appro‐
priate. Reuse is valuable because it reduces duplication and keeps similar behavior consistent.
However, teams should not force reuse too early in artificial ways. Reuse is most helpful when
the repeated need is genuine.

Maintainability means the design supports future change. This includes adding features, fix‐
ing defects, improving performance, and helping new team members understand the code.
Maintainability matters because software rarely ends with the first release.

­ CHECKPOINT
Why can a design that seems fast to build today become expensive tomorrow if cohesion
is low and coupling is high?

4.5 Common Software Design Approaches

4.5.1 Structured, Object‐Oriented, Component‐Based, and User‐Centered Think‐

ing

Several design approaches are common in software work. Structured design often focuses
on functions, processes, and the flow of information through the system. It can be useful in
systems where process logic is central and can be expressed clearly in steps.

Object‐oriented design organizes software around objects or classes that combine data and
behavior. This approach is helpful when the problem naturally includes real entities such as
students, books, orders, or appointments with related operations and state.

Component‐based design emphasizes building systems from reusable, well‐defined parts. These
may be internal components created by the team or external components provided by frame‐
works and libraries. This approach is useful because modern software rarely starts from noth‐
ing.
 4 DESIGNING AND BUILDING SOFTWARE Designing the Structure of a System
125

User‐centered design keeps user needs, goals, and difficulties visible throughout the design
process. Instead of only asking whether the system is technically possible, user‐centered design
asks whether it is understandable, efficient, and suitable for the people who must use it.

These approaches are not enemies. A project may combine them. A team may use object‐
oriented code, component‐based tools, structured flow thinking for some processes, and user‐
centered methods for the interface.

4.6 Designing the Structure of a System

4.6.1 System Architecture and Major Components

At a broad level, software structure is often described using architecture. For first‐year stu‐
dents, architecture can be understood as the high‐level arrangement of the system’s main parts
and relationships. It is not necessary to make architecture mysterious. It simply means the big
structural decisions that guide the rest of the work.

Many student systems use a layered or three‐tier style, even if students do not name it for‐
mally. One layer presents the interface. Another applies rules and processing. Another stores
and retrieves data. This division helps because each layer can focus on a different kind of re‐
sponsibility. Separate interface,
logic, and data

Suppose a campus announcements system has a student‐facing page, an administrator page,

announcement rules, and a database. A structured design may separate these concerns into
presentation, application logic, and data access. That is already a useful architectural choice.

4.6.2 Designing Modules and Interfaces

Once major components are identified, the team should think about modules in more detail. A
module should have a clear job. The team should also define its interface, meaning how other
parts interact with it. The interface may be a function, a method, a service call, or an agreed
set of inputs and outputs.

Clear interfaces are important because they reduce confusion between team members. If the
interface of the reporting module is vague, developers may build against different expectations.
If it is clear that a function returns approved results only, the team can build and test with more
confidence.
 4 DESIGNING AND BUILDING SOFTWARE Designing the User Interface
126

4.6.3 Thinking About Data Flow

Every system moves data. Information comes in, is checked, is processed, is stored, and is
shown again in useful form. Designing data flow means asking where information begins, what
changes it undergoes, what rules apply, and where the outputs go.

For example, in a clinic booking system, a student’s booking request enters through a form,
is validated, checked against schedule rules, saved to the database, then shown to staff. If
cancellations occur, notifications may also be sent. A team that designs this flow early is less
likely to miss important steps.

Í Typical questions when designing structure

Question Why it matters

What are the main modules? Prevents the system from becoming one large block.
What does each module own? Reduces confusion and overlapping responsibility.
How do modules communicate? Helps developers agree on interfaces early.
Where does data enter and go next? Reveals validation, processing, and storage needs.
Helps separate interface behavior from business
Which rules belong where?
logic.

4.7 Designing the User Interface

4.7.1 Why User Interface Design Matters

The user interface is the part of the system users see and interact with. If the interface is con‐
fusing, even a technically strong system may feel broken to the people who depend on it. This
is why interface design matters. It affects speed, confidence, accuracy, and user satisfaction.

Good interface design is not about decoration alone. It is about making work understandable.
A clean interface helps users know what to do, what has happened, and what to do next.

4.7.2 Characteristics of a Good Interface

A good interface is usually simple, consistent, clear, easy to navigate, and responsive in the
sense that it gives feedback. Simplicity means users are not buried under unnecessary choices.
Consistency means similar actions look and behave similarly. Clarity means labels, messages,
 4 DESIGNING AND BUILDING SOFTWARE Designing the User Interface
127

and layout make sense. Ease of navigation means users can move through tasks without getting
lost. Feedback means the system tells the user whether an action succeeded, failed, or needs
correction.

For example, when a student submits a maintenance request, the interface should show whether
the request was saved, not leave the student guessing. If a required field is empty, the system
should explain the problem clearly near that field.

ʢ SIDEBAR | A poor interface is expensive

When an interface confuses users, the cost is not only frustration. People make mistakes,
support requests increase, work slows down, and trust in the whole system drops.

4.7.3 Common Interface Elements and Design Problems

Interfaces often use forms, menus, buttons, tables, alerts, and status messages. These ele‐
ments are not difficult to name, but they are easy to misuse. A form with too many fields
discourages users. A menu with vague labels slows navigation. An error message that says only
“Invalid input” teaches the user very little.

Common interface problems include confusing layouts, too many steps, unclear error mes‐
sages, inconsistent screen behavior, and poor support for ordinary user mistakes. Beginners
often focus on making a page work technically without watching what the user must think and
do while using it.

4.7.4 A Practical Screen Example

Consider a login screen. A strong design usually includes a clear page title, a username field, a
password field, a visible login action, and a useful error message when details are incorrect. It
may also include password reset support or visibility controls when appropriate. A weak design
may hide the action, give vague messages, or ask for extra unnecessary information.

­ CHECKPOINT
Why is an error message such as “Something went wrong” less useful than a more spe‐
cific message near the field or action that caused the problem?

4.8 Designing Data and Databases

 4 DESIGNING AND BUILDING SOFTWARE Designing Data and Databases
128

4.8.1 Why Data Design Is Important

Many systems exist mainly to store, retrieve, process, and report data. If the data design is
weak, the rest of the system suffers. Reports become unreliable. Rules become difficult to
Bad data design apply. Searches become awkward. Duplicate and inconsistent information appears.
spreads pain

Good data design begins by asking what information the system must store, who uses it, how
it changes, and what relationships exist between pieces of information.

4.8.2 Entities, Attributes, and Relationships

An entity is a thing the system needs to keep track of, such as a student, a book, an appointment,
or a room. An attribute is a property of that entity, such as student number, title, appointment
date, or room capacity.

Entities are also connected by relationships. A student can make many maintenance requests.
A book can have many copies. A lecturer can teach many courses. These relationships matter
because they shape how tables, rules, and screens should work.

For example, in a library system, Book and Member are entities. A borrowing record connects
them. If the team forgets to model that relationship properly, it may struggle later to know
who currently has which copy.

4.8.3 Database Tables, Keys, and Good Data Practice

In relational database systems, entities are often represented through tables. Rows represent
individual records. Columns represent attributes. A primary key identifies a record uniquely.
A foreign key connects one table to another so relationships can be represented consistently.

Good database design tries to avoid unnecessary duplicate data, maintain consistency, pro‐
tect integrity, and support efficient retrieval. For example, if the same student phone num‐
ber is copied carelessly into many places, it becomes harder to keep records accurate when it
changes.
 4 DESIGNING AND BUILDING SOFTWARE Design Tools and Diagrams
129

Í A simple library data model

Entity Possible attributes

Book BookID, Title, ISBN, Category

Copy CopyID, BookID, Status, ShelfLocation
Member MemberID, Name, Program, Contact
Borrowing BorrowingID, CopyID, MemberID, BorrowDate, DueDate, ReturnDate

4.8.4 Designing Data for Real Use

Data design should not be done in isolation from user work. If librarians search by title and
category, the system should store those clearly. If a clinic must track cancellations separately
from missed appointments, the design should distinguish them. If staff members need to audit
who changed a record, the design may need created‐by and updated‐by fields or related logs.

This is another reason why design should remain connected to requirements and user under‐
standing.

4.9 Design Tools and Diagrams

4.9.1 Why Design Diagrams Help

Diagrams and sketches help teams think and communicate. They reduce the burden of holding
everything only in words. A simple drawing can often reveal structure or confusion faster than
a long explanation.

Design tools are not valuable because they look professional. They are valuable because they
make ideas visible and discussable.

4.9.2 Common Design Diagrams in Beginner Projects

Flowcharts help show step‐by‐step logic. They are useful when the team needs to explain a
process such as course approval or password reset flow.

Use case diagrams help identify who interacts with the system and what they are trying to do.
They are especially useful early, when the team is clarifying user activities.
 4 DESIGNING AND BUILDING SOFTWARE Introduction to Software Construction
130

Data flow diagrams show how information moves through processes, stores, and external enti‐
ties. These help when teams want to understand movement of data more clearly than interface
screens alone can show.

Entity relationship diagrams help show entities, attributes, and relationships for database de‐
sign. These are very helpful in data‐heavy systems.

Class diagrams are common in object‐oriented work and help show classes, attributes, meth‐
ods, and relationships. They are useful when the team is building with object‐oriented thinking
and needs a clearer code‐level model.

Wireframes or interface sketches help teams discuss screen layout and task flow before full im‐
plementation. Even a paper sketch can reveal missing buttons, confusing labels, or unnecessary
steps.

4.9.3 Choosing the Right Level of Diagramming

Not every project needs every kind of diagram. Students should avoid making diagrams only
to satisfy formality. Instead, they should ask which diagram helps the team understand the
problem or communicate the design more clearly. One good wireframe and one sound data
model are often more valuable than six diagrams nobody uses.

ʢ SIDEBAR | A helpful beginner habit

Draw before you code when the structure is unclear. The drawing does not need to be
beautiful. It only needs to make the next design conversation better.

4.10 Introduction to Software Construction

4.10.1 Meaning of Software Construction

Software construction is the practical work of turning design into running software. It includes
writing code, building modules, using libraries and frameworks, testing parts, fixing defects,
and documenting important details.

Construction is where ideas become concrete. At this stage, the quality of earlier design starts
to matter visibly. A clear design usually leads to smoother implementation. A weak design
often reveals itself through duplication, confusion, and fragile code.
 4 DESIGNING AND BUILDING SOFTWARE Writing Clear and Maintainable Code
131

4.10.2 Construction Is More Than Typing Code

Beginners sometimes imagine construction as a long session of writing lines of code. In reality,
construction involves many linked decisions. A developer writes code, runs it, checks errors,
adjusts structure, integrates with other modules, validates input, and confirms that behavior
matches the design and acceptance criteria.

Construction also involves judgment. Should this logic be a separate function? Is this name
clear enough? Is this code duplicated elsewhere? Should this input be validated here or in a
shared layer? Good construction depends on such small repeated decisions.

4.10.3 The Role of Developers During Construction

During construction, developers do not merely obey instructions passively. They interpret de‐
sign, raise concerns, notice awkwardness, and improve the shape of the software. If the code
reveals that one screen depends on too many hidden rules, the developer should say so. Con‐
struction is part of thinking, not just execution.

4.11 Writing Clear and Maintainable Code

4.11.1 Why Readability Matters

Code is read more times than it is written. Even the original programmer will later forget some
details. Team members who review, test, fix, or extend the software also need to understand
it. This is why readability matters.

Readable code reduces mistakes, speeds reviews, supports teamwork, and lowers maintenance
cost. Unreadable code may still run, but it makes the project weaker.

4.11.2 Meaningful Names and Sensible Organization

Names should help people understand intent. A variable named studentCount is clearer
than x. A function named calculateFine communicates more than processData. Files and
classes should also reflect responsibility.

Code should be organized so related behavior is grouped together and responsibilities are sep‐
 4 DESIGNING AND BUILDING SOFTWARE Coding Standards and Team Guidelines
132

arated. Very large functions often hide several jobs at once, making defects harder to spot and
changes harder to make.

4.11.3 Comments, Formatting, and Duplication

Comments are useful when they explain why something is done, especially when the reason is
not obvious from the code itself. Comments are less useful when they merely repeat what the
code already says clearly. Formatting also matters. Consistent indentation, spacing, and layout
help the team scan code more easily.

Avoiding duplication is another important habit. Repeated code increases the chance that one
copy will be updated while another is forgotten. Shared helper functions or reusable compo‐
nents often provide a cleaner solution.

­ CHECKPOINT
Why can duplicated code be dangerous even when both copies are correct today?

4.12 Coding Standards and Team Guidelines

4.12.1 Why Standards Matter

Coding standards are agreed rules about naming, formatting, file organization, comments, and
sometimes error handling or testing habits. Standards matter because software development
is collaborative. If each developer writes in a completely different style, reading and reviewing
Consistency helps the code becomes slower.
teams

Standards do not make code good by themselves, but they remove many avoidable distractions.
They help the team focus on real logic instead of arguing repeatedly about small style choices.

4.12.2 Simple Standards for Student Teams

A student team may decide on a few practical rules:

• use descriptive names;

• keep functions reasonably small;
 4 DESIGNING AND BUILDING SOFTWARE Error Handling and Input Validation
133

• place validation near user input and in shared rules where needed;
• write commits with clear messages;
• use one consistent formatting style;
• remove dead code instead of leaving confusion behind;
• update important documentation when behavior changes.

These rules are modest, but they already improve team collaboration strongly.

ʢ SIDEBAR | Standards are not only for lecturers or companies

Coding standards are a kindness to future teammates and to your future self. They re‐
duce friction in review, maintenance, and debugging.

4.13 Error Handling and Input Validation

4.13.1 Why Error Handling Matters

Real users do not always enter perfect input, and real systems do not always run under perfect
conditions. Networks fail. Files are missing. Passwords are wrong. A requested record may
not exist. Error handling is the practice of responding to such situations in a controlled and
understandable way.

Without good error handling, a system may crash, confuse users, or hide important information
from developers. With better error handling, the system remains calmer under difficulty.

4.13.2 Different Kinds of Errors

Students often first meet syntax errors, which prevent code from running because the language
rules were broken. They then meet logic errors, where the code runs but produces the wrong
result. Runtime errors happen while the program is executing. User input errors happen when
entered data is missing, badly formatted, or outside allowed rules.

These categories matter because they call for different responses. A syntax error must be fixed
in code. A logic error must be reasoned about. A user input problem should usually be handled
with helpful feedback rather than a crash.
 4 DESIGNING AND BUILDING SOFTWARE Debugging Software
134

4.13.3 Input Validation

Input validation checks whether incoming data is acceptable before the system uses it. This in‐
cludes checking required fields, data types, ranges, formats, and relationships between values.
For example, a registration form may need to confirm that student number format is correct,
that required fields are present, and that the selected course units do not clash.

Validation is important not only for correctness but also for security and trust. If a system
accepts anything carelessly, defects and abuse become more likely.

Í Examples of practical validation

Validation type Example

Required field A complaint cannot be submitted without a title and description.

Format check Email address must match a sensible structure.
Range check Requested room capacity cannot be negative or unrealistic.
Relationship check End date must not be earlier than start date.
Rule check A student cannot register for a course without meeting its prerequisite.

4.13.4 Helpful Error Messages

A strong error message helps the user recover. Instead of simply saying “Invalid input,” it tells
the user what needs correction. Instead of showing a system crash screen, it guides the user
or at least protects the system from revealing unnecessary internal detail.

For developers, errors should also be logged in a useful way. If the system fails silently, diag‐
nosing problems later becomes much harder.

4.14 Debugging Software

4.14.1 Meaning of Debugging

Debugging is the process of finding the cause of a defect and correcting it. It is different from
testing. Testing helps reveal that a problem exists. Debugging investigates why it exists and
how to fix it.

Debugging is a normal part of development, not a sign of incompetence. Even experienced

 4 DESIGNING AND BUILDING SOFTWARE Debugging Software
135

developers debug regularly because software systems contain many moving parts and assump‐
tions.

4.14.2 Common Causes of Bugs

Bugs often come from incorrect assumptions, weak logic, incomplete requirements, typing mis‐
takes, and unexpected user inputs. Sometimes the bug is not in the code that first appears
suspicious. Sometimes it is in data, configuration, integration, or misunderstanding of the re‐
quirement.

4.14.3 Basic Debugging Techniques

Useful debugging habits include reading error messages carefully, reproducing the problem
consistently, checking recent changes, isolating the smallest failing part, and testing assump‐
tions one by one. Print statements, logs, and debuggers can all help when used thoughtfully.

One of the most important habits is to avoid random changes. If a developer edits many things
at once without understanding the cause, the system may become harder to reason about.

ʢ SIDEBAR | A good debugging rhythm

1. Reproduce the problem.
2. Observe what is happening.
3. Form a likely explanation.
4. Test that explanation.
5. Fix the real cause.
6. Re‐test the behavior.

This rhythm is slower than guessing, but usually much more effective.

4.14.4 Learning from Defects

Some bugs reveal deeper design or process issues. If the same category of defect returns re‐
peatedly, the team should ask whether a shared function, stronger validation, better review,
or clearer acceptance criteria could prevent it in future.

4.15 Using Libraries, Frameworks, and Tools

 4 DESIGNING AND BUILDING SOFTWARE Using Libraries, Frameworks, and Tools
136

4.15.1 Why Existing Tools Matter

Modern software development rarely begins from nothing. Teams use libraries, frameworks,
packages, UI kits, database systems, testing tools, and version control platforms because these
save time and provide tested capability.

A library usually offers useful functionality the developer calls when needed. A framework
provides a broader structure within which the application is built. Beginners do not need to
memorize a perfect definition immediately, but they should understand that these tools shape
how software is constructed.

4.15.2 Benefits and Risks of External Tools

Using existing tools can speed development, reduce repetition, and improve reliability by rely‐
ing on components that have already been tested widely. However, external tools also carry
risks. If the team does not understand the tool well, it may misuse it. Dependencies may create
compatibility or security issues. Upgrades can break assumptions. Poorly chosen tools can add
complexity instead of removing it.

The lesson is not to avoid tools. It is to choose them carefully and understand them enough to
use them responsibly.

4.16 Version Control in Software Construction

4.16.1 Meaning and Value of Version Control

Version control is the practice of tracking changes to project files over time in a controlled way.
In software projects, this is essential because teams need to know what changed, who changed
Track change it, and how to recover if something goes wrong.
deliberately

Common concepts include the repository, which stores the project history; the commit, which
records a set of changes; the branch, which allows parallel work; and the merge, which com‐
bines work from different branches. Sometimes changes conflict, meaning two versions altered
the same area in incompatible ways.
 4 DESIGNING AND BUILDING SOFTWARE Documentation During Construction
137

4.16.2 Why Version Control Helps Student Teams

Without version control, student teams often exchange files manually, overwrite one another’s
changes, or lose working versions. With version control, collaboration becomes safer and more
visible. The team can review history, experiment more responsibly, and work in parallel with
clearer control.

Version control is not only a storage tool. It is also a communication tool. A clear commit
message and sensible branch practice help others understand what happened.

­ CHECKPOINT
Why is version control useful even for a small project with only two or three team mem‐
bers?

4.17 Documentation During Construction

4.17.1 Why Documentation Still Matters While Coding

Some students think documentation should wait until the end of a project. In practice, useful
documentation must grow during construction. Setup notes, design decisions, API expecta‐
tions, test instructions, and deployment steps are easiest to capture while they are still fresh.

Documentation can take several forms: code comments, technical notes, README files, user
instructions, installation guidance, and records of important decisions. The right amount de‐
pends on the project, but some documentation is always helpful.

4.17.2 Characteristics of Good Documentation

Good documentation is clear, accurate, updated, and easy to follow. Poor documentation is
vague, outdated, or longer than it needs to be without answering practical questions.

If the system has changed but the documentation has not, new team members lose time and
trust. This is why keeping documentation current is more important than writing large volumes
once.

4.18 Refactoring and Technical Debt

 4 DESIGNING AND BUILDING SOFTWARE Refactoring and Technical Debt
138

4.18.1 Meaning of Refactoring

Refactoring means improving the internal structure of code without changing its external be‐
havior. This may include renaming unclear variables, splitting large functions, removing dupli‐
cation, simplifying logic, and improving module boundaries.

Refactoring matters because first versions are rarely the best possible versions. As the team
learns more, the code can often be made clearer and safer.

4.18.2 Technical Debt

Technical debt describes the future cost created when teams take shortcuts that make later
change harder. This may happen because of rushed coding, poor design, duplication, weak
documentation, or postponed cleanup. Sometimes taking a shortcut is a conscious trade‐off.
The danger comes when the debt grows silently and begins to slow everything.

Technical debt often appears as code that nobody wants to touch, features that break unex‐
pectedly, or changes that require too many edits in too many places.

4.18.3 Managing Debt Through Deliberate Improvement

Teams manage technical debt through regular refactoring, code reviews, better standards, stronger
tests, and improved documentation. The goal is not perfection. The goal is to prevent the soft‐
ware from becoming harder and harder to develop.

ʢ SIDEBAR | A practical warning

If every new feature feels slower than the one before, the team should ask whether tech‐
nical debt is growing. Slowness is not always caused by laziness or weak tools. Some‐
times the code structure itself is getting heavier.

4.19 Secure Software Construction

 4 DESIGNING AND BUILDING SOFTWARE Running Case Study: Designing and Building a Library
Management System
139

4.19.1 Why Security Matters During Construction

Security is not something that can be added only at the end. Construction choices affect secu‐
rity from the beginning. Weak password handling, hard‐coded secrets, poor input validation,
careless error messages, and exposed sensitive data can all create serious problems. Build with care

Even beginner systems should develop good habits early. Validate user input. Protect access
to privileged actions. Avoid storing sensitive data carelessly. Do not expose internal details in
user‐facing errors. Keep dependencies updated. Think about who is allowed to see or change
what.

4.19.2 Practical Secure Coding Habits

Secure coding at this level means respecting basic discipline:

• validate and sanitize inputs;

• use proper authentication and authorization controls;
• protect passwords and sensitive records;
• log problems safely without exposing secrets;
• avoid hard‐coding credentials in the source code;
• keep frameworks and dependencies updated when possible.

Students do not need to become security specialists in this chapter, but they should learn that
careless construction can create risks long before deployment.

4.20 Running Case Study: Designing and Building a Library Man‐

agement System

4.20.1 Project Background

Consider a student team building a library management system for a departmental library. The
system should help staff register books, track copies, record borrowing and returning, calculate
overdue fines, and allow students to search the catalog.

The requirements are clear enough to begin design, but the system still needs structure.
 4 DESIGNING AND BUILDING SOFTWARE Running Case Study: Designing and Building a Library
Management System
140

4.20.2 Identifying Main Modules

The team identifies several modules: book management, member management, borrowing
and returning, fine calculation, reporting, and authentication. This helps the team avoid placing
every function into one large collection of files.

They also decide that the interface, application logic, and data access should be separated. This
means the search page should not directly contain all database details and business rules in one
place.

4.20.3 Designing the Data Model

The team identifies entities such as Book, Copy, Member, and Borrowing. They define relation‐
ships carefully so that one book can have multiple copies and one member can borrow multiple
items over time. They include due dates and return dates because these are needed for fines
and status tracking.

4.20.4 Designing the User Interface

For the interface, the team sketches screens before coding. The search page should be simple
and usable by students. The staff pages should support adding books, marking items borrowed,
and viewing overdue records. They decide to keep forms short and place error messages near
the fields that need correction.

4.20.5 Constructing the System Responsibly

During construction, the team agrees on naming standards, small commit messages, and visible
task ownership. They build the borrowing workflow in pieces, testing each part rather than
waiting for the entire system to exist before checking behavior.

When they notice duplicate logic for overdue calculations in two different places, they refactor
that logic into a shared function. When a bug appears because returned books are still shown
as unavailable, they debug by reproducing the flow and checking recent changes in status han‐
dling.
 4 DESIGNING AND BUILDING SOFTWARE Chapter Summary
141

4.20.6 Improving Through Review

By the second sprint, the team notices that one module mixes search logic with formatting
rules for the user interface. They separate those concerns, making later changes easier. They
also update the README with setup instructions and note the decisions they made about fine
calculation.

This case shows that design and construction are not separate worlds. Good design guides the
build, and construction reveals where design needs improvement.

­ CHECKPOINT
In the library case study, which design decisions helped later construction move more
smoothly?

4.21 Chapter Summary

Software design helps teams move from requirements to a structure that can be built, under‐
stood, and changed responsibly. It includes decisions about overall system shape, detailed
module behavior, user interface flow, data design, and the relationship between software
parts. Strong design principles such as modularity, abstraction, separation of concerns, co‐
hesion, coupling, and encapsulation help control complexity and support maintainability.

Design also connects directly to construction. Construction is the practical work of turning
design into code, tests, fixes, and working features. Good construction depends on readable
code, meaningful names, sensible organization, validation, careful error handling, debugging
habits, coding standards, version control, documentation, refactoring, and secure practices.
Teams that build with these habits create software that is not only functional, but also easier
to improve and trust.

n KEY TAKEAWAYS
• Design helps teams think before code becomes difficult to change.
• High‐level and detailed design answer different but connected questions.
• Good design principles reduce confusion, duplication, and fragile dependencies.
• User interface design, data design, and system structure must support one an‐
other.
• Construction includes testing, validation, debugging, documentation, and cleanup,
not only coding.
 4 DESIGNING AND BUILDING SOFTWARE Review Questions
142

• Coding standards and version control make teamwork safer and easier.
• Refactoring and technical debt management are part of responsible software de‐
velopment.
• Secure coding habits should begin during construction, not after release.

4.22 Review Questions

4.22.1 Short Answer Questions

1. Why does software design usually come before coding?

2. What is the difference between high‐level design and detailed design?
3. What is modularity?
4. Explain abstraction in simple terms.
5. What is meant by separation of concerns?
6. Why is high cohesion preferred to low cohesion?
7. What is the role of input validation?
8. What is the difference between testing and debugging?
9. Why is version control important in team projects?
10. What is technical debt?

4.22.2 Discussion Questions

1. A team says, “We will design as we code and not waste time with structure.” What risks
can follow from this?
2. How can a poor database design create problems in screens, reports, and later mainte‐
nance?
3. Why can readable code be considered a teamwork issue and not only a personal style
issue?
4. Compare a helpful coding standard with an unnecessarily rigid rule. How can a team tell
the difference?
5. In what ways can secure coding habits be useful even in small student projects?

4.22.3 Practical Activity

Choose one of the following systems or use your own project idea:
 4 DESIGNING AND BUILDING SOFTWARE Review Questions
143

• Course registration support system.

• Clinic appointment system.
• Library management system.
• Hostel repair request system.
• Student event booking system.

Prepare a short design‐and‐construction brief that includes:

• Main modules of the system.

• One simple interface sketch or wireframe description.
• Main entities and attributes.
• Two important relationships between entities.
• Two validation rules.
• Three coding standards your team will follow.
• One likely source of technical debt and how you will reduce it.

4.22.4 Mini Design Review Exercise

1. Write one user story for your chosen system.

2. Identify which module should own that behavior.
3. Describe what data the feature needs.
4. Write two acceptance criteria.
5. Explain one likely bug or misuse case and how the design or code should handle it.

CHAPTER REVIEW

SUMMARY REVIEW QUESTIONS

• Design turns requirements into a structure 1. What are the main modules and responsi‐
the team can build responsibly. bilities of this system?
• Good design principles help software stay 2. Where should validation, rules, and data
understandable and changeable. storage responsibilities live?
• Construction includes coding, validation, 3. How will the team keep code readable and
debugging, documentation, and cleanup. maintainable?
• Readable code, standards, version control, 4. What risks should be reduced during con‐
and refactoring support quality and team‐ struction rather than after release?
work.
REFERENCE

CHAPTER 4 KEY TERMS

Plain‐language meanings for design and construction work.

Software Design The technologies and implementation choices

used to realize the design.

Modularity
Deciding how a software system should be orga‐
nized so it can meet requirements effectively.

High‐Level Design Dividing a system into smaller parts with clear re‐
sponsibilities.

Abstraction
The broad design of the system’s main parts and
their relationships.

Detailed Design Focusing on important behavior while hiding un‐

necessary internal details.

Separation of Concerns
Closer design work about specific modules, func‐
tions, data structures, and logic.

Logical Design Keeping different responsibilities apart so they can

be understood and changed more easily.

Cohesion
A description of what the system should do and
how information should move.

Physical Design How strongly related the responsibilities inside one

module are.

144
 4 DESIGNING AND BUILDING SOFTWARE Review Questions
145

Coupling A field that links one table to another.

Software Construction

How strongly different modules depend on one an‐

other.
The practical work of turning design into running
Encapsulation software.

Input Validation

Protecting a part’s internal details and exposing

only what others need to use.
Checking whether incoming data is acceptable be‐
Wireframe fore using it.

Debugging

A simple sketch of a screen or interface layout.

Entity Finding the cause of a defect and correcting it.

Version Control

A thing the system needs to keep track of, such as

a student or book.
Tracking and managing changes to project files
Attribute over time.

Refactoring

A property of an entity, such as name, date, or sta‐

tus.
Improving internal code structure without chang‐
Primary Key ing external behavior.

Technical Debt

A field that uniquely identifies a record in a table.

Foreign Key Future cost created by shortcuts that make later

change harder.
 4 DESIGNING AND BUILDING SOFTWARE Review Questions
146

COMING UP NEXT

Connecting, Checking, and Improving Systems

The next chapter moves beyond individual modules into integration, testing, quality improvement,
maintenance, and the work of making complete systems dependable.
CHAPTER NO. 5

5
Connecting, Checking, and
Improving Systems

INTEGRATION, QUALITY, TESTING, DEPLOYMENT, MAINTENANCE, AND LONG‐TERM SOFTWARE CARE

œ LEARNING OBJECTIVES
By the end of this chapter, you should be able to:

• Explain why software that works in separate parts can still fail when the parts are
combined.
• Describe common kinds of integration and practical strategies for integrating sys‐
tems safely.
• Explain software quality in a way that includes user needs, organizational needs,
and developer responsibilities.
• Distinguish between quality assurance, quality control, verification, and validation.
• Describe different forms of testing and explain what each one is trying to reveal.
• Prepare simple test plans and test cases for beginner software projects.

147
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Introduction to Connecting and Checking Systems
148

• Explain how technical reviews help teams find problems before they become ex‐
pensive.
• Describe how teams prepare software for delivery and choose suitable deploy‐
ment approaches.
• Explain why maintenance, monitoring, and continuous improvement are normal
parts of software life.

5.1 Introduction to Connecting and Checking Systems

5.1.1 From Separate Parts to a Complete System

Y THE TIME A TEAM REACHES this stage, many useful things may already exist. The user

B interface may work on its own. The database may store records. Some business rules
may already be coded. A login page may succeed. A search feature may return results.
Each part may look promising when viewed separately. Yet the system as a whole may still be
Parts working unreliable.
alone is not enough

This happens because software systems do not create value only through isolated parts. They
create value when those parts connect properly. A registration portal is not useful because it
has a login screen and a database in separate corners. It is useful because students can log
in, choose units, have rules checked, save records, receive correct feedback, and later retrieve
accurate information.

The move from separate pieces to a complete working system is therefore a major stage of
software development. It requires integration, checking, review, and improvement. Teams
that ignore this stage often discover late that the software “worked on my machine” but not as
a dependable system.

“A software system is not proved by isolated success. It

is proved by whether its connected parts behave
correctly together under real conditions.”
SYSTEM REALITY
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Introduction to Connecting and Checking Systems
149

5.1.2 Why Built Software Still Needs to Be Checked

Some students feel that once code exists and the main screens appear to work, the project
is almost complete. In reality, building software and checking software are deeply connected.
A feature may appear correct with one example and fail badly with another. A system may
pass through a clean demonstration and still break under ordinary user mistakes, higher data
volume, network delay, or inconsistent assumptions between modules.

Checking is needed because software is full of hidden assumptions. One developer may assume
dates are always present. Another may assume a status field is never blank. A third may assume
a report only shows approved records. These assumptions may remain invisible until features
are connected and users behave in ordinary, unpredictable ways.

5.1.3 The Relationship Between Integration, Quality, and Improvement

Integration, quality, and improvement belong together. Integration reveals how parts behave
together. Quality work helps teams judge whether the system is dependable, usable, secure,
and correct enough for its purpose. Improvement responds to what the team learns from in‐
tegration, testing, user feedback, and real operation. Check, learn,
improve

This means Chapter 5 is not only about defect hunting. It is also about maturity. Strong teams
do not merely hope the system is good. They create habits that help them discover problems,
judge readiness honestly, and improve both product and process.

5.1.4 Chapter Overview

This chapter begins with system integration and practical ways of combining software parts.
It then introduces software quality and explains how quality can be understood from several
points of view. After that, the chapter explores reviews, verification, validation, and testing as
complementary ways of checking software.

Later sections focus on test planning, defect handling, delivery, deployment, maintenance,
monitoring, and project closure. A running case study based on a student registration system
ties these ideas together so the chapter remains grounded in practical software work rather
than abstract terminology.

5.2 Understanding System Integration

 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Understanding System Integration
150

5.2.1 Meaning of System Integration

System integration is the process of connecting different parts of a software system so that they
work together correctly. The parts may include modules, databases, user interfaces, external
services, or even hardware devices. Integration matters because a system is useful only when
those parts cooperate reliably.

For example, a clinic appointment system may have a booking form, a schedule checker, a
patient database, and an SMS notification service. Each part may seem reasonable alone. In‐
tegration checks whether booking a real appointment causes the right data to be saved, the
correct conflict checks to happen, and the appropriate message to be sent.

5.2.2 Common Things That Need Integration

Many beginner projects need to integrate at least three broad kinds of parts: internal software
modules, persistent data storage, and user‐facing screens. More advanced projects may also
integrate external APIs, authentication services, payment platforms, scanners, printers, cloud
storage, or reporting tools.

The important lesson is that integration is not rare or special. It is normal. Even a simple student
project that saves form data to a database is already performing integration.

ʢ SIDEBAR | A beginner example of integration

Suppose a student complaint system has:

• a form where students submit complaints;

• a database table that stores those complaints;
• an admin page where staff review them.

The system is only integrated if the form sends correct data, the database stores it cor‐
rectly, and the admin page retrieves and displays the right record. If any step breaks, the
system is incomplete even if the separate pieces looked fine alone.

5.2.3 Why Integration Is Often Difficult

Integration can be difficult because parts are often built at different times, by different people,
under different assumptions. One module may expect one data format while another produces
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Integration Types and Strategies
151

a different one. One developer may assume an external service always responds quickly. An‐
other may forget what happens if the network fails.

This is why teams should not postpone integration until the end if they can avoid it. The longer
assumptions remain untested, the more painful the correction becomes.

­ CHECKPOINT
Why can two individually correct modules still fail when combined?

5.3 Integration Types and Strategies

5.3.1 Different Kinds of Integration

There are several common forms of integration in practical software work. Module integration
checks how internal program parts cooperate. Database integration connects application logic
to stored data and ensures records remain consistent. Interface integration connects user ac‐
tions to system behavior so that forms, buttons, and screens trigger the right logic and show
the right results.

API integration connects the system to external services such as email providers, SMS gateways,
payment services, or maps. Some systems also involve hardware and software integration, such
as barcode scanners used with a library system or fingerprint devices used with attendance
systems.

Students do not need to memorize these as a rigid list. The practical question is always the
same: what separate parts must communicate correctly for the system to do real work?

5.3.2 Big Bang, Incremental, Top‐Down, Bottom‐Up, and Continuous Integration

Teams integrate systems in different ways. Big bang integration means combining many parts
at once near the end. This may look fast, but it is risky because when something fails, it becomes
difficult to know which connection caused the problem.

Incremental integration combines parts step by step. This is usually easier to manage because
problems are revealed in smaller, more understandable pieces. If the login feature is integrated
first, then profile loading, then reporting, the team can trace failures more clearly.
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Common Integration Problems
152

Top‐down integration starts from higher‐level components and gradually brings in lower‐level
parts, sometimes using temporary placeholders called stubs. Bottom‐up integration starts
from lower‐level components and moves upward, sometimes using drivers to simulate higher‐
level callers. These ideas are useful because they show that integration can be staged thought‐
fully.

Continuous integration in modern development means integrating code frequently rather than
letting branches drift apart for long periods. This often goes together with automated builds
and tests. The main benefit is not fashionable tooling. The real benefit is early discovery of
integration problems.

Í Comparing common integration approaches

Approach Main strength Main caution

Problems become hard to trace

Big bang Simple idea, little early setup
when many parts fail together.
Easier fault isolation and learn‐ Needs planning about order and
Incremental
ing dependencies.
Lower‐level placeholders may
Top‐down Early view of high‐level behavior
hide some detail.
Good testing of lower‐level Full user‐visible behavior ap‐
Bottom‐up
components early pears later.
Early detection and steady col‐ Requires discipline, tool sup‐
Continuous integration
laboration port, and frequent merging.

5.3.3 Choosing a Practical Integration Strategy

The best integration strategy depends on project size, risk, team maturity, and tooling. Small
student projects often benefit from incremental and frequent integration because it keeps the
work visible and reduces last‐minute surprises. Larger and more complex systems may combine
several strategies.

In general, early and repeated integration is healthier than waiting until the end. Integration is
easier to fix while the project is still flexible.

5.4 Common Integration Problems

 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Introduction to Software Quality
153

5.4.1 What Usually Goes Wrong

Integration problems often come from incompatible components, mismatched interfaces, dif‐
ferent data formats, connection failures, hidden assumptions, weak security controls, or poor
error handling. A page may send a field called studentId while the receiving service expects
student_number. A module may expect approved data only, but receive unfiltered records. A
payment service may time out and leave the system unsure whether the payment succeeded.

Database connection issues are also common. The application may connect to the wrong
schema, use outdated table names, or mis‐handle missing relationships. Network and commu‐
nication failures can reveal whether the system behaves calmly under partial failure or simply
crashes.

5.4.2 How Teams Reduce Integration Problems

Teams reduce integration problems through clear interface definitions, shared understanding
of data formats, early integration, realistic test data, strong documentation, and active com‐
munication between developers. It helps to agree on expected inputs, outputs, and error re‐
sponses instead of leaving them to guesswork.

Another useful habit is to test connections under less‐than‐perfect conditions. What happens
if the external service is slow? What happens if the database returns no rows? What happens
if the user submits the form twice? These questions make the system stronger.

ʢ SIDEBAR | A quiet source of failure

Many integration failures are not caused by very advanced technical problems. They
are caused by ordinary assumptions that were never written down and never tested to‐
gether.

5.5 Introduction to Software Quality

5.5.1 Meaning of Software Quality

Software quality is the degree to which software is fit for its intended purpose. This sounds
simple, but it is richer than “does the code run?” A system may run and still be difficult to
use, too slow, insecure, or impossible to maintain. Quality therefore includes several aspects
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Quality Management, Standards, and Reviews
154

Quality is broader of behavior and usefulness.

than correctness

Quality is also viewed differently by different people. A user may care most about ease of use
and dependable results. A manager may care about reliability, reporting, and reduced opera‐
tional disruption. A developer may care about maintainability, clarity, and defect prevention.
All these views matter.

5.5.2 Why Quality Matters

Poor quality creates cost. Bugs consume time. Users lose trust. Organizations depend on un‐
reliable data. Security weaknesses expose private information. Support teams become over‐
loaded. Eventually the project spends more effort reacting to problems than improving the
product.

Good quality does not mean perfection. It means the software is dependable enough for its
purpose, and the team works deliberately to reduce avoidable failure.

5.5.3 Important Quality Attributes

Several quality attributes appear again and again in software projects. Correctness asks whether
the software gives the right results. Reliability asks whether it continues working dependably
over time. Usability asks whether people can understand and use it effectively. Efficiency
concerns speed and resource use. Security concerns protection of data and control of access.
Maintainability concerns ease of fixing and improving the system. Scalability concerns growth
in users, load, or data. Availability concerns whether users can access the system when needed.

Students do not need to memorize all of these in abstract language. They should connect them
to ordinary questions: Is it right? Is it dependable? Is it understandable? Is it fast enough? Is
it safe? Can we improve it later?

­ CHECKPOINT
Why can a system be functionally correct and still be considered low quality by users?

5.6 Quality Management, Standards, and Reviews

 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Quality Management, Standards, and Reviews
155

5.6.1 Quality Planning, Assurance, and Control

Quality management means organizing work so the project can reach the desired level of qual‐
ity. This includes planning quality goals, preventing defects where possible, checking work
products, and learning from mistakes.

Quality assurance focuses on preventing problems by improving how work is done. This may
include standards, training, review practices, and better development habits. Quality control
focuses on finding defects in the product through testing, inspection, and checking outputs.

The difference matters because quality is not created only by testing at the end. Strong teams
build quality into the process as well as into the product.

5.6.2 Why Standards and Procedures Help

Standards and procedures help teams work consistently. A coding standard reduces unnec‐
essary variation. A testing procedure helps ensure that important checks are not forgotten.
A documentation standard makes handover easier. A release checklist helps the team avoid
missing critical preparation steps.

For first‐year students, standards should stay practical. The point is not bureaucracy. The point
is repeatability and clarity. If every team member names files differently, writes defect notes
differently, and tests in completely different ways, quality becomes much harder to manage.

5.6.3 Technical Reviews

Technical reviews are structured ways of checking work products before relying on them too
heavily. Reviews can be informal or more organized. Teams can review requirements, designs,
code, test plans, user manuals, and other project artifacts. Find problems
early

Reviews help because many problems are cheaper to fix before execution or before wide de‐
ployment. A requirements review may reveal ambiguity before coding starts. A design review
may reveal tight coupling before implementation spreads. A code review may reveal confusing
logic, duplication, or security weaknesses before users ever see the system.

ʢ SIDEBAR | Testing is not the first line of defence

If a defect can be found in a review before the software is even run, the team saves time.
This is why mature teams do not rely only on testing. They review thinking as well as
behavior.
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Verification and Validation
156

5.6.4 Simple Review Types

Informal reviews are lightweight checks, such as one developer asking another to look at a
module. Peer reviews involve colleagues examining work more deliberately. Walkthroughs in‐
volve the author guiding others through the work product and collecting questions or concerns.
Inspections are more formal and structured.

In beginner projects, a lightweight peer review is often enough to teach the discipline of shared
checking.

5.7 Verification and Validation

5.7.1 Two Important Questions

Verification asks whether the team is building the system correctly. Validation asks whether
the team is building the correct system. These phrases are easy to repeat but much more
valuable when understood practically.

Verification concerns whether the implementation matches the requirements, design, and agreed
rules. Validation concerns whether the result actually solves the user’s real problem in a satis‐
factory way. A system can be verified well and still fail validation if it is the wrong solution. It
can also satisfy users in one area while being poorly verified in technical details that later create
risk.

“Verification asks whether the system was built right.

Validation asks whether the right system was built. Both
matter.”
TWO CHECKING LENSES

5.7.2 How Verification Happens

Verification can happen through requirements checks, design reviews, code reviews, static anal‐
ysis, traceability, and several forms of testing. The main idea is to compare what was produced
with what was expected.
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Testing the System
157

For example, if the requirement says only approved results should be visible to students, ver‐
ification checks whether the design supports that rule, whether the code implements it, and
whether the tests cover it.

5.7.3 How Validation Happens

Validation often involves users and stakeholders more directly. It can happen through demon‐
strations, prototypes, usability testing, field trials, user acceptance testing, or stakeholder re‐
view. The question is not only whether the feature works technically, but whether it fits real
work, real expectations, and real conditions.

Suppose a student portal technically allows students to register in the right order, but users still
find the process confusing and frequently abandon it midway. That is a validation problem.

­ CHECKPOINT
Why is user acceptance testing usually more closely connected to validation than to ver‐
ification?

5.8 Testing the System

5.8.1 Meaning of Software Testing

Software testing is the activity of executing or checking software to discover defects and build
confidence about behavior. Testing is not proof of perfection. It is a disciplined way of learning
where the software fails and where it appears dependable.

5.8.2 Common Levels and Kinds of Testing

Unit testing checks individual parts such as functions, classes, or modules. Integration testing
checks interaction between connected parts. System testing checks the complete system as a
whole. Acceptance testing checks whether users or stakeholders agree the software is ready
for its intended use.

There are also special‐purpose tests. Regression testing checks that changes did not break
older working behavior. Performance testing explores speed and behavior under load. Security
testing explores authentication, authorization, protection of data, and resistance to misuse.
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Test Planning and Test Cases
158

Í Testing types and their main purpose

Testing type Main question

Unit testing Does this small part behave correctly on its own?
Integration testing Do these connected parts work together properly?
System testing Does the whole system behave as expected overall?
Acceptance testing Do users or stakeholders agree it is suitable for use?
Regression testing Did a new change damage something that used to work?
Performance testing Is the system fast and stable enough under expected load?
Security testing Are access controls, data handling, and protections working properly?

5.8.3 Why Different Tests Are Needed

No single kind of testing is enough. Unit testing may show that the fine calculation function
works, but not whether the borrowing screen calls it at the right time. Integration testing may
show the modules connect, but not whether users understand the workflow. Acceptance test‐
ing may show the workflow is acceptable, but not whether performance remains stable during
peak use.

This is why testing should be layered rather than treated as one event near the end.

5.9 Test Planning and Test Cases

5.9.1 Planning Tests Before Panic Time

A test plan is a simple statement of what will be tested, how it will be tested, in what environ‐
ment, with what data, by whom, and when. Even small student projects benefit from basic test
planning because otherwise testing tends to become rushed, uneven, and incomplete.

A practical test plan should identify the features to be tested, any features outside current
scope, the environment, the test data, the schedule, and the responsibilities. This does not
need to be long. It needs to be useful.
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Defects and Defect Management
159

5.9.2 Writing Test Cases

A test case describes a specific check. It usually includes an identifier, objective, setup or input
data, steps, expected result, actual result, and a pass/fail outcome. Writing test cases forces
the team to be more precise about what correct behavior means.

For example, a login test case might specify valid credentials, steps to sign in, the expected
landing page, and the expected behavior when the password is wrong. A registration test case
might check what happens when a student chooses two clashing courses.

ʢ SIDEBAR | Why test cases help beginners

When students test casually, they often remember the “happy path” only. Test cases
encourage them to check less comfortable situations too: missing input, invalid choices,
repeated submissions, unauthorized access, and edge cases.

5.9.3 Using Good Test Data

Test data should reflect realistic use. If every test uses neat and perfect values, many important
problems stay hidden. Teams should include normal cases, boundary cases, invalid cases, and
unusual but possible situations.

5.10 Defects and Defect Management

5.10.1 Meaning of a Defect

A defect is a flaw in the software or its related artifacts that may lead to wrong behavior. People
also use words such as bug, error, or failure, though they are not always exactly identical. For
first‐year students, the practical issue matters more than the terminology: something is wrong,
it needs to be described clearly, and the team must handle it systematically.

5.10.2 Reporting Defects Clearly

A useful defect report explains what happened, how to reproduce it, what was expected, what
actually happened, how severe the issue is, and how urgent it is. Weak defect reports waste
time because other team members cannot reproduce or understand the problem.
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMSPreparing the System for Delivery and Deployment
160

For example, saying “login broken” is not enough. A better report says that when a valid stu‐
dent signs in after changing a password, the system redirects to a blank page instead of the
dashboard, and it happens consistently in a specific browser or context.

5.10.3 Fixing, Retesting, and Learning

After a defect is fixed, the team should retest the corrected behavior and, when necessary,
run regression checks nearby. Defects also provide learning. If similar defects keep appearing,
the team should ask whether the root cause lies in unclear requirements, poor design, weak
review, inadequate test data, or rushed coding.

­ CHECKPOINT
Why is it not enough to fix a defect once and move on without asking why it appeared?

5.11 Preparing the System for Delivery and Deployment

5.11.1 Readiness for Delivery

Before software is delivered, the team should check whether the important features are com‐
plete enough, whether critical tests have passed, whether serious defects have been resolved
or consciously deferred, whether documentation is current, and whether users or support staff
have what they need.

Delivery is not just sending files. It is preparing the system and the people around it for suc‐
cessful use.

5.11.2 Release Preparation

Release preparation often includes version numbering, release notes, installation or setup in‐
structions, backup planning, and communication about what changed. Even in student projects,
it is valuable to practice this discipline because it reflects professional care.
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS System Maintenance, Monitoring, and
Improvement
161

5.11.3 Deployment and Changeover Strategies

Deployment means placing the system into the environment where it will actually be used.
This may require installing software, configuring databases, creating user accounts, assigning
permissions, and providing training.

Teams can deploy in different ways. Direct changeover replaces the old system immediately.
Parallel changeover runs old and new systems together for a while. Phased changeover intro‐
duces the system in parts. Pilot changeover starts with a smaller group before broader rollout.

The right choice depends on system risk, user readiness, organizational size, and how much
failure can be tolerated during transition.

Í Choosing a deployment approach

Approach Often useful when

Direct changeover Risk is manageable and fast replacement is practical.

Parallel changeover Accuracy is critical and the old system cannot be dropped immediately.
The system can be introduced feature by feature or department by de‐
Phased changeover
partment.
Pilot changeover The team wants to learn from a smaller real‐world rollout first.

5.11.4 Supporting Users During Early Use

Deployment is not complete when installation ends. Early user support matters because real
use reveals real friction. Training, quick‐response support, and careful observation of early
problems can prevent frustration from turning into rejection.

5.12 System Maintenance, Monitoring, and Improvement

5.12.1 Why Maintenance Is Normal

Many beginners imagine that once software is deployed, the main work is over. In reality, de‐
ployment often marks the beginning of a different kind of work. Systems need fixes, adaptation,
improvement, and protection over time. Software lives
after release

Corrective maintenance fixes defects discovered after deployment. Adaptive maintenance

 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Closing a Software Project
162

helps the system fit changed environments, rules, or platforms. Perfective maintenance im‐
proves performance, features, or usability. Preventive maintenance reduces future problems
by improving structure, security, or internal quality before visible failure happens.

5.12.2 Monitoring the System

Monitoring means observing how the system behaves in operation. Teams may watch avail‐
ability, response time, logs, security events, usage patterns, and user complaints. Monitoring
matters because some problems appear only in live conditions with real users, real traffic, and
real timing.

Monitoring also helps prioritization. If a system is technically functional but users repeatedly
struggle with one process, that issue deserves attention even if it does not produce a crash.

5.12.3 Continuous Improvement

Improvement should not depend only on crisis. Strong teams collect feedback, notice patterns,
prioritize useful changes, and improve both the product and the process. If several users com‐
plain about the same unclear message, improve the interface. If the same category of defect
appears in every sprint, improve review or testing habits. If deployment support was chaotic,
improve the release checklist.

ʢ SIDEBAR | Improvement applies to the team too

Continuous improvement is not only about software features. It is also about how the
team works: how clearly it communicates, how early it tests, how carefully it reviews,
and how honestly it reports problems.

5.13 Closing a Software Project

5.13.1 Meaning of Project Closure

Project closure is the deliberate finishing of a project or project phase. It includes confirming
delivery, handing over the system or artifacts, documenting remaining issues, capturing lessons
learned, and releasing resources or responsibilities appropriately.

Closure matters because unfinished endings create confusion. Without clear closure, people
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Running Case Study: Checking and Deploying a
Student Registration System
163

may not know whether the system was accepted, what still needs attention, or who owns the
next stage of work.

5.13.2 Lessons Learned

One of the most useful closure activities is reflecting on what went well, what went badly, and
what should be improved next time. This is valuable in both student projects and professional
work. Lessons learned prevent the team from repeating avoidable mistakes blindly.

5.13.3 Final Reporting and Handover

At closure, the team should be able to explain what was delivered, what remains unresolved,
what recommendations are important, and what documents or instructions the next users or
maintainers need. This creates continuity.

5.14 Running Case Study: Checking and Deploying a Student Reg‐

istration System

5.14.1 Project Background

Consider a student registration system with modules for student accounts, course registration,
fee verification, timetable checking, and reporting. Earlier chapters showed how such a system
might be planned, designed, and built. Now the team must integrate it, verify it, validate it,
deploy it, and prepare it for continued use.

5.14.2 Integrating the Main Modules

The team first connects login with student account data, then connects course registration with
timetable and prerequisite checks, then connects fee verification so that students with unpaid
balances receive the correct message. Reporting is integrated later so approved registration
records can be summarized for administrative staff.

During this work, the team discovers a mismatch: the timetable module expects one format
for course codes while the registration module uses another. Because integration is being done
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Running Case Study: Checking and Deploying a
Student Registration System
164

incrementally, the team notices the issue early and corrects it before more features depend on
the inconsistency.

5.14.3 Reviewing, Verifying, and Testing

The team performs a short requirements review to check that important registration rules are
clear. A design review reveals that one report pulls unapproved records accidentally. Code
review reveals repeated validation logic that should be shared.

Verification then proceeds through unit tests on registration rules, integration tests on the in‐
teraction between fee verification and registration, and system tests covering end‐to‐end regis‐
tration. Regression checks confirm that recent fixes did not break previously working behavior.

5.14.4 Validating with Real Users

Two administrative staff members and several students participate in user acceptance testing.
They confirm that the system generally works, but students report that the clash warning mes‐
sage is unclear. Staff also request a clearer summary view of rejected registrations. These
findings are not treated as embarrassment. They are treated as valuable validation results.

5.14.5 Preparing for Deployment

The team updates the documentation, writes release notes, prepares a backup of test data, and
decides that a pilot‐style deployment is safest. One department will use the system first while
the team monitors errors and collects feedback. Training notes are prepared for staff who will
assist students.

5.14.6 Maintaining and Improving the System

After early use begins, monitoring shows that registration checks are slower during peak hours.
The team investigates the database queries and improves one report. User feedback also re‐
veals that students want clearer next‐step guidance after a rejected registration. This becomes
part of perfective maintenance.

­ CHECKPOINT
In this case study, which activities belonged mainly to verification, and which belonged
mainly to validation?
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Chapter Summary
165

5.15 Chapter Summary

Software systems must be connected, checked, and improved before they can be trusted in real
use. Integration joins modules, interfaces, databases, and services into one working whole,
while quality work helps teams judge whether that whole is correct, usable, reliable, secure,
and maintainable enough for its purpose. Reviews, standards, and quality planning help pre‐
vent defects early rather than relying only on late testing.

Verification and validation ask different but equally important questions: whether the system
was built correctly and whether the right system was built. Testing supports both by checking
units, integrations, complete systems, acceptance, regression, performance, and security con‐
cerns. Defect management, delivery preparation, deployment strategy, maintenance, monitor‐
ing, and project closure all help software move from a build artifact into a dependable service
that can continue improving over time.

n KEY TAKEAWAYS
• A system is only valuable when its parts work together correctly.
• Quality includes correctness, usability, reliability, security, maintainability, and
other practical concerns.
• Reviews and standards help prevent defects before testing alone can find them.
• Verification checks whether the system was built correctly; validation checks
whether it is the right system for users.
• Different forms of testing reveal different kinds of risk.
• Delivery and deployment require preparation, not only working code.
• Maintenance and monitoring are normal parts of software life, not signs of failure.
• Improvement should continue after release through feedback, learning, and de‐
liberate change.

5.16 Review Questions

5.16.1 Short Answer Questions

1. What is system integration?

2. Why can individually correct modules fail when combined?
3. What is the difference between quality assurance and quality control?
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Review Questions
166

4. Define verification and validation in simple terms.

5. What is the purpose of integration testing?
6. Why are technical reviews useful before testing?
7. What information is usually included in a test case?
8. What is regression testing?
9. Name four common deployment strategies.
10. Why is maintenance needed after deployment?

5.16.2 Discussion Questions

1. A team says, “Our modules work separately, so we are almost finished.” What risks would
you point out?
2. Why can a system pass many technical checks and still fail users in practice?
3. Compare verification and validation using a university portal example.
4. When might a pilot deployment be wiser than direct changeover?
5. How can repeated defects teach a team something about its process rather than only
about its code?

5.16.3 Practical Activity

Choose one of the following systems or use your own:

• Student registration system.

• Clinic booking system.
• Library management system.
• Hostel request system.
• Campus announcements platform.

Prepare a short checking‐and‐release brief that includes:

• Main modules or parts that must be integrated.

• Two likely integration risks.
• Three quality attributes that matter most for this system.
• Two review activities the team should perform before release.
• Three test cases, including one invalid‐input or edge case.
• A recommended deployment approach and reason.
• One expected maintenance need after release.
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Review Questions
167

5.16.4 Mini Test and Review Exercise

1. Write one user story for your chosen system.

2. Write two acceptance criteria for that story.
3. Create one unit or component test idea for it.
4. Create one integration test idea for it.
5. Describe how a real user would help validate whether the feature is actually useful.

CHAPTER REVIEW

SUMMARY REVIEW QUESTIONS

• Integration turns separate parts into a 1. Which parts of the system are most risky to
working system and reveals hidden as‐ integrate?
sumptions. 2. How will the team know the product is both
• Quality work includes prevention, check‐ technically correct and useful to users?
ing, and continuous improvement. 3. What tests, reviews, and release checks
• Verification, validation, reviews, and test‐ must happen before deployment?
ing each contribute a different kind of con‐ 4. How will the team monitor, maintain, and
fidence. improve the system after release?
• Deployment, maintenance, and monitor‐
ing continue the software life after con‐
struction ends.
REFERENCE

CHAPTER 5 KEY TERMS

Plain‐language meanings for integration, quality, testing, and software improvement.

System Integration Activities that help prevent defects by improving

how work is done.

Quality Control
Connecting software parts so they work together
correctly as one system.

Incremental Integration Activities that find defects in the product, such as

testing and inspection.

Technical Review
Combining parts step by step instead of all at once.

Continuous Integration
A structured check of a work product such as re‐
quirements, design, code, or tests.

Frequently merging and checking code so integra‐

Verification
tion problems appear early.

Software Quality
Checking whether the system was built correctly
according to agreed requirements and design.

The degree to which software is fit for its intended

Validation
purpose.

Quality Assurance
Checking whether the built system is the right one
for real users and stakeholders.

168
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Review Questions
169

Unit Testing

A specific check with steps, input, expected result,

and outcome.
Testing a small part of the software on its own.

Defect
Integration Testing

A flaw in the software or related artifacts that may

Testing how connected parts work together. cause wrong behavior.

System Testing Deployment

Testing the complete system as a whole. Placing the system into the environment where it
will actually be used.
Acceptance Testing

Maintenance

Testing with users or stakeholders to confirm readi‐

ness for use. Changing software after release to fix, adapt, im‐
prove, or protect it.
Regression Testing

Monitoring

Testing after changes to ensure older working be‐

havior still works. Observing how a system behaves in operation so
problems and improvement opportunities can be
Test Plan noticed.

Project Closure

A short plan describing what will be tested, how,

when, and by whom.

The deliberate finishing of a project, including han‐

Test Case dover and lessons learned.
REFERENCE

COURSE GLOSSARY
Key terms for Software Development Practices.

Program

A prioritized list of work that may be done on a soft‐

ware product.
A set of instructions written for a computer to per‐
form a task.
Product Backlog Item

Software System

One item in the backlog, often written as a user

need, feature, task, defect, or improvement.
Connected software parts, data, people, proce‐
dures, and sometimes hardware that support a
Sprint
real activity.

Stakeholder
A short fixed period in which a team works toward
a clear goal and produces a usable increment.

A person or group affected by a system or inter‐

Sprint Planning
ested in its success.

Requirement
A meeting where the team chooses what it can
complete in the sprint and agrees on a sprint goal.

A statement of what the software should do or a

Daily Stand‐up
condition it should satisfy.

Product Backlog
A short coordination meeting where team mem‐

170
 5 CONNECTING, CHECKING, AND IMPROVING SYSTEMS Review Questions
171

bers share progress, plans, and blockers.

Sprint Review A practical check of whether a project can and

should be done.

Functional Requirement
A meeting where completed work is shown to
stakeholders for feedback.

Sprint Retrospective A requirement describing what the system does.

Non‐Functional Requirement

A meeting where the team reflects on how to im‐

prove its way of working.
A requirement describing a quality such as speed,

Acceptance Criteria security, or usability.

Testing

Simple testable conditions used to decide whether

a backlog item is complete.
Checking whether software behaves as expected in

Project Scope normal and unusual situations.

Maintenance

The boundary of what a project will and will not

include.
Changing software after release to fix, improve,

Feasibility Study adapt, or update it.

This page intentionally left blank.