ELEC340 & ELEC440
Guidelines for Specification report: ELEC340 & ELEC440
Cover sheet
All reports must include the cover sheet template (See appendix - a word template is available
online)
If you don't know your assessor yet, you can leave this blank.
Abstract
These guidelines are a suggestion for the structure of a specification report. Your project supervisor
may have different ideas so you should consult them. Note that an abstract is different from an
introduction. An abstract is a quick summary or overview of the complete report. Someone should
be able to read the abstract in order to know if this is the report that they should read in full.
1. Introduction
This section should introduce the project as well as the structure of the report.
2. Project Description
An overview of the project. What are the aims and objectives of the project? How are
those aims going to be realised?
3. Literature Review
A complete literature review is not expected at this stage, but you should have gained an
initial overview of your project. The reference list should be structured following the IEEE
format (See examples in references section).
4. Project Specification
This is the most important chapter of this report.
Give detailed specifications of what you want to achieve by the end of the project. These
specifications will be used to judge your progress during the project.
Please agree these aims with your supervisor!
Specifications and requirements are an important planning tool in an engineering project.
Prior to starting a project, engineers need to be clear what they want to achieve, how their
work fits within a product, regulatory framework and commercial landscape. Detailed
specifications at the beginning of a project are used to plan your work by breaking it down
into small work packages and judge the success and timeliness of a project.
You (as well as your supervisor and assessor) will use the specifications drawn up in this
report to evaluate the progress of your project and your achievements. So please take great
care with this report. If your success criteria are not clearly defined, your project is more
likely to look like a failure!
Break your project down into clear work packages. When defining your work packages be
SMART.
Specific Break your project down into small parts relating to your project.
Avoid general packages such as design, built, test. Instead, break down
into packages that are specific to your project. E.g., design amplifier
stage, or design data auction protocol.
Measurable How can you judge this has been successful?
Be specific how you judge quantify success. Give criteria such as
bandwidth, power consumption, and accuracy with specific values you
want to achieve. Think what test you can do to measure that you
achieved this.
Achievable Can it be done in time with the resources you have?
Be realistic, are you sure, you can do it the timeframe or is it too much.
Relevant Does this relate to your project?
Is this package critical to your project or just a 'nice to have' feature?
Give priority to critical difficult work packages. If you finish early you
still can add additional features
Time-bound How long will this step take?
Don't underestimate external factors such as ordering components,
manufacturing PCB etc.
5. Methodology
How are you going to complete this project? What is it that you are actually going to do?
How are you planning to do it?
6. Project Plan
This section should refer to the tasks, milestones and deliverables agreed with your
supervisor (included in Appendix 2). This section must refer to a GANTT chart included in
appendix 1.
7. Project Rationale and Industrial Relevance (this section must be included)
Why are you doing this project? Is it relevant to industry? Does it have market potential? Is
it related to the research interests of your project supervisor?
8. Results
At this early stage, you might not have any results yet, but you can report on the progress
you made so far. E.g. For hardware projects, this may include any circuit designs, if you have
not started to build the circuit. For software projects, this may include hierarchical charts,
flow charts or Nassi–Shneiderman diagrams, if you have not started writing programme
code.
9. Conclusion
Summarise the report in this section.
11 Appendix 1 Specification and verification table
This table should give a detailed, verifiable overview of what you aim to achieve and set out how
each parameter will be validated. You will need to include this in your final report to analyse how
well you met the goals you set out at the beginning.
e.g. for a weather station it might start like this:
Parameter Verification
Humidity 0% to 100%, resolution 1% Test in lab
Temperature -30oC to +90oC, resolution 0.1oC Test in lab
Wind speed 0m/s to 40m/s, resolution 0.1m/s Test ….
Record data every 30s Measure data rate using ……
Save data on removable memory for up to 30
days
review calculation
Battery-powered for up to 30 days Measure current for x seconds and
extrapolate
Data displayed over an inbuilt wireless network demonstration
12 Appendix 2. List of work packages, milestones and deliverables
Work packages, in some cases, a brief description can be useful. Make sure your work
packages are 'SMART'
Project milestones - where several work packages come together
Deliverables - What will you deliver at the end of your project? Give detailed, measurable
criteria of what you want to achieve.