Course Guide

Within the course ENGN4221 Systems Engineering Project, we refer to all of the activities within the course as “Capstone Project”.

ENGN4221 Systems Engineering Project Course Outline

This course is designed to mimic an industrial design problem as closely as practical in a university setting. Students select projects and are given an ill-defined problem statement. From the problem statement, the students are responsible for developing the full set of requirements, key performance indicators, and milestones to guide the design deliverables. The students then proceed through a systems design process including conceptual design, sub-system requirements, and quantitative trade-off analyses, using the full range of engineering science and professional skills developed during the degree course. The course emphasises teamwork (both team leadership and membership), communication skills (formal and informal, written and oral), and team and personal management and a professional approach to engineering design.

Capstone Project is the capstone group project course in Engineering at ANU. Capstone Project is an authentic technical-based project experience, both in preparing students to have the autonomy they will require to be professionals in their field and giving students the experiences and skills they need to be attractive to a variety of graduate jobs.

Course description
Mode of Delivery In person, and autonomous group work
Prerequisites ENGN2225 or ENGN2300, ENGN2226 or ENGN2301, ENGN3221 or ENGN3300, ENGN3230 or ENGN3301
Co-taught Courses VCUG3100
Equivalent Courses COMP4500 (TechLauncher)
Course Convener Dr Catherine Galvin
Linked.In Dr Catherine Galvin
Office Room: Ian Ross Building (31), R230
Student Consultation Book a meeting via email.
Tutors Details about your tutors can be found in Wattle.

Value in Capstone Project

In Capstone Project, you should only be doing activities that help you to deliver value.

The goal of Capstone Project is to deliver real value to the client, project team, and to other teams in Capstone Project. We consider “value” as the complementary development of your project outcomes and governance of the project, both at a systems level. There is no prescribed outcome for projects, and each project will have different goals and challenges to overcome.

Determining value in a Capstone Project project
Determining value in a Capstone Project project

Project selection, tutorials, team formation & project showcase

Students can seek permission to join a Software project and enrol in COMP4500 instead of ENGN4221.
Details about TechLauncher in CS can be found at

Projects in this course come from industry, research, and community partners. You can also ‘launch’ your own idea for a project, provided it is approved by the convener before Project Selection night.

The process for choosing projects and forming teams is:

  1. projects will be listed during O-week, with time for students to review before the Project Selection night.
  2. At the Project Selection night, it is suggested that you will partner with a friend, buddy or classmate and look to select a project
  3. To select your project, you are required to come to the Project Selection night, and ‘interview’ potential project clients. Clients will interview you too!
  4. At the conclusion of the evening, you and your ‘buddy’ will complete a Project Preference card. Clients will do the same.
  5. After Project Selection night, ‘buddies’ will be offered a position in a Project team. You will be required to accept or reject the project offer.

Teams of 3-6 will be formed through mutual agreement with the client, convener, and team membership by the end of week 1.

Please make sure you are available for the following events:

  • Tuesday 27 July 2021 5-7 pm - Project Selection night - attendance required to join a team (Thorough Online Conference software)
  • Week 11 - Project Showcase - attendance required to demonstrate your work, run in conjunction with Individual Project poster day, and the Masters group project (Virtual).

Learning activities

The tutorials are structured to simulate a team business meeting. There are typically three teams in a tutorial, and tutors act as your ‘supervisors’. Each team will have equal time during the tutorial. When you are not meeting, you will take on an advisory role as a ‘shadow’ for another team. This is an opportunity to examine how another team operates, and provide suggestions where possible. All team members are expected to attend the full tutorial.

Tutorial timeslots will be available shortly after Team Formation, and should reflect the times available on the ANU Timetable.

Class Schedule

Students and tutors, please take note of the following weekly schedule.

