IB Computer Science Topic B1.1.1: Constructing a Problem Specification Notes

Problem Specification: Pinning Down the Problem Before Designing a Solution

1. A problem specification is a written account of the problem a solution must solve, produced before any design or code exists.
2. It is what turns a vague complaint into something a programmer can build against and a client can check.
3. A full specification usually covers six elements:
   1. Problem statement
   2. Constraints and limitations
   3. Objectives and goals
   4. Input specifications
   5. Output specifications
   6. Evaluation criteria

Problem Statement: Naming the Fault and Its Cost

1. A problem statement says exactly what is going wrong and why that matters.
2. A strong statement is concise and specific, and it answers both the what and the why of the problem.
3. It also quantifies the impact, so the size of the problem is on record and can be compared against the finished system.

Constraints and Limitations: What the Solution Is Not Allowed to Do

1. A constraint is a restriction or boundary that limits what the solution can be.
2. Constraints fall into three broad groups:
   1. Resource limits such as time, budget and staf.
   2. Technical limits such as the capability of the hardware and software already in place.
   3. External factors such as school policy, data protection regulation, or dependence on a system someone else controls.
3. Each constraint has to be precise enough to rule design options in or out.

Objectives and Goals: Broad Aims Versus Measurable Targets

1. An objective is a broad, high-level outcome the solution aims for.
2. A goal is a measurable, time-bound target that shows whether an objective is being reached.
3. Every goal must trace back to a figure in the problem statement, or the solution is being built for a problem nobody reported.

Input Specifications: The Data Going In

1. Input specifications define the format, type and characteristics of the dat the solution will receive.
2. They are what make the incoming data compatible with the processing that follows.
3. A usable specification names the source of each field, its data type and format, and any validation rule it has to pass.

Output Specifications: The Results Coming Out

1. Output specifications state what information the system produces and in what form.
2. Common formats are dashboards, reports, alerts and charts.
3. They also record who each output is for, since teachers and students rarely need the same view of the same data.

Evaluation Criteria: How Success Will Be Judged

1. Evaluation criteria are the benchmarks used to decide whether the finished system solved the problem it was built for.
2. Five criteria cover most solutions:
   1. Effectiveness: does the system do the job described in the problem statement?
   2. Efficiency: how fast is it, and how much memory and processing does it us under a realistic load?
   3. Accuracy: are the results consistently correct?
   4. Usability: can the intended users work it without training?
   5. Maintainability: can it be updated when the requirements change?

Worked Specification: A School Canteen Pre-Order System

1. The canteen throws food away most days and runs out of the hot option before the second lunch sitting.
2. Written out as a full specification, the same situation looks like this.
3. Problem statement
   1. “The canteen prepares a fixed 400 meals a day, discards an average of 70 unsold meals, and sells out of the hot option before the second sitting on three days in five, so around 18% of food is wasted while some students get no choice at all.”
4. Constraints and limitations
   1. No new hardware: students order on their own phones through the school login that already exists.
   2. Orders close at 09:30, because the kitchen needs two hours of preparation before the first sitting.
5. Objectives and goals
   1. Objective: cut canteen food waste while giving every student the meal they chose.
   2. Goal: bring discarded meals from 70 down to under 20 a day within one term, with the hot option still available at the second sitting on at least four days in five.
6. Input specifications
   1. Student ID as an integer, meal choice as one of four categories, order timestamp, and a dietary flag as a Boolean.
   2. One order per student per day, with a later submission overwriting the earlier one.
7. Output specifications
   1. A kitchen report at 09:30 listing the count of each meal category, on screen and printed.
   2. A confirmation message to each student, and an alert to the canteen manager if any category passes its prepared maximum.
8. Evaluation criteria
   1. Effectiveness: waste falls below 20 meals a day.
   2. Efficiency: the 09:30 report generates in under five seconds for 400 orders.
   3. Accuracy: the category counts in the report match the stored orders exactly.
   4. Usability: a student can place an order in under 30 seconds.
   5. Maintainability: adding a fifth meal category needs no change to the reporting code.

Answering a Specification Question in the Exam

1. B1.1.1’s command term is Construct, so the marks are for writing a specification, not for describing what one is.
2. Answer inside the scenario in the stem, naming the organisation, its data and its figures, because a specification that would fit any school earns nothing.
3. Give each element one sentence a client could sign, and make every figure in a goal traceable to a figure in the problem statement.