DEPARTMENT OF ELECTRICAL

AND ELECTRONIC SCIENCE

DOCUMENT FRAMEWORK

COURSE:

B.ENG. (ELECTRICAL AND ELECTRONICS)

VERSION CONTROL
ACTION

PERSON

DATE

Design

Dr WA Clarke

2007

Modified

Dr WA Clarke

2009

With contributions from:

Prof J Meyer

Prof I Hofsajer

TABLE OF CONTENTS

1 DESIGN PROJECT DOCUMENTATION FRAMEWORK

2 FRAMEWORK OVERVIEW
3 STYLE AND FORMATTING GUIDELINES
3.1 INTRODUCTION
3.2 LANGUAGE, GRAMMAR AND TONE
3.3 GENERAL DOCUMENT STYLE AND FORMATTING GUIDELINES
3.4 TITLE OF DOCUMENT
3.5 DOCUMENT FRONT MATERIAL
4 CHECKLIST BEFORE HANDING IN A CHAPTER
5 CHAPTER 1: PROBLEM STATEMENT
6 CHAPTER 2: REQUIREMENTS ANALYSIS
7 CHAPTER 3: LITERATURE STUDY
8 CHAPTER 4: DESIGN
9 CHAPTER 5: EXPERIMENTAL DESIGN
9.1 TEST AND EVALUATION STRATEGY
10 CHAPTER 6: IMPLEMENTATION OVERVIEW
11 CHAPTER 7: RESULTS AND ANALYSIS
12 CHAPTER 8: CONCLUSIONS
13 REFERENCES
14 APPENDICES

Dr WA Clarke

2009

3
4
6
6
6
7
10
10
13
15
19
23
25
27
27
30
31
32
34
36

2 of 38

1 DESIGN PROJECT DOCUMENTATION

FRAMEWORK
In this document, a documentation framework is provided for documenting a design
project in such a way that the 5 ECSA outcomes are demonstrated.

Please note that each project is unique. This suggested heading structure is based on a
design-type project, and not for a research-type project.

However, some of the

headings may still be applicable

This is only a recommended framework, and learners are free to use their own initiative.
However, experience has shown that Project Investigation is the first encounter that
learners have with this scale of documentation, and need some initial framework to get
them started. Our suggestion is therefore to follow the framework closely, especially as
a learning exercise.
Remember that each chapter has to have a central theme and has to fit in logically with
the rest of the work. Information that will disturb the flow of the work (e.g. instructions
on how to use certain measurement apparatus) should be moved to an appendix.

Dr WA Clarke

2009

3 of 38

2 FRAMEWORK OVERVIEW
The following figure depicts the design framework:

Figure 1: Design Project Documentation Framework

There is a flow throughout the framework, and one step follows from the previous step.
The documentation flow must follow this framework flow.
Any design project will benefit from Project Management. This management process
sets up a plan to help you to successfully complete the design process. In this plan,
risks are identified and mitigation strategies put in place, the financial impact analysed
and a work plan put in place to follow. Remember that equipment acquisition is a
lengthy process and must be planned for.

In the Problem Statement phase, the problem is introduced, the context in which it
lives as well as the objective of the design project. Included in this is also the scope of
the project.
The Requirements Analysis phase follows on the problem statement. In this step the
problem is analysed in detail to better understand the issues involved.

Dr WA Clarke

2009

Also in this

4 of 38

phase, the requirements for the project are listed, including the quality and performance
specifications that must be complied with.
In the Literature Review, all the necessary tools to solve problem and fulfil the
requirements must be identified.

This includes theory, components, tools, etc.

It

creates the knowledge pool from which you will draw during the rest of the project.
The Design phase is the creative part of your project. Drawing from the knowledge pool
(in the literature review) and your understanding of the problem, you create design
options.

Each option must be evaluated against the requirements, and finally one

design is chosen (obviously with a good motivation). A more detail design of this final
design option must then be made.
In the Implementation phase, the chosen design is implemented and made to work.
The documentation should reflect the implementation details, i.e. choices made, design
parameters, tools used, programme development, issues identified, pictures and photos
of the process, etc.

Document everything used in the process of fulfilling the

requirements.
The Results phase constitutes a critical evaluation of your design. Tests and
experimentation are performed; the results documented (tables, figures, graphs) and
discussed, and compared to the performance requirements.
Finally, the Conclusion phase is reached.

In this phase, you evaluate the project at

arms length. Step back to the project objectives and scope, and with reference to the
requirements, judge and discuss the success of the project (successes and failures) and
the process (methods and tools used, with reference to the project plan). Identify any
shortcomings and further work that may be done in the future.

Dr WA Clarke

2009

5 of 38

3 STYLE AND FORMATTING GUIDELINES

3.1

Introduction

Your mini-dissertation or dissertation documentation is very important, as this is

probably ALL that the external examiner sees of your work. It is therefore important to
take extra care to ensure that the first impressions are positive.