Semester schedule
Week Tutorial Topic Assessment
1 No Tutorials, Introductory Lecture Project Selection
2 Tutor Meeting and Course Structure
3 Audit 1 First Assessment
4 Audit 1 Feedback Tutorial
5 Project Progress Update and Team Coordination
6 Audit 2 Audit 2 Repository, Systems Design Documents, PA2 Feedback
Make-up Audits where needed -
7 Audit 2 Feedback Tutorial
8 Showcase & Poster Workshop and Project Progress
9 Project Benchmarking and Handover
10 Audit 3 Audit 3 Repository, Handover Draft, Showcase Poster, PA3 Feedback
11 Audit 3 & Portfolio Workshop Project Showcase
12 No tutorials Final Project Repository, Completed Handover
12+1 Professional Portfolio

Notes: Bold indicates Important Activities. The Make-up Audit will be used to review any teams not meeting expectations and at risk of failing

Classes locations are shown on the ANU Timetable.

Audit Tutorials

Audit Tutorials are focussed on the independent review of your team’s work. Each team has equal time to update the class, including tutors, conveners and clients, on the progress of their project. Teams are free to decide on how this time is used; however, it is strongly recommended that teams provide a 5-minute project update (with slides or handouts), and the rest of time is given to questions. Excellent teams will anticipate the types of questions, and have ready access to their repository and supporting data.

Expected Workload

Capstone Project involves independent group work, supported by tutorials in a professional development. Your team is autonomous as to how your time is best spent delivering outcomes for the project. This includes a small amount of structured time and a large amount of independent group work, and you should put approximately 120 hours of work into the course over the 12 weeks of semester. If you are spending drastically more or less time than this, you should discuss with your tutor how to manage your workload better.


The pattern of tutor meetings aims to promote an Action Learning Cycle, where tutorials are designed to help groups go through a process of Planning, Acting, Collecting Feedback on actions, and Reflecting.

Action Learning Cycle in Capstone Project (image adapted from The University of Sheffield)
Action Learning Cycle in Capstone Project (image adapted from The University of Sheffield)

Learning outcomes

  1. Technical. Synthesise technical knowledge and approaches to generate solutions to a complex problem.
  2. Problem Solving. Develop, analyse, and critically evaluate alternative options in order to justify and generate solutions in a real-world project.
  3. Teamwork. Apply project management and organisational skills to produce time-sensitive deliverables in a multi-disciplinary team.
  4. Communication. Effective transmission of decisions and solutions using appropriate media to professional and lay audiences.
  5. Reflection. Demonstrate and reflect on leadership and creativity as an individual and within a multi-disciplinary team.

Assessment processes

The Assessment Guide describes the assessment in detail

The learning outcomes align to the following assessment processes:

  • Project audits and review (75%, group and individual indicators)
  • Professional reflection or professional development (25%)

The Audit activities are coordinated around a Many Eyes Process, which is designed to give you relevant and timely feedback and guidance on your project. Details about this process can be found in this Guide.

General expectations against grades

The following table provides a guide to what quality of work we expect to see at each grade level:

Quality of work expected at each grade band
Grade Expectations
Fail Work which is incomplete or displays an inadequate understanding of the subject matter or an inadequate grasp of relevant skills. Poor attendance.
Pass Work of satisfactory quality, which displays an adequate understanding of most of the subject matter and a sufficient grasp of relevant skills. Meets or exceeds client expectations.
Credit Work of good quality, which displays a good understanding of the subject matter and a sound grasp of relevant skills. Delivers value that meets the expectations of the client or target market.
Distinction Work of superior quality, which demonstrates a thorough knowledge and understanding of the subject matter, proficiency in relevant skills, and analytical, design and implementation ability of a high order. Delivers value that exceeds the expectations of the client or target market.
High Distinction Work of exceptional quality, which demonstrates comprehensive understanding of the subject matter, mastery of relevant skills, sophisticated or original analysis, design and implementation, and outstanding quality in clarity, precision and presentation of work. Delivers systems-level value that significantly exceeds expectations

As a capstone course, Capstone Project is designed for you to implement what you already know into a project, and independently learn about what you don’t already know to complete the project. If you and your team are properly extending yourself, you will find that there are gaps in your knowledge?from practical to technical-and this course is a great opportunity to fill those gaps.

