4.14.3.1, 4.14.5.1 - Project analysis and measurable objectives

The problem, background and recipients

Analysis should let a third party understand the specific problem and who needs its solution or investigative findings.

“Create a booking program” does not explain the difficulty. For a fictional rehearsal studio, a useful problem statement is: staff cannot reliably detect overlapping room bookings because requests arrive through several paper diaries. The intended users are reception staff; performers need accurate confirmations. Relevant background includes room capacities, opening hours, booking duration and the current process for cancellations. The description should make sense to a reader who has never visited the studio.

Identify the problem area and the specific problem within it. Room scheduling is the area; preventing overlaps while handling changes is the specific problem. State what is included and excluded. A small booking project might include rooms, time slots and cancellations, while excluding payment processing. Exclusions must be justified by the agreed scope, rather than used to hide an essential requirement.

For an investigation, identify the recipients of the findings and the precise question. “Investigate whether two routing strategies produce shorter journeys on a stated type of network” is more useful than “investigate algorithms”. Define the conditions and output needed to answer that question. In either type of project, analysis explains the real need before selecting attractive software features.

Research and dialogue

Requirements should arise from evidence and dialogue with the people who will use the solution or receive the findings.

Select research methods that answer relevant questions: observe bookings being made, discuss edge cases with reception staff, examine anonymised example diaries and consult reliable subject information. Record what was examined and what was learned. A long bibliography without an explanation of its contribution does not establish that the problem was understood.

Dialogue is more than collecting a signature. Ask whether a booking ending at 14:00 can be followed immediately by one beginning at 14:00, whether setup time is needed, and who may override a conflict. Confirm interpretations and resolve differences. Do not invent interviews or feedback. If access to a user is limited, explain that limitation to the supervising teacher rather than fabricating evidence.

For an investigative project, discuss what the recipients need from the findings: relevant measurements, input sizes, assumptions or presentation. Then document how that dialogue influenced the scope. Research can continue during prototyping; if evidence changes a requirement, record the reason and update the objectives and model.

Single-purpose measurable objectives

An objective must be precise enough for a reader to determine what is in scope and later decide whether it has been achieved.

“The system must be good and quick” hides several possible meanings. Replace it with numbered objectives that cover every agreed function or area of investigation. For example:

1. Reject a proposed booking if its interval overlaps an existing active booking for the same room.
2. Permit a receptionist to cancel an active booking and make that interval available for another booking.
3. Display the bookings for a selected room and day within two seconds on the studio computer with 10,000 stored bookings.

The first objective has a precise behavioural test even without a numeric threshold: a conflict must be rejected. The third states a performance threshold and conditions. Clarify the meaning of “overlap”, perhaps by agreeing that intervals include their start but exclude their end. Without that rule, adjacent bookings are ambiguous.

Keep each objective single purpose. “Add customers, print reports and be secure” should be separated into specific behaviours and constraints. Avoid prescribing implementation without a reason: “use a linked list” is not normally a user need. If the problem genuinely requires a particular platform or library, state it as a justified constraint. Numbering lets design decisions, tests and evaluation cite the same objective reliably.

Check completeness as well as precision. Three perfectly written objectives can still omit cancellation, permissions or a vital investigative condition. Trace each user need to an objective, and each objective back to a need. Resolve gaps before treating the list as complete.

Modelling a fully scoped problem

A useful analysis model retains the entities, relationships, states or constraints that the design will need.

The studio model could contain Room, Customer and Booking, with a Booking linking one customer to one room over a start and end time. Include active/cancelled status because cancellation affects availability. A data dictionary explains identifiers, time units, valid ranges and constraints. For a route investigation, a graph might represent locations as vertices and journeys as weighted edges. Choose a model appropriate to the problem; an entity–relationship model is not compulsory for every project.

Explain the connection to later design. A BookingID distinguishes two bookings made by the same customer; separate start and end values support overlap checks. Retain necessary distinctions while omitting irrelevant personal details. A model that looks elaborate but cannot represent a required case is not sufficient.

In the formal analysis grid, Level 3 (7–9) describes a fully or nearly fully scoped real problem with measurable appropriate objectives, dialogue-derived requirements and useful modelling. Level 2 (4–6) allows some omissions that do not undermine later design; Level 1 (1–3) has partial scope, objectives, dialogue and modelling. These are descriptions of overall evidence quality, not a checklist awarding one mark for each heading. “Fully scoped” means relevant research, clear problem definition, no material omission for later stages, unambiguous objectives and modelling where possible and necessary.

Use that distinction to improve your own understanding: a reader should be able to move from the analysis to a sensible design without guessing what the problem means. The teacher applies the official grid to assessed work; the practice questions here use their own stated point credits.