Basically, what you are trying to do in a report is to provide a convincing argument for your reader. Identify the problem at hand and your proposed solution. Include only points that affect your argument (positively or negatively); leave out irrelevant information that has no ties to your argument.

Since this is a technical report, your writing style should be formal. Avoid using contractions (e.g. don't, aren't), colloquial language, and whatever else you were told to avoid in technical writing in your highschool English classes.

Know your (intended) audience. Your assignments are indeed graded by TAs, but the intended audience is the personel in a company. This means that your interviewee, a developer, a project manager, a marketing manager, a project leader, etc. should all be able to read your reports and understand them. So, define the terms and acronyms you use.

Make your report well structured. Always include an introduction so the reader knows what you are going to tell him/her. Present your argument coherently and logically. Conclude with a summary or concluding statement so the reader knows what you tried to communicate.

Any point you use in your argument should be backed up by some evidence. Your evidence should come from reliable sources. When you quote someone or some article, you need to put the sentences in double quotes and the source needs to be acknowledged. For example: ... "the system is still 80% reliable" (Smith, PC). If you are quoting from an interview, you can source the interviewee's name and put "PC" for "personal communication". Alternatively, you could reference the appendix which has a record of the conversation.

When figures/tables are provided, an accompanying explanation or description is needed. Do not expect the reader to understand the shorthands or notations you use. Sometimes the structure of the tables can be very unintuitive. In general, you should explain at least the first row of entries in the tables or a small component of the figures so the reader knows how to make sense of it all. A bunch of numbers or nodes won't make sense by themselves.

A summary of comparisons is probably a good idea. If it is succinct, you could do this in a paragraph. Otherwise, a list or a table of features would probably be more suitable.

Sections should be well named and well numbered. Linear text is very hard to read unless it is well structured.

The above points apply to appendices as well. When you make reference to some supporting evidence, you need to say where the source come from. If more detail is found in the appendices, then reference the appendix section. Furthermore, each appendix should also be well named and well ordered. If an appendix has a GUI snapshot or a table of values (or other kinds of tables and diagrams), it should have a short explanation that describes what that specific appendix is about. Otherwise, the appendices would just be a collection of a bunch of miscellaneous papers.

Your argument should be easy to follow. Good writing helps to achieve this.

It may be helpful to know that your assignments (and tests) are graded based on effort as well as correctness. A lot of the students seem to think that it's good enough they put something down on paper and handed it in. Effort is definitely a big part, since it determines what you hand in. However, we want to also make sure you understand the material. So we grade on correctness as well. Therefore, if there is something you are not sure about or you don't understand, ASK. I've been told this is not a UofT tradition, but it is a piece of advice that will probably help you excell in this course.