There are great resources available for managing professional engineering projects:

And relevant standards can be accessed via the ANU Library:

  • ISO/IEC/IEEE 15288 - Systems and software engineering?System life cycle processes
  • ANSI/EIA?632 - Processes for engineering a system
  • ISO/IEC/IEEE 26702 - Systems engineering?Application and management of the systems engineering process
  • ISO/IEC/IEEE 29148 - Software and systems engineering?Life cycle processes?requirements engineering
  • ISO/IEC/IEEE 16326 - Systems and software engineering?Life cycle processes?Project management

And the graduate competencies that you are demonstrating in the project:

When researching journals for your project, many standards and standards can be accessed on campus, or off-campus using the ANU?s reverse proxy server:

There is no pre-set methodology that your team needs to follow in this project. However, a good systems engineering process is considered best practice in a wide range of projects, and is the ‘default’ process we would like to see followed in this course. If your client would like you to follow a different variation, you should do this in consultation with your client. For example, many entrepreneurial projects might take an ‘agile’ approach.

As a default systems engineering process, the following steps are a good representation of a model-based systems engineering approach, and the relationships between steps.

A lightweight model-based systems engineering approach
A lightweight model-based systems engineering approach

Approval processes for project activities


Insurance is required if you travel off-site to meet with clients.

If you plan to visit or work on a client site you must fill out the Student Activity Approval Form.

Submit your completed forms to the engineering school manager:

  • SoEn School Manager: Reception Counter, Level 2, Ian Ross Building.

The school manager will arrange for the form to be signed by the School Director. You will be advised by email once the form has been signed.

Use the following information to complete the form:

Insurance data
Field Value
Student Name, Number and Phone Your details
Course / Award ENGN4221
Period Semester and year. eg. “Semester X, 20XX”
Organisation providing supervisor The name of your client’s company or business
Location of experience Address of the client workplace
Work experience or research Project supervisor The name of your client
Phone Number Your client’s phone number

Intellectual Property & NDA

By default, students own their Intellectual Property, outlined in the Student intellectual property policy. However, a client may request assignment of project IP (Intellectual Property), and an undertaking not to disclose confidential information. This is usually disclosed at the start of the project, and reaching this understanding should be undertaken prior to Project Audit 1.

Clients can propose an agreement; however, the ANU has already prepared a Preferred Agreement that may be used as a starting point regarding the protection of IP.

Students should follow the following process:

  1. The client may propose an agreement, but we would prefer you start with the ANU’s Preferred Agreement.
  2. Once you have an agreement ready to sign, you should seek your own independent legal advice before signing. Free legal services are available from both ANUSA and PARSA. If you do NOT obtain independent legal advice, this is your choice; however, the delegate at ANU will not sign the Preferred Agreement without written acknowledgement that you have been advised to seek independent legal advice.
  3. If you have signed the agreement, it will need to be submitted to college staff for signing by the college delegate. You must also submit an email stating that you have understood the need to obtain your own independent legal advice. Submit your signed agreement and email to:
  4. You will receive an email notifying you when the agreement has been signed by the college delegate.

Include examiners, tutors and observers

The Many Eyes Process used in Capstone Project requires examiners, tutors and students from other teams (shadows) to evaluate the work produced by a team. This means they will need access to the team’s work and may need to be included in any agreements regarding IP.

Public presentations & posters

It is a requirement of the course that students present their work to the public. This may present challenges for students subject to IP agreements. However, it is usually possible to present work in such a way as to not violate any such agreements. In all cases, whether subject to IP agreements or not, students should seek approval from their client and other relevant stakeholders before any public presentation of their work.

It is a requirement of the course that students display a poster describing their work at the Showcase. The posters may also be displayed on this website. If there is any reason why this cannot happen, please make the course convener aware.


How to deal with expenses you may incur

We do not expect students to bare any significant costs associated with the course. In general, any significant project costs should be covered by the project client. However, there may be times when teams choose to cover minor costs for project items such as materials or consumables. To offset these costs, a number of Microgrants will be available to teams that comply with financial reporting requirements.

