B1.1 Approaches to computational thinking

A good problem statement must be specific, measurable, and consequential — it should explain exactly what the problem is, quantify the impact, and link it to a real negative outcome.

Option A uses the vague phrase 'has problems' with no specifics. Option C says 'outdated and staff are unhappy' — still vague and unmeasurable. Option D gives a partial description but no quantified impact or cause.

Option B states the specific problem (manual processing), gives a measurable impact (3 hours per day), names the process causing harm (phone notifications), and identifies real consequences (double-bookings, delayed notifications).

Option B satisfies all criteria for a strong problem statement: it is specific, measurable, and consequential. This makes it the clear best choice.

The question asks for the best problem statement, meaning the most specific, measurable, and consequence-linked description of the problem.

'Has problems' is extremely vague — it tells a developer nothing about what specifically needs fixing or why it matters. This is eliminated immediately.

'Outdated' and 'unhappy' are subjective and unmeasurable. There is no quantified impact or specific workflow identified, so this option fails.

While slightly more specific, 'sometimes' is not measurable, and no root cause or consequence is clearly linked. This is too weak to be a strong problem statement.

The option mentioning 3 hours per day, manual processing, and double-bookings is the only one that is specific, measurable, and consequential — it is the correct answer.

The algorithm (flowchart) is producing incorrect outputs — patients are being routed to wrong departments. This is a logic error within the algorithm itself.

Algorithmic design involves creating and analysing step-by-step logical instructions. Tracing an algorithm with test inputs is the standard technique for identifying where logic diverges from intended behaviour.

Abstraction would not help trace a specific logic error. Deleting bookings (pattern recognition misapplied) destroys data rather than finding the fault. Separating departments (decomposition misapplied) does not fix the decision logic.

Tracing the flowchart step-by-step with sample inputs is a direct application of algorithmic design and is the correct approach for diagnosing incorrect decision logic.

The question asks which computational thinking approach best identifies where a logic error occurs in a flowchart algorithm.

Deleting and re-entering all patient data does not address the decision logic in the flowchart — it would simply recreate the same error. This is not what abstraction means in this context.

Finding and deleting incorrect bookings treats the symptom, not the cause. This does not identify where the algorithm goes wrong, and deleting records would be harmful.

Physically separating departments does not address the flowchart's decision logic error and misrepresents what decomposition means in computational thinking.

Tracing the flowchart step-by-step with sample inputs directly targets the logic error in the algorithm — this is the correct and precise application of algorithmic design.