Info Regarding Digital Contactless Tachometers

Well, use APA writing style, one sided page, and double space your lines. That is typically a standard practice.

Start your paper with an abstract and follow the APA style for scholarly papers. That usually wastes a lot of space. Remember, you need to add lots of boring details about the problem space, the proposed solution you began your project with, why you chose that solution as your starting point, changes made to the design concept, problems encountered, solutions to the problems encountered, and lessons learned. Finally, you can drool on about your test plan to prove that the device satisfies all the requirements you developed with your design.

Another twist is you could approach it from an engineering point of view and provide a series of documents as such:

Statement of Work: Defines the basic criteria and problem space from a customer point of view. These are very high level requirements for the "product" and the proposed solution and its features and user interface. It is essentially the formal work assignment given to you by your instructor.

System Requirements Document: High level requirements that detail the design requirements. Requirements are written with "shall" statements. Each "shall" defines a requirement that must be fulfilled to satisfy the solution (your assignment). This document describes "what" to build.

Hardware & Software Design Document: These are the low level design requirements. Each low level "shall" requirement should be traceable to a high level requirement in the System Requirement Document. This document describes "how" to build the product.

Test and Verification Plan: This will detail a step-by-step plan for testing the product to prove that each high level requirement has been satisfied in the final product and that the product performs the intended function without faults or missing features. It will also test the robustness of the product to insure it performs as designed and intended. This document describes "how" you prove that you have built "what" you intended and it functions "how" you intended correctly.

Correlation Matrix: If you really want to impress your instructor, create an Excel spreadsheet that has a column for each of the above documents (except the statement of work). Start with the System Requirements Document and list each shall statement, its section in the document and its shall tag number. Each requirement gets its own row in the spreadsheet. Then, in the next set of columns list the corresponding low level requirement that traces or satisfies the high level requirement for that row. Sometimes there will be more than one low-level requirement for each high-level requirement. Finally, the last column is used for the Test and Verification Plan's test. Each spreadsheet row gets a test name that tests those requirements. This document proves that you have not forgotten anything or added something you don't need..

You may want to look up DO-178B. We use this for software development for FAA approved avionics, but the principle applies to hardware. It will teach you how to design and build rock solid products that work correctly. It seems like a lot of work (it is!), but you will be assured you have built what you have intended and it will work. Besides, you will have generated more than 80 pages of documents and your instructor will see you have an iron clad understanding of the engineering principle of design and execution. That is, if that is what he is after? If not, ignore me!