Everything you need to design, plan, build, and evaluate your major project from scratch
The HSC Software Engineering Project is worth 30% of your school-based assessment. You build a software solution from scratch and document every step. The code matters — but so do the planning, design decisions, testing, and evaluation. You submit a folio, not just a working app.
NESA structures the work into four phases:
What are you building? Who needs it? What must it do? What data will it store?
How will you build it? Which methodology? What's the schedule?
Write the code. Design the UI. Use version control. Document algorithms.
Does it work? Run a test plan. Get feedback. Write an evaluation report.
How today works: We won't just talk about these phases — we'll start working through them for your actual project. Each section introduces a tool or concept, then you apply it to your own idea straight away. By the end of the lesson you should have the foundation of your Phase 1 documentation.
The best project is one you actually care about. It also needs to solve a real problem for a real person — even if that person is you. Work through these rounds to surface an idea. Don't filter yourself early — generate first, evaluate second.
Answer each question out loud or jot a few words. Quantity over quality right now.
Once something starts to form, run it through these five questions. If you can answer all of them, the idea is workable.
| # | Question | What a strong answer looks like |
|---|---|---|
| 1 | Who is it for? | A named person or specific group — not "everyone" or "people who like X" |
| 2 | What problem does it solve, and what's the current workaround? | You can describe what people do now without your app — a spreadsheet, a note, nothing at all |
| 3 | What data does it store? Can you name at least 3 distinct types of information? | e.g. users, [content], [relationship between them] — these become your classes |
| 4 | What would a user actually do in a typical session? | You can describe 3–4 actions without hesitation |
| 5 | Can you stay motivated on this for 10 weeks? | Genuine yes — not "I guess so" |
The project needs to be complex enough to demonstrate your Year 12 skills, but realistic enough to finish. Run your idea through this list:
| The project should have… | Why |
|---|---|
| At least 3 meaningful classes with real relationships | Needed for OOP design — class diagrams, inheritance, associations |
| User accounts with login and registration | Demonstrates Secure Software Architecture — authentication, hashing, sessions |
| Persistent data storage (a database) | Demonstrates back-end engineering, SQL, parameterised queries |
| A searchable, filterable, or sorted data view | Demonstrates algorithm design and data retrieval |
| Realistic scope for ~8 weeks of coding time | Your Gantt chart has to be honest — padding it doesn't help |
Too big: anything with real-time features, complex social interactions, or payment processing. Cut features until you have a tight, deliverable core.
Too small: a single-class app with no user accounts and no data relationships. If it's simple, add depth — user accounts, categories, search, admin panel.
Write this sentence for your project: "I am building [what] for [who] that solves [problem]."
It doesn't need to be final. But commit to a direction now — a vague idea that keeps shifting is the most common reason HSC projects fall behind. You'll refine it in the next section.
Phase 1 turns your idea into formal documentation — the kind that goes in your folio and shows the marker you understood the problem before you started coding. Each step below: brief explanation, then you apply it to your own project.
A needs statement is 2–4 sentences that justify why your software needs to exist. It names a specific user group, the problem they have, the current workaround (or absence of one), and the proposed solution. It is not a feature list.
Template: [Project name] addresses the problem that [who] currently have to [workaround or gap]. There is no existing tool that [what's missing]. The proposed solution will provide [your solution in one sentence].
Use the one-sentence idea from Section 2. Expand it using the template. A strong statement names a real frustration and a concrete gap. If you can't name the current workaround, the problem isn't defined sharply enough yet — go back and sharpen it.
Requirements are the formal list of what your software must do. There are two kinds:
| Type | What it describes | Write it as… |
|---|---|---|
| Functional | Observable behaviour — things the system does | "The system shall…" |
| Non-functional | Quality attributes — performance, security, usability | "The system should…" |
A good requirement is specific (what exactly?), testable (can you write a pass/fail test for it?), and achievable (can you build it in 8 weeks?).
"The app should be fast." → Non-functional. Fix: "The system should load the main dashboard within 1.5 seconds on a standard 4G connection."
"Users can do stuff with their account." → Functional. Fix: "The system shall allow users to register, log in with username and password, update their display name, and delete their account."
"The system should be secure." → Non-functional. Fix: "The system shall hash all passwords using bcrypt before storing them. All user input shall be validated and sanitised before any database interaction."
Use these prompts, then convert each answer into a formal statement:
After writing them, read each one back. Can you imagine a specific test that would produce a clear pass or fail? If not, it needs to be more specific.
NESA expects a brief feasibility study — two questions you need to answer honestly before committing to the project:
| Type | Question to answer |
|---|---|
| Scheduling | How many weeks do you have? Can the core features realistically be built and tested in that time? |
| Financial | What tools, hosting, or services does the project need? Are any of them paid? |
Two or three sentences each is enough. Be honest about time — if something sounds tight, it is. Scope it back before you start rather than halfway through.
Scope creep — adding features mid-project — is how HSC projects stall. Defining the boundary now means you have something to refer back to when you're tempted to add "just one more thing."
Explicitly listing exclusions matters as much as listing inclusions. Each out-of-scope item needs a brief reason so the marker can see it's a deliberate choice, not an oversight.
| In scope — must deliver | Out of scope — not in this version, because… |
|---|---|
| Feature 1 | Excluded feature — reason |
| Feature 2 | Excluded feature — reason |
| Feature 3 | Excluded feature — reason |
| Feature 4 | Excluded feature — reason |
A data dictionary formally defines every piece of data your system stores. It forces you to think about data structure before writing code — and directly feeds into your database schema and input validation logic.
Format: one row per field, five columns:
| Field Name | Data Type | Format / Range | Validation | Description |
|---|---|---|---|---|
| user_id | Integer | 1 – 99999 | Auto-increment, unique, not null | Primary key for user records |
| username | String | 3–30 chars | Not null, alphanumeric + underscores only, unique | Login identifier |
| password_hash | String | 60 chars (bcrypt output) | Not null, never returned in API response | bcrypt-hashed password |
| is_admin | Boolean | True / False | Not null, default False | Elevated access flag |
Notice how the Validation column maps directly to your security knowledge — the rules you apply here are the same input validation and sanitisation from Lessons 7–9.
Pick the central "content" entity in your project (not User — the thing your app is actually about). List at least 5 fields with types, ranges, and validation rules. Ask yourself: what would break if this data were missing, null, or malformed?
Design documentation turns your requirements into diagrams and structures that you can hand to a developer (yourself, in 2 weeks' time) and build from. Three tools you need: Data Flow Diagrams, class diagrams, and pseudocode.
A DFD shows how data moves through your system — not code logic, not screens. It answers: who gives what to which part of the system, and what comes back?
Four elements:
| Symbol | Name | What it represents |
|---|---|---|
| Rectangle | External entity | A person or system outside your app — User, Admin |
| Circle / oval | Process | Something your system does to data — Authenticate, Search |
| Open rectangle (two lines) | Data store | Persistent storage — User Database, Content Table |
| Labelled arrow | Data flow | Data moving between elements — "login credentials", "search results" |
A Level 0 diagram shows your entire system as one process bubble, surrounded by external entities and a database. It's the highest-level view — zoomed out as far as possible. Here's what one looks like:
Rule: Every arrow must be labelled with what data it carries — not "data" or "information", but the specific thing: "login credentials", "search query", "updated record".
You don't need to draw it perfectly yet — describe it in words first:
Write it as a list or a rough sketch on paper. Next session we'll formalise it into the proper diagram notation.
A UML class diagram is the formal notation for your OOP design. Each class is a box with three sections: name, attributes (- = private), methods (+ = public). Here's the format:
Start with a noun hunt: list every important "thing" in your system. Each noun that holds data and has behaviour is likely a class.
Fill this in for your project. User is already there — add the classes that are specific to what your app does.
| Class name | Key attributes (what data it holds) | Key methods (what it can do) |
|---|---|---|
| User | user_id, username, password_hash, is_admin | login(), logout(), is_authenticated() |
| Your main class… | … | … |
| Second class… | … | … |
| Link class (if needed)… | … | … |
Once you've filled this in, look at the relationships. Does any class store a reference to another (foreign key)? Does one class inherit from another? We'll draw the formal diagram next session.
Every major function in your project should be documented in pseudocode before you write the code. This goes in your folio and proves you designed the algorithm before implementing it.
Pseudocode is structured English with programming logic. It doesn't use a specific language — it's readable by anyone. Example:
FUNCTION search(query):
SET results = empty list
FOR each item IN database:
IF query is found in item.name (case-insensitive):
ADD item TO results
IF results is empty:
RETURN "No results found"
ELSE:
RETURN resultsThink about the core thing your app does — the action a user comes back for. Write the algorithm for it in pseudocode. If it involves a search, filter, or data lookup, that's a good candidate. If you're unsure which function to pick, write the login flow.
Phase 2 is about deciding how you'll build the thing. Three decisions to make: which development methodology, when you'll do what, and how you'll roll the app out to users.
You know Waterfall and Agile. There's a third option — WAgile — that's worth knowing for the HSC project specifically.
Which methodology suits your project? Write 2 sentences: the choice and why it fits — mention one advantage and one limitation of your chosen approach.
A Gantt chart maps tasks to time. At this stage you only need a phase-level view — which weeks are spent on Phase 1 planning, which on building, and which on testing. Here's the pattern most HSC projects follow:
| Phase | Wk 1 | Wk 2 | Wk 3 | Wk 4 | Wk 5 | Wk 6 | Wk 7 | Wk 8 |
|---|---|---|---|---|---|---|---|---|
| Phase 1 — Identify & Define | ||||||||
| Phase 2 — Research & Plan | ||||||||
| Phase 3 — Produce & Implement | ||||||||
| Phase 4 — Test & Evaluate |
Spending weeks 1–6 coding with no time left for Phase 4. Testing and evaluation take longer than expected — and they're worth significant marks. Set a hard cutoff: any feature not built by Week 6 is out of scope, no exceptions.
How many weeks do you actually have? Adjust the table above to match your real schedule. Then name the sprints in Phase 3 — what's Sprint 1? What's Sprint 2? What's the minimum viable version that would exist by the end of Sprint 1?
When you deploy your finished software (or a new version), how do you roll it out? There are four strategies:
| Method | What happens | Risk |
|---|---|---|
| Direct | Old system off, new system live immediately | High — no fallback if something breaks |
| Phased | Features released one at a time | Low — each feature tested before the next ships |
| Parallel | Old and new run side-by-side until confident | Very low — but double the infrastructure cost |
| Pilot | Tested with a small group before full rollout | Low — real feedback before full commitment |
Write one sentence: the method you'd use and why. Think about whether there's an existing system being replaced, how many users you'll have, and how much risk you can accept if something breaks on launch.
You won't write test cases until Phase 3 is underway — but you need to know the format now, because every requirement you wrote in Section 3b should map to at least one test case. If you can't imagine a test for a requirement, it's not specific enough. Go back and sharpen it.
Test plan format — one row per scenario:
| Test ID | Description | Test Data / Steps | Expected Output | Actual Output | Result |
|---|---|---|---|---|---|
| T-01 | Valid login | Correct username + password | Redirect to dashboard, session created | filled when you run the test | PASS |
| T-02 | Wrong password | Correct username, wrong password | Error: "Invalid credentials" | filled when you run the test | PASS |
| T-03 | Empty username (boundary) | Username: "" (empty string) | Validation error before submission | filled when you run the test | FAIL |
We'll build your full test plan together once your first sprint produces working code.
Pick up where we left off in Section 7 and finish each step properly. Create one document (Google Docs, Notion, or Word) and bring it to the next session.
Next session: we review the document together, lock in the requirements, and convert the class list into a proper UML class diagram — the first real design artefact for your folio.