Software Design and Development Notes | Leaving Cert Computer Science

Software is built in stages: investigate, plan, design, create, evaluate, document, and then repeat. This note covers how to plan and structure a program, design accessible interfaces, validate input defensively, test systematically across unit, function, and system stages, and reflect on the finished solution.

The Software Development Process and Methodologies

Building reliable software requires a structured process. Without one, teams quickly run into missed deadlines, blown budgets, and buggy programs that fail to do what the user needed. The Leaving Certificate specification models software development as an iterative cycle of six stages:

Investigate: Define the problem clearly, identify user and stakeholder needs, and examine whether building a solution is feasible.
Plan: Understand the problem fully, break it into smaller tasks, assign team roles, and set a timeline with milestones.
Design: Create a representation of the solution (such as flowcharts, pseudocode algorithms, and screen sketches) and decide which tools and programming languages to use.
Create: Implement the plan by writing the code, setting up data structures, and commenting functions clearly.
Evaluate: Determine whether the solution is appropriate. Check whether it meets the user requirements, and carry out testing to eliminate errors.
Document: Report, present, and reflect on the process. Record what was done, how computational concepts were applied, what worked well, and what you would change.

Because the process is iterative, you will regularly loop back to earlier stages when testing shows a bug or when a user suggests an improvement.

Six development stages connected in order, with feedback arrows returning to earlier stages.

Staged vs Iterative Methodologies

Software projects usually follow one of two broad approaches:

Feature	Waterfall (Staged / Linear)	Agile (Iterative / Flexible)
Stage order	Strict sequence: each phase must finish before the next begins.	Short cycles (sprints): planning, coding, and testing happen repeatedly.
Requirements	Fixed and signed off at the very start.	Evolving: requirements are reviewed and updated throughout.
Handling change	Difficult and expensive to alter course late in the project.	Welcomes change based on ongoing user and client feedback.
Working software	Delivered only near the end of the project lifecycle.	Delivered in small, working increments after every sprint.
Best used when	Requirements cannot change, such as software for a medical device.	Requirements evolve through user interaction, such as a new student app.

Feasibility

During the investigate stage, teams assess whether the project is worth pursuing:

Technical feasibility: Do the hardware, software tools, and technical skills exist to build it?
Economic feasibility: Is the project financially viable, and do the benefits justify the cost?
Legal and ethical feasibility: Does the software comply with data protection regulations such as GDPR, licensing rules, and ethical standards for user privacy?

Requirements, Stakeholders, and Team Roles

Before writing code, developers must understand who they are building for and what those people need.

Requirements and Stakeholders

A requirement is something the finished software must do, or a quality it must have:

Functional requirement: What the system must do. For example, "A student can log in and view their timetable."
Non-functional requirement: How well the system performs. For example, "The timetable must load in under two seconds" or "The app must be navigable using a screen reader."

A stakeholder is any person or group affected by the software. For a school homework app, stakeholders include students, teachers, parents, the principal, and the IT administrator. Each group brings a different perspective. Parents might want automated deadline alerts, teachers need a fast grading interface, and students need offline access on mobile devices.

Common ways to gather requirements include interviewing stakeholders, distributing surveys, observing how people currently carry out the task, and testing early prototypes with users.

Working in a Team

Most software is built by teams rather than individuals. Assigning distinct roles avoids duplicated effort and ensures every part of the project receives attention:

Project manager: Coordinates the schedule, tracks progress against milestones, and resolves roadblocks.
Designer: Plans user flows, screen layouts, and user interface mock-ups.
Developer / Programmer: Writes and refines code for specific program modules.
Tester: Designs test plans, prepares test data, and logs bugs.

Effective teams agree on deadlines early, divide work into independent modules so members can work in parallel, communicate regularly, and use shared repositories so everyone works on the latest version.

Decomposition, Modular Design, and Prototyping

Tackling an entire software project in one go is overwhelming. Computational thinking manages this complexity through decomposition and abstraction.

Top-Down Design

Top-down design starts with the main purpose of the software and breaks it down into progressively smaller sub-problems. For example, a canteen-ordering app can be split into three sub-systems: Menu Display, Order Processing, and Payment Handling. Each of these is then divided further until every sub-task can be solved by a single, focused algorithm.

Modular Design

Modular design divides a program into separate, self-contained units called modules or functions. Each module performs one specific task and keeps its internal details hidden. Other parts of the program only need to know what to pass in (the parameters) and what comes back (the return value).

A canteen-ordering app branches into three subsystems; a separate module inset shows parameters entering and a return value leaving.

Modular design provides three main benefits:

Parallel development: Different programmers can write and test separate functions at the same time without interfering with each other.
Reusability: A reliable validation function written for one project can be reused in future programs without changes.
Easier debugging: When an error occurs, you can test and fix the individual function without having to search through the entire codebase.

Prototyping

A prototype is an early, simplified version of a system or user interface. It demonstrates key visual layouts and basic interactions so users and clients can give feedback before developers invest time writing backend logic and database connections.

User-Centred Design and Universal Design

