One running scenario that ties Modules 1, 2 and 3 together: a real Data Flow Diagram, a working relational database, a small website, and a written discussion of the wider impact — the same four deliverables you'll be assessed on across the unit.
The Scenario
Sweet Escape Bakery & Café is a small neighbourhood business that currently takes orders on paper tickets and tracks stock in a notebook. Mistakes happen: illegible handwriting causes wrong orders, nobody notices when cocoa or flour is running low until it's too late, and the owner has no easy way to see which pastries actually sell best. She has asked you — her IT-savvy customer — to design a proper information system for her shop.
Stage 1 — Model the Current System MODULE 1 · DFD
Before building anything, capture how information currently flows through the bakery.
Draw a context-level DFD showing Sweet Escape as a single process, with Customer, Supplier and Owner as external entities.
Draw a Level 1 detailed DFD breaking that process into at least three sub-processes (e.g. Take Order, Update Stock, Generate Report), with proper data stores for Orders, Inventory and Customers.
Check your diagram for the common errors covered in the DFD lesson: black holes, miracles, unlabelled flows, and processes/flows labelled with the wrong word class.
Deliverable: one context diagram + one Level 1 diagram, each entity/process/store/flow correctly symbolised and labelled.
Turn your Orders, Inventory and Customers data stores into a normalised relational database.
Start from one flat, messy order sheet (customer name, phone, item, quantity, unit price all in one table) and apply 1NF, 2NF and 3NF to remove redundancy and anomalies.
Identify a primary key for each resulting table (a composite key where needed), and the foreign keys that link them.
Draw an ERD showing Customer, Order and Product as separate entities, connected by the relationships you identified.
Build the database for real: create the tables, enforce referential integrity, add at least one data-entry form, one query and one report.
Deliverable: a working database file (e.g. LibreOffice Base) with normalised tables, an ERD diagram, one form, one query, one report.
Stage 3 — Build the Customer-Facing Website MODULE 2 · WEB PAGES
Give Sweet Escape a simple web presence that reflects what your database now manages.
Construct a basic multi-page site in HTML: a home page, a menu page, and a contact/order-enquiry page with a form.
Use appropriate formatting tags (headings, lists, tables) and at least one form element that could, in principle, validate input on the client side.
Justify your choice of IT tools (word processor vs. web authoring tool vs. hand-written HTML) against the selection criteria from Module 2: nature of the solution, type of analysis, type of data, and so on.
Deliverable: a short, working HTML site (3+ pages) plus a one-paragraph justification of your tool choices.
Stage 4 — Discuss the Wider Impact MODULE 3 · WRITTEN DISCUSSION
Step back from the technical build and discuss what this system means for the bakery and its people.
Identify at least two security, health/safety, or environmental risks the new system introduces (e.g. customer data theft, eye strain for staff, e-waste from old registers) and one mitigation strategy for each.
Discuss one legal/ethical consideration — for example, how customer data should be protected, or licensing terms for any software used.
Reflect on how automating order-taking might change staff routines, and one way the bakery could manage that change well.
Deliverable: a 600–700 word written discussion (excluding diagrams/tables), matching the Unit 2 SBA report length.
ERD with correctly identified primary/foreign/composite keys
Working database: tables, one form, one query, one report
3+ page HTML website with a form element
600–700 word written discussion of risks, ethics and impact
Purpose & Syllabus Mapping
This project is designed as an integrated practice run for the Unit 2 School-Based Assessment, not a replacement for it. It deliberately touches every Specific Objective a Unit 2 SBA project could draw on, so students rehearse the full workflow — model, design, build, present, reflect — before doing it independently for their own chosen problem.
Obj. 1–5, 10 (tool selection, form-enabled web pages)
Written discussion
Module 3
Obj. 3–6 (risks, threats, mitigation), and ethical/legal considerations
Suggested Timeline (4 sessions)
SESSION 1
Scenario walk-through; draft context & Level 1 DFDs in pairs; peer review against the common-error checklist.
SESSION 2
Normalisation walkthrough on the board using the flat order sheet; students build their own ERD and construct the database.
SESSION 3
Web page construction lab; review tool-selection justifications as a short class discussion.
SESSION 4
Draft the written discussion in class with teacher guidance; peer-review a partner's draft before final submission.
Marking Guide Notes
DFDs (20%): correct symbol use, at least 3 processes at Level 1, no black holes/miracles, consistent notation style throughout.
Database (35%): demonstrable progression through 1NF–3NF (not just a final answer), correctly identified keys, referential integrity enforced, at least one form/query/report each functioning correctly.
Website (20%): valid, working HTML across 3+ pages; a genuine form element; a reasoned (not just asserted) tool-choice justification.
Written discussion (25%): at least two distinct risk categories with named mitigation strategies, one clearly explained ethical/legal point, word count within 600–700 (excluding diagrams/tables/bibliography), as per the syllabus's Unit 2 SBA guidance.
Sample Answer Key: The Flat Order Sheet to Normalise
Give students this single messy table as the Stage 2 starting point (deliberately violates 1NF, 2NF and 3NF):
OrderID
CustomerName
CustomerPhone
Items
UnitPrice
O001
A. Ramkissoon
555-0142
Cocoa Bread, Sponge Cake
17, 34
O002
A. Ramkissoon
555-0142
Sponge Cake
34
Expect students to split repeating groups (1NF) into one row per item, separate Customer into its own table keyed on CustomerID to remove the partial/transitive dependency on the phone number (2NF/3NF), and end with Customer, Order and OrderLine tables linked by foreign keys — mirroring the worked Bayview-style examples used elsewhere in this course.