Practical Issues Involved in the Use of ICT in the Digital World

INFO4 Coursework Guide

Contents
Introduction 3
1.
Background and Investigation 4
1.1 An introduction to the organisation. 6
1.2 Describe the current system or existing situation and the
environment that it is set in. 6
1.3 Identification of client and users.
7
1.4 A business case (reasons) for change.
7
1.5 Evidence of the use of relevant investigation techniques.
1.6 Requirements of the client
8
2.
Analysis and deliverables
10
2.1 Statement of scope
10
2.2 Description of the proposed system 10
2.3 Documentation of the processes
11
2.4 Description of the users of the proposed system 11
2.5 Evaluation criteria 11
2.6 Agreed deliverables
11
2.7 Evidence of checking the findings with the client 11
3.
Design and planning for implementation
13
3.1 Evidence of investigating alternative design solutions 13
3.2 Draft design work 14
3.3 Final design work 14
Storyboard
14
Reports and other outputs 15
Other Issues 15
3.4 Plan for implementation, testing and instalment, including
proposed time scales 15
3.5 Training requirements for the new system 15
3.6 Testing strategy 15
3.7 Test plan
16
4
Testing and documentation of the implementation 17
4.1 Evidence of testing
17
4.2 Evidence of client and end user testing
17
4.3 Comprehensive documentation of the solution
17
5
Evaluation of the implemented solution
18
5.1 A critical evaluation
18
5.2 Evaluation of own performance 18
6
The project report 19

Introduction
The aim of this unit is to provide you with the opportunity to complete a
substantial project involving the production of an ICT-related system
over an extended period of time. In this section you will investigate the
clients requirements and draw up a set of working objectives. You will
investigate an existing system (either computer and/or paper-based)
within an organisation and determine how it could be improved by the
introduction of a new system. This involves a feasibility study and
analysis of existing systems to determine what user requirements
(objectives) could be addressed by the introduction of a new system.
It is important to remember that at this point, you do not know that you
will be producing the system in Microsoft Access.
This coursework module is worth 20% of your overall A Level grade and
will take up a lot of your time this year.
The coursework module is split into several different sections:
1.
2.
3.
4.
5.
6.

Background and investigation

Analysis and deliverables
Design and planning for implementation
Testing and documentation of implementation
Evaluation of the implemented solution
The Project Report

[14 marks]
[15 marks]
[14 marks]
[13 marks]
[7 marks]
[7 marks]

Total 70 marks
The first aspect you should consider on your project is a plan of any
work that needs to be carried out. You should create a Gantt Chart
similar to the one shown below in Figure 1 - Sample Gannt Chart and
Milestone Table to show exactly how you plan to deliver your project on
time, using milestone dates for the completion of each aspect of the
project; this section of your project documentation is vital as the
planning process will allow you to gain a better understanding of the
tasks and sub-tasks you will need to complete.

Milestone Dates
Background and investigation
Analysis and deliverables
Design and planning for
implementation
Testing and documentation of
implementation
Evaluation of the implemented
solution
The Project Report

Write your dates

Figure 1. Sample Gannt Chart and Milestone Table.

Also look at www.ganttproject.biz for free project management software.

1.

Background and Investigation

You need to find a real client (end-user) for your project as soon as
possible. After finding an organisation on which to base your
coursework you need to get in touch with them to discuss possible
projects in more detail. Remember that the project has to have enough
scope to gain you good marks and that you have a limited amount of
time in which to complete it. Under no circumstances take on a project
that is too big or too small without consulting your teacher. After
finding an organisation on which to base your coursework you need to
get in touch with them to discuss possible projects in more detail.
4

A three-step approach is recommended:

1.
Informal Discussion
You should establish what the problem to be solved is. You should then
complete Appendix A and discuss it with your teacher before agreeing
to tackle the problem.
2.
A formal investigation
This should take the form of an interview, observation and/or
questionnaire. Try to get hold of any original documents (order forms,
invoices, receipts etc.) used in the current system for inclusion in your
appendices. If a computer based system is already in place try to get
screen dumps (or photographs) of the current system. These will help
you to identify inputs, stored data, processing and outputs. The
transcript of the actual interview (or questionnaire) will be included in
your appendices. The information gathered here will be used later on in
the project. Make sure you are fully prepared for the interview asking
carefully considered questions now will provide you with a good
framework for tackling the specification and analysis. In addition, your
client is likely to be more receptive and helpful if it looks like you are
treating the project seriously!

Interview Tips
The aim of your interview should be to gather information about the Current
System and proposed improvements. It should cover the following:
The organisation/department function
Aims and objectives of the current system
General procedures including time-lines/frequency of events
Users of the current system
Information/data gathered to be input what and how?
Documents/reports that are produced using the gathered data i.e. outputs
How the data is processed into the output information
Security, storage of data and backup issues
Problems encountered during any of the above procedures including errors
caused and encountered
Hardware and software available on-site and/or planned to purchase for the
new system
Users ICT skills current ICT usage, training etc.
Clients requirements regarding a new system with reference to the above

3.

Investigation Summary

List as numbered points the key factors identified at your interview,

these must include:
Current system
Problems encountered
User requirements for the new system
Your added suggestions for the new system based on your analysis of
the current system
The client should verify the contents of this document and sign/date
their agreement. Both the summary and the interview transcript will be
included in your appendices and must be referred to in your
documentation.

1.1

An introduction to the organisation.

This should include the type and purpose of the organisation, and give
an idea of its size and scale of operation, where it is based; number of
transactions per day etc. All contact with the organisation should be
documented and evidenced for example; keep a log of any phone calls
made and print out any emails sent and received.

1.2 Describe the current system or existing situation and the

environment that it is set in.
Move down in scale to describe the system or existing situation within
the organisation which is being investigated. What people and
departments are involved? This should be a detailed description of the
main points of your investigation/research regarding the current system.
Describe how the current system operates with the aid of data flow
diagrams and process flowcharts. You need to identify tasks being
performed and data flows. Refer to the questionnaire/interview
transcript and any original annotated source documents in your
appendices.
Process Flowcharts
Process flowcharts detail the exact mechanics of the system within the
organisation.
Data flow diagrams
Used to identify how data is transferred around the organisation and
what processing is required to turn it into information.
Input, Outputs and Processing
Your detailed analysis must explicitly identify all inputs, outputs and
processing:
6

List all the data input (and data capture methods)

Describe the information output (including format and content)
Describe what data processing is carried out
If there is a current system, a one-page description of its purpose, who
uses it, what functionality it has, what data it contains, what information
it produces and what shortcomings does it have?
If there is no system, you need to give a good description of what
happens now, including the context.

1.3

Identification of client and users.

Who is the new solution for? Make sure that the client and users are
clearly identified. Typically there will be one client but multiple users of
the new solution, are there different levels of security or will everyone
have the same rights to use the system?

1.4

A business case (reasons) for change.

Why is the new solution needed by the organisation? What problems

exist with the current system? Be specific here, for example; Orders
take too long to process leading to customer dissatisfaction; It is
difficult to find out if an item is in stock; Invoices have to be calculated
manually leading to the possibility of mistakes being made etc.
List and describe the problems identified in detail. The more problems
or potential problems you can identify the more scope you will have to
exploit the features of Access. Provide an overview of the problem you
intend to solve but do not discuss how you will solve it. Avoid phrases
such as up-to-date and modern system as they are meaningless. Try
to identify what the client wants and what would be the most appropriate
software for it.
Example
XYZ Ltd deals with 30 telephone orders per day. At present these orders are
recorded manually on a carbon pad and then passed on to the warehouse for
processing. If ordered items are in stock the warehouse will process the order
and complete an invoice and delivery notes using a word processing package
total values are calculated by hand. One copy is despatched to the customer
and another sent to the Accounts department. The system generally works
well but as this side of the business has expanded Mrs. Smith (Partner) feels
that the current system has major flaws.
She has three concerns: On busy days there can be a delay in processing