User-Centred Design (UCD) puts the needs, preferences, and limitations of end users at the centre of every design decision.

Developers distinguish between two related ideas:

User Interface (UI): The visual and interactive elements a person touches, clicks, or views (buttons, menus, text fields, and colour schemes).
User Experience (UX): How the user feels while interacting with the software, including its speed, ease of navigation, clarity, and convenience.

The 7 Principles of Universal Design

Universal Design is the design of software and environments so that they can be accessed, understood, and used by all people, regardless of age, size, ability, or disability. The seven principles were developed at North Carolina State University and are promoted in Ireland by the Centre for Excellence in Universal Design (CEUD):

Principle	Software Meaning	Digital Example
1. Equitable Use	The design is useful and accessible to people with diverse abilities.	Built-in screen reader support for visually impaired users.
2. Flexibility in Use	Accommodates a wide range of individual preferences and abilities.	Offering multiple ways to complete a task: keyboard shortcuts, mouse clicks, or voice commands.
3. Simple and Intuitive Use	Easy to understand regardless of user experience, language, or literacy level.	Using standard icons that require no explanation, such as a magnifying glass for search.
4. Perceptible Information	Presents necessary information clearly using multiple sensory modes.	Video players that provide closed captions and subtitles alongside audio tracks.
5. Tolerance for Error	Minimises hazards and the negative consequences of accidental actions.	Providing an "Undo Send" popup or asking for confirmation before permanently deleting a file.
6. Low Physical Effort	Can be used comfortably and efficiently with minimum fatigue.	Auto-filling form fields and allowing full navigation using the Tab key.
7. Size and Space for Approach and Use	Appropriate size and spacing for interaction and reach.	Designing large touch targets on mobile screens so users do not hit adjacent links by accident.

Comparing Two User Interfaces

Consider two ticket-purchasing interfaces: a self-service train station kiosk with a large touchscreen versus a text-dense mobile website.

The kiosk applies Size and Space for Approach and Use by featuring large, spaced buttons that are easy to press even for users with limited motor control, and Perceptible Information by pairing written text with audio prompts.
The mobile website packs small text links close together, making accidental clicks common and violating Tolerance for Error.

A kiosk has large separated ticket buttons and audio support; a mobile page has crowded links with overlapping touch areas.

Defensive Design, Input Validation, and Errors

Defensive design means writing code that anticipates mistakes, unexpected inputs, and deliberate misuse. A central defensive technique is input validation, which checks that incoming data is sensible and reasonable before the program processes it.

Common Validation Checks

Range check: Verifies that a number falls between a set minimum and maximum (e.g. an exam percentage must be between 0 and 100 inclusive).
Type check: Checks that data belongs to the expected data type (e.g. ensuring an age consists entirely of digits).
Length check: Confirms that a string is neither too short nor too long (e.g. a password must contain at least 8 characters).
Format check: Ensures data follows a strict layout pattern. An Irish example is verifying an Eircode, which must follow the pattern of a three-character Routing Key followed by a space and a four-character Unique Identifier (e.g. D02 X285).
Presence check: Checks that a mandatory field was not submitted blank.

The Limitation of Validation

Validation checks only that data is sensible and follows the rules; it cannot verify that the data is true. For example, typing someone else's Eircode will pass a format check, and entering an age of 45 will pass a 0–120 range check even if the user is actually 15.

Input Validation Loops in Python

In Python, input() always returns a string. You must validate user input before converting it into an integer, otherwise unexpected text will crash your program.

tickets = input("How many tickets (1-8)? ")
while not tickets.isdigit() or int(tickets) < 1 or int(tickets) > 8:
    print("ERROR: Please enter a whole number from 1 to 8.")
    tickets = input("How many tickets (1-8)? ")
tickets = int(tickets)
print("You booked", tickets, "tickets.")

How this works:

.isdigit() acts as a type check. It returns True only if every character is a digit. It safely rejects words, spaces, negative signs, and decimal points.
Because Python evaluates logical or statements from left to right, it stops checking as soon as one condition is true. If tickets.isdigit() is false, Python never runs int(tickets), preventing a crash.
The loop repeats until the user supplies a valid value.

Input passes through digit and range decisions; failed checks display an error and request input again, while accepted input reaches booking output.

Types of Programming Error

Syntax error: The code breaks the grammatical rules of the language. The program refuses to run at all. Example: if score > 50 missing the colon at the end.
Runtime error: The syntax is correct, but an illegal operation causes the program to crash during execution. Example: dividing a number by zero (ZeroDivisionError) or trying to convert "ten" to an integer (ValueError).
Logic error: The program runs without crashing but produces the wrong output because the algorithm is incorrect. Example: writing if age > 18: when the requirement states "18 or over". An 18-year-old is incorrectly rejected. The fix is if age >= 18:.

Debugging Techniques

Trace tables (dry runs): Stepping through code manually line by line with pen and paper, recording how each variable changes.
Print statements: Temporarily printing variable values at different points in the code to pinpoint where calculations go wrong.
Interactive debuggers: Setting breakpoints to pause execution and stepping through the code one line at a time to examine memory.