** IMPORTANT **

Names for the various documents associated with degrees:

1. For a final-year B.Ing project, you do a mini-dissertation.
2. For a Masters Degree with no lectured component, you do a dissertation.
3. For a Masters Degree with a lectured component, you do a mini-dissertation.
4. For a Doctorate Degree, you do a thesis.

In this section, several aspects of the documentation will be discussed. There are few
formal requirements regarding the documentation, but these guidelines will ensure a
more professional look-and-feel.

3.2

Language, grammar and tone

In South Africa we use UK English instead of US English. For example most of the
zs in words should be ss, but not all!

Set the language of your word processor to English (South African or UK) if you write
in English.

Before you hand in, please have the document checked for grammar and spelling.
Spelling and grammatical errors negatively reflect on your professionalism.

Dr WA Clarke

2009

6 of 38

Keep the tone formal and professional. This implies that you dont always write the
same way that you speak, since spoken language is often informal.

3.3

General

Document

Style

and

Formatting

Guidelines
To ensure readability and professionalism, use the following as a strong guideline when
typing your document:

Use Microsoft Word as word processor. This makes it easier to store the documents
electronically. Also, there are probably more people around that can help you.

Use white A4 pages. Set this up in the word processor as well. If the word processor
is set up with Letter and you print out on A4, a lot of space is wasted, and the
layout will be wrong.

Use Times New Roman 12 point for normal text, as it facilitates easier typing of
mathematical formulae. The Faculty has acquired a license for MathType. The full
version provides better support for equation numbering and editing than the version
included in standard Word.

Set up the document style before you start typing. Retrofitting a style is difficult and
time consuming.

Page Margin settings

Page margin settings can impact on the location of document entities such as drawings,
tables and references to pages. It is therefore advisable to set this up before you start
your document.

Dr WA Clarke

2009

7 of 38

The top, bottom, left and right page margins should be 2.54cm (1).

Headers: 1.27cm from edge

Footers: 1.27cm from edge

Headings
Headings provide the reader with clear boundaries within your text, and simplify
readability and understanding. Headings group text that belong together and share a
common theme.
Here are some recommendations regarding headings:

All headings should be in the font Times New Roman

Headings must be numbered (e.g. 1 Introduction; 1.1 Scope, etc.) and Left Justified.

First Level Headings: 16 Point, in bold and ALL CAPS (e.g.

1 HEADING

LEVEL 1)

Second Level Headings: 14 Point, in bold, SMALL CAPS (E.G.

1.1 HEADING LEVEL

2)

Third Level Headings: 12 Point, In Italics, normal (e.g. 1.1.1 Heading Level 3)

Most word processors have styles or templates that you can use, i.e. a Heading 1
style/template. You edit this style in terms of font, justification, size, numbering etc.
and then apply it to text. You can then automatically generate a table of contents
based on these templates/styles. It is recommended that you use this feature, as it
will simplify your work at the end.

Headers
A header is the text at the top of each page, usually followed by a line or other
separator to distinguish it from the body text. This provides readers with information
regarding the present section/chapter in the document.

Headers are usually on each page, except on the first page of a Chapter.

Dr WA Clarke

2009

8 of 38

A header consists of text followed by a full horizontal line (see top of this page).

On the left hand side of the header, type (in 10 point, italics and Times New Roman)
the title of the Chapter, i.e. Chapter 4: Design and Implementation.

Footers
A footer is the text at the bottom of each page, usually below a line or other separator,
to distinguish it from the body text. This provides readers with information regarding
the page, and often the author of the document. Sometime a date is also included.

Footers are usually on each page, except on the first page of a Chapter.

A footer should consist of a full horizontal line followed by text (see bottom of page).

Page Numbering
The page numbering is a controversial issue. To simplify page numbering, use sections
and section breaks (Word). Between each chapter in your document, insert a section
break (starting on a new page). Then restart page numbering for that section, and edit
the header and footer for that section to include the right information.

Page numbers should be in the footer and located at the bottom right.

Page numbering should include chapter numbers (i.e. 4.6 for Chapter 4, page 6).

Page numbering for each chapter should start from page 1, e.g. 3.1, 3.2, for
Chapter 3. This makes it easier to add changes to a specific chapter later, without
reprinting the whole document just because the page numbering had changed.

Tables

All tables must be numbered and have descriptive headings.

Headings of tables must be in italics.

Place table headings at the top of the Table.

Number tables in Upper Case Roman Numbers, i.e. Table I, Table II,

Example:

Table I: Caption of Table I

Dr WA Clarke

2009

9 of 38

Column 1

Column 2

Data

Date

Figures, drawings, pictures

All figures, drawings, pictures have to be numbered and must have descriptive
headings.

Headings must be in italics.

Place headings at the bottom of the figure, drawing, picture.

The numbering must include the chapter number, followed by the figure number in

the chapter.
Figure 3.1: Telecoms rack