The Microgrant operates out of a limited pool. We will do our best to balance the circumstances of your project with the considerations of other teams.

The grant can be used for activities relating to:

  • hardware for prototyping or producing an artefact,
  • consumables directly relating to producing a product.

Microgrants will not be approved for materials and services not otherwise accessible on campus. If it is not clear how the expenses add directly value to the project, the team will not be eligible for a Microgrant.


There is no guarantee for partial or full reimbursement of a Microgrant if pre-approval is not completed. To obtain approval for a Microgrant, send an email to the course convener outlining:

  1. A short summary of the project need for expenditure (in the email)
  2. An itemised list of proposed or incurred expenses (as an attachment for our records)
  3. A link to full financial records for your project (a link to your repository)
  4. A link to any research into purchase options justifying the decision (a link to your repository)

In addition, please CC your tutor into the email for endorsement.


After approval of a Microgrant, funds can be accessed the following ways:

For situations where the team has purchased items using their own funds
  1. To be reimbursed, one team member will need to complete the Expense Reimbursement Form, together with copies of all authentic receipts of purchase in one PDF.
  2. Once confirmed, your reimbursement will be forwarded to the relevant School Admin to process the reimbursement.

A reimbursement takes 7-10 business days to complete. Please submit one application by each team with one of your team member?s Uni ID. The School Admin will require student?s current bank details held at ISIS.

For situations where the team is unable to cover the costs of the purchase, the school can organise purchase
  1. To initiate the purchase, please contact the relevant convener to obtain instructions.
  2. One team member will need to provide a purchase order or online order that can be fulfilled by School administration.


If, for any reason, you are in a situation where your project and learning will be at risk because of funding limitations, please talk to the convener. We are also happy to talk to clients directly about funding issues.

Work Health & Safety

You must align with the WHS standards of the place that you are working, as well as the ANU’s own standards

Hazards, small or large, exist in any work environment. Understanding these hazards is a key responsibility of your team. This is particularly relevant if you are undertaking work in a workshop. We do not support students working in ad-hoc spaces that are not appropriate for the task, and students should seek advice if they are uncertain.

We will run an introduction to the relevant work health and safety (WHS) and Technical support staff at the beginning of each semester, including a workshop induction. If you are unable to attend, these can be arranged separately for your team.

Relevant Policies

All students should understand where relevant:

Hazard Assessment

The Research School of Engineering has its own simplified processes for research groups when dealing with managing Hazard Assessment.

Where appropriate, we expect groups to complete:

  • Hazard rating matrix
  • Hazard register

And to complete these forms in consultation with the School WHS Officer, Beatriz Velasco These forms can be obtained through email. Please include your course convener in any discussions around WHS.

Philosophical notes and comments

This section discusses many of the philosophical underpinning of this course. It is important to note the extraordinary transformation and legacy that occurred with the collaboration between Computer Science and Engineering, when TechLauncher grew to a College-level collaboration during 2017. A special shout-out to A/Prof Shayne Flint, who probably authored most of this advice (directly or indirectly), during this collaboration.

Although the Engineering projects have now been excluded from TechLauncher, we continue along that trajectory and look to continue the meaningful project work that this collaboration inspired. And beyond!

These resources have been compiled over a number of years working with student groups.

Being a Shadow

Are you a Shadow, Observer or Red-Teamer?

During the course, you will take on two key roles: ‘team member’ and ‘shadow’. You will give and receive feedback in this role. This is a form of 360-degree feedback, and is commonplace in many industries today. The role of Shadow is designed to provide critical review and an alternative perspective to project teams. We find that students can sometimes find this role challenging.

The radio program ‘Best Practice’ has a great description of the role of Shadow, and how it is used in industry. “Red-Teamers” are the modern equivalent of the “Office of the Devil’s Advocate”. Successful teams in leading companies and organisations are increasingly using Red-Teamers ? these are people specifically brought into a project who critique decisions and by doing so extend the project team’s thinking. The perspectives of “Red-Teamers” are not always right, but they are always valid.

