REQUIREMENTS FOR WRITTEN REPORTS Introduction to reports in Project The ability to prepare high quality documentation is a very important

skill that each engineer has to demonstrate throughout his/her career. The reports prepared in Project lays the foundation for this. You have to be proud of your Project reports. The final report is the only permanent record of your work. Even if you did excellent technical work (either in Project or further in your career), a poor report will create a bad impression of your work. Reports of very high quality are expected in Project; this is the norm, not the exception. Consider buying a good textbook1 on technical writing, and also attend in class, where the Project Proposal and other project reports will be discussed in some detail. You will find that different employers require technical reports in different formats in your future career. Details on the required contents and format of the project reports in this module appear below. You must adhere to this format strictly. You will notice that the requirements differ for the various reports. Incomplete or unsatisfactory reports WILL be penalised HEAVILY and will have to be revised. Instructions for the various reports appear in Appendices 2, 3 and 4 of the Project EPR400/EPR402 study guide.

e.g., Beer,D. & McMurrey,D., "A Guide to writing as an engineer", John Wiley and Sons, NewYork, 1997

APPENDIX 2.

REQUIREMENTS FOR THE PROJECT PROPOSAL

The project assignment you received from your study leader may be regarded as a concept proposal, which you have to develop into a full project proposal. When approved (through the Project Proposal submission process), this proposal will then be your agreement with your study leader and the Project Lecturer (prof. J.J. Hanekom) on the deliverables of your project. The approved Project Proposal must be bound into the final report, and examiners will use this as a reference against which your outputs will be evaluated at the end of the year. It is compulsory that this report should contain exactly the layout and contents described below. Use the provided numbering scheme below. More detail on what is required will be discussed during the lectures. Examples of previous Project Proposals will appear on the Project website. The length of the proposal should typically be around four (4) pages, excluding the title page.

2.1 TITLE AND APPROVAL PAGE Choose the title of the project (as given on the Project Proposal) carefully. The title on the approved Project Proposal will be the final official title of the project and can only be changed with written permission from the Project Lecturer. The first page (cover) is a title page that also serves as an approval page that contains declarations by your language editor and your study leader. Follow the English and Afrikaans templates on the Project website for this cover page. The title page should not be numbered. Use the font sizes and layout as used in the template. Note that the study leader (whose name appears on this page) can only be a lecturer in the Department. In some projects, a co-studyleader may be someone external to the University. His or her name may also appear on the cover page, but there is no requirement that a co-studyleader needs to sign the Project Proposal.

2.2 CONTENTS OF THE PROJECT PROPOSAL Introduction As explained in class, there are some slight differences between the Project Proposals for design projects and investigative projects. Design projects comply primarily with ECSA exit level outcome 3 (design - say 70%), while having a component of investigation (outcome 4 - say 30%) as well. Investigative projects typically have a larger investigative component (outcome 4) and a smaller design component (outcome 3). This is reflected in the way the Project Proposal is formulated, as described below.

Sections of the Project Proposal 1. Problem statement This section answers the question, WHY? This section will be the same for design projects and investigative projects. This section gives a problem statement, a motivation for the work, and contextualises the work by giving appropriate references to literature. You should have at least four paragraphs in this section, as described below. (i) Motivation paragraph. First, state the problem briefly in engineering terms. Ensure that you describe the problem and the context thereof, and not a summary of what you will be doing (i.e., do not describe your solution to the problem). Commence with a phrase like "The problem addressed in this project is...", or, "The motivation for this project is". For example: "Crime is a growing problem in South Africa [1]. Existing video surveillance of sensitive areas does not appear to be an adequate deterrent any more. Thus, the problem addressed in this project is to develop a new kind of multi-technology surveillance system based on audio and video data to act as stronger crime deterrent. " Notes: (a) This paragraph should motivate the necessity of the work. (b) Note the reference given in square brackets in the example above. This is a reference to the source of this particular statement; e.g., (for this particular example) this will be some source of crime statistics. Be careful not to make sweeping statements; always support your claims or statements with appropriate references. (ii) Context paragraph. The subsequent paragraph gives more background on what is presently available or techniques that are presently applied. The aim is to describe the context of the problem, and to assist with this, references to literature are given. This paragraph will end with a sentence or two on how your project will extend the work reported in the references that you provide, or how your work will contribute to existing knowledge or technology. Technical challenge paragraph. Next, state the engineering challenge (or technical challenge) explicitly. Typically, you will use a sentence that commences with "The engineering challenge is ..." or "The technical challenge is". The engineering challenge is that aspect (or those aspects) of the project that makes it a technical challenge for a final year engineering student. For example: "The technical challenges in this project are: (i) to develop new technology to from first principles; (ii) to design an algorithm that will ".

