MEMO Number <It's always a good idea to uniquely identify your notes> DATE: <and to date them> TO:

<Standard form. You can address this one to me> FROM: <and of course we need your name> SUBJECT: <and a subject>

INTRODUCTION

The form that I've provided in this document is one that I have used on hundreds of "internal" notes. I use these to document significant amounts of work that I have done. My notes range from 2-3 pages to 70+ pages. These are my own record of my work. They are intended to capture my thoughts (even if wrong) and the rationale for my decisions. Although I have used these notes or memos as the basis for conference and journal papers, they are intended as a much less formal development of the information. In that sense, they truly do serve as "notes" for the more formal paper. The basic structure is flexible and varies with the subject I'm discussing. You might consider Introduction, Problem Statement, Background, Analysis, Discussion, Conclusions, but you don't necessarily use everything in every note. In my mind, the most important section is the Introduction. I usually write it twice, once when I get started and then again after I get done. A good principle to follow is "Tell what you are going to tell, then tell it, then tell what you told". The introduction is the "Tell what you are going to tell part". It doesn't hurt to summarize the results in the introduction. The Introduction should enable a manager or co-worker to get a feel for what you did and why. It should not have any detailed analysis. I try to limit my introduction to no more than 1 page in these kind of notes, although I confess to having several 2+ page Introductions. I've provided a sample tech note. You will note that the example is much simpler than anticipated in this document. That's acceptable if the problem warrants it. I also have examples that are much more detailed.

PROBLEM STATEMENT

What is the problem? It is amazing that many people automatically assume that their audience already is up to speed with the problem. I've found that the readers even knowledgeable readers appreciate some description of what you're trying to do. And you will appreciate it as well when you come back to refer to the memo 10 years from now. 3 BACKGROUND

Sometimes I combine Problem Statement and Background. Background sets things up for the discussion and analysis to follow. It doesn't need to be a textbook! For example, if our problem involved analyzing differences between satellites in geo-synchronous and low Earth orbits, we
Page: 1 Honeywell,International, Inc. 2007 All rights reserved Tech Note Format saved 2/10/2010 7:56:00 AM printed 4/11/2010 2:29:00 PM

would probably want to explain those terms and provide some key definitions. As with the other sections you may or may not include this one, depending on your subject matter. 4 ANALYSIS

This section "does the math" for the problem. Because much of what I did as a system engineer was analytical in nature, I almost always have a section named "Analysis". This is where you build the mathematical models that enable you to address the problem at hand. Major equations should be numbered so you can refer to them later. A very useful add-in for Microsoft Word is the MathType equation editor. Linux/Unix people will probably use LaTeX. MathType can be LaTEX compatible. I use it constantly: I use it for all of my equations for lectures. Personally, I prefer figures that are in-line with the text, so I don't have to keep going to the back of the paper to see the figures. But you are in control of that decision: choose the way that works best for you. One hint: when inserting a figure into a Word document, I've found that it is much more effective to use some other drawing tool even PowerPoint is OK, Viso is better and then to copy the figure and paste it in (Paste-Paste Special) as an Enhanced Metafile. If you do it this way you can't edit it in Word (which isn't a very good drawing editor anyway) but you can scale it properly. Again, that's just advice, not requirement. 5 DISCUSSION

Once you have done the analysis, you need to discuss what it means to the problem at hand. Do your models have weaknesses? Don't be afraid to admit it! If you can find a weakness, someone else will be able to as well. It is much better to acknowledge them yourself. For example, we might do an analysis of the signal processing in a radio and make the assumption that we have a floating point processor available. Make sure this kind of assumption is stated. Not only will it make your point more clearly, it will enable you to reconstruct your thinking when you come back to the subject years later. 6 CONCLUSIONS

In longer papers, it is a good idea to specifically summarize the conclusions of your discussion and analysis. In shorter papers, you can combine this with the discussion. If you have any very involved derivations, you might want to move them from your Analysis section to an appendix. We usually identify appendices as Appendix A, Appendix B, etc. After the Appendices, put your references. Use IEEE form, as I've given you in the past. A very useful add-in to Microsoft Word for the creation of references is EndNote. I think it's available in the Bookstore or maybe even for download at student prices.

Page: 2 Honeywell,International, Inc. 2007 All rights reserved Tech Note Format saved 2/10/2010 7:56:00 AM printed 4/11/2010 2:29:00 PM