DGB 2: Hardware and Software

← Digital Literacy – Year 2

A digital device works as a system: hardware provides the physical components, while software defines processes and functions. Only their interaction enables input, processing, storage, output and communication. Thinking in systems helps students understand devices as cooperating components rather than only as visible interfaces.

Curriculum reference

Area	Classification
Competence area	Action
Perspectives	Technical perspective (T)
Focus	Hardware and software working together as a system
Competence	Match hardware and software components to typical tasks, understand the operating system as an intermediate layer and trace processes through complete digital systems.

Learning objectives

Students can:

distinguish hardware from software confidently;
match CPU, RAM, storage, input and output devices to their basic functions;
distinguish operating systems from application software;
explain that programs are executed using hardware resources;
understand drivers in basic terms as software that enables interaction with hardware;
trace an input through processing, storage and output;
name the hardware and software involved in a digital task;
understand system requirements as a relationship between software and available hardware;
classify common faults as more likely related to hardware, software, connection or settings;
describe a device from both a user and a system perspective;
compare systems for a task using performance, usability and equipment.

Learning content

Hardware as the physical basis

Processor, memory, SSD, screen, keyboard, camera, microphone and network adapter are hardware. They provide computing power, storage, input, output and communication. Connections and power supply are also part of the functioning system.

Software controls processes

Software provides instructions and user functions. Applications perform tasks for users, while the operating system manages resources and provides services used by programs. A program cannot perform useful work without suitable hardware on which to run.

Operating system as an intermediary

The operating system connects applications with files, memory, input/output devices and network functions. It also provides a user interface and manages access to resources. This explains why the same application may depend on a particular operating system or version.

Drivers and device support

A driver is software that helps the operating system communicate with a hardware device. If a device is physically connected but the system cannot use it, the problem may involve a driver, setting, permission or connection rather than broken hardware.

Following a task through the system

When a user types a character, the keyboard creates input, the operating system and application process the event, memory holds working data, and the screen displays output. Saving the document adds storage to the process.

System requirements

Software may require a particular operating-system version, processor capability, memory, storage space or graphics support. System requirements therefore connect software needs with hardware capabilities.

Troubleshooting with a system view

A useful troubleshooting approach asks whether the problem concerns hardware, software, settings, permissions, connection or data. Checking one category at a time is more effective than making random changes.

Classroom activities

Break everyday tasks into hardware and software

Choose tasks such as typing, video calls or printing and list the physical and software components involved.

Expected outcome: A system-level component map.

Investigate device components

Identify visible and known internal components of a computer or tablet and assign basic functions.

Expected outcome: Correct component-function mapping.

Compare software types and system roles

Sort operating system, driver, application and service examples.

Expected outcome: Understanding of software layers.

Trace an input through the system

Follow a key press or photo capture from input through processing to output and storage.

Expected outcome: A complete process description.

Solve system-view case studies

Use fictional faults to decide whether hardware, software, settings or connection is the most likely category.

Expected outcome: A structured diagnosis.

Describe a device from two perspectives

Write a user view (‘what can I do?’) and a system view (‘which components make it possible?’).

Expected outcome: Two complementary descriptions.

Model the operating system as intermediary

Draw application → operating system → hardware relationships for three examples.

Expected outcome: A simple layer model.

Test hardware–software interaction

Change a safe setting such as audio output or display device and observe how software and hardware interact.

Expected outcome: A practical system observation.

Compare systems for a task

Evaluate two fictional computers for a given task using requirements and available hardware.

Expected outcome: A justified system choice.

Create a troubleshooting checklist

Write an ordered list of checks for a common device problem.

Expected outcome: A reusable diagnostic routine.

Self-check

I can distinguish hardware and software.
I can explain basic roles of CPU, RAM, storage and input/output devices.
I can distinguish operating system, driver and application.
I can trace a task through several system components.
I understand why software has hardware requirements.
I can narrow down faults systematically.