3.4

Title of document

Please spend some time with the title. The title sets the readers frame of mind from
this point on, the reader expects to see some relevance between the title and the rest of
the document. If you get it wrong here, the reader is already expecting something other
than what you will be presenting. This creates a dissonance that can only spell disaster
for you. Therefore, make sure that the title matches your work! Here are some pointers
to help you formulate a title:

Have someone else read the title and explain to you what he/she understands and
expects.

Dr WA Clarke

2009

10 of 38

Take your problem statement and see if the title reflects an answer, solution,
outcome, etc.

What is the scope implied in your title? The scope of the title should not be wider
than what you have presented in your document.

Does the action implied by the title match what you have done, i.e. are you
designing, modifying, analysing, etc.?

Stay away from the terms new, improved and similar words unless you are
absolutely certain that it is the case. At this point, the question of patents comes
into play.

3.5

Document front material

These items include (each starting on a new page):

o

The Title page, as prescribed.

summary

in

English

and

Afrikaans

(PLEASE

CHECK

YOUR

LANGUAGE/GRAMMAR)
o

Table of Contents (Headings and page numbers) dont go into too much detail
only provide first to second level headings.

List of figures List all figures with figure number, figure caption and page
number in a table format.

List of tables List all tables with the table number, table caption and page
number in a table format.

List of symbols List all symbols with the symbol and its meaning in a table
format.

List of acronyms List all acronyms used with the Acronym, and the definition in
a table format.

Number these pages in small roman numbers, e.g. i, ii, iii,

The following is an example of the title page of a typical mini-dissertation

(distributed over the whole length of an A4 page.). Please change the text indicated
in block brackets [NAME] with your specific details:

Dr WA Clarke

2009

11 of 38

[TITLE]
by
[FULL NAME AND SURNAME]
A mini-dissertation submitted for the partial fulfilment of the requirements for the degree
BACCALAUREUS INGENERIAE
in
ELECTRICAL AND ELECTRONIC ENGINEERING SCIENCE
at the
UNIVERSITY OF JOHANNESBURG

STUDY LEADER: [PROF./DR./MR./MS. .........]

[JUNE / NOVEMBER 20...]

Dr WA Clarke

2009

12 of 38

4 CHECKLIST BEFORE HANDING IN A

CHAPTER
The following is a checklist to go consider before handing in any chapter for review.
1

The page size used is set to A4 for the document.

Headers and footers are included as described.

Fonts for headings and text as described (12pt Times New Roman).

Page numbers are included on each page (except the first) of the chapter.

The document language was set to UK English.

The language used is formal, preferably in the third person.

The title of the chapter is as described, e.g. Chapter 1 Problem Statement.

Text line spacing is set to 1.5 lines.

An Introduction section at the beginning of the document.

A Conclusion section at the end of the document.

0
1

All tables have captions (including number) at the top of the table. An entry

for each table in the List of Tables.

All figures and drawings have captions (including number) at the bottom of

the figure. An entry for each figure in the List of Figures.

All equations are centre justified and numbered (numbers right justified and

in brackets).

All symbols used in equations are explained in the text that follows and

includes units (e.g. m is mass in kg). All symbols used are included in the List
of Symbols.

All acronyms used are defined the first time they are used, e.g. Commercial

Off-The-Shelf (COTS) hardware. Further, all acronyms are included in the List of

Dr WA Clarke

2009

13 of 38

Acronyms.
1

No empty pages or large gaps between text.

6
1

The document was read for a second time to check for errors (spelling,

grammar, logic).

The document was read and reviewed by a second person.

8
1

The flow and ordering of the chapter makes sense.

9
2

You used several figures and drawings to simplify explanations rather than

long sequences of text.

All information used by other sources is properly referenced (e.g. [1]). Each

reference is properly included in the References chapter.

References used are from reputable sources, e.g. journals, conference

proceedings, books, spec sheets. Little use of Wikipedia, web-pages,

white papers, etc.

Dr WA Clarke

2009

14 of 38

5 CHAPTER 1: PROBLEM STATEMENT

The purpose of this chapter is to introduce the reader (read E*X*A*M*I*N*E*R) to your
work.
Chapter 1 will be read completely and in-depth. Spend some time on it. Please make
sure that you describe the problem and not the solution. The solution only follows from
Chapter 4.

A suggested heading structure for Chapter 1 is provided.

The purpose of this chapter is to present the problem or task to the reader. Ensure that
the problem is fully understood.

Fundamental errors in the application of the wrong

solution or technology can only be avoided if the problem is fully understood.

This section is used to explain the reasons for the project. Here is explained what the
problem or task is, why it is a problem, to what extend the problem is going to be
addressed, and what are all the benefits if the problem/task is addressed.
It is important to describe the problem and not the solution.

Do not present the

implementation of the solution.

Chapter 1 must display the following:

The project addresses a vaguely defined, open-ended problem;