So, if you’re not an active shadow, maybe you’re letting yourself and your shadow team down!

Playing the devil?s advocate or Red Teaming is a good way to avoid the trap you can fall into when ‘grading your own home work’. Asking an outsider to go through your work with an unflinching critical eye, according to Bryce Hoffman, can make good plans great or perhaps even save you from a disaster. - ‘Best Practice’, Saturday 5 August 2017

Being a Systems Engineering Professional

In Capstone Project you are representing ANU as a practising professional

Everything you do in your project must be professional - respecting the client, your team, your peers and yourself.

If you find yourselves doing something that does not appear to be a good use of time, or seems unnecessary, then STOP and REFLECT - do you really need what you are doing, have you missed something, can you use your time better?

The ‘Triple Bottom Line’

In order to deliver on your project, you should also consider a ‘Triple Bottom Line’

  • do the best you can for your client or business
  • be a humble learner, and learn as much professionally as you can
  • demonstrate the quality and value of the work you’ve done, and highlight the future work

These three objectives are interlinked. Focussing on one to the exclusion of the others will lead to sub-optimal outcomes.

  • learning about teamwork, stakeholder engagement and applicable technology will lead to improved satisfaction of client needs and, ultimately, better outcomes
  • you will need to learn a great deal during the course to satisfy the needs of your client. In doing so, you will be able to present a great story in your project audit, leading to great outcomes
  • staying humble as a learner - you are presenting your work to domain experts. It is entirely professional to demonstrate you understand the limits of your work.

In Capstone Project, the focus is on ‘value’. If you are using language such as ‘marks’, ‘grades’, ‘scores’, or ‘points’, you are missing the point. Instead, focus on how your work will be ‘evaluated’ - the value you are generating for your client through the project outcomes and processes.

Presenting your work

Your professional responsibilities are on show here. Refer to the Engineers Australia Code of Ethics Section 1.3, and/or the Australian Computer Society Code of Professional Conduct Section 1.2.6.

Professionalism at Meetings

The aim of the Tutor Meetings is for you and your team to develop and practise the ability to succinctly present work, and to then address comments and questions in a coherent manner. Tutorials are an opportunity to get feedback from your peers, tutors, mentors, and other stakeholders. They are also an opportunity for you to develop your ability to understand and critique the work of others, and to ask well formed questions that improve your understanding.

With this context in mind, it is important for everyone in the room to:

  • introduce clients and other stakeholders who are present
  • engage in the process - no mobile phones, laptops, et cetera
  • be respectful of others - particularly the team presenting and their client
  • while robust, frank and open discussion is very much encouraged, it is not acceptable for people to abuse and attack each other. The point of robust interactions is to help improve approaches and outcomes

Presentation tips

  • Be honest and open - put your cards on the table. There are people around who know the truth.
  • Be enthusiastic about your work and proud of what you have achieved.
  • Act like a team. No back-biting or contradictions.
  • When pitching - everyone to be engaged in the presentation - we can learn a lot by looking at those who are not presenting!
  • Talk about what you have learned from both failure and success - technical and project perspectives.
  • Always have something concrete to show or demo.
  • Remember that some people will have no idea what you are doing. Set the scene for the context for the system you are developing, what the client?s business is and what they want you to do.

Repository tips

  • Reviewers will use your Audit Landing Page to guide their review. Make it easy for them to find the work you want reviewed.
  • Make sure you refer to evidence and rationale for decisions made by your team. For example, meeting minutes, slack communications et cetera. Many teams will maintain a wiki as a kind of ’engineering logbook? or ‘decision log’.
  • Point reviewers to exactly where they can find your work - don’t expect them to trawl through repositories looking for material to review - make sure you point them to work that addresses the evaluation criteria.
  • Make sure all reviewers have access rights to read your repositories.
  • If you have physical artefacts you want reviewed, then make clear to the reviewer how they can inspect them - eg. contact details to arrange an inspection.
  • It is really up to you to decide how you present your work for review. If you don’t allow your reviewer to properly and fairly review your work, then you should not expect a good evaluation.

