Example Enterprise Project

Meet Canteen Insights

Start here A fictional Year 12 project, followed from problem to evaluation

Canteen Insights is a sales and stock dashboard for a school canteen. The canteen manager, Sandra, wants to see what sells, when it sells and what to reorder, so that popular items stop running out and fresh food stops being thrown away. Jordan, a Year 12 student, builds it as an HSC enterprise project.

How this page is organised

NESA describes the design and production process in four stages. This page follows them in order, and each stage shows the real artefacts a marker or client would expect to see, not a description of them.

The syllabus explanations live in the Enterprise project notes, and the management techniques are explained in the Project Management Guide. This page is the worked example that sits between them. Diagram notation follows NESA’s Enterprise Computing Course Specifications (© NESA), redrawn for these notes; the official document is on NESA’s website ↗.

The Client and the Problem

Artefact Client profile and problem definition

The client and the setting

Sandra manages the canteen at the fictional Kestrel Ridge High School. She works with a small team of paid staff and parent volunteers, serving about the same set of twelve items every day. Sales are rung up on a till that can export a weekly file of what was sold. Orders to suppliers are placed on Fridays, and fresh food such as pies and rolls is prepared each morning.

At the moment Sandra decides how much to order and prepare from memory and a paper stock sheet that is counted by hand on Friday afternoons. The till export is filed and never looked at.

Problem statement

A good problem statement names who has the problem, what is going wrong and what a solution must let them do, without describing the solution. Jordan deliberately did not write “build a dashboard”: a spreadsheet, a printed report or a better paper stock sheet might have solved it too, and choosing between them is part of the project.

Success criteria

Success criteria turn the problem into something that can be checked at the end. Jordan and Sandra agreed these four, and the evaluation comes back to each one.

Stakeholders

A stakeholder is anyone affected by the system. Sandra is the client and the main user. Canteen staff and volunteers count stock and would enter corrections. Students are affected indirectly by what the canteen stocks, but never use the system. The school leadership cares about food waste and cost, and the supplier receives Sandra’s orders. Jordan is the developer, and Priya, another student, agreed to act as a beta tester.

Requirements and Constraints

Artefact Functional and non-functional requirements, with constraints

Requirements say what the system must do or be. Functional requirements describe behaviour, such as calculating waste. Non-functional requirements describe qualities, such as speed, accessibility or privacy. Each has a priority (Must, Should, Could) and, importantly, a way of being tested, shown in the last column.

Constraints

A constraint is a limit the project has to live with. Unlike a requirement it is not negotiable by adding effort.

Time and Resources: the Gantt Chart

Artefact Gantt chart with resources and percentage complete; weekly action plan

Jordan broke the six weeks into four phases that follow NESA’s stages, gave every task a self-explanatory name, an owner and a duration, marked the dependencies and put a milestone at the end of each phase. The chart below is the version at the end of Wednesday 29 July 2026, when the plan was updated with actual progress, as NESA asks (“charts should be regularly updated during development to reflect actual versus estimated times”).

Reading the plan

The plan is a time and resource management tool because it answers four questions at a glance: what has to happen, in what order, who is doing it and whether the project is on track. At the status date, Phase 3 is 54% complete: the two finished tasks (2 and 3 days long), the half-finished filters task (4 days at 50%) and the unstarted reorder task add up to 7 of 13 working days. Phase 3 was expected to be further ahead, so Jordan did three things that day: recorded the reason in the process diary, moved the optional “export chart as an image” feature into a “Could” list, and used the spare Friday as a buffer.

Time/task action plan for the week

The Gantt chart shows the whole project. A time/task action plan zooms in on the next few days, so nothing depends on memory. This is Jordan’s plan for the week beginning Monday 27 July.

Social, Ethical and Legal Considerations

Artefact Impact review: privacy, fairness, health, accessibility and data retention

Before building anything Jordan asked, for each stakeholder, who could be helped and who could be harmed. The review is short, and each finding changed the design.

Notice the pattern: each row ends with a design decision. A social or legal review that produces only a list of worries has not done its job. The most effective privacy control here is not a rule, it is not collecting the data in the first place.

Interviews, Surveys and Prototypes

Artefact Research summaries, analytical report extract, prototype log

Jordan used more than one research tool, because each answers a different question. Interviews give depth, surveys give breadth, an analytical report of existing data gives evidence, and prototypes test ideas cheaply.

Interview with the client

A structured interview asks the same planned questions in the same order and records the answers. Jordan interviewed Sandra on Monday 6 July for 30 minutes, with open questions that invited stories rather than yes or no answers.