The problem is in a specialised area;

Dr WA Clarke

2009

15 of 38

That you understand the problem and its context; and

That you follow an acceptable design methodology.

General notes:

You have to use references in this chapter;

All references used throughout the document are combined in the References
chapter at the end of the document;

Note the style and formatting suggestions

1.1INTRODUCTION AND CONTEXT

Provide a context for the problem addressed by the project and provide some
background information leading to the project. Identify the specialised area that you will
be working in. Note that the actual problem or the projects objective is not stated here,
that will be done later. In this section, only enough information is provided to get the
reader interested.
A good progression is to start wide with your context (e.g. why the technology is
important, where it is used, why it is important in this time, etc.) and work towards the
specific area of your project.

This section provides a general background/context to

interpret and understand the problem statement in the next section.

Some guiding questions that may help you are the following:

What is the technology used?

Why is it important?

How does it impact on people?

What is some recent industry news around it?

Suggested length: Approximately 1.5 pages or longer

1.2PROBLEM STATEMENT

Dr WA Clarke

2009

16 of 38

Describe the general problem area that will be addressed, and why it is a problem.
What will be the benefits of solving this problem. State the reason why the problem
should be addressed.

Note that this section is not describing your project, but only the larger problem area. It
provides the larger problem area to be addressed. By describing this, the logic of your
specific project will become clear.
Suggested length: 1 page or longer
1.3PROJECT OBJECTIVE
State the objective of this project.

Everything further on must relate to this objective.

This objective must be stated on a higher level it is the overall purpose that you try to
achieve. It is important that you do not include the solution (or aspects thereof) in this
section.
In normal engineering work, we usually approach a complex problem by breaking it up
into smaller problems. By solving these smaller, but more achievable problems, we
solve the larger problem (or objective). In this section, break the objective into smaller
problems, e.g. sub-problems or objectives to be solved. List each of these sub-objectives
or problems and provide a short discussion on each of them.
Suggested length: page to 1 page
1.4SCOPE OF THE PROJECT
The scope determines the boundaries of the project. It is important to get this right!
The scope must relate to the title, objective, and problem statement.
The scope will also guide the rest of the document as to what is included and what not.
Examination/oral questions such as Why have you not considered ...? can be avoided
by getting the scope right.
Suggested length: page to 2 pages
1.5METHODOLOGY OVERVIEW

Dr WA Clarke

2009

17 of 38

Document and discuss the methodology to be followed in this project (What it is, why
applicable to your project, shortcomings, advantages, etc.).

Read up on design

methodologies, especially those normally followed by the engineering profession. This

methodology will normally include a design, implement and test phases.
Suggested length: 1 page
1.6DELIVERABLES
In this section, list what needs to be delivered at the end of the project.
Suggested length: page
1.7ECSA OUTCOMES
Provide a short overview of how you anticipate the ECSA outcomes to be achieved with
this project.
Suggested length: 1 page
1.8OVERVIEW OF THE DOCUMENT
Provide an overview of the rest of the document. In this section you should provide the
golden thread to the reader, how everything fits together to solve the problem and
achieve the objective. Dont start every sentence with In Chapter X ....
Suggested length: page
1.9CONCLUSION
Write a short conclusion for the chapter, including aspects such as the following:

A recap of the problem

A short summary of the objective

A short summary of the scope

A short summary of the methodology

Dr WA Clarke

2009

18 of 38

A short summary of what is to follow next.

Dr WA Clarke

2009

19 of 38

6 CHAPTER 2: REQUIREMENTS ANALYSIS

In this Chapter, you will analyse the problem in more detail, to show the examiner that
you really understand the problem.

The main objective of this chapter is to list the

issues, requirements and constraints of your project.

This chapter should indicate how you intend to address the problem and list any known
constraints which may affect the solution
2.1INTRODUCTION
Provide a statement of the contents of the previous chapter, followed by a short
overview of this chapter and its objectives. Describe the logic and flow of this chapter.
2.2IDENTIFIED ISSUES AND CONSTRAINTS
In this section, you will identify the issues and constraints that surround your specific
problem/project in order to better understand the problem space.

It is better to spend

some time to thoroughly think through all the issues and constraints that may impact on
your project before you start the design and implementation.

Once the project is in

motion, retrofitting the design with late-discovered issues and constraints may scuttle
the project.
The issues will need to be addressed in your design, and the constraints considered. It
may be beneficial to number these - in this way you may reference them later as part of
your discussion in later chapters.
The following headings provide a suggested structure for you to use as a starting point.
Your project may not have all these categories, or may even need other categories.
Adapt it as you see fit for your project.
2.2.1 TECHNICAL
Technical issues and constraints are usually the easier ones to identify. List and discuss
all technical issues and constraints related to the project/problem.
2.2.2 FINANCIAL AND ECONOMIC

Dr WA Clarke

2009

20 of 38