customer orders. The telephone operator has some idea of which items are in
stock but their information is based on the previous days stock levels. If an
item has run out of stock they will only find out when the warehouse has
attempted to process the order. This can lead to the embarrassing situation
where customers have to be phoned backed and told that their order cant be
processed immediately.
The manual calculation of order values can lead to mistakes being made. This
is particularly true as product prices change on a regular basis. Customers
are often quoted one price and then invoiced for a different one. This has led
to customer dissatisfaction and even threats of court action!
The present system seems to generate unnecessary amounts of paper!
Communication between telephone operators, the warehouse and accounts
department is by printed copy.
Mrs. Smith feels that the introduction of a computer database system could
tackle some or all of these problems. She is hoping for a system that can
process customer orders faster and more accurately. She also wants to
reduce the amount of paper generated by the system and feels that a
centralised system could improve communication between the 3
departments.
I believe that the introduction of a new computer based system could address
Mrs. Smiths requirements and in addition could also:
provide her with MIS information (sales, customers etc)
provide a facility for backing up important documents
improve data security

1.5

Evidence of the use of relevant investigation techniques.

Give evidence of planning, conducting, documenting and evaluating

meetings with clients, interviews, observation, questionnaires and
research as appropriate. Use the original documents (order forms,
invoices, receipts etc.) that you gathered at the interview stage.

1.6

Requirements of the client

What is the new system to provide? Make sure that both quantitative
and qualitative requirements are considered. Describe the clients
requirements and your aims in very general terms. This might include,
for example holding details about customers, products and orders or
calculating the value of invoices. The specific objectives outlined below
will act as performance criteria for your project.
Specific quantitative objectives
8

Prepare a numbered list of your quantitative objectives. These are

objectives that can be measured i.e. it should be possible to find a
customers details much faster; stock levels should be automatically
updated when an order is processed.
Specific qualitative objectives
Prepare a numbered list of your qualitative objectives. These are
objectives that cant easily be measured (e.g. the system should be user
friendly) but are important for the project to be successful. On
completion of the project the client will need to be involved in the
testing to show that you have met these objectives.
Specific objectives agreement
Get the client to sign and date your objectives to show that he/she
agrees with your assessment of the problem and what needs to be
achieved. This part of your paperwork is VERY important, as you will
need to refer back to it often in your analysis, design, testing and
evaluation. Objectives should be numbered so that you can easily refer
back to them e.g. Objective 3 was met by Unless you can link these
sections of your coursework to specific objectives you may score badly.

Terminology
You should describe all the requirements in detail, using the following ICT
terminology wherever possible:
Data capture methods and procedures
Validation and verification
Data Processing
Output required (including format)
The user interface
Navigation around the system
MIS issues
Security issues
Data backup issues
Archiving
Training needs
Integrating the two systems

10

2.

Analysis and deliverables

This section will allow you to think analytically and logically, to present
your findings using appropriate techniques, and to produce a
specification to use during Design.

2.1

Statement of scope

Include any internal or external constraints on the proposed system.

These may include hardware, communication technologies, software
(systems and application), format of external information requirements
(as certain organisations have rigid formats for information), staffing
and environmental factors.
Describe the hardware available to you at the clients organisation, at
school and at home and what tasks you will be performing on each
system. Describing does not mean simply listing the components, it
means that you should discuss what implications these components will
have on the system (e.g. The 2.4GHz Intel Pentium 4 processor in the
clients computer will allow the system to process data in an quick
manner). You may find that one computer is particularly slower than the
others; therefore it is important that you discuss what implications this
will have on your objectives (i.e. quantitative).
Describe the software available to you at the clients organisation, at
school and at home. Again, discuss what impact this software will have
on any potentially new system. If your system includes data of a
personal nature it will need to comply with the Data Protection Act 1998.
Outline the nature and content of the DPA and explain how you will
ensure that your system does not breach this Act.