Surveys

A survey collects the same answers from many people, so results can be counted. Jordan ran two short paper-and-form surveys on Tuesday 7 July and Wednesday 8 July: one of students (to test how common sell-outs are from the customer’s side) and one of canteen staff and volunteers (to find out how fresh-food quantities are decided today). Both were anonymous.

Sample question: “This term, how often have you found the item you wanted sold out at the canteen?” with fixed choices, so answers can be counted. A poor version, “Do you like the canteen?”, would not have led to any decision.

Read the results critically. Nearly four in five students have met a sell-out at least sometimes, which supports the problem. But a sample of 64 students who chose to answer may not represent the school, and “shorter queues” came first, so a dashboard cannot claim to fix everything students want. Jordan wrote that limitation into the report below.

Analytical report from existing data

The most convincing evidence was already in the till export. Jordan loaded eight weeks of it into a spreadsheet and summarised what it showed. This is an extract from the report.

Presenting the research

Jordan presented these results to Sandra and three volunteers in a ten-minute session using five slides. The aim of a presentation of research results is agreement on what to build, so each slide carried one message and one chart or table.

Prototypes

A prototype is a trial version built to test an idea before the full system exists. Jordan built four, each answering one question and each cheaper than the mistake it prevented.

Modelling the System: DFDs and the System Flowchart

Artefact Level 0 and Level 1 data flow diagrams, system flowchart, informatics table

Jordan drew three models. The data flow diagrams show what data moves, the system flowchart shows which devices and processes carry it, and a table of informatics names the participants, data and components. All use NESA’s notation.

Level 0 data flow diagram

The Level 0 diagram (or context diagram) shows the whole system as one process, with every external entity and no data stores. It is the picture Sandra checked first, because she could see what goes in and what comes out without any technical detail.

Level 1 data flow diagram

Level 1 opens the circle: four processes, each a job the system does, and two data stores. The data stores are the database tables from the schema. Every Level 0 flow appears here again with the same label, which is how you check the two levels balance.

System flowchart

A system flowchart shows the main processes and devices, and the arrows show the direction of data. It answers a different question from the DFD: what hardware and storage does the system touch? This one uses eight of NESA’s nine symbols; nothing in Canteen Insights needs magnetic tape.

Informatics: participants, data and components

Informatics is the science of processing data for storage and retrieval. To clarify each of the relevant informatics in the new system, Jordan listed who takes part, what data exist, and which components handle them at each step.

Reorder Rules: the Decision Tree

Artefact Decision tree that the dashboard runs

The rules for reordering had to be ones Sandra understood and could challenge, so Jordan drew them as a decision tree before writing any code. A decision tree represents all possible combinations of decisions and their resulting actions, and every path ends in a final action.

The tree is the code

This diagram is not a picture of the rules. It is the rules. The function that decides the action in the dashboard’s code has one branch for each path, in the same order:

function decide(perishable, wastePct, daysCover) {
  if (perishable) return wastePct > 10 ? 'forecast' : 'buffer';
  if (daysCover < 3) return 'now';
  if (daysCover < 5) return 'soon';
  return 'hold';
}

Two other parts of the reorder list follow from the tree. The forecast is the average units sold per day over the last ten trading days, times five days. Order forecast + 10% adds a buffer so fresh items do not sell out, and Order to forecast leaves the buffer off where waste is high. Reorder now and Reorder soon order enough for five days of sales plus a 20% buffer, less what is on hand. In the dashboard, the list shows which rule each suggestion used, so Sandra can disagree with a specific step.

Data Design: the Dictionary and the Schema

Artefact Data dictionary and schema

Data dictionary

A data dictionary describes every field: its name, type, format, size, meaning and an example. Formats use NESA’s notation: X is any character, N is a digit and # is a numeric digit. Jordan wrote one for each of the three tables so anyone importing data knows exactly what will be accepted.

Schema

The schema shows the structure: which tables exist, which field is each table’s primary key, and how tables are linked. Jordan normalised the data: an item’s name, price and category are stored once in Items, not repeated in each of the 480 sales rows. If a price changes, one row changes, and the data cannot contradict themselves.

Screen Design: the Storyboard

Artefact Storyboard and the design decisions behind it

A storyboard shows each screen and how the user moves between them. Jordan drew four and took them to Sandra on Thursday 16 July. Designing for ease of operation meant asking of every screen: could Sandra use this on a busy Friday, with one hand and no manual?

Design decisions

The last row shows why a design is not finished when it is approved. Prototype P3 showed a better layout than the storyboard. Jordan updated the design and recorded the change, rather than building something that no longer matched the plan.