List and discuss all economic issues related to the project/problem, e.g. how the
economic environment impacts on the project, and/or how the project/problem impacts
the economy.
Also list any financial constraints that may apply.
2.2.3 SOCIAL
Most design projects have some interface with a segment of society. The impact of this
interface may be bidirectional.

On the one hand, the design may impact society in

some way, but on the other hand, society and its needs may impact on the design.
List any issues and constraints related to the impact society and your design project.
2.2.4 LEGAL
Projects seldom exist outside the legal framework of a country. Laws govern quality,
testing, safety and health aspects, responsibility towards users, etc. Also, patents may
inhibit you from using a good design.
List any legal issues and constraints that may pertain to your project.
2.2.5 SAFETY
List any safety issues that may pertain to your project. This includes the process you
follow (e.g. if it includes construction work, working with electricity, etc.) and the safety
issues related to the output of your project and its use.
2.2.6 ENVIRONMENTAL IMPACT
The world has become more environmentally aware.

Designers of products that

negatively impact the environment may soon find that their products are unpopular,
even though they may be the best/cheapest/most advanced, etc.
Critically evaluate the environmental impact of your project on the environment and
how it may affect your design. Include things such as the use of your product/design,
the materials used in its construction, getting rid of it once it reaches its end,

the

manufacturing process, packaging materials, how to sell it, transporting it, energy
consumption, etc.

Dr WA Clarke

2009

21 of 38

2.2.7 ETHICAL CONSIDERATIONS

Discuss any ethical considerations that pertain to your project.
2.2.8 USABILITY CONSIDERATIONS
Although this is closely related to the impact on society, this section focuses more on
the usability of your project/design.

This may include ergonomic considerations, e.g.

where knobs are places, which type of knobs are used for which purpose, displays and
markings, the colour and materials used, the enclosure, the depth of the menu, layout of
the screen, etc.
Also take into consideration people with disabilities.
2.3ASSUMPTIONS AND EXCLUSIONS
In all projects engineers make certain assumptions. It is often better to express these
assumptions explicitly to avoid later complications. The exclusions state what are not
included.
Just make sure that these assumptions and exclusions make sense in the context of the
purpose, scope, and specifications.
Identify and list any assumptions that you make about the project/product, as well as
any issues that are excluded.
2.4REQUIREMENTS SPECIFICATION
In this section, a list of requirements that must be fulfilled should be presented.

Be

careful what you specify, as you will need to discuss (in the Results) how these
requirements were fulfilled and to what degree.
Requirements specifications must be very specific in describing what must be done,
and how well. They often include a how part as well.
Bad example:

Gadget must operate in a hot environment

Better example:

Dr WA Clarke

2009

22 of 38

1. Accepted operation of Gadget is considered to be an output voltage of 5V with a

tolerance of 1%.
2. Gadget must operate acceptably in a temperature range of -10 to 50 degrees Celsius
for at least 1 hour.
Use the following list of headings as a guiding principle. This list follows the same as
those in the issues and constraints section.

However, in this section, list the

requirements that you will design to.

2.4.1 TECHNICAL
2.4.2 QUALITY AND PERFORMANCE
2.4.3 FINANCIAL
2.4.4 SOCIAL
2.4.5 LEGAL
2.4.6 SAFETY
2.4.7 ENVIRONMENTAL
2.4.8 USEABILITY

Dr WA Clarke

2009

23 of 38

7 CHAPTER 3: LITERATURE STUDY

In the literature study you provide an overview of the current state of the technology.
This

state

of

technology

includes:

theory,

standards,

applications,

products,

components, etc. It includes anything pertinent to the solving of your problem (and sub
problems).
This chapter shows that you have done your homework. Armed with the knowledge of
this chapter, you will be able to attack the design phase with more confidence.

Standards are almost always applicable and can include safety standards, EMC
standards, protocol standards (if communications are applicable), usability
standards, etc.

Although the Internet is a useful resource, it is not the only one and certainly not a
reliable one.

Use more trusted resources, i.e. text books, spec sheets, previous

dissertations, academic journals, etc. Your work gets rated based on the foundation you
build on if your foundation is built on unreliable Internet resources, you start of on the
wrong foot! Remember that most of the information on the Internet is to generate sales,
and therefore biased.

If you must use Internet web-pages, do, and show a critical

evaluation of that information.

Remember, you build on other peoples work. Provide references if you use other
peoples work.

Dont quote more than one or two sentences.

Try to integrate

information in your own words from several sources on a specific topic (obviously with
the required references!).
A suggested heading structure for Chapter 3 is the following:
1.1.1 INTRODUCTION AND OVERVIEW
Summarise the work from Chapter 1 and Chapter 2, and state the objective of this
chapter. End with a short overview of the chapter.
3.2STANDARDS AND LEGAL CONSTRAINTS (If applicable)

Dr WA Clarke

2009

24 of 38