2.2

Description of the proposed system

Include the benefits that the new system will provide for the
organisation. For example, will they need to purchase any new
equipment or software? Will existing practices have to be altered as a
result of the introduction of the new system? Include any soft benefits
such as improvements in customer or staff satisfaction. As well as
benefits you need to discuss any impacts that it will have on the
organisation, is the organisation moving or will they have to reorganise
themselves as a result of the new system being introduced?

11

2.3

Documentation of the processes

A decomposition diagram or flowchart should be created to provide an

overview of the flow of data through the new system. All inputs,
processes and outputs should be presented in tabular format. This
information should then be used to create dataflow diagrams to
illustrate the data dynamics of the new system.

2.4

Description of the users of the proposed system

Give an indication of the users/clients ICT skills (novice, intermediate or

expert?) and identify what effects this may have on the design of the
new systems e.g. will the user interface need to be intuitive? How did
you determine the level of IT skills possessed by the end user? Explain
any training needs that will need to be addressed.

2.5

Evaluation criteria

You should refer back to the quantitative and qualitative criteria that
were discussed previously and produce a set of criteria against which
the system could be tested and evaluated. Describe how you will
assess whether your solution has fulfilled the requirements. In table
format list the performance criteria as either qualitative
(user/process/system effectiveness) or quantitative (realistic timing
issues in comparison to the old system). Remember to present your
quantitative objectives as closed (yes or no) questions. This section is
very important as it will be used to carry out your evaluation.

2.6

Agreed deliverables

What is to be produced and handed over to the client? Is it going to be

a full prototype system or a partial system? List the deliverables, with
the dates when they will be delivered.

2.7

Evidence of checking the findings with the client

These must be understandable by the client. Keep all work neat,

organised and in the right format for collating into one report at the end.
Make it look as professional as possible as the client will need to see
this work. You could produce a sheet describing the work that has been
done, including scope, proposed system and evaluation criteria, and,
once they are satisfied that you can solve the problem in the manner
that you are suggesting, they can sign it to indicate agreement.
Each phase of the project requires a similar sign-off, which should be
titled and personalised for the client.
12

3.

Design and planning for implementation

This section is intended to show off your ability to design and document
effective solutions using your capacity to think creatively and
innovatively, and to select appropriate solutions. Your skills in thinking
logically and planning will also be assessed through your ability to
design appropriate implementation and testing strategies and plans.

3.1

Evidence of investigating alternative design solutions

This should include investigating options for all elements of an ICT

system as appropriate to the project. These could be software
alternatives, other technology alternatives, alternative approaches,
evidence of research, meeting notes etc. Your project could probably be
implemented using a range of software applications and one solution
might even be to streamline/improve a paper-based system. You need to
justify the use of the new software solution by comparing it with at least
two other packages. Compare and contrast different applications with
reference to the Requirements Specification to identify a specific
package to use.
Based on the above explain why you have the software to use. Try to
relate your explanation to the key advantages of your chosen software:
the reduction of redundancy, inconsistency, program/data dependency
etc. You must justify the chosen package with reference to the
performance criteria and in terms of its usability and functionality.
Describe the minimum hardware requirements for the new system
(including peripherals).

13

Justification Diagram

Specific Software

Types of software available

Different ways of solving the problem
General Problem

3.2

Draft design work

This will be used to discuss your ideas with the client. The designs
should be accurate and presented as a word processed document or as
neat samples etc. You must show all of your draft layouts for your
proposed documentation/layout and these must be sketched by hand
(or using a DTP package). Your designs should be annotated to describe
each element used. The designs do not need to be works of art but
should contain enough detail and information to allow your client to
understand and for a 3rd party to implement the design as you intended.

3.3

Final design work