Computational, Design and Systems Thinking

Artefact Three ways of thinking, applied to the project

The syllabus asks how three kinds of thinking help in designing and developing a system. Jordan used all three, at different moments, on the same problem.

Notice that the three are not competing methods. Systems thinking shows where the problem sits, design thinking keeps the project close to the people it serves, and computational thinking gets the solution into a form a computer can run.

Working with the Client: Collaboration and Negotiation

Artefact Collaboration set-up, needs versus wants, and the way of working

Online collaboration

Jordan, Sandra and Priya used ordinary tools rather than a purpose-built project system. Files lived in a shared school folder with version history, so any earlier copy could be recovered. Sandra sent each week’s till export to Jordan through the school email system. A single feedback log, a shared document with the date, who said it, what changed and its status, meant nothing said in a hallway was lost.

Negotiating needs and wants

Clients often ask for more than the time allows. Jordan sorted Sandra’s requests into needs and wants and negotiated the boundary using the priorities from the requirements.

Criteria for working collaboratively

Jordan chose collaborating and managing criteria at the start, so behaviour could be judged against something later.

Choosing a Development Approach

Artefact Approach comparison and justification

Jordan compared NESA’s five approaches against the project’s facts: unclear requirements at the start, one developer, a client who is available in short bursts, no money and a fixed end date.

Decision: prototyping, run as an iterative approach with a short cycle each week: build, show Sandra, record feedback, adjust. Two features of the project made the choice: the requirements were uncertain, and changing a prototype was far cheaper than changing a finished system. The risk of prototyping is that it never ends. Jordan controlled it with the Gantt chart and by fixing the Must items first.

The changing nature of enterprise

Some features of this project reflect how enterprise projects are now run, and some show what it would look like if they were run another way.

Budget

Artefact Project budget with spreadsheet formulas

A budget lists what a project will cost and where the money comes from. Canteen Insights needs almost no cash, but Jordan still built one, because a project that has not counted its costs cannot say whether it was worth doing. Time is shown separately, as a notional cost, because Jordan is not being paid.

Comparing cost and benefit

In the eight sample weeks, the waste cost $2,151.60 at cost price. If the reorder list helped the canteen cut that by a quarter, the saving would be about $537.90 every eight weeks (=0.25*2151.60), which is more than the whole cash budget. That is an estimate, not a promise: it assumes the waste can be reduced without causing more sell-outs. It is one measure that the evaluation checks.

The Live Dashboard

Artefact A working solution you can use in the browser

This is Canteen Insights. It runs entirely in your browser, on 480 generated sales records: eight weeks (Monday 4 May to Friday 26 June 2026) of twelve items in five categories. Nothing you do is sent anywhere or stored. The data were made by a seeded random-number program with built-in patterns, such as busy Fridays, a sports carnival on Wednesday of week 5 and some wet days, so they are the same every time you load the page.

How the dashboard meets the requirements

Built to be used by everyone

• Keyboard: every control can be reached with Tab. The bars are buttons, and in the line chart the left and right arrow keys, Home and End read each day.
• Text alternatives: each chart has a text summary, and both charts have a table view (the daily figures table and the data table).
• Colour is never alone: the reorder actions are words, and selected bars are labelled as well as coloured.
• Themes and motion: it follows the light and dark themes of these notes, and any movement is switched off when your device asks for reduced motion.
• Phones: the layout is single-column at phone width, and tables scroll inside their own frame.

The dashboard’s code is one file, js/pages/example-project.js, in two halves: an engine of plain functions (the data, the calculations, the reorder rules and the checks on typed data) and the code that draws it. Keeping calculation and drawing apart is what let Jordan test the numbers without looking at a screen. The test table runs those same functions.

SQL and Spreadsheet Formulas Behind the Numbers

Artefact Queries and formulas that produce the dashboard’s figures, checked live

Jordan’s test for “are the totals right?” was to get the same numbers by two other routes: a SQL query, and spreadsheet formulas. The queries use only the four keywords in NESA’s Course Specifications, SELECT, FROM, WHERE and ORDER BY, and tables are joined by matching key fields in the WHERE clause. Because those keywords select and sort rows but do not add them up, the totals come from adding a column of the result, exactly as you would in a spreadsheet.

Query A: one item, one week

“Show every sales row for meat pies in week 5, with the price.” The result has five rows (Monday to Friday). Adding Sold gives 215 pies, and Sold × UnitPrice gives $967.50.

