Capstone project
This is the work where everything learned over seven years has to function together and at the same time. It does not assess a topic: it assesses the ability to take a real problem from the statement through to a solution that works, is documented and can be defended.
01What is expected of a capstone project
| Expected | Not expected |
|---|---|
| A real problem, with someone it is useful to. | A made-up exercise to justify using a component. |
| Verifiable requirements defined before starting. | “It should work well,” with no acceptance criterion. |
| Justified decisions backed by calculation or testing. | Picking a component because it was in the drawer. |
| A prototype tested against the requirements. | An assembly that worked once on the day of delivery. |
| Documentation that lets someone else reproduce it. | A report written the week before the defense. |
| A defense in which every decision is answered for. | A slide presentation that is simply read out. |
- Real: someone has it. A school workshop, a community garden, a club, a local producer, a person with a concrete need.
- Scoped: it fits in the available time with room to spare. An ambitious project left half finished is worth less than a modest one that works.
- Verifiable: it can be demonstrated that it meets the requirements, with measurements.
- Within reach: components that can be obtained and tools that exist at the school.
- Integrative: if it can be solved with a single topic from a single subject, it is not a capstone project.
Starting from the solution: “I want to build something with an ESP32.” The project is already crooked from birth, because a problem then has to be invented to justify the choice. The right order is the reverse: problem, requirements, alternatives, justified choice. And sometimes the honest conclusion is that the problem could be solved without a microcontroller, which is also a valid result.
02From requirement to design
| Stage | What is done | What is delivered |
|---|---|---|
| 1 | Survey the need with the end user and observe how it is solved today. | Project description and a record of the current situation. |
| 2 | Write verifiable requirements, and separate them into essential and desirable. | Requirements specification. |
| 3 | Propose at least two alternative solutions and compare them against explicit criteria. | Analysis of alternatives with the justified decision. |
| 4 | Design: block diagram, schematic, calculation of each stage, mechanical design in CAD. | Design documentation and calculation report. |
| 5 | Build in parts, testing each block before integrating. | Working prototype. |
| 6 | Tests against each requirement, including limit and endurance tests. | Test protocol with results. |
| 7 | Final documentation, user manual and delivery to the end user. | Complete project folder and delivered equipment. |
- 3D modeling of parts and assembly, with interference checking before manufacturing anything.
- Manufacturing drawings with dimensions, tolerances and materials: this is what is handed to whoever will make the part.
- Exploded views for assembly and the manual.
- Files for laser cutting or 3D printing, when applicable.
- And on the electrical side, the schematic and the board, using what was covered in schematics and printed circuit boards.
- Mathematics: calculus, statistics of the tests, error propagation.
- Physics: mechanics, thermal, optics and everything the phenomenon involves.
- Legal framework: applicable standards, responsibility, ownership of the work.
- Health and safety: risk analysis of the product and of the construction process.
- Economics and production: costs, feasibility, scale and comparison with what already exists.
03Managing the project
| Tool | What it is for |
|---|---|
| Task breakdown | Splitting the project into jobs of a few days, each with a concrete result. |
| Schedule | Placing the tasks in time, with their dependencies. It shows what can be done in parallel. |
| Critical path | The chain of tasks with no slack. A delay there delays the whole delivery; elsewhere, it does not. |
| Milestones | Checkpoints with a verifiable deliverable. Without milestones, a delay is discovered at the end. |
| Roles | Who does what. Rotate so that everyone goes through everything, but with a clear owner for each task. |
| Risk register | What can go wrong, how likely it is, what the impact is and what is done if it happens. |
| Project logbook | What was done each day, what was measured and what was decided. It is the memory of the project and the basis of the report. |
| Risk | Impact | Plan if it happens |
|---|---|---|
| The key component cannot be obtained | high | Have a replacement chosen from the design stage, and buy it at the start. |
| The board burns out at power-up | high | Build two, and test in stages with a current-limited power supply. |
| A team member stops participating | medium | Keep documentation up to date so someone else can continue. |
| The end user changes what is asked for | medium | Requirements agreed in writing from the start. |
| The workshop is not available | low | Move forward everything that does not depend on the workshop. |
The most frequent delay in school projects is not technical: it is waiting for a component. Buying the critical parts early solves more problems than any design optimization.
04Costs and feasibility
- Materials, with real prices surveyed and dated.
- Labor hours, priced: even if the work is done at school, the project has to show how much it would cost to do.
- Third-party services: board fabrication, machining, treatment.
- Tools and instruments that the project requires and that are not available.
- A contingency margin, which for a prototype is no less than 15%.
The cost of your own solution against what already exists on the market. It is an honest comparison that must be made, and its result does not invalidate the project: often the commercial solution is cheaper and the project is still justified because it is custom-made, because the commercial equipment cannot be obtained, or because the value lies in the learning.
What is not acceptable is to avoid the comparison. A project that does not know how much the thing it solves costs is not finished.
05The defense
- Structure: problem, requirements, alternatives and why one was chosen, design, tests, results, conclusions and what would be done differently.
- Live demonstration, with a plan in case something fails: a backup video and an explanation of what is being shown.
- Data, not adjectives: “it measures with an error of ±0.3 °C over the tested range” says far more than “it works really well.”
- Everyone speaks and everyone knows the whole project, not just their part.
- Prepare the hard questions: why that component, what happens if such-and-such fails, how much it costs, which standard applies, what limitations it has.
- Acknowledge the limits of the work. Saying “we could not test this” is much better than exaggerating a result, and the examining panel spots it right away.
It is not the flashiest project: it is the one that shows complete reasoning. A team that understands why it chose each thing, that measured what it claims and that knows what is missing, defends a modest project better than a spectacular one whose operation it cannot explain.
06The work throughout the year
Identify the problem with the end user, survey how it is solved today and write the preliminary proposal: problem, requirements, alternatives evaluated, scope, preliminary schedule and estimated budget. It is presented and corrected before going on.
Block diagram, schematics, calculations, CAD models and drawings. Cross-review with another group before buying or manufacturing anything: it is the cheapest moment to find a mistake.
Assembly by blocks with verification of each one, integration, and tests against each requirement —including limit, endurance and fault-recovery tests—. Everything recorded in the logbook.
Final documentation, user manual, delivery to the end user and defense before the examining panel. With a full run-through of the presentation at least one week beforehand, timed.
07Common mistakes
| Mistake | Consequence |
|---|---|
| Starting from the solution instead of the problem | The project solves nothing real and cannot be justified. |
| Scope too ambitious | It arrives at the end of the year half finished, and can neither be tested nor defended. |
| Vague requirements | There is no way to demonstrate that the project meets them. |
| Buying components late | The delay of a single component delays the whole project. |
| Integrating everything at the end | The problems all appear at once, with no time to resolve them. |
| Documenting at the end | The data, decisions and measurements are lost, and the report ends up empty. |
| Splitting the work into compartments | Nobody understands the whole and the defense collapses at the first cross-question. |
| Exaggerating the results | The examining panel detects it and ruins the credibility of the entire work. |
08Self-assessment
What is the correct order for starting a project?
Problem, requirements, alternatives, justified choice. Starting from the solution forces you to invent a problem to justify it afterwards.
What makes a requirement verifiable?
That it has numbers and test conditions: range, allowable error, response time, operating conditions. It is what makes it possible to demonstrate that the project meets it.
Why should at least two alternatives be put forward?
Because a design decision is justified by comparing. Without alternatives there is no choice, just a whim.
What is the critical path?
The chain of tasks with no slack: a delay in any of them delays the whole delivery. It is where attention has to be concentrated.
What are milestones for?
To detect delays in time. Without checkpoints with a deliverable, the problem is discovered at the end, when there is no margin left.
What is the most frequent cause of delay in a school project?
Waiting for a component. Buying the critical parts early and having a replacement chosen solves more problems than any design improvement.
What is counted in the budget besides materials?
Priced labor hours, third-party services, necessary tools and a contingency margin that for a prototype is no less than 15%.
If the commercial solution is cheaper, does the project lose its meaning?
Not necessarily: it can be justified by being custom-made, by availability or by the learning. What is not acceptable is to avoid the comparison.
What structure works best for the defense?
Problem, requirements, alternatives and choice, design, tests, results, conclusions and what would be done differently. With concrete data, not adjectives.
Is it a good idea to acknowledge the limitations of the work?
Yes. Saying what could not be tested shows judgment, whereas exaggerating a result is detected right away and ruins the credibility of everything else.