You will use this to actually create and implement your solution. This
design work should be in enough detail that it could be implemented by
a third party, it should be accurate, detailed and contain relevant
annotation to explain features to be used etc. You will produce final
designs for all elements of your solution (forms, documents, video
storyboards reports etc).

Storyboard
Draw a detailed storyboard of the system from the users viewpoint i.e.
the interface forms/switchboards, dialogue boxes and outputs. You must
show the links between boards and for each sketched board add
14

reference numbers that can be cross-referenced in the sub-sections

below.

Reports and other outputs

Explain why the use of reports/letter or other outputs are important for
your solution. What will they show, how will they be launched? Will you
be linking your output to another application, mail merge, spreadsheet
etc.
Output design checklist:
For each output you must include:
A description of the outputs purpose
Sketches of designs in development including any rejected ideas
Fully annotated sketches source tables/queries/fields, background or
text colours and styles, calculations, additional formatting

Other Issues
Some, if not all, of the data in your application is going to be
commercially sensitive. Assigning passwords and/or security levels
allows you to control who sees what in your application. Explain why
security is necessary (refer to the DPA) and explain how you will protect
the data in the application.
Prepare a strategy for backing up the system.

3.4 Plan for implementation, testing and instalment, including

proposed time scales
Revise your project plan, or create a new one, in light of further
discussion with the client. This is a more detailed plan than the one
included earlier in your work. Your preparation should have given you a
better idea of all the tasks you will need to tackle in order to meet the
deadline. Prepare a plan listing and prioritizing how you will complete
the project (including start and end dates). You must describe in detail
the sub-tasks that will need to be completed and should include a Gantt
chart.

3.5

Training requirements for the new system

This may include what documentation will be required for training the
users. You need to think about whether any security awareness training
is needed etc. Will you need alternative materials or a different format of
training materials for different types of employees?

3.6
15

Testing strategy

This should set out what testing is necessary, who will do it, when and
where. Students should describe here any constraints on live testing
that require a simulated environment to be used. This needs to be
clearly laid out in a logical order, stating who will be involved in a
particular stage of testing and a broad description of what is being
tested and how. Make sure that you do this with reference to your
clients requirements.

3.7

Test plan

Include the tests to be undertaken, what the tests are testing, and the
order in which the tests will be completed. You must also make clear
what data will be used and the expected results. It cannot be
emphasised enough how important this element of your design is. Make
sure that every field and control in your application is tested in some
way. Look back at your input/output/table designs and identify what you
need to test. Make sure that you test your solution as part of a complete
process.
Design a questionnaire for the end-user elements of the testing strategy.

16

Testing and documentation of the implementation

This section will assess your ability to implement and document

effective solutions which will be shown through your testing and
documentation of the system.

4.1

Evidence of testing

Testing should concentrate on the testing of complete processes and

the system as a whole. Evidence of functional or unit tests, for example
for validation or for the backing up of one file, is not required. No
individual field or button testing or validation testing is required as this
should have been done at AS level but you must evidence and cross
reference a selection of tests.
It is important that you complete full unit testing to make sure your
system works, that all validation is correct etc before you start formal
system testing. There is NO requirement for you to provide evidence of
unit testing. If you include it you will not gain any credit for it and AQA
have specifically stated that they only wish to see evidence of testing
the whole solution.
As there is no requirement for unit testing, and you no longer have to
provide any evidence of creating the solution (implementation), testing
and documentation is the only place you have to show the quality and
extent of what you have created. The marker and examiner will not see
your finished solution, only your project report, so if you have an allsinging, all-dancing spreadsheet or database then you need to make
sure there is evidence of it here. If it is not appropriate to include it in
the testing section, then consider whether it would be more appropriate
in the technical documentation section e.g. database structures,
finished web pages etc.
Copy the test plan from the design section into this section and carry
out each test systematically one at a time. For EVERY test you need to
add what actually happened to the Actual Results column. You must
provide evidence via screenshots, scans of reports etc plus a
description of what the evidence shows. In the comments column you
can add any modifications you had to make or include a reference to the
page number of where the testing results can be found. Make sure
every piece of test evidence refers to the correct test number. Before
and after screenshots may be applicable in some cases to prove
something works. If any test fails, for whatever reason, you must retest
it and show evidence of it working.