Software Testing and Evaluation

Testing finds defects, while evaluation determines whether the software is the right solution to the problem.

The Three Stages of Software Testing

The specification defines three progressive stages of software testing:

Unit testing: Testing individual components or functions on their own, in isolation from the rest of the program. Developers write unit tests during coding to verify that a single function returns the correct output for given inputs. Example: Testing a calculate_vat() function with several prices to check the arithmetic.
Function (functional) testing: Testing the features of the program against the requirements specification. It checks what the system does from the user's perspective, without looking at internal code. Example: Confirming that clicking "Checkout" displays the correct order summary and updates stock levels.
System testing: Testing the complete, fully integrated software application end to end on actual hardware and network setups. It assesses whether all parts work together under realistic conditions, including speed, reliability, and security. Example: Verifying that 500 students can log in and submit an online exam at the same time without the server crashing.

Unit testing isolates calculate_vat; function testing checks checkout outcomes; system testing connects users, devices, a network and the complete application.

Beyond these stages, developers also distinguish between two testing purposes: functional testing checks what the system does against requirements, while non-functional testing checks how well it performs (execution speed, capacity, and security under load).

Writing a Test Plan

A good test plan tests three categories of data:

Normal data: Valid values that sit safely inside the expected range (e.g. testing 4 for a ticket count requiring 1 to 8).
Boundary data: Values at the edges of acceptability and just outside them (e.g. testing 1 and 8 to ensure they are accepted, and 0 and 9 to confirm they are rejected).
Erroneous (Invalid) data: Inputs of the wrong type or completely outside allowable limits (e.g. "five", -3, or 15).

Integer ticket counts 1 through 8 are accepted; boundary tests include accepted 1 and 8 and rejected 0 and 9. Four is a normal test.

A standard test table includes columns for Test Number, Input Value(s), Type of Test, Expected Output, and Reason. When executing the tests, testers add Actual Output and Pass/Fail columns.

Evaluating, Reflecting, and Documenting

While testing asks "Does the code work without errors?", evaluation asks "Is this the best possible solution to the problem?"

When evaluating a completed program, consider:

Requirements: Did the finished artefact meet every functional and non-functional requirement set out by stakeholders?
Efficiency and feasibility: Does the program run quickly, handle reasonable data volumes, and avoid wasting memory?
Ethical impact: Does the solution protect user privacy and avoid bias?
Short- and long-term outcomes: Does it work today, and will it continue to work if user numbers increase tenfold?

Reflecting means identifying clear limitations and proposing concrete improvements (such as replacing hard-coded values with database queries). Finally, documenting records the process: code comments explain why tricky logic was written for future developers, and user documentation gives end users clear instructions on how to install and run the software.

Key terms

Waterfall Model: A linear, staged software development methodology where each phase must be fully completed before the next phase begins.
Agile Methodology: An iterative software development methodology that prioritises flexibility, short development cycles, continuous feedback, and working software.
Functional Requirement: A statement specifying a particular action, service, or feature that a software system must be able to perform.
Non-Functional Requirement: A statement specifying quality criteria or performance constraints for a system, such as speed, security, or accessibility.
Top-Down Design: A problem-solving approach that breaks a complex system down from a high level of abstraction into progressively smaller sub-tasks.
Modular Design: A programming approach that divides a system into independent, self-contained units (modules or functions) that each perform a specific task.
Universal Design: The design of products and software so that they can be accessed, understood, and used by all people regardless of their age, size, or ability.
Input Validation: Defensive programming checks that verify user input is sensible, reasonable, and in the correct format before processing.
Syntax Error: An error caused by code that breaks the grammatical rules of the programming language, preventing the program from running.
Runtime Error: An error that causes a syntactically valid program to crash while it is running due to an illegal operation.
Logic Error: A flaw in an algorithm that causes a program to run without crashing but produce incorrect or unexpected results.
Unit Testing: The stage of software testing where individual functions or components are tested in isolation from the rest of the application.
Function Testing: The stage of software testing that checks whether the overall features of a program behave in accordance with user requirements.
System Testing: End-to-end testing of the complete, integrated application under realistic operational conditions to verify overall performance.

Check yourself

Name the three stages of software testing in order, from lowest to highest level.
Unit testing, function testing, and system testing.
A student writes if age > 18: to check if a user qualifies for an adult ticket (defined as 18 or older). What type of error is this, and how should it be fixed?
This is a logic error because 18-year-olds will be rejected; it should be corrected to if age >= 18:.
Why can you not use type(response) is int to validate a number entered via input() in Python?
Because input() always returns data as a string (str), so the check would evaluate to False for every input.
Which Universal Design principle is demonstrated when an email app provides an 'Undo Send' option for five seconds after dispatching a message?
Tolerance for Error, because it minimises the negative consequences of accidental or unintended actions.
Give one example of a functional requirement and one example of a non-functional requirement for a school library system.
Functional requirement: A student can search for a book by author and reserve it. Non-functional requirement: Search results must appear within one second.

Software Design and Development