In addition to technical standards that describe sizes, types, interfaces, levels, etc.,
remember safety standards, health standards, environmental standards, EMC standards,
and SABS standards.
Also provide (if applicable) an overview of any legal constraints that may apply.
3.3THEORY AND METHODS
Based on the objectives, problem statement, scope, assumptions and specifications,
only include theory that it relevant. If you use a component as a subsystem to a larger
system, dont provide the full description of the underlying theory unless it has a direct
impact on the dissertation, e.g. if you use a GSM module, dont provide a 10-page
overview of the GSM technology. Rather provide an overview of the module, how to use,
limitations, etc.
However, ensure that you completely discuss the main theory on which your work is
based. Remember to use references regularly. Do not overuse a single reference.
3.4TOOLS
Describe any tools (software, measurement equipment, hardware or other) available
that will be relevant to this topic, again within the context and scope. Also describe
availability of such tools, and possible constraints (e.g. lead times, availability, size,
power requirements, hardware requirements, etc.)
3.5SIMILAR WORK
Provide an overview of similar work or competing products available, if any.
thorough search.

Do a

Also include prices (if available) and features, and describe

differences between these products and what you are trying to achieve, and why yours
is better.
This is an important section, as it considers the competition and what it is doing,
whether it be theory or product. If this is too short, it is an indication that you do not
fully comprehend the scope of the project and the theory.
3.6COMPONENTS OR SOFTWARE
Provide an overview of different components that are available and applicable to this
project.

Components here refer to subsystems, i.e. not complete, competing

products/components to your development.

Dr WA Clarke

2009

Provide technical information on the

25 of 38

components, but also constraints such as availability, cost, delivery times, etc.
3.7CONCLUSION
Summarise the chapter and state what is coming in the next chapter.

8 CHAPTER 4: DESIGN
In this chapter you will provide and discuss the design process. The idea is to provide
and discuss a few initial high level designs and/or variations in the form of functional
block diagrammes. Evaluate each design in terms of the requirements specifications,
theory, methods, standards and assumptions. From these, motivate one design to
continue with.
Note that this section is relevant to research and simulation type projects as well. In
this case, the design of the simulation will be discussed.
Provide an overall and interconnected functional block diagramme of the chosen design,
and then describe each individual function block in terms of purpose, motivation for its
existence, specifications, expected behaviour, expected inputs, standards it must
adhere to, etc. Also, provide the detailed level design of each component, using maths
and the physical sciences where appropriate.

Discuss the use of design tools (i.e.

Matlab, Simulink, PSpice, etc.)

A suggested heading structure for Chapter 4 is the following:
4.1

INTRODUCTION AND OVERVIEW

The same as in the previous chapters.

4.2DESIGN ALTERNATIVES
Discuss the design options available to you. Provide a short overview of each option and
evaluate them against the requirements, issues, and what you have learned in the
literature review.

Finally compare the options against each other and chose one to

continue with. Motivate your choices.

It is suggested that you use diagrammes (block) to indicate the design alternatives.

Dr WA Clarke

2009

26 of 38

4.3DETAILED DESIGN
Divide your selected solution(s) into subsystems and draw a block diagramme of it.
Take each subsystem and provide a detailed design of each, including an overview of
functionality, the implementation of such functionality, design parameters chosen,
mathematical evaluations, etc.
Show how you use design tools such as PSpice, Matlab, other modelling tools,
programming languages, etc.
Remember to include issues such as interfaces between the different subsystems,
functionality, specifications, and other requirements.
4.4CONCLUSION
Give a short overview of the chapter, and what is to follow next.

Dr WA Clarke

2009

27 of 38

9 CHAPTER 5: EXPERIMENTAL DESIGN

9.1

Test and Evaluation Strategy

For the system as a whole and its subsystems, define a test and evaluation strategy.
This may include input test signals and expected output signals, environmental tests,
and expected behaviour. This must be designed in accordance with your specifications
in Chapter 2. Complying with these tests will partly imply success. Include performance
tests as well, i.e. do not just test whether it works; also show how well it works.
Remember to include detailed discussions on experimental setup and the equipment
used. Provide graphical descriptions together with motivations.
In any scientific work, it is important to produce work that is repeatable or reproducible.
In this sense, the experimental work should be described such that someone else can
repeat them with your specific gadget, simulation, etc. and get similar results. It is
therefore important to describe each experiment completely and in detail, including
aspects such as the aim, equipment used, setup, procedures, handling of uncertainty,
and analysis.
5.1INTRODUCTION
5.2EXPERIMENTAL OVERVIEW
Provide a global experimental overview, depicting the strategy you used to design the
experiments and how each of them fit into the global objective. In most cases there will
be several types of experiments, e.g.

Environmental experiments (determine the operation with regards to environmental

conditions such as temperature, humidity, vibration, orientation, dust, noise, etc.);

Functional experiments (to determine whether it works);

Performance experiments (to determine how well it works and within which limits).