Evaluation tips

Conducting Project Audits

Projects are reviewed by tutors, team shadows and the team itself using our Many Eyes Process.

This page provides some guidelines you might consider when conducting your audit.

Being a reviewer

Your task as a reviewer is to explore the work completed by the team and to use what you find (or don’t find) to complete the Project Review.

We expect that conducting an Audit and submitting the Project Review would take approximately 1 hour, outside of the tutorial. A good process is to:

  • Familiarise yourself with the Audit marking criteria, and the Project Review form.
  • Review the work completed by the team and form an overall view as to its quality.

More specific tips:

Look at the actual work done
It is important that you look for evidence of the actual work completed by the team. If you cannot find the actual work done, then contact the team so that they can improve their work.
Look through the repositories
Every team is expected to have put in place mechanisms to store and track the artefacts they produce during their project. The repositories should be well organised and incorporate version control - especially for software projects. If there is no repository, then provide feedback such as No evidence, Work is inaccessible. Check that version control is being used. A complete version history is a good way to understand the processes and progress of work undertaken by the team. If, for example, a team has just uploaded a bunch of work in recent days, then provide feedback such as Ad-hoc processes.
Look for evidence
If the team claims to have completed specific work, then you must check that they have actually done that work and that it is of real value. The Audit landing Page should refer you to this evidence (could be documentation, meeting minutes, prototypes, code etc.). For example, the inclusion of a project plan needs to be backed up with evidence that they are actually using the plan. If they are not using the plan, then it is of very little value.
Look for decision-making
Teams are expected to make, implement and track decisions during their project. You should look for evidence of this during your review (documentation, meeting records etc.). It is very important that decisions are supported with evidence. For example, there should be evidence demonstrating the feasibility of any requirements specification or detailed project plan produced by a team. This may take the form of stakeholder consultation, experimentation, prototyping, evaluations, research, et cetera.
Work quality
You can use the notes sections of the Project Review to comment on the quality of the team’s work, but be constructive and offer suggestions for improvement where applicable.

Many Eyes Process

The Many Eyes Process encourages active participation throughout the evaluation process

All evaluated tasks go through the Many Eyes Process. This process has been developed to ensure that we are able to consistently assess every team and individual students, even though they are working on very different projects and are producing a very different set of deliverables. The Many Eyes Process provides feedback throughout the Action Learning Cycle.

In summary, the Many Eyes Process comprises three stages:

  1. Collection of feedback through Project Reviews from students (self evaluation), peers, tutors, clients and examiners.
  2. Reflection and Action on the feedback performed by the team.
  3. Careful consideration of data from all sources to award the progress indicator.

This process is used for the evaluation of project work where there is one or more stakeholders involved.

Inputs and Outputs

The Audit processes takes the Project Work as input and, through a team-led quality control process, provides valuable formative feedback on the groups project.

The Project Reviews are made up of a quantitative evaluation of project quality, as well as constructive and actionable feedback as a result of careful and considered interaction with the work. Each are used differently from here: the feedback is used by the team to improve their project, and by the examiners as input to evaluate the quality of work.

Block diagram of the Many Eyes Process
Block diagram of the Many Eyes Process

Marking Process

The Many Eyes Process is used as input into the final determination of a grade for each stage. This process generates inputs, but is then considered individually by the examiners on a case-by-case basis, involving the review of comments, relative performance and?if necessary?a convener tag report.

Consideration from all sources
Consideration from all sources

The Professional Portfolio uses a similar process, with the self, tutor and convener roles.

See the Assessment Guide for a full run-down of the marking process used in Capstone Project.

Coursework expectations, policies and processes

Absences & misadventure

It is expected that you will attend all classes, but as senior students at ANU the responsibility is on you. You should address any absences for worthy reasons in a professional way; for example, notifying your team and tutor of absence so that your team can record this in the meeting minutes.

Late submissions and extensions