SELECT DailySales.SaleDate, Items.ItemName, DailySales.Prepared, DailySales.Sold, DailySales.Wasted, Items.UnitPrice
FROM DailySales, Items
WHERE Items.ItemID = DailySales.ItemID
AND DailySales.SaleDate >= '01/06/2026'
AND DailySales.SaleDate <= '05/06/2026'
AND Items.ItemName = 'Meat pie'
ORDER BY DailySales.SaleDate ASC, Items.ItemName ASC

Checking in your browser…

Query B: a category over several weeks

“Show every drinks sale from week 3 to week 5.” This one joins three tables. Each extra table needs its own line of key equality in WHERE.

SELECT DailySales.SaleDate, Items.ItemName, DailySales.Prepared, DailySales.Sold, DailySales.Wasted, Items.UnitPrice
FROM DailySales, Items, Categories
WHERE Items.ItemID = DailySales.ItemID
AND Categories.CategoryID = Items.CategoryID
AND DailySales.SaleDate >= '18/05/2026'
AND DailySales.SaleDate <= '05/06/2026'
AND Categories.CategoryName = 'Drinks'
ORDER BY DailySales.SaleDate ASC, Items.ItemName ASC

Checking in your browser…

Query C: where is the waste?

“List the days on which ten or more units of a perishable item were thrown out, worst first.” The comparison operators and the sorted output do the analysis. Press the button to run this exact text in the browser and compare the count with a plain JavaScript filter over the same records.

SELECT DailySales.SaleDate, Items.ItemName, DailySales.Prepared, DailySales.Wasted
FROM DailySales, Items
WHERE Items.ItemID = DailySales.ItemID
AND Items.Perishable = 'Y'
AND DailySales.Wasted >= 10
ORDER BY DailySales.Wasted DESC, DailySales.SaleDate ASC

The same numbers in a spreadsheet

In a spreadsheet the sales rows go on a Sales sheet and the item list on an Items sheet. The formulas use only functions from NESA’s list: SUM, MAXIMUM, IF and LOOKUP. LOOKUP needs the ItemID column to be sorted ascending, which it is (I01 to I12). References to the Items sheet are absolute ($A$2:$A$13) so they stay fixed when the formula is filled down; references to the current row are relative.

Spreadsheet software names these functions differently (MAXIMUM is written MAX in most packages), so in the exam use NESA’s wording.

Live check: dashboard, SQL and spreadsheet

The panel below follows the dashboard’s filters. It rewrites the query for whatever you have selected, runs it with a small interpreter for NESA’s SQL, applies the spreadsheet formulas row by row, and compares all three. Because it reads the same data as the dashboard, it still agrees after you save a correction in the form above.

Implementation Plan

Artefact Implementation plan: method, integration, training, risks and testing

A system that works on the developer’s laptop is not yet a solution. An implementation plan says how it will move into the real setting and how Jordan will know it is feasible, meaning that it can actually be done with the time, skills and equipment available.

Design thinking and the tools used

Jordan followed a design-thinking cycle and used a tool at each step. Each is a section of this page.

Risk analysis

A risk is something that might go wrong. For each one Jordan estimated how likely it is and how much damage it would do (Low, Medium, High) and planned what to do about it.

Hardware and software integration

Canteen Insights uses equipment that already exists, so integration is mostly a weekly routine. On Friday the till exports the week’s file to the shared folder. On Monday morning Sandra (or a volunteer) opens the dashboard, imports the file and checks the message it shows. The laptop’s browser runs the dashboard, the printer produces the reorder list and the database is copied to the cloud backup. The system flowchart shows these links. The one integration risk, the export format, is covered in the table above.

Training and documentation

Preferred implementation method: pilot

NESA names four methods of implementation: direct, parallel, pilot and phased. Jordan chose a pilot. For two weeks only Sandra uses Canteen Insights, and only for hot food, sandwiches and fresh food, the three categories where the data show waste. Drinks and snacks stay on the paper stock sheet. Then the dashboard is extended to everything, and the volunteers start entering corrections.

Testing methodology

Jordan planned testing before the build ended. The next part covers it in detail, and the plan draws on the methods in the Course Specifications: functional testing against the requirements, live and simulated data (the sample data are simulated; the pilot uses live data), beta testing by Priya, and acceptance testing by Sandra.

Testing with Normal, Boundary and Erroneous Data

Artefact Test table that runs live in your browser

Testing checks whether a system does what it should, and a good test set does not just try things that work. Jordan chose data of three kinds for every input, because different faults hide in different places.

The test table

