As engineers, the majority of what you have to do will involve either the words "build this to do that" or the words "how are we going to fix this so it can do that"? In most companies or organizations in which we work you will be asked to design something, build and test it, and then submit a report on it. The way the company asks you to do something is typically called a "request for action", or "task requirement" or something like that. One might look like this.

Complete the following system design project:

Required Actions

From this requirement you should develop in your head an idea of how you can break up this requirement into smaller tasks that you can do piece by piece (it also saves a HUGE amount of headache if you write down these ideas in your notebook as a plan). A plan of action for the above project might look this:
 
 

Report

A good project report should include the following parts:

1. Title page including name of project, name of team or division, names of team members and author, and date. In your case, since you are not working on teams, include the title, your name, date, and class.
2. Abstract - an abstract is a concise, one paragraph description of your entire project. This may sound hard to do but it doesn't need to be. In this case a good strategy would be to include one sentence describing the needed features of the function generator you had to design and one sentence for each of the four individual labs/parts of the bigger project. Later in the report you will say all this again in greater detail - that's the idea.
3. Design procedure - brief description of the total design process. Here you want to describe each part of the plan, each lab you did, with a few sentences in a short paragraph. Talk about what you did in Pspice - how you simulated the design - in one paragraph. In the next paragraph note anything you would want to know about building the system on the protoboard and the process of testing it. You don't need to include results as there is another section coming for that. You also don't have to be as rigid as one paragraph for each section, but remember you don't have to write a book. The goal of this part is to convey enough of the right information that someone coming to the project cold could reproduce your progress so far.
4. Theory of operation - here you should describe how and why the function generator works (including the LEDs) including any equations and formulae you developed or borrowed (mention where they came from) that can be used to determine the characteristics of the system (include the equation for f_osc in this part). You should go into enough detail that someone of your own level of expertise could pick up the report and understand the basics of how the device works. Include a block diagram of the system in question (the function generator) in this section.
5. Results and Conclusions - In this section you say whether the design did what it was supposed to, plain and simple. Don't try to say anything the right way, just say it. If the design did not meet specs, or if it was kind'a in the gray area explain exactly what it did and how close it got. Mention anything that didn't look right and briefly describe your conclusions about why it did or did not perform as expected and where you think you should go from here.
6. Appendix - Last but not least you should include the following pertinent information in an appendix

Copyright 2000, New Mexico Tech