Reasonable requests for extensions, special consideration and accessibility will be considered with courteous regard to the due dates. If you have any concerns, please talk to your team members, tutors and convener (very) early. No leeway will be offered after due dates. Due dates are listed in the Assessment Guide.

No late submissions will be accepted for the Audit processes; these must be submitted on time.

Submissions, feedback and improvement

Links to digital repositories and other submissions will be submitted through Wattle, even through the bulk of your work will be accessible through repositories linked through Wattle. Feedback on your submissions will be available through the Wattle Gradebook.

Feedback is widely misunderstood concept in education. In systems theory, feedback is a systems process that drives behaviour (such as negative feedback in an electronics circuit) towards an objective, rather than being the outcome of a process.

In this course, there are many formal and informal processes to collect formative feedback to help you produce the best work you can. These include regular opportunities with your tutor for specific feedback before Project Reviews. Your peers, both in your team and otherwise, are a central part of this process.

Very little ‘summative’ feedback will be given with the return of assessment - take the ample opportunities you have in this course to get formative feedback before you submit.

Marking and assessment

The work you do in this course should transcend the normal assessment processes; the value of the outcomes from your project should provide you with examples of experience, mentoring and an application of systems approaches to engineering problem solving that will help launch your career.

However, at this stage the norms of university processes and student expectations require us to give you a grade. To this end, the assessment processes are designed to evaluate and benchmark the work that you actually undertake on your project, to help you to plan, design and evaluate your own and each other’s work, and take on feedback in a constructive way for the improvement of your project and own professional development.

Project Audits are the main assessment activity in this course. Audits are undertaken in stages of Audit, Review and Feedback. These are described in the relevant assessment item.

Resubmission of assessable works

Groups may be required to resubmit work where the submission is deemed below acceptable quality, or requires major revision. The course conveners shall notify groups within one week of submission and negotiate a plan for resubmission. Work falling into ‘Unsalvageable’ and ‘Unacceptable’ will likely fall into this category.

Referencing requirements

There are no specific referencing requirements. You should consult with your client where referencing is required, and align with norms in the discipline you are working in.

Grievances, issues, and complaints

If you have a problem with the marks you receive, there is a process that you can follow to come to a resolution on the issue. It is worth remembering that the teaching team has a wealth of experience in professional practice and mentoring junior engineers, and their perspective on your work can be a shock to students who have not been challenged outside of the sandbox of academic practice.

If you would like to appeal your grade, this process must be initiated within two weeks of receiving your mark:

  1. discuss the issue with your tutor.
  2. Your tutor will provide further comments, clarification and sage advice if needed.
  3. If the issue remains unresolved, you can:
    • ask the course convener to re-mark the assessment - this requires you to first submit in writing exactly what your concerns are and how the marking has missed some significant aspect of your work against the criteria. Not including this information will lead to the convener denying this request.
    • ask the course convener if you can resubmit (typically reserved for failed work) - this requires negotiation with the course convener
  4. If you are unhappy with the course convener?s response, you can appeal to the Associate Director (Education), in consultation with the course convener as described by the appropriate policy.

Final Grades

Final grades are subject to deliberations at School and College examiners meetings. We try hard to align the course grade expectations with the expectations of the examiners meetings to avoid scaling or grade shifting to meet University expectations.

Academic integrity

All students must read and understand the ANU guidelines on Academic honesty & plagiarism.

Any sign of academic misconduct in any assessment task will be fully investigated in accordance with the ANU Academic Misconduct Rule 2015.

Turnitin submissions

The following applies specifically to your Professional reflection, but all work in your repository is subject to academic integrity.

The ANU is using Turnitin to enhance student citation and referencing techniques, and to assess assignment submissions as a component of the University’s approach to managing Academic Integrity. For additional information regarding Turnitin please visit the ANU Online website. Students may choose not to submit assessment items through Turnitin. In this instance you will be required to submit, alongside the assessment item itself, copies of all references included in the assessment item.

Policies for studying at ANU