17

4.2

Evidence of client and end user testing

The client and end user testing should be made evident. You must get
them to complete and sign the questionnaires that you have created.
It is essential you have your client and users test the system you have
created. There needs to be evidence of their involvement and it is
beneficial if you can get all of your users to test the system.
Print out the user test plan you created in the design section and give a
copy to your users (you should have more than one user). You may
have different tests being done by different users so make it clear which
users are doing which tests. Ask them to do all the tests you have
identified and to add their results and comments to the page. It is also
sometimes beneficial to give the users a blank test plan so that they can
add any extra tests they think of that you may have overlooked. Or ask
them to write a short document about their findings. (Refer to sections
4.5, 5.1 and 5.2 regarding client feedback). These documents can then
be scanned into the appropriate place in your project report.

4.3

Comprehensive documentation of the solution

This should be comprehensive documentation of the solution that would

allow the solution to be used, maintained or developed further which is
appropriate for the end user. This documentation could be technical or
user documentation depending on the individual project undertaken and
the agreed deliverables however as a minimum a user guide must be
produced.
The types of documentation you could consider creating:
o User Guide
o Technical or maintenance documentation
o Installation Guide
o Training Manual
o Training Instructors Manual
You will probably create just the first two of these, unless you have a
specific requirement from your client to create any of the others, or to
deliver a training course. Include a paragraph in your report of how you
think your documentation (all types) meets the needs of the client/user.
Make sure you reference where the documents can be found in the
Appendix.

18

User Guide
A User Guide should be a separate document provided for your users
and should be presented in the appendix. It should be written in
language that your users can understand (i.e. not technical!) and should
be pleasing to the eye. Try and find some good and bad examples of
manuals to help inform your choice. What you include will depend on
your system but you could consider:
o A Front Cover
o A Table of Contents
o An introduction stating what the system is about and who uses it
o Instructions on how to load the system (and install it if
appropriate)
o Routes through menus/website navigation guide
o An explanation of what each option on a menu does using
screen shots to illustrate
o Samples of output on screen and paper outputs
o Any special instructions on how to input data e.g. the format of a
date field or the range of accepted values for a field
o How to save changes
o Explanation of error messages and what to do if they occur / FAQ

Technical Documentation
A separate document that can be used as technical documentation is
strongly recommended though it does depend on what type of system
you have created. Include it as a separate document with its own front
cover, table of contents, page numbering etc and include it in the
appendix. This is NOT a guide on how to use the software (assume that
the reader knows the software); it is documentation to help someone
maintain your system and make changes to its structure, add new
features etc. Remember what was said in the testing evidence. If you
have a complex solution but it hasnt been evidenced very well in testing
or anywhere else, consider putting it in the technical documentation.
What you include will depend on your system but you could consider:
o Hardware and Software requirements
o Instructions for opening and configuring the system
o Database relationship diagrams
o Database table structures
o Validation and verification procedures
o Macros
o Complex formulae, functions, calculations etc
o Any programming code you have used
o How web pages link together (hierarchy diagram)
o How to upload changes to a website
19

o Information about domains, web hosting etc

20

Appropriateness of Documentation
You need to get feedback from all of your users so that they can
comment on the documentation you have supplied. You could do this
via a questionnaire if you wish. It could also be combined with all the
feedback you need to get for the whole solution, not just the
documentation. Write a concluding paragraph to back up your evidence
and explain your conclusions. Include any client and user comments
here with evidence e.g. scans, letters, emails etc.

21

Evaluation of the implemented solution

