Example Project

About this worked example

This page follows one project, Canteen Pre-Order, from the first idea to the final evaluation. Sam is a Year 8 student. Sam builds a way for students to order lunch before first break and collect it at lunch.

Every focus area in this course moves through the same four stages. The table shows what Sam made in each one.

Read the example as a model, not a template. For each piece, ask: could someone who was not there use it to check or repeat the work?

Stage 1: Identifying and defining

Before anyone writes code, a project needs a clear problem. In this stage Sam writes the problem down, breaks it into parts, names the people it affects and turns wishes into rules that can be tested.

The problem statement

A problem statement says who has a problem, what goes wrong and what a solution must let them do. It does not describe the solution. Sam’s statement reads:

Notice that Sam did not write “build an app”. A paper system or a better stock sheet might solve the problem too. Choosing between options is part of the project.

Breaking the problem into parts

Decomposition means breaking a big problem into smaller parts. Each part is easier to build and test on its own. Sam’s project has four parts:

• Order screen. Students see the menu and choose a quantity for each item.
• Price calculator. Works out each line, takes off any discount and gives the total.
• Order checker. Looks at each number and gives a friendly message if something is wrong.
• Pick-up list. Shows canteen staff each order and its pick-up code, sorted by pick-up time.

Users and stakeholders

A user uses the system. A stakeholder is anyone the system affects, even if they never touch it. Sam listed both kinds of people.

Functional and non-functional requirements

A functional requirement says what the system must do. A non-functional requirement says how well it must do it, such as how fast, how easy or how safe. Each requirement must be something you can check.

Three use cases

A use case describes one thing a user wants to do, and the steps that follow. Sam wrote three.

Test cases

A test case gives an input and the output you expect from it. Write the expected output before you run the test. That way you cannot change the expected answer to match a result you did not want. Sam wrote eight test cases. The lab in stage 3 runs the same eight.

Stage 2: Researching and planning

In this stage Sam looks at options, chooses one and plans the work. Good planning uses evidence: what canteen staff said, what the menu costs and what a student can do on a phone.

Two alternative designs

A design is one possible way to solve the problem. Sam wrote two alternatives, each in the same format, so they could be compared fairly.

• Design A: paper order slips. Students fill in a slip at roll call, with items and quantities. Staff add up the slips by hand from a price list.
• Design B: an online order form. Students fill in a web page on a phone or laptop. The page works out the total and checks each number as it is typed. It also gives the canteen a list it can print.

Both designs could work. The real question is which one works better for the people who matter most.

Choosing with a weighted decision table

A weighted decision table scores each design against several criteria. Some criteria matter more than others, so each one gets a weight. Sam followed four steps:

1. List the criteria, in plain words.
2. Give each criterion a weight from 1 (least important) to 3 (most important).
3. Score each design from 1 (poor) to 5 (very good).
4. Multiply each score by its weight, then add up the results for each design.

Design B scored 39 out of 50, and design A scored 29, so Sam chose design B. Design B takes longer to build, so Sam will also keep paper slips as a backup for students who cannot use a phone. The scores are Sam’s own judgement, not measured results. The canteen manager should check them before the choice is final.

Privacy and safety decisions

Privacy means collecting only what is needed, and keeping it safe. Sam made these decisions before building anything:

• First names only. Students type a first name or nickname, never a surname. The pick-up list shows the first name and the pick-up code.
• No contact details. The form never asks for a phone number, an email address, a home address or a birthday.
• No payments. The project does not handle money or card details. How students pay stays the same as it is now.
• No health information. The form does not ask about allergies. A student with an allergy talks to the canteen manager directly, as now.
• Short-lived lists. The pick-up list is used on the day, then deleted or shredded after lunch.
• No logins. The prototype has no login and stores no passwords. If a login were ever added, the school’s IT team would need to approve it first.

A simple task plan

A task plan shows what needs doing, in what order and by when. Sam planned six weeks, with a check at the end of each week.

Data to collect and who owns it

Data is any information a project uses or collects. Every set of data needs an owner: the person who decides who can see it, how it is kept and when it is deleted.

Stage 3: Producing and implementing

Now the project gets built. Sam designed the screen and the rules first, then wrote code that follows them. The code is short on purpose, so you can run it in your head before you trust it.

The wireframe, in words

A wireframe is a plan of a screen. It shows where things go, without colours or the final look. Sam’s order screen, described in words:

• A title at the top: “Canteen pre-order”.
• One row for each of the five menu items, with the name, the price and a box for the quantity.
• A total line under the list, which changes as the quantities change.
• A message area under the total, for friendly messages.
• A large Place order button at the bottom, easy to tap with a thumb.

The flowchart

A flowchart shows the steps and decisions in order. Sam used ovals for START and END, rectangles for steps, parallelograms for input and output, and diamonds for decisions. Every diamond has a Yes exit and a No exit, and each exit is labelled.

The price calculator (Python)

The price calculator works out the total. Sam keeps money in cents, so $4.50 is stored as 450. Whole numbers are exact. Decimal numbers can round in odd ways on a computer: in Python, 0.1 + 0.2 gives 0.30000000000000004.

The code below is the version after the fix in stage 4, which uses > (more than) rather than >= (at least).

# MENU holds prices in cents: 450 means $4.50
MENU = {"Meat pie": 450, "Veggie wrap": 600, "Fruit cup": 350,
        "Bottled water": 250, "Muesli bar": 200}