ANU has educational policies, procedures and guidelines, which are designed to ensure that staff and students are aware of the University?s academic standards, and implement them. You can find the University?s education policies and an explanatory glossary at:

Students are expected to have read the Academic Misconduct Rule before the commencement of their course. Other key policies include:

  • Student Assessment (Coursework)
  • Student Surveys and Evaluations

Course improvement

There will be opportunities to provide feedback throughout the course to the course convener, tutors, and course reps. One of the key formal ways students have to provide feedback is through Student Experience of Learning Support (SELS) surveys. The feedback given in these surveys is anonymous and provides the Colleges, University Education Committee and Academic Board with opportunities to recognise excellent teaching, and opportunities for improvement.

For more information on student surveys at ANU and reports on the feedback provided on ANU courses, go to and

We ask all students to complete their SELS during the final tutorial.

Course evolution

We take feedback seriously in ENGN4221. The following changes have occurred in the course since 2017. These suggestions below came from ENGN4221 Course Reps.

  • Online systems for ENGN4221 students are now streamlined. The central system for Capstone is Wattle. Teams are encouraged to maintain their own communications systems (eg slack).
  • In the early tutorials we focus on getting the projects up and running during early tutorials.
  • The list of available projects will be made available prior to the Project Selection night, which is an opportunity for you to interview and discuss the projects with clients. After the Project Selection night,teams will be formed through mutual consultation between client, yourselves and Convener Dr Catherine Galvin. Team selection will balance a range of criteria, such as who you would like to work with (not ’first-in, best-dressed!).
  • We require all ENGN4221 teams to complete at a minimum Concept of Operations in Audit 1 and demonstrate the System Requirements, Functional Analysis, and System Architecture by Audit 2 (the default where appropriate).
  • The ENGN4221 evaluation process will aim to deliver quality feedback.
  • The ENGN4221 team member contributions are based on recommendations from your tutor, who will negotiate final values and use it as a diagnostic tool.
  • ENGN4221 ‘Team reps’ (one or two members, perhaps cycling through) will meet with me and tutors on a weekly/fortnightly basis for an ‘exec’-style meeting about TechLauncher.

Support for students

The University offers a number of support services for students. Information on these is available online from We practice respect, diversity and inclusion in our practices - if there are issues that have not been addressed that need to be, please get in touch with someone from the teaching team, or someone you feel comfortable with who can on your behalf.

Version Control

Authorship & Citation

This Course Guide and associated frameworks have been designed by Dr Chris Browne over many years of teaching, and ideas from this design have been published in multiple sources. Parts of this text originate from A/Prof Shayne Flint, from when this course was a part of TechLauncher. I acknowledge the hundreds of students, dozens of tutors and number of colleagues and clients who have provided input into the design as it is today. The design of the course today would not be possible without the critical collaborations with A/Prof Shayne Flint and Dr Lynette Johns-Boast, who pioneered authentic project-based learning in the Research School of Computer Science for over a decade, and Prof Richard Baker who showed me a better way to learn. - Chris Browne

The current course convener Dr Catherine Galvin acknowledges the immense support from Dr. Chris Browne for his contribution to build up and set up a fantastic Capstone program and to train her to run the course in the right spirt and effective manner.

This acknowledgement cannot be removed from this guide without express permission from the Author. If you do like ideas here, please cite the source:

Browne, C., 2019, “Capstone Project Course Guide”, ANU, accessed <>, <>

Document Information

Document Information
This document ENGN4221 Course Guide [Download as PDF]
Format PDF preferred, also available as web page
Document type Information and Procedures
Purpose Overview of course requirements, governance and processes for students undertaking ENGN4221 Systems Project
Semester Semester 2, 2021
Audience Current Students
Version v2021.S2.1
Related Content ENGN4221 Assessment Guide [Website] [Download as PDF]

Change log

2021.S2: 2021-07-12

  • First commit for S1 2021
  • updated dates for S2 2021

Updated: 13 Jan 2022/ Responsible Officer: Head of School/ Page Contact: ENGN4221 Webmaster