BCS Written ICT common mistakes
BCS Written ICT · Understand the traps and how to avoid them.
Writing the answer to a 'define and explain' question as a single memorised definition sentence and then stopping, without giving the requested explanation or example, so a 10-mark question earns only 2-3 marks.
Candidates revise from short notes and treat the command word ('explain', 'discuss', 'illustrate') as decoration; under time pressure they dump the definition they know and move on rather than building the answer to the mark allocation.
What to do instead
Before writing, underline the command word and count the marks; allocate roughly one substantive point per mark. Structure each answer as definition, mechanism, worked example, and one limitation or local application, then check that every clause of the question has been addressed.
Describing how a system works only in general terms without naming components, units, or the sequence of operations, e.g. answering a cache-memory question without mentioning hit ratio, levels, or the fetch path.
Weak grasp of internal architecture means the candidate can only produce a textbook summary sentence; they cannot reconstruct the mechanism, so they pad with vague phrases instead of technical detail.
What to do instead
For each hardware topic build a one-page mechanism diagram from memory (fetch-decode-execute, memory hierarchy, interrupt cycle, DMA transfer) and practise writing a 150-word explanation that names every component and its role.
Confusing related operating-system concepts in the answer, such as paging with segmentation, deadlock avoidance with prevention, or a process with a thread, and giving one definition that silently covers the wrong term.
These concepts are learned together in quick revision and share vocabulary; without a comparison table the candidate's memory blurs the distinguishing criterion (fixed-size frames versus logical segments, safe state versus resource-ordering).
What to do instead
Prepare contrast tables for the classic pairs (paging/segmentation, process/thread, deadlock prevention/avoidance/detection, internal/external fragmentation) with the single distinguishing criterion in the first column, and in the exam open the answer by stating that criterion explicitly.
Answering a numerical networking question (subnetting, host count, throughput, propagation delay) with a narrative description instead of showing the binary or arithmetic working and the final figure.
Candidates avoid calculation under exam pressure because they have practised concepts but not timed drills; they hope a descriptive answer will earn partial credit.
What to do instead
Do weekly timed drills: convert addresses to binary, derive subnet masks, usable hosts and broadcast addresses, and compute delay and throughput with units shown. In the exam, write the formula, substitute values, then state the result with units.
Drawing an ER diagram or writing SQL that ignores the stated constraints, for example omitting a weak entity's identifying relationship, missing a foreign key, or forgetting GROUP BY and HAVING in an aggregate query.
Candidates memorise syntax patterns and symbols but do not re-read the scenario for cardinality, participation, and aggregation requirements, so the diagram is syntactically valid but semantically wrong.
What to do instead
Annotate the scenario before drawing: underline every noun as a candidate entity, every verb as a relationship, and record cardinality and participation beside each. For SQL, list the required output columns, then the joins, then the grouping and filtering, and test the query mentally against one sample row.
Writing code in the answer booklet without declaring variables, initialising accumulators, or handling the boundary case (empty input, single element, zero division), so the algorithm fails on the first test the examiner applies.
Candidates practise by reading code rather than writing it by hand, so they skip the mechanical discipline of declarations and initialisation that a compiler would normally enforce.
What to do instead
Hand-write at least two full solutions a week on paper with no IDE, then trace them by hand on an empty case, a one-element case, and a typical case. In the exam, dry-run the code line by line on a small example and write the trace beside the answer.
Choosing an algorithm or data structure by name rather than by the required complexity, e.g. proposing a linear search inside a loop for a large dataset or a stack where a queue's FIFO order is required, and failing to state the time complexity.
Candidates learn definitions and operations of each structure but not the selection criteria, so they cannot map problem constraints to the right tool.
What to do instead
Build a decision sheet linking problem signals to structures and algorithms (ordered lookups, LIFO versus FIFO, sorted versus hashed access), and end every algorithm answer with best, average, and worst-case complexity plus a one-line justification.
Writing a software-engineering or systems-analysis answer that lists only the phases of a lifecycle model, without producing the requested artefact such as a context diagram, data-flow diagram, use-case description, or feasibility argument for the given scenario.
The syllabus invites recall of model names, and candidates default to the list they memorised, ignoring that the question supplies a scenario and asks for an applied deliverable.
What to do instead
Practise converting a short scenario into each standard artefact within 15 minutes: level-0 and level-1 data-flow diagrams, a use-case with main and alternate flows, an entity list, and a cost-benefit or technical feasibility paragraph. Always tie each symbol back to a named element of the scenario.
Treating a security question as a definition request, so a question asking how to secure a described system receives a list of terms (firewall, encryption, antivirus) with no threat being countered, no placement in the architecture, and no legal or policy dimension.
Candidates revise security as vocabulary and separate it from the legal framework, so they do not connect a control to a specific threat or to the applicable statute.
What to do instead
Answer security scenarios in a fixed frame: asset, threat, vulnerability, control, residual risk, and legal or policy basis. Memorise the key provisions of the relevant national cyber-law instruments and cite the applicable one by name whenever the question involves offences, liability, or data handling.
Describing an emerging technology or e-governance project only by its benefits and buzzwords, with no architecture, no implementation constraints, and no evaluation of risks, cost, or readiness in the local context.
Candidates rely on promotional articles and headlines, so they can define the term but cannot reason about deployment, interoperability, privacy, or sustainability, which is what higher-mark questions test.
What to do instead
For each emerging technology keep a four-part card: how it works, enabling infrastructure, realistic use case in public service or education, and risks or policy prerequisites. For project questions, always add scope, stakeholders, timeline, budget logic, and a monitoring-and-evaluation indicator.