(iii)

(iv)

Limitations paragraph. Any engineering challenge always includes limitations or restrictions that the student (or engineer) has to contend with. Therefore, state these clearly in a final paragraph. For example: "Limitations to contend with is the restricted available bandwidth. Because limited bandwidth is available, video data will have to be compressed before transmission".

2. User requirement statement (for design projects or investigative projects) or Objectives (for investigative projects) For investigative projects, you may use either of these headings as appropriate for the specific project. Some investigative projects are in fact open-ended design projects, so that the headings for design projects would be more appropriate. Content of this section This section answers the question, WHAT? This section describes the mission requirements of the system. E.g., what should the product do? Or, for investigative projects, WHAT are the needs addressed by this project? We discussed in class a number of questions that one should ask a client, and this section of the Project Proposal should include the answers to many of these. You should give a description of the proposed system or solution as you visualise it. This is not a list of measureable specifications, but rather a description of the visualised requirements in the language of the client. Also, these are requirements of the product, and not your tasks. For design projects (and for the design part of investigative projects) you should provide a description of what the product should do. I.e., describe all aspects of the system as visualised, including where it fits in (e.g. part of a larger system with specified inputs and outputs; a description of the environment in or circumstances under which it will be used). You don't need to include any additional requirements that cannot be classified as mission requirements of the system or product to be developed. For example, some of the deliverables may include simulations before the final product is implemented. These would typically not be part of your final product or system and should usually not be expanded on in the mission requirements. These should, however, be mentioned in section 5 (Deliverables). For investigative projects, this section will be the same as above for the design part of the project (i.e. visualise the characteristics of the product). However, the investigative part of the project is described in a different fashion by (i) describing the project objectives of the project in list format (paragraph with heading: Project objectives), and (ii) by explicitly providing the research questions that will be addressed (Paragraph with heading: Research questions). The set of objectives as described in this paragraph is an expansion or breakdown of the overall project objective into measurable outcomes. I.e., these are the outcomes that you aim to achieve at different stages of the project

in order to meet the objectives of the project. Objectives may include the design of experiments and development and experimentation with simulations. Formatting of this section Give the user requirements in bullet list format. Ensure that you always use the correct format for a list (see the list of common errors on the Project website). Always commence with an introductory paragraph before you give a list. Then provide a detailed description (in list format) of the mission requirements of the system that you have to design. For investigative projects, use these additional headings: 2.1 Design part of the project 2.2 Investigative part of the project 2.2.1 Project objectives 2.2.2 Research questions 3. Functional analysis (for design projects or investigative projects) or Approach (for investigative projects) For investigative projects, you may use either of these headings as appropriate for the specific project. As mentioned earlier, some investigative projects are open-ended design projects, so that the headings for design projects would be more appropriate. Content of this section This section answers the question, HOW will the problem be solved? This is a description of your approach to solving the problem. For design projects, this will be in the form of a functional analysis. Also, the design part of investigative projects should be presented as a functional analysis. For design projects and the design component of investigative projects, you will have to show a first systems-level design in the form of a block diagram. Therefore, for the design component of projects, provide a functional block diagram and give a complete description of the system functions. Define the inputs and outputs explicitly. Note that there will be a strong correspondence between the specifications (next section) and the functional block diagram. In addition, although you may also include this for design projects, it is imperative that you give a task breakdown or description of steps to be followed for investigative projects. This should be in the form of a separate block diagram and description, distinct from the functional analysis. I.e., the functional analysis is used to break a product down into its functional units, while the task breakdown describes the tasks or design steps of the engineer. Formatting of this section The functional description must be in paragraph format.