This section will demonstrate your ability to carry out logical, reasoned,
critical evaluation that is related to the evaluation criteria and clients
needs for the solution and to your own development. Ask your client
and users for feedback about your solution. This could be in the form of
a questionnaire so you can ask specific questions, or it could be general
comments from them. Either way, you must include some feedback in
your evaluation and also refer back to your testing to back up any
statements you make. Include any written feedback you receive in your
report.
Look at the solution as a whole and identify the strengths and
weaknesses of the system.
o What works really well?
o What is not so successful?
o Is the solution an effective one?
o What improvements and enhancements would you suggest?
o Are there any changes the user would like to make? Why?

5.1

A critical evaluation

This should be a critical evaluation of the solution against the evaluation

criteria and the clients needs as defined during the investigation and
analysis stages. Show evidence from testing and how it relates to the
evaluation criteria. You need to identify any strengths or weaknesses in
the solution and any areas for improvement. Think about evaluating
against client requirements and the original problem. How has the
company benefitted? Are there any negative implications? How do you
know? Are there any areas for future development?
Now you need to evaluate your system in more detail by referring back
to the original client requirements and evaluation criteria. Copy your
table of requirements and evaluation criteria into this section from the
analysis section.
For each requirement, comment critically about each of the evaluation
criteria that relate to that requirement. Again refer to client feedback
and your own testing to back up your comments. You can include any
suggested improvements here too. Use the four questions above to
help structure your comments.

22

5.2

Evaluation of own performance

You are required to identify your strengths and weaknesses in the

approach you took and how you have learned from any problems or
achievements. How would you improve your performance on a similar
project in the future? What else could it do and what would you do if
you had to do the project again? Think critically about what you have
done and what you have failed to do?
Then you need to consider areas for improvement. Students usually
find this part quite difficult. AQA have included an example of a selfevaluation on the teacher resource bank of the website and you should
have a look at this for ideas. Also, try the following:
o Identify an achievement, something you were pleased with, or
proud of, in this project
o What have you achieved? What has changed for you? Is there
something you can do now that you could not do before? Is there
something you now understand that before wasnt clear?
o Why is this achievement important? What does it mean to you?
o How do you know what youve achieved? What specific evidence
do you have? This could be a skill you have acquired in your
project.
o How did you get there? What specific actions did you take?
o Can you build on what youve achieved? Is there a next step? Are
there still aspects you would like to improve that would make an
impact on your performance in the future?
o Try and answer the above questions for other achievements in
this project.

23

The project report

The report should be well structured and should make use of the
facilities available within software packages to enable this to be done;
for example, by including a contents list, headers/footers, pagination,
indexes, effective use of appendices and presentational techniques.
You need to make use of technically accurate illustrative and visual
material for effective communication. The standard of your written
communication will be assessed in the report.

Use of Software
Use styles to ensure all headings are consistent throughout the
report
o Make good use of consistent styles for different levels of
your work
o Use bullets, outline numbering techniques (i, ii etc)
o Page numbers are essential in the footer and should be
sequential
o Use headers and footers for other relevant/helpful information
o Page layout (both landscape and portrait may be required
within the document)
o Use of section breaks
o Use consistent margins
o Include a table of contents
o Include an index if appropriate
o Captions for any illustrative material
o Use an Appendix where appropriate e.g. for Terms of
Reference, User Guide etc
o Appendices should be used sparingly

Organisation and Use of Language

o Use the section headers detailed in this guide, this will help
with your organisation
o Use appropriate technical language
o Make sure you use the spell checker and that it uses UK
spellings not USA
o Use correct grammar
o Dont use text-speak!
o Get someone to proof read your work
24

o Check, check and check again. There is nothing worse as a

marker seeing constant spelling and typing errors.

Diagrams and Illustrations

Illustrate your work as appropriate using
o Photographs and pictures
o scans of original documents
o sketches
o screenshots
o hierarchical diagrams e.g. in website design or organisation
structure
o Use captions on your illustrations e.g. Fig 1 etc and refer to
them in your written work

25

26