How to Write a Capstone Project — Final Year STEM Guide

What Is a Capstone Project?

A capstone project (also called a final-year project, senior design project, or honours project) is an extended individual or team-based project completed in the final year of an undergraduate degree. It integrates knowledge from across the degree programme, requires independent work over a full semester or academic year, and typically results in both a tangible deliverable (prototype, software system, report, or experiment) and a written report.

Unlike a standard assignment, the capstone project is open-ended: the problem is real, the solution is not predefined, and you are expected to make professional-level decisions about approach, tools, and trade-offs. This is what makes it both more challenging and more valuable than a standard coursework assignment.

Types of Capstone Projects in STEM

Discipline	Typical Deliverables
Mechanical / Civil Engineering	Physical prototype, structural design, technical drawings, FEA analysis
Electrical / Electronic Engineering	PCB design, embedded system, signal processing implementation
Computer Science / Software Engineering	Working software system, app, algorithm implementation with testing
Biomedical Engineering	Medical device prototype or design, clinical validation plan
Environmental Science	Field survey and analysis, environmental management plan
Data Science / Statistics	Data pipeline, model, dashboard, or analytical report

Phase 1 — Problem Definition and Scoping

The most underestimated phase of any capstone. A well-scoped project defines exactly what will and will not be built or investigated. Spend the first two to three weeks on this before touching any design or analysis work.

Problem statement: what specific problem will you solve and for whom? Be precise — "improve water quality monitoring" is too vague; "design a low-cost turbidity sensor for rural water supply networks using ESP32 and a nephelometric optical arrangement" is specific
Objectives: 3–5 SMART objectives that define what a successful project looks like
Scope boundaries: explicitly state what is out of scope — this prevents scope creep and manages examiner expectations
Constraints and assumptions: budget, time, available materials, regulatory constraints, technical assumptions
Success criteria: how will you know the project has succeeded? Define measurable criteria upfront

Write a project brief at the end of Phase 1. A one-to-two page document that your supervisor approves before you begin design work. This protects you if the scope changes during the project — you can reference the agreed brief as the baseline.

Phase 2 — Literature Review and Background Research

Before proposing a solution, establish what already exists. Your literature review should cover:

Existing solutions to the same or similar problems — commercial products, academic prototypes, published methods
Relevant theoretical background (key equations, physical principles, algorithms)
Applicable standards and regulations your solution must comply with
The gap or limitation in existing approaches that justifies your design

This is not a full systematic review — it is focused background research that informs your design decisions. Aim for 20–40 sources.

Phase 3 — Design and Development

The methodology of a capstone project is the design process itself. Document every decision:

Concept generation: generate multiple design concepts (typically 3–5) before selecting one — use morphological charts, mind maps, or brainstorming
Concept evaluation: use a weighted decision matrix to select between concepts systematically. Criteria: cost, feasibility, performance, safety, time
Detailed design: drawings, schematics, algorithms, or models for the selected concept
Prototyping or implementation: build, code, or simulate — document each iteration and any changes from the original design
Testing and validation: does the solution meet the success criteria? Run systematic tests against each objective

Need help writing up your capstone project?

Our STEM specialists help with project reports — from literature review and methodology to results analysis and discussion chapters.

Get Help Now →

The Capstone Project Report

The report is assessed separately from (and equally to) the deliverable in most programmes. A well-executed prototype with a poorly written report scores lower than a modest prototype with excellent documentation of the engineering process.

Report structure

Executive Summary — 1 page, standalone overview for a non-technical reader
Introduction — problem statement, objectives, scope, report structure
Background / Literature Review — existing solutions, theoretical context, gap
Design Methodology — concept generation, evaluation matrix, selected design rationale
Detailed Design — drawings, circuit schematics, system architecture, material specifications
Implementation — build process, key decisions made during development, deviations from original design
Testing and Results — test plan, results against each success criterion
Discussion — interpretation of results, limitations, what would be done differently
Conclusion and Future Work — summary, whether objectives were achieved, recommended next steps
References
Appendices — full calculations, code listings, datasheets, test records

Reflection and Critical Evaluation

Most capstone marking rubrics include a reflection or critical evaluation component worth 15–25% of the project mark. This asks you to honestly evaluate:

Which objectives were fully met, partially met, or not met — and why
What decisions in hindsight were good, and which would you make differently
What the main technical, time, or resource constraints were
What the project would look like if continued (future work)

Students who describe an unrealistically perfect project score lower than those who engage critically with real limitations. Examiners know that nothing goes exactly to plan — honest reflection is the mark of a professional engineer or scientist.

The Viva / Presentation

Most capstone projects conclude with a presentation to a panel — sometimes including industry sponsors. Prepare for:

A structured 10–15 minute presentation: problem → approach → solution → results → conclusions
A live demonstration of the deliverable where possible
Technical questions from the panel — know the detail of your design, testing results, and limitations
Questions about what you would do differently — this is not a trap; honest answers score well

Practice the demonstration. If your prototype will be demonstrated live, rehearse it in the exact room with the exact equipment at least twice before the assessment day. Demonstrations that fail due to environment issues (wrong power supply, missing cable, software that won't install) are avoidable and costly to marks.

Common Mistakes

Scope too large: trying to build a full commercial product in one semester — scope for a proof-of-concept, not a market-ready system
No decision matrix for concept selection: saying "we chose option 2 because it was better" without systematic justification
Not testing against objectives: if you set success criteria in Phase 1, you must report whether each was met
Report written as a narrative diary: the report documents the engineering process systematically, not "first we did X, then we tried Y"
All effort on the deliverable, none on the report: the report can be worth 40–50% of the total mark

Frequently Asked Questions

Can my capstone project be purely a research or analysis project?

Yes — many programmes accept projects that produce an in-depth analysis, a data study, or a systematic review rather than a physical or software deliverable. The same principles apply: clear objectives, documented methodology, results against criteria, and critical reflection. Confirm with your department what types of projects are accepted.

What if my prototype doesn't work as planned?

A non-working prototype with excellent documentation of the design process, honest failure analysis, and a clear account of what went wrong and why can still score well. Examiners assess your engineering judgement, not just the final product. A working prototype with no documentation of the process scores poorly. Document everything, even failures.

How detailed should the appendices be?

Include every calculation, every line of code, and every raw test result in the appendices — even if it seems excessive. Examiners checking your numerical work expect to find the full working. Omitting it looks like the work wasn't done. Use the main body of the report for summary results and key equations; use appendices for the complete detail.