For investigative projects, use these additional headings: 3.1 Design part of the project 3.2 Investigative part of the project

4. Specifications (for design projects or investigative projects) or Target specifications (for investigative projects) As before, for investigative projects you may use either of these headings as appropriate for the specific project. Content of this section Compile system specifications to specify the inputs, outputs, system functions, and the environment in which your design will have to operate. This answers the question, HOW WELL should tasks be performed? For investigative projects, this translates to target specifications (i.e., you may not know exactly which specifications are achievable, but you will have some target in mind) and requirements with which the deliverables will need to comply. An example is given towards the end of this section. Certain details will not be available yet, and you are not expected to complete a design before you write this section. I.e., you should focus primarily on the aspects that define the system, i.e. the global specifications, and not the detailed specifications defining subsystems. For example, when you design a digital communication system, aspects like desired data rate may be important, but details on the power supply may not. You should commence with one or more specifications that characterise the system as a whole (the global or overall system specifications). These are the most important, i.e. the mission-critical specifications. Next, ensure that there are specifications for each functional block (where appropriate). These provide measures against which you can measure that each functional block performs its task correctly. There will usually be a one to one correlation between the specifications and the functional block diagram. Finally, it is required that you also give a clear description of the origin of each specification. Use the following headings in this section. 4.1 Mission-critical system specifications 4.2 Detailed specifications System specifications for design projects (and the design part of investigative projects) must describe how well (in measureable terms, whether measured with (e.g.) an oscilloscope or measured against some standard or yardstick) the functions (those in the functional analysis) should be performed. Specifications may be expressed as performance specifications (typically

measured with an instrument) and/or functional (operational) specifications that specify functionality only (e.g., you have to implement a specific protocol). There will still be a yardstick against which you measure in this latter case, e.g. you have to implement the USB 1.1 protocol correctly, and this will be measured by communicating correctly with a USB device. Note also that specifications may be regarded as mission-critical or designcritical (e.g., to drive a 1 kW machine, you will need at least 1 kW of input power) or as target specifications (e.g. 80% correct identification for a speech recognition system). Note that in the latter example, environmental factors will influence the choice of target specification, and these should also be specified clearly (e.g., the speech recognition should be at least 80% correct when isolated words are spoken in quiet conditions with background noise level smaller than 20 dB SPL). Specifications to include for design projects (or the design part of investigative projects) may be: tolerances, signal-to-noise ratios, quality of required signal, perhaps specifications in terms of test programs, test vectors or test signals to be used. Examples were discussed in class. For the investigative part of design projects, or for investigative projects, you may typically have more target specifications and fewer design-critical specifications. Also, the outcomes of investigative projects are often measured against what has been achieved before (as described in journal articles). This may used to define target specifications, e.g. "The expected outcomes should match those of Johnson and Mathibe (2010)". Finally, an alternative approach for investigative projects would be to describe specifications as requirements with which the deliverables have to comply. E.g., if one of the deliverables is to perform an experiment at different signal to noise ratios using different algorithms, the specifications may say something like: "The experiment should be repeated at SNRs of -10 dB, -5 dB, and 0 dB for each of the algorithms A, B and C. The experimental outcomes should be compared for noise suppression and the trade-off with complexity of implementation". Formatting of this section Give the specifications in table format under each of the two headings mentioned above see the provided template for an example. Each specification must be motivated, or the origin should be described. 5. Deliverables This section answers the question, WHAT WILL BE SHOWN? Describe (mostly in bullet list format, see below) what you are going to deliver at the end of the module. All deliverables should be mentioned, including PC boards, computer software, software for embedded processors, simulations, test programs and experiments. You should not list (e.g.) the final report as a deliverable; list only technical outputs of the project as deliverables. This section will be similar for design projects and investigative projects. The following headings are compulsory.

