WESC: How to write a good report

  • Article

Posted by: Sue Loh

I have been reviewing reports for the Windows Embedded Student ChallengE and was inspired to write up this explanation of how to write a good report.  Too bad it's too late for everyone in this year's contest.  :-(  Sorry everyone.  But at least this year's finalists can use it to make better presentations at finals.  And students in the future can use it.

WESC: How to write a good report.

1. Know what you are being judged on.

Read the judging criteria and take it to heart.  This is not about convincing a professor that you understand some technical concept.  It's about creating a project that is useful and feasible.  Imagine you are forming a small company to produce a product, and that the judges are investors who are deciding whether to give you money.  You need to convince those investors of two very important things.

First, convince us that your product accomplishes a useful goal.  Your report should show that you have an original solution to the stated problem or theme.  Your solution should be commercially feasible:  It should be reasonable to expect that consumers or governments will pay the money required for your total solution -- the required eboxes, PCs, Windows Mobile devices, plus any additional hardware and software you add.  You don't have to convince us that your "company" will make a ton of money (perhaps it would be a nonprofit for the benefit of mankind), but it should be clear where the money for your product will come from.  It would be even better if you do a little market analysis -- a summary of what's already available, an evaluation what you think people/governments would pay, a survey of target customers.

Second, convince us that your team is capable of producing the product you say you will produce.  Explain your design methodology.  Explain what technical ideas you explored before reaching your final solution.  Explain your team organization.  Explain what software tools and libraries you make use of.  (Not down to the detail of, say, "grep," but tell us whether you're using the .NET framework or SQL or some 3rd-party drivers.)  Tell us what hardware is involved.  Tell us your schedule and your plans for testing the project.  Where applicable, perform trials with sample end users.

2. Be clear.

Do include a diagram of the major components in your system, and how they connect to each other.  Do explain network topology when applicable.  Don't include a lot of irrelevant information.  You don't need a circuit diagram or flow chart if you can explain your innovation in clear words.  Remember that we're not professors grading you on the minute details a project.  We're investors who just need to understand enough details in order to believe that your project works.

The judges understand that a lot of you aren't native English speakers.  Perfect spelling and grammar are not required.  But you should still be able to organize your information and argue your points.  We should be able to understand why your system is good, how it works, and how you accomplish it.

Stay focused.  Don't suggest features or extensions that you don't need.  Rather than making your project more compelling, they will make it seem more complicated, confusing, and unplanned.  Convince the judges that every feature is well thought out.

3. Be complete.

Judges will deduct from your score if your project is incomplete: if it has fatal flaws that would hurt your product if you tried to sell it as-is.  Even if you don't have time to address these flaws, you should at least note them and explain in your report how you'd go about solving them if you were to really make this into a commercial product.

Think of the overall result you are presenting.  How will users react to it?  What requirement is being placed on the education or skills of the users?  Are there security issues?  Are there privacy issues?  Will you have to deal with users who try to break the solution?  (eg. if your project is monitoring equipment for a vehicle or a factory, would the vehicle or factory owner try to sabotage the results to avoid government inspection?)  What kind of local or national infrastructure is required, and could it be "phased in" a little at a time?  How badly would power or network outages affect the project?

When you describe your testing, cover all the points that would be really important to the total solution.  You don't have to describe item by item but you should explain your methodology.  If sensor measurements or image processing is involved, what error rates to you get?  Do performance testing when it applies.  If battery lifetime would be important, measure it.  If network throughput or latency would be important, measure it.  Measure scaling factors: if one ebox connects to many sensors or cameras, how many connections can a single ebox handle?  If many eboxes connect to each other or to a PC, how big can the network get?  How many users or customers can the total system support?  If you encouter problems that you haven't solved yet, explain how you'd work on them.

In summary.

Here is the critical question to ask yourself:  Do I believe this could really happen?   The more the judges believe that it could, the better.

Good luck!

 

UPDATE Nov. 7 2006: Even better, this year they are clearly publishing the judging criteria online.  Please see https://imaginecup.com/Competition/EmbeddedApplications.aspx.  Take the criteria to heart!  Write your report with these in mind!

  • Originality and Creativity (25%)
  • Relevance (25%)
  • Feasibility and Analysis (25%)
  • Planning and Teamwork (15%)
  • Quality of the Report (10%)