def order_total(order):
    # order is a dictionary: item name -> quantity
    total = 0                               # running subtotal, in cents
    for item, qty in order.items():
        total = total + MENU[item] * qty    # one line: price x quantity
    # The rule: $1.00 off only when the subtotal is MORE than $10.00
    if total > 1000:
        total = total - 100
    return total

print(order_total({"Meat pie": 2, "Bottled water": 1}))  # prints 1050, which is $10.50

Try it by hand. The order has two Meat pies (2 × 450 = 900) and one Bottled water (250). The subtotal is 1150 cents. That is more than 1000, so 100 comes off. The answer is 1050 cents, which is $10.50.

Checking an order (Python)

The order checker runs before a total is shown. It returns a list of friendly messages. An empty list means the order is fine, and the screen shows the same messages that the code returns.

def check_order(order):
    # Returns a list of messages. An empty list means the order is valid.
    problems = []
    for item, qty in order.items():
        if item not in MENU:
            problems.append(item + " is not on the menu.")
        elif type(qty) is not int or qty < 0 or qty > 10:
            problems.append(item + ": pick a whole number from 0 to 10.")
    if not problems and sum(order.values()) == 0:
        problems.append("Choose at least one item.")
    return problems

Try it by hand. With {"Meat pie": 11} the list holds one message, so the order is refused. With {"Meat pie": 0} nothing is wrong with the numbers, but the sum is 0, so the list holds “Choose at least one item.”. The last check only runs when nothing else is wrong, so a student never gets two messages for one mistake.

A tiny order form (HTML)

A form collects input from the user. Each box has a label that says what it is for. This form asks for a first name and a quantity for one item. The min and max settings tell the browser the allowed range, but the checker above still runs, because one setting in one place is not a full check.

<form>
  <label for="first-name">First name (not your surname)</label>
  <input id="first-name" type="text" maxlength="20" required>

  <label for="pie-qty">Meat pie (0 to 10)</label>
  <input id="pie-qty" type="number" min="0" max="10" step="1" value="0">

  <button type="submit">Place order</button>
</form>

A calculator you can try

The tool below uses the same price rule and the same messages as the Python code. Change the quantities, then run the eight tests from stage 1. Try to break it: what happens with 2.5, with 11 or with a blank box? A blank box counts as 0. The tool sends nothing anywhere and keeps nothing, so the Place order button in the wireframe is not part of it.

Project record and journal

Sam keeps a project record: a short summary of what the project is and who owns each part. Each week Sam adds a dated journal entry. A journal says what was done, what went wrong and what happens next.

Week 1 · Friday 18 September 2026

Met the canteen manager for twenty minutes and wrote the problem statement. Noor read it and asked who the “users” were, so I added a user table. Wrote the eight test cases before writing any code.

Week 2 · Friday 25 September 2026

Compared two designs and scored them. Design B scored 39 and design A scored 29. Wrote the privacy list: first names only, no payments and no health information. The canteen manager gave me the menu prices in writing, so the price list is checked against a source.

Week 3 · Friday 2 October 2026

Built the price calculator and the order checks. For the test order the calculator printed 1050, as I expected. I ran all eight tests and seven passed. T3 failed: an order of exactly $10.00 came out as $9.00. I had written the rule as “at least $10.00” by mistake. I have not fixed it yet, and next week I will fix it and keep both results.

Stage 4: Testing and evaluating

Testing asks whether the product does what the requirements say. Evaluating asks whether it is good enough, and what would make it better. Sam tested first, then judged the project against the requirements, then thought about its wider effects.

Test results: one failure and its fix

Sam ran the eight tests from stage 1 twice. The first run used the rule “at least $10.00”. The second run used the correct rule, “more than $10.00”. The table compares each result with the expected output.

The fix. Sam changed one symbol in the price rule. The line if total >= 1000: became if total > 1000:. T3 then gave $10.00, and all eight tests passed. Sam ran them again and kept both runs in the record.

Peer feedback

Noor, a classmate, tried the order form on her phone and read the problem statement. She gave three notes, and Sam replied to each one.

• Noor said, “The message was tiny and under the total, so I missed it.” Sam replied, “I moved the message above the total and made it a clearer colour.”
• Noor said, “I thought the $1.00 off applied to every order.” Sam replied, “The rule only applies over $10.00. I added a line on the screen that says so.”
• Noor said, “On the pick-up list I could not tell which code was mine.” Sam replied, “The list now shows the first name next to each code. I did not add surnames.”

Evaluation against the requirements

To evaluate is to judge against criteria. Sam checked each requirement from stage 1, gave a judgement and pointed to the evidence.

Overall judgement. The calculator and the order form meet most of the requirements. The project is not finished, because the pick-up list does not exist yet. Sam would offer the system to the canteen manager as a trial, not as a finished service.

Social, ethical and cybersecurity review

A system affects people, not only computers. Sam asked three questions about the project.

What comes next

A good project ends with a plan, not just a finish line. Sam’s next steps, in order:

1. Build the pick-up list and test it during a short trial at lunch.
2. Ask Noor and four other classmates to place orders while Sam watches. Write down every problem they have.
3. Check the price rules with the canteen manager. Do they match what the canteen really does?
4. Write a one-page guide for staff, and a short privacy note for students.
5. Decide whether the paper backup is still needed after the trial.