Each row gives the input, the expected result worked out before testing, and the actual result. Jordan worked the expected totals out in a spreadsheet, and wrote the expected messages from the rules in the requirements. In this table the Actual column is filled in by your browser, just now, by running the dashboard’s own functions on a fresh copy of the sample data; the Result column compares the two.

Running the tests…

The dashboard handles the erroneous cases, it does not just survive them. In the Correct a record form above, every rule in E1 to E8 produces a message that says what is wrong and how to fix it, marks the field, and saves nothing. Try the example buttons under the form. The filter cases (E9 to E11) never leave the dashboard in an impossible state: the item list follows the category, a reversed range is swapped with a notice, and an empty selection shows “n/a” and “No sales match these filters” instead of a blank or a divide-by-zero error.

Methods of testing

The Course Specifications name six methods of testing. Here is how Jordan used each one.

Verification and Validation

Artefact Requirements traceability: evidence of verification and validation

The two words are easy to confuse. Verification asks “did we build the system right?”, meaning does it meet its specification, and is checked by testing, inspection and comparison. Validation asks “did we build the right system?”, meaning does it meet the client’s real need, and is checked with the client and users. A system can pass every test and still be useless if the requirements were wrong.

Notice the gap in the accessibility row. Verification passed, but validation with real users who rely on assistive technology has not happened. Being honest about that gap is part of a good evaluation.

Client Feedback and Evaluation

Artefact Client feedback, evaluation against the success criteria and the impact of the system

Client feedback

Sandra worked through the dashboard on the canteen laptop on Wednesday 12 August, with Jordan watching and saying nothing. These are her words, recorded in the feedback log.

Evaluation against the success criteria

An evaluation makes a judgement against criteria set at the start, with evidence, and does not just say “it went well”.

Limitations

• The till records what was sold, not what customers wanted. On the days pies sold out, demand is understated, so the forecast for pies is probably too low.
• The what-if panel uses assumed price sensitivities. They came from interviews and are not measured, so its projections show direction, not exact amounts.
• Only eight weeks of data and a single canteen. Seasonal effects, such as cold weather and end-of-term days, are not modelled.
• The import is manual, so a busy week without an import leaves the dashboard out of date.
• Accessibility was tested in two browsers and by keyboard, not with screen-reader users.

Impact of the system on its environments

An enterprise system does not only work or fail technically. It changes the places it is used in.

Modifying the design

Feedback led to three changes, each written up in the process diary and the change log: the four screens were merged into one page (P3), the what-if panel now shows waste as well as revenue (P4), and the evaluation now states that sold-out days hide real demand. The next version would add a column for “sold out before closing” to the till import, so the system can see lost sales.

Maintaining the System

Artefact Maintenance plan and documentation trial

Systems are used for far longer than they are built. Maintenance is the work of keeping a system correct and useful once it is live. Jordan wrote a plan so that Sandra, or someone after Jordan, could look after Canteen Insights without guesswork.

Trialling the documentation

Documentation is only useful if someone else can follow it. Jordan gave Priya the maintenance guide and asked her to add a new item, an iced tea, with no help. This is the extract she followed.

1. Open the Items table and add a new row at the bottom.
2. Give it the next ItemID in order, for example I13, using the format XNN.
3. Enter the name, choose its CategoryID from the Categories table, and enter the price and cost in dollars.
4. Enter Y for Perishable if unsold units are thrown out, otherwise N, and enter the units on hand.
5. Check the dashboard: the item appears in the item list, and the three-way check still agrees.

Priya stopped at step 3 because it was not clear whether the cost meant the cost of one item or a box. Jordan rewrote the step to say “cost of one item, for example $0.80”, and the change is in the log. Trials find problems that the author never sees, which is why NESA lists trialling the operation and maintenance documentation as part of verifying a system.

Version log

Process Diary Excerpt

Artefact Two entries from the process diary

A process diary documents the progress of a project. NESA lists what each entry should include: the date, the person making the entry, progress since the last entry, tasks achieved, stumbling blocks and how they were managed, possible approaches for upcoming tasks, reflective comments and resources used. Here are two of Jordan’s entries (fictional).

Notice that the second entry connects to the Gantt chart, the test table and the version log. A diary earns its place because it is the link between the plan, the problems and the decisions. This is what NESA means by ongoing evaluation: judging progress as it happens, not only at the end.

How This Maps to the Syllabus

Finish Each dot point in the Enterprise project focus area, and where this page shows it

The Enterprise project focus area has nine dot points. This table lists each one (NESA’s wording) with a link to the explanation in the Enterprise project notes, and links to the places in this page that demonstrate it. Use it as a checklist for your own project: could you point to an artefact for each row?