5.1 Design and investigative components Clearly define both the design component and the investigative component of your project in this paragraph. You may use paragraphs that commence with "The design component of this project is" and "The investigative component of this project is". For example, "The design component of this project is the design and implementation of the modulation, encryption and demodulation schemes on a DSP board. The investigative component comprises an investigation into the most appropriate modulation scheme, given the requirements for high data rate at low power". 5.2 Technical deliverables List every deliverable in detail (including simulations and experiments), and indicate explicitly whether this deliverable will be designed by yourself from first principles, or will be taken "off-the-shelf" (i.e. complete subsystem provided by a third party, e.g. bought or downloaded from the internet). List only deliverables that are part of your product, not things like your reports and orals. NOTE: the assumption will be that every deliverable not described as "off-the-shelf" will be designed and implemented by you. Nonetheless, you should still indicate this clearly in your Project Proposal. 5.3 Additional project requirements Here you need to list your tasks that are not necessarily part of your final product, but are nevertheless required as part of your project (e.g. simulations). There may not be additional requirements in every project. If there are none, then this section should simply state "There are no additional requirements in this project". 5.4 Demonstration at the examination Visualise and describe explicitly what you plan to demonstrate at the final examination, keeping in mind that this will be a 10 minute demonstration. This should be a step-by-step description, for example: "The demonstration will commence by placing the robot in the middle of the soccer field. A command will then be given to ". Formatting of this section Give the deliverables under headings 5.2 and 5.3 as bullet lists. Sections 5.1 and 5.4 may be in paragraph format. 6. References A reference list is compulsory. Cite the journal articles, books and/or internet sites that you consulted to prepare your Project Proposal. Use either the Harvard format described in Appendix 6 of the Project study guide, or IEEE style (please check your study leader's preference). The library's website contains links to both reference styles. Ensure that you use the chosen format correctly and consistently. If you participate in a group project, refer to your colleagues formally, and as if they have already completed their projects, as in the following example.

This is how the reference will look in the reference list (when using Harvard style):
Johnson, P.P., 2012. The design of a high power 12V to 220V inverter (Final report for Project EPR400). Pretoria: Department of Electrical, Electronic and Computer Engineering, University of Pretoria.

In the text, refer to this student's work in the following formal way (Harvard style example):
The current project is a collaborative effort with Johnson (2011), who will develop the inverter shown on the functional block diagram.

2.3 SUMMARY OF HEADINGS IN ENGLISH AND AFRIKAANS Table 1 below summarises the headings to be used for design and investigative projects, and gives the correct Afrikaans headings as well.
Table 1. Summary of headings in English and Afrikaans (in brackets) for the two types of project. Design projects Investigative projects Problem statement Problem statement (Probleemstelling) (Probleemstelling) User requirement statement User requirement statement or Objectives (Gebruikersbehoeftestelling) (Gebruikersbehoeftestelling of Doelwitte) 2.1 Design part of the project (Ontwerpsgedeelte van die projek) 2.2 Investigative part of the project (Ondersoekgedeelte van die projek) 2.2.1 Project objectives (Projekdoelwitte) 2.2.2 Research questions (Navorsingsvrae) Functional analysis Functional analysis or Approach (Funksionele analise) (Funksionele analise of Benadering) 3.1 Design part of the project (Ontwerpsgedeelte van die projek) 3.2 Investigative part of the project (Ondersoekgedeelte van die projek) System specifications System specifications or Target specifications (Stelselspesifikasies) (Stelselspesifikasies of Teikenspesifikasies) Mission-critical system specifications Mission-critical system specifications (Missie-kritiese stelselspesifikasies) (Missie-kritiese stelselspesifikasies) Detailed specifications Detailed specifications (Detailspesifikasies) (Detailspesifikasies) Deliverables Deliverables (Aflewerbares) (Aflewerbares) Design and investigative components Design and investigative components (Ontwerp- en ondersoekende komponente) (Ontwerp- en ondersoekende komponente) Technical deliverables Technical deliverables (Tegniese aflewerbares) (Tegniese aflewerbares) Additional project requirements Additional project requirements (Bykomende projekvereistes) (Bykomende projekvereistes) Demonstration at the examination Demonstration at the examination (Demonstrasie by die eksamen) (Demonstrasie by die eksamen) References References (Verwysings) (Verwysings)

2.4 FORMAT OF THE PROJECT PROPOSAL It is easy to follow the rules for proper formatting and it is expected that a final year engineering student do this accurately. Students that make mistakes here will be penalised heavily. Use the template provided on the Project website. Language: The report must be in English only or Afrikaans only. You are advised to write in the language most familiar to you. Mixing of languages is unacceptable. No ring bound or glue bound reports are allowed. Staple the document with three or more staples on the left edge of the paper, so that the pages turn like that of a book. Laser quality printing is required. Use 12 point font size. Use a serif font (like Times Roman) and not a sans-serif font (like Arial). Do not mix fonts in your report, but use the same font throughout. Spelling errors are completely unacceptable. Poor language and grammar is unacceptable. It is a requirement that your report is proofread (edited for language and spelling) by someone who either writes very well or is a professional language editor. The language editor's name and signature must appear on the Project Proposal. Write in formal style. You may never write in the first person. Do not write in a conversational style. Also do not give a chronological account of what you did. The report should be factual and not bound to you as a person. This is a technical report, not a personal narration of your experiences and ideas. Give the facts in a brief, clear and professional manner. You may never write in telegram style. Use full sentences, unless you are writing a section in list format. In that case, make sure you use the correct list format as prescribed. Appendices: No appendices are allowed in the Project Proposal. Footnotes: If you want to refer to a footnote in the text, put the number of the footnote directly to the right of a word as superscript, for example: "Here FDM1 is used in stead of TDM2". You must then give an explanation at the bottom of the same page. Draw a line across the page at the bottom of the page (typically from margin to margin, or from the left margin to at least halfway across the page) and place the footnote below this line. Number the footnote with the same superscript number against the left margin. Print the footnote in 8 point font size. Footnotes are numbered consecutively throughout the text.

Binding:

Printing:

Spelling: Language:

Style:

Page layout Use the template provided on the Project website. Where discrepancies appear to exist between the guidelines below and the template, the latter takes priority. The numbers below are guidelines. Margins: 30mm left, 20mm right, 20mm bottom, 20mm top. Line spacing: single Section headings: uppercase, 18 point bold font; Subheadings: 14 point bold uppercase; sub-subheadings 12 point bold and italic. For further depth of subheadings: lowercase, 12 point bold and italic. Numbering of headings: Use the numbering scheme above. Subheadings: (e.g.) 1.1.; sub-subheadings: (e.g.) 1.1.2.; for further depth of subheadings: no numbering. Left justify headings. Underline section headings with a horizontal line from margin to margin. Page numbering: lower right corner. Print only on one side of the paper. Use either left justification or full justification for all text. Leave one blank line between paragraphs and do not indent the first word of a paragraph. Figures and tables Tables and figures may not flow from one to the next A4 page, and A4 sized figures are preferred to larger figures. For A3 sized figures, fold the figure appropriately so that the orientation is the same as that of the rest of the text. All tables and figures should preferably have the same orientation as the rest of the text, or be placed with the bottom of the figure facing towards the outside edge of the page. Under all circumstances, the caption should be upright. Text in figures should be in the same language as the rest of the text and also in the same font. The minimum text size in tables or figures is 8 point font. Number tables and figures separately from number 1. Do not use frames around figures. Captions appear below figures and tables. Figures and tables should each have a short description printed in the caption. Print the figure or table number as well as the caption in bold. Below is an example of a caption.
Figure 1. The figure shows data as measured for the protection circuitry. Note that the current limits at 10A.

All figures must be referred to in the text of your report.