Dr WA Clarke

2009

28 of 38

5.3EXPERIMENTAL DESIGN
This is the meat of this chapter, considering each experiment in detail. Experiments
must be documented individually, however, experiments with similar aims and setups
can be grouped together.
In the following, a suggested heading structure for each experiment will be provided.
5.3.1 EXPERIMENT 1
5.3.1.1

AIM

Provide an aim or objective for the experiment. This can be a short, one or two sentence
statement.
Remember, in most cases we keep as much as possible constant for an experiment
while varying a single element or variable. This is to determine the effect of the variable
or element on the rest of the system, simulation or software. If we vary more than one
variable at a time, it is difficult to determine the effect of each one on the system.
Therefore take care to control what you change and what you vary, and any
interdependencies between them.
5.3.1.2

RELATION TO OBJECTIVE

Provide a short discussion on how this experiment fit into the whole, e.g. objective.
5.3.1.3

EQUIPMENT

Provide a list of equipment.

If more than one experiment will be using similar

equipment, list it completely the first time and then reference it from the later
experiments.
It is important to be as specific as possible here, listing the make of the equipment, its
function, any limitations, accuracy expectation, last time calibrated, etc. Remember that
this experiment should be repeatable by someone else.
To make it more tangible and interesting, you may include pictures of the equipment.
5.3.1.4

SETUP

Describe the setup of the experiment, e.g. how the equipment is connected, the

Dr WA Clarke

2009

29 of 38

parameters settings for the equipment, simulation, or software. In most cases you will
require a diagramme together with a photo of the actual setup.
5.3.1.5

PROCEDURES

Provide the procedure used to conduct the experiment. This may also be a flow
diagramme or a numbered list of steps. Provide enough detail to be repeatable.
5.3.1.6

UNCERTAINTY AND CONTROL

Describe how you will manage uncertainties. Uncertainties include measurement noise,
variability

in

environmental

conditions,

inability

to

keep

variables

constant,

measurement equipment accuracies, resolution of software, etc. Carefully consider how

you can reduce these uncertainties, either through experimental procedures, better
equipment, number of measurements, etc.
This is a good place to start using the statistics, e.g. mean, variance, graph matching,
smoothing operators, outlier detection and handling, etc.
Dont remove outliers too easy, rather try to explain and interpret them.
5.3.1.7

EXPECTED RESULTS AND ANALYSIS

Discuss the results that you expect to find and the methods that you will use to analyse
it. A good suggestion is to draw a graph with expected results, upper bounds, etc. and
explain why you expect these results.
You are required to provide analysis in addition to just results. Therefore, provide a
discussion on methods to analyse the results.
5.4CONCLUSION

Dr WA Clarke

2009

30 of 38

10 CHAPTER 6: IMPLEMENTATION
OVERVIEW
In this chapter, you provide an overview of the actual implementation process. In any
implementation/experimentation projects, things usually go wrong, or at least not as
expected. The purpose of this chapter is to provide the reader with an overview of the
issues involved in constructing the proposed design. Remember the objective is for
someone else to be able to replicate your work.
Discuss what changes you have made and why, what tools you have used, and what
their strengths and weaknesses were. It is not a sin to make errors or run into difficulties
when you design. Write it down you could possibly help someone else not to make the
same mistakes. It also shows that you did it on your own.
Finally, show any optimisations that you have made. Refer back to your functional block
diagramme and show the differences.
Provide a cost analysis of the project.

Show step-by-step pictures of the construction/implementation process

A suggested heading structure for Chapter 6 is the following:

6.1INTRODUCTION AND OVERVIEW
6.2COMPONENT IMPLEMENTATION ISSUES
6.3INTEGRATION ISSUES
6.4CONSTRUCTION ISSUES
6.5COST SUMMARY
6.6CONCLUSION

Dr WA Clarke

2009

31 of 38

11 CHAPTER 7: RESULTS AND ANALYSIS

In this chapter, you show that the project as constructed in the previous chapter, works
and comply with the specifications (including performance).

This is achieved by

performing the experiments as described in Chapter 5.

Use graphs, pictures and tables where possible. Convince the examiner that it works! If
your project involves experimentation, you provide the results in this chapter.
Show the results of any optimisation.
Show how information is derived from the data and interpret such information.
A suggested heading structure for Chapter 7 is the following:
7.1INTRODUCTION AND OVERVIEW
7.2EXPERIMENTAL RESULTS
Follow the experimental chapter planning structure.
7.3ANALYSIS OF RESULTS
7.4CONCLUSION

Dr WA Clarke

2009

32 of 38

12 CHAPTER 8: CONCLUSIONS
This is an important chapter and should be of sufficient scope.

This last chapter

provides an overview of the work, from the beginning and ties everything neatly
together in a whole.
Note the following points:

Discuss the success of the project, based on the requirements specifications and the
objective of the project

Discuss the shortcomings of the project, and what you would do differently next time

