In this guide
Most custom-project disappointment traces back to the requirement, not the build. "I need an IoT project" produces a technically fine system that misses your evaluation criteria, your deadline, or your syllabus — and fixing it mid-build costs far more than specifying it right at the start. A complete requirement has four parts. Write all four before anyone orders a component.
Part 1: What the project must do
List the features in priority order — must-have first, nice-to-have clearly marked. "Must monitor soil moisture and send a phone alert below 30%" is buildable; "smart agriculture system" is a conversation starter, not a requirement. Priority order matters because when time runs short (and it will), the builder needs to know what to protect and what to cut. If you’re unsure what’s realistic, check how to pick a project that fits your timeframe before finalising the list.
Part 2: Tech-stack constraints
This is the part most people skip — and the most commonly missing piece in failed requirements. The idea is rarely the problem; the constraint is. State explicitly:
- Required: the board, language, or platform your syllabus or guide demands (e.g., "must use Arduino Uno — it’s what our lab stocks").
- Forbidden: anything you can’t use — no cloud dependency if your demo venue has no internet, no components your guide won’t approve.
- Available: what you already have — lab equipment, software licences, a 3D printer — so the build plans around reality.
A builder who knows your constraints designs within them. One who doesn’t will pick the technically elegant option that your examiner rejects.
Tip: When in doubt, over-specify constraints and under-specify implementation. "Must run on ESP32, must work offline" is useful. "Use exactly these three libraries" is micromanagement that blocks better solutions.
Part 3: Submission format and deadline
Spell out what "done" looks like and when:
| Item | Specify |
|---|---|
| Working system | Finish level — breadboard prototype or enclosed, presentable build? |
| Report | Full report or system-only? Page expectations, revision rounds |
| Presentation | Deck needed? How many slides, for what audience? |
| Demo | Live demo date and venue constraints (power, internet, space) |
| Deadline | The real date — submission day, not "around March" |
Deadlines drive timeline and cost: a two-week rush and a six-week standard build are different products at different prices. State the real deadline upfront — discovering it mid-build helps no one.
Part 4: Domain knowledge
Who is this for, and where will it be used? A soil-moisture system for a college demo and one for an actual farm need different enclosures, power supplies, and reliability levels. Tell the builder about the users, the environment (indoor lab vs. outdoor field vs. classroom demo), and any evaluation criteria your guide or university applies. Domain context is what turns a generic build into your project — it’s also what makes your synopsis and viva answers specific instead of generic.
Vague vs. specified
| Vague (causes rework) | Specified (buildable) |
|---|---|
| "IoT home automation project" | "Control 4 room appliances via phone app; ESP32; must work on local Wi-Fi without internet; demo on 15 March" |
| "Sensor-based project for final year" | "Monitor temperature/humidity in a 10×10 ft lab room; log to SD card every 10 min; Arduino Uno; report + deck needed" |
| "Something with AI" | "Classify leaf images as healthy/diseased using a pretrained model on Raspberry Pi; 85%+ accuracy on 200 test images; offline" |
Warning: Late changes cost more — sometimes much more. Adding "oh, and it needs a mobile app too" in week three means redesigning the firmware’s communication layer, not just "adding an app." Every change after work starts re-prices the affected parts. Freeze the requirement in writing, and route new ideas through a proper change decision: is it worth the delay and the cost?
The requirement template
Copy this into a document, fill it in, and share it before work begins:
- Project title (working title is fine)
- Must-have features (numbered, priority order)
- Nice-to-have features (clearly marked optional)
- Tech constraints — required / forbidden / available
- Deliverables — system, report, deck, code, in what finish level
- Deadline — demo date and submission date
- Domain context — users, environment, evaluation criteria
- Budget range — so the design fits what you can spend
A one-page requirement written in an hour saves weeks of rework. It also protects you: when both sides agreed in writing, "that’s not what I asked for" stops being an argument and starts being a checklist item.