Discuss future work for someone that wants to take it further

Discuss how creativity was implemented

Discuss how you dealt with risks, uncertainty and difficulties

Discuss how the project crossed disciplinary boundaries

Discuss techno-economic analysis

Discuss impact on social, legal, health, safety and environment

Assess the engineering methods, tools and skills used

Discuss the information technology used in the project

8.1INTRODUCTION AND OVERVIEW

8.2RESTATEMENT OF OBJECTIVES
8.3ACHIEVEMENT OF OBJECTIVES
8.4IMPLEMENTATION ISSUES

Dr WA Clarke

2009

33 of 38

8.5SHORTCOMINGS
8.6RECOMMENDATIONS
8.7ACHIEVEMENT OF ECSA OUTCOMES
8.8FUTURE WORK

Dr WA Clarke

2009

34 of 38

13 REFERENCES
References provide credibility to your work. Therefore, show that you have done your
homework.

Show that you have referenced reputable text books, journals, and

manufacturing spec sheets.

Sometimes you can also reference discussions you had

with experts.
Be careful with referencing the Internet never just state THE INTERNET. If you used a
document that was downloaded from the Internet (i.e. a .pdf or a .doc), then state the
name of the document, where it was originally published, the author and date of
publication (as a normal document), but include the URL as well to indicate where to
find the document. Web pages as references are less credible, as they have a short life
span.

State the URL, date downloaded, a title and give a short description of the

contents. If it was an important reference (hopefully not!), then print it, and add it to the
appendices. Remember that anyone can publish information on the Internet no one
critically evaluates it.
updated.

Also remember to look at the last time the information was

Take into consideration the source of the information.

The purpose of

whitepapers is often to sell. Dont base everything on a whitepaper only, get different
views, and critique it.

DONT BELIEVE EVERYTHING THAT IS PUBLISHED ON THE INTERNET, ESPECIALLY IF IT

WASNT PEER REVIEWED. EVEN IF IT CLAIMS TO BE REVIEWED, CHECK ON THE
REVIEWING PROCESS.

Try to never quote a reference verbatim. State the reference, but state it in your own
words. Better still integrate several references into one statement, e.g. In [1, 5, 9,
and 10] it is shown that . The more you integrate the work of references into your
own, the more credibility you build.
It is recommended that you use the IEEE method of referencing. In the text, use [1] to
reference a text. In the references, list these references as they appear chronologically,
i.e. the first reference you use is 1, the second is 2, etc.
As an example, see the following:

Dr WA Clarke

2009

35 of 38

For articles:
[1]

VI Levenshtein, "Binary codes capable of correcting deletions, insertions and

substitutions of symbols", Doklady Academy of Sciences of the USSR, Vol. 163,
No. 4, pp. 845-848, 1965.

For Theses/Dissertations:
[2]

ASJ Helberg, Coding for the correction of synchronisation errors, Doctoral Thesis,
Rand Afrikaans University, November 1993.

For Conference Proceedings:

[3]

AB Cowen, Title, Proceedings of the 2004 IEEE International Symposium on

Information Theory, vol.2, pp.504-510, Trondheim, Norway , June 2004.

For books:
[4]

IH Witten, Data Mining: Practical Machine Learning Tools, Morgan Kaufmann

Publishers, San Francisco, 2000.

For chapters in a book:

[5]

IH Witten, Data Mining: Practical Machine Learning Tools, Chapter 1, Morgan

Kaufmann Publishers, San Francisco, 2000.

For quotations from a book:

[6]

IH Witten, Data Mining: Practical Machine Learning Tools, pp.351-360, Morgan

Kaufmann Publishers, San Francisco, 2000.

For articles found on the Internet:

[7]

AB Cowen, Article Title, Siemens White paper, 2001,

http://www.siemens.com/whitepapers/art1.pdf, Referenced on 12 November
2003.

Dr WA Clarke

2009

36 of 38

For web-pages on the Internet:

[8]

S7-300 Overview on PLC product page,

http://www.siemens.com/products/plc/s7300/overview.htm, Referenced on 12
November 2003.

14 APPENDICES
Provide all additional material as appendices. These can be:
o

Manufacturer spec sheets;

Code (software). This should normally not be presented in the chapters;

Printouts of Internet pages;

Bulky calculations, data, results, etc.; and

Additional information that help to understand or interpret the work in the main
document.

THE APPENDIX IS NOT A DUMP OF MATERIAL IN ORDER TO SUPPLEMENT THE

DOCUMENT PAGE COUNT!

A good idea is to provide a copy of all relevant reference material in electronic format on
CD with the final document. Extensive code listing is better provided on CD which saves
a lot of paper.

Web pages which are referenced should also be included on the CD

(check copyright first). The reason for this is that the web page may not exist when
used for future reference.

Dr WA Clarke

2009

37 of 38

-- o0o ---

Dr WA Clarke

2009

38 of 38