Database Fundamentals Assignment (Weighting 70%)

Database Fundamentals Assignment (Weighting 70%)
For your assignment you are required to design and Build a database application in Microsoft
Access.
The design brief is as follows:
1. You are required to design a computerised database system for an online bookshop.
2. The system must enable the user to perform the following tasks:
• Log on as either user or administrator
• Register as a new user.
• Allow all users browse the shop by Subject.
• Allow all users to search by Author/Title/Subject.
• Allow all user to check order status
• Allow the user to check out
• Allow the user to view/edit personal information.
• The administrator must be able to add and delete items of the store and change
their description. The standard user will not be able to do this.
3. Your design should be implemented in Microsoft Access database.
4. I shall arrange for each one of you to have three 5 minutes interview with me during
the development. These interviews will be arranged during the following lecture
sessions:
Interview 1: Specifications Week 6
Interview 2: Testing Week 9
Interview 3: Commissioning Week 12
I shall produce an alphabetically arranged list of students with interview times.
To help you with your design and development work I have included guidelines below. These
guidelines are designed to tell you how you should approach the problem, carry out the design
and implementation and what evidence you must submit to support your work.
The guidelines use reference to imaginary users of the database in order to give you an idea of
what details need to be included.
The marks for this assignment are allocated according to the following scheme:
Database Fundamentals - Assignment Marking Scheme
Activity description
Allocated
Marks
1 Definition - Nature of the problem. 5
2 Investigation and Analysis. 15
3 Design 10
4 Intended Benefits. 3
5 Limits of the Scope of the Solution. 2
6 Development and Testing. 15
7 Implementation. 10
8 Appropriateness of structure and Exploitation of Available Facilities. 5
9 Technical documentation. 10
10 User documentation. 5
11 Discussion of the degree of success in meeting the original objectives. 10
12 Evaluate the User's Response to the System. 5
13 Recommended further work 5
Total Marks 100
1

Database Fundamentals - Assignment Project Report
Guide for students
Table of Contents
Section 1 Analysis ............................................................................................................ 3
(a) Definition, Investigation and Analysis ...................................................................... 3
(i) Definition - Nature of the problem. (5 marks) ................................................................. 3
(ii) Investigation and Analysis. (15 marks).......................................................................... 4
1. Problem. ......................................................................................................................... 4
2.Backround........................................................................................................................ 5
3.Solutions. ......................................................................................................................... 5
4. A requirements specification. ......................................................................................... 5
(b) Design .......................................................................................................................... 6
(1) Nature of the Solution. (10 marks) ............................................................................... 6
(ii) Intended Benefits. (3 marks) ......................................................................................... 7
(iii) Limits of the Scope of the Solution. (2 marks).............................................................. 8
(c) Software Development, Testing and Implementation. ............................................ 8
(i) Development and Testing. (15 marks) ........................................................................... 8
(ii) Implementation. (10 marks)........................................................................................... 9
(Iii) Appropriateness of structure and Exploitation of Available Facilities. (5 marks)........ 10
(d) Documentation.......................................................................................................... 11
(i) Technical documentation. (10 marks) .......................................................................... 11
(ii) User documentation. (5 marks) ................................................................................... 12
(e) Evaluation. ................................................................................................................. 13
(i) Discussion of the degree of success in meeting the original objectives. (10 marks)... 13
(ii) Evaluate the User's Response to the System. (5 marks)............................................ 14
(iii) Recommended further work. (5 marks) ...................................................................... 14
2

You will be assessed for each of the sections given in this guide according to the evidence that
you produce. The evidence that is required for each section is clearly stated in the guide.
Your assignment report should consist of the following sections
Section 1 Analysis
(a) Definition, Investigation and Analysis
(i) Definition - Nature of the problem. (5 marks)
Every project has an aim and in this case you are required to solve a problem. You are
computer systems analyst who is charged with delivering a solution to this problem. Your client
is me (for most part of this project). You will need to meet up with me for a 5-minute session on
three occasions;
1. At the beginning in order to elicit information from the client (week 6)
2. Mid-way through the project (week 9), to determine if system is looking right.
3. At the end of the project (week 12) to determine if the product is as client
expected.
To define the problem you will have to meet with me for the first session and for this you will
prepare a series of interview questions that I shall try to answer. You will use these answers
and any assumptions that you may need to make, to produce the requirement specification.
Some of the details that you will need are: (other details you will obtain at the interview, and
remember that you can also make some reasonable assumptions)
You are required to design a computerised database system for an online bookstore.
At present the customer runs a book shop and wants to expend the business aiming to
open an online book shop which allow user to register and browse the bookshop and order
books online. When registering, the new user should provide information like full name,
address, email, phone number and credit card information as well as choosing a
username. The user should be able to browse the shop based on subjects. It should also
provide the search functions based on the author, title and subjects. User should be able
to easily add the books browsed to the shopping cart. The system should also a user
friendly function for checking out and provide users the invoice. The system should include
an administrator accunt which allows the administrator to add new books to the database
or delete the book which has been sold out.
Although it will be perfect to provide a web based online bookshop, it will be good that at
the first stage you can design a database systems simulating how it will work just in a PC
with Access 2007 installed.
There are two administrators on the system: Joe Lunghi (shopkeeper) and Anjim Brown
(his assistant).
It is further intended that the computerised system support the following features:
• Log on as either user or administrator
• Register as a new user.
• Allow all users browse the shop by Subject.
• Allow all users to search by Author/Title/Subject.
• Allow all user to check order status
• Allow the user to check out
• Allow the user to view/edit personal information.
• The administrator must be able to add and delete items of the store and change
their description. The standard user will not be able to do this
3

• The user should be able to submit a registration form, but the administrator has to
approve it before the user is allowed access to the system.
Evidence:
As evidence that the work has been carried out properly for this section you will need to
produce the following:
A description of the organisation that has the problem and the place of the problem
within it.
I have done this for you above, in its basic form and you can include the description that I have
given. You are welcome to change it as you see fit and make any assumptions.
A description of how the chosen problem is dealt with at the moment.
Once again, I have given a brief description. You can make some assumptions and elaborate
on this. Assume it is your local library and consider that the system is not computerised yet.
Then make assumptions on how things are done.
A clear description of the data that is used in the area of the problem.
Once again, you will need to consider the data that is needed to help you maintain a record of
lending in a library. You can start by considering that data structure is as follows:
Books: Author, Title, ISBN, Price, Subject
Orders: OrderNo,ReeceivedDate,ShippedDate, ShipAddress
Etc..
Note that the exact data that will form part of the solution is as yet not known because the
problem has not been fully specified, however, it is necessary to be aware of all the data that
may be required.
A clear indication of where the data came from. How it is collected.
Much of this information may not be known. The analyst may have to make and clearly state
any assumptions at this stage,
(ii) Investigation and Analysis. (15 marks)
This section of the work is in four parts:
1. Finding out what the problem is in some detail.
2. Learning about the area within which the problem is situated.
3. Considering different types of solution to the identified problem.
4. A requirements specification, which will allow the student to carry on to the next stage.
1. Problem.
This is going to involve the end user, in this case me. The analyst (student) needs to find out,
in detail, what the end user wants from the system. The normal solution is to arrange an
interview with the end user. This is not a matter of the student having a general chat with their
end user, or even having detailed discussions where the end user has carefully considered all
the questions and asks them in order. It must be planned and yet be very different from simply
reading from a questionnaire.
The interview sessions will take place in week 6. Each student will have the opportunity to ask
me questions about the work and I shall allocate a strict limit of 5 minutes to each student, (so
come prepared).
The student should go into the interview with a series of well-prepared questions to ask.
However, they should not be asked as a simple list. If this is all that is done, the interview is a
waste of time; the end-user could simply have filled in a questionnaire.
4

The whole point about an interview is that the questioning should be flexible. Students should
have `starter' questions on each of the areas to which they want answers. They should also
have prepared a series of follow up questions that can be used, dependent upon the answer to
the initial question.
2.Backround.
Students should not forget that there are different people involved in this organisation. I have
identified for you that there are two administrators and a number of users. You may assume
that the maximum number of registered users on the system is 1000.
At this stage the analyst may chose to gather information from these here will be important to
be gleaned from these people about the features of the system. This can be done by using
different methods of collection. For example, a sample of users (how are they to be chosen?)
could be sent a questionnaire. If you chose to design such a method, you may consider other
students as users, and if they are willing to fill in a questionnaire then this is up to you to
organise.
3.Solutions.
Having collected all the information, different types of solution may present themselves for
consideration.
In general I have suggested that a database solution is required. However, you will need to
consider how the database will be shared with users. It is likely that different solutions will be
possible and you need to consider these.
These different types of solution must be considered as they provide a pointer towards the
identification of the final problem. These different approaches should be discussed with the
end-user and the responses should be noted. You may chose to ask me questions at interview
1, in relation to this.
4. A requirements specification.
Now that you have identified the problem and the type of solution, which is necessary.
Thoughts must now turn toward the hardware and the software that will be necessary to
provide a solution. I have given you the specification of the network, but you are welcome to
suggest any modifications at the interview stage.
Evidence:
This section deals with the specifications. Some of these are given to you, and you should list
these if you chose to adopt them. Other functionality you will ascertain from the interview.
Thus, detail relating to the planning of the end-user interview need to be produced.
The original plan of the questions, showing that all areas had been planned to be covered and
that sensible follow up questions had been considered.
Transcript of the interview itself, including an element of later analysis and isolation of
important facts.
Further evidence of information collection relevant to the problem area.
Possibly a data flow diagram (or some other representation) showing how the present system
works.
Consideration of different methods of solving the problem, together with some evidence that
the end user has been involved in the decision making.
Hardware and software requirements of the system with discussion about the needs for each
and any problems that may arise because some elements are not available.
5

(b) Design
(1) Nature of the Solution. (10 marks)
Following the collection of information about the organisation and the perception of the enduser
about the problem that needs to be solved, the student should now decide what the scope
of the project is going to be.
In other words, the student should decide what needs to be done by the time the project is
finished.
The student should draw up a list of required outcomes (objectives).
Just to give you an idea what objectives are, consider an unrelated problem of allocating
lockers in a primary school. Here, for example, the list might start with the following objectives:
• Mr. Bezanov must be able to access all the records.
• Mrs. Rogers must have complete access to year 8 records but not to other years.
• It must be possible to pass on records to the next year/form groupings at the end of a
year.
• A form teacher must be able to output a series of letters to the parents of pupils who
are behind with their payments.
These objectives must be easily quantifiable. When the project is over it is simple to check to
see if form teachers can produce the required letters.
The final list of objectives should be signed by both parties and will provide the basis both for
the evaluation of how successful the project has been, and also for the testing regime that is
going to be used towards the end of your work.
When you are ready with your objectives, you can ask me to come and sign the document that
constitutes our agreed objectives. This document should be submitted with your report.
The next stage is for the student to design the output documents and the input formats with
appropriate screen designs.
The end-user does not need to know anything about the processing or the data structures that
are to be used because they are not in the realm of the user.
However the end-user does need to know what the input and output formats are likely to look
like. These, together with the list of objectives, make up the design specification and should
now all be agreed with the end-user.
Students should realise that this process of agreeing the design specification should take some
time. If the student has one interview with the end-user, who, subsequently, immediately
agrees to all the student's suggestions without needing further modification, then the
relationship is not a realistic one.
Remember that the intention is to mirror the real world, in which the process would continually
need fine-tuning. Later in the project the student may well find that the original design
specification is no longer satisfactory, this is not a point at which the student should think that
their project is a disaster, but rather an opportunity for involving their end user again in
modifying the design specification. The student should be encouraged to document all such
occurrences and how they were resolved.
The next stage is to determine how the data will be moved around the system and be stored
within it. The simplest way of describing this is to draw it but it could be described carefully in
6

words. The important thing is to convey to the reader that there is a clear idea of how the
different parts of their system fit together and where the data is stored within the system.
The next stage is to consider the data that needs to be stored on the system. The data should
be divided up into different groups (files) dependent on the use that will be made of them, and
the links with the other files.
An attempt should be made to arrange the data into files so that there is as little duplication of
the data as possible. This will inevitably mean that the files will need to be linked so that data
from one file can be used in an application area designed for a different file.
The data attributes, or fields, from each file should be listed. It should be clear what field or
fields will be used as the key and also the foreign keys that are going to provide links with the
other files in the system.
It is then necessary to explain the purpose of storing each of the fields and to decide the data
type that is to be used for each field. When the files have been defined, it is then necessary to
size them by giving a size to each of the fields and scaling up to give an indication of size for
the whole file.
Each of the items of data in the file will need to be input; consequently there will need to be
validation done on the data input. These proposed validation checks should also be detailed.
Evidence:
A list of objectives against which the final product can be measured. This report should be
signed by the end-user (me in this case)
An explanation of the way that the data is to be collected.
An explanation of the way that the data is to be input to the system together with any initial
plans of input screens, and explanation of intended means of validation.
An explanation of the output that should be expected and any initial screen designs for the
output of data.
Details of the file structures that are to be used and the links between them.
Explanation of the way the data is manipulated through the system. This section could contain
a diagrammatic representation of the data through the system.
If the solution is to be attempted in module form there should be a description of the way the
problem has been modularised and also how the modules will ft together.
(ii) Intended Benefits. (3 marks)
The introduction of a new system should, by definition, include changes that will be made from
the old way of doing things. If there are to be no changes, then what is the point of the system
being changed in the first place?
These changes can be one of two types. Either they bring improvements on what went before,
or they make the system worse. It is to be hoped that the time and energy expended on
producing a new system will mean that the solution is an improvement on what was there
before. It is the expected improvements that are discussed here.
The sort of response expected is: "The new system allows the user to search a large number
of records for the presence of a particular value far faster than the old system because the
user does not have to look at all the individual paper records."
7

Evidence:
In this section you will need to produce evidence of three specific improvements that the new
system will make to the running of the old system. It may be useful to give four benefits to be
on the safe side.
(iii) Limits of the Scope of the Solution. (2 marks)
Any solution will be limited as to its effectiveness by a number of things. The hardware that is
available to produce the solution may limit the number of options available. For example, if
there is no A3 printer available, then it is not possible to produce an A3 version of a large
spreadsheet to be used at a board meeting. The software will dictate the types of solution
possible and the facilities of the particular examples of the generic software that are available
dictate the way that the final product can be presented.
You may need to make assumptions here, but do state what assumptions you have made.
Particularly important are the files of data that are to be used as part of the solution.
The real world aspect is that the files will be of a measurable or predictable size. It is
necessary to know this predicted size because it will effect many other decisions. An obvious
one is the decision about how the file is to be backed up and onto what medium.
The other aspect of the size of the data files. There is a limit to the size of the files that it is
sensible to expect a student to produce. It is not a sensible use of a student's time to expect all
the data to be input to the system, so the idea of creating a file, which is a fraction of the size of
the real file, while retaining its characteristics, is sensible.
It is necessary to size the full file to show that the size of the file is understood and then to list
the size of the file and the time available as a limitation in the solution.
Evidence:
A description of the contents and data types stored in each of the files to be used together with
an approximation of their size.
Any adjustments that the student thinks are necessary to their solution compared to the real
thing.
A list of any limitations that have been placed on the solution because of the hardware
available and the software available.
(c) Software Development, Testing and Implementation.
(i) Development and Testing. (15 marks)
By this stage the planning of the intended system has been done and the design has been fully
documented. The decision has been made whether to use a tailored version of a software
package, or to write a piece of software or a mixture of the two.
Whichever it is, it is necessary to produce outputs to demonstrate the necessary tailoring has
been done and that the data files exist. That the coding has been written and that the results
are produced.
All the work that is given under this section should be annotated do not be scared of `spoiling'
your beautiful printout by annotating it. The more written explanation the better. It is a good
idea to do all the annotation in pencil because it distinguishes it from the other work and it also
means that it can be altered easily.
It is essential that the solution is tested in order to make sure that it is able to do all the things
expected of it.
Note that if the testing is planned after the solution is developed there are two problems. The
first is that the testing will tend to be devised in order to show what the solution can do, not
8

whether it can do what was intended and this leads to the second problem, that the original
specification may not be tested at all.
For these reasons the testing needs to be planned before the development of the solution. This
test plan should contain details of the areas of the solution that will be tested and the results
that should be obtained when they are tested.
The final report should contain evidence of the existence of the solution and also the input and
output from the solution to prove that it actually exists. The elements that were detailed in the
test plan before the development of the software solution should now be executed and the
results tabulated.
Remember that it is impossible to fully test a software solution to ensure that it always works
because for most problems there will be an infinite number of possible input/process/output
combinations. All that can be reasonably expected is that enough test runs have been carried
out to show that the different parts of the system work as anticipated and that errors in the data
are captured and don't produce any unpleasant surprises.
If the solution involves original coding then the listing should be present and should be fully
annotated by the student. It is important to think of the reader of your report as someone who
can understand program logic, but who does not know the particular characteristics of the
specific programming language that the student has used.
Evidence:
The testing plan. This should consist of at least 8 different areas of the solution to be tested,
including an indication of what is expected as the outcome.
If the full marks are wanted from this section, the student should include enough testing to be
able to test all the different areas of the solution, though, remember, it is not possible to test
every aspect of the solution with all possible values, and this should not be attempted.
Data structures are described and their existence is proved by means of printing them out.
Input and output screens are described and produced. They should be fully annotated to show
their effectiveness.
The file before and after the input of the data to show that the test has proven that the data is,
indeed, input to the file. Remember that it is not good enough to simply type in the different
fields of a record and print out the form to call it a test.
For each of the tests planned the intention of the test run and the reason why this particular
test is necessary.
What is it testing? It is also necessary to have a clear idea of what the expected result is. If the
test does not produce the expected result there should be a detailed explanation as to why the
expectations were not met.
Detailed and annotated program listing if any original code has been produced.
(ii) Implementation. (10 marks)
This section refers to the way that the end user, or their organisation, has been involved in the
development of the solution. Ideally, the end user has been asked at various stages to look at
the solution `so far' and to give their opinions.
This is known as prototyping, and the end-user's views should be acted upon as far as
possible, or at least discussed to explain why something may not be possible.
This sort of exchange should be documented as it shows that the importance of the end-user is
understood by the student. The user should be able to use the solution and obtain meaningful
outputs, evidence of which should form part of the report.
9

Not every project will result in the system being fully implemented into the organisation for
which it is intended. It is probably rare because the limitations imposed on the solution are
normally such that there is a better solution available elsewhere.
However, it is important for the student to imagine that the solution will be fully implemented,
because there are marks in this section for producing a working plan for the change over of the
organisation from their old system to this new one.
This plan of implementation should have details of the training that is required to allow the
workers to be able to use the new system adequately, and where this training is going to be
available and what it needs to contain.
Plans must be made for the creation of the files, where the data is going to come from and how
they are to be kept up to date while being produced.
Finally, how will the changeover be made? Will it be a big bang, or a phased introduction, or is
there a better means of introducing the new system? What are the reasons for the choice that
has been made?
Evidence:
Evidence that the end-user, or some other representative of the organisation, has seen the
system. Here we will have another interview this will be in week 9. I shall once again allocate 5
minutes to each analyst in order to see their system and give them feedback. You can design a
short questionnaire for me if you like, but all in all I shall only spend 5 minutes with each
analyst.
Evidence that the end-user has used the system, and has obtained meaningful results from the
system.
Evidence that the end-user has been involved at different stages of the system development
and has not just been tacked on at the end. You will keep a logbook, to be used as evidence of
this. (But as I said, I shall not mark the logbook)
Hopefully some evidence that the opinions of the end-user have been used to adapt the
solution.
Details of the training that will need to be available for the staff that must use the new system.
Details of the means by which the new files are going to be created, including some indication
of the scale of the problem.
Details of the changeover anticipated.
(Iii) Appropriateness of structure and Exploitation of Available Facilities. (5 marks)
Whatever the original problem and the solution decided upon, there will be a degree of
choosing the solutions to problems before they have actually arisen. If I once again consider
the example of locker in a school, then, at one extreme, the school has a certain amount and
type of hardware available, in reality the student has no control over this, and with hindsight it
may well be that the available hardware was not ideal.
Similarly, the software that was used in the solution may not have been the best available, or a
choice made earlier in the project may lead to problems later on.
The purpose of this section is to show that the student can look beyond their solution to identify
problems that have arisen. To show that the student is capable of being critical of his or her
own work in the same way that a systems analyst would need to be.
All large-scale work of this nature will be subject to difficulties during the construction of the
solution. Any project that has been produced by a student who says that there were no
problems has either been too superficial or the student is suffering from selective memory! It is
10

important that these difficulties are noted and that the student reports them and catalogues the
solutions that were found.
Evidence:
A critical appraisal of the hardware that has been used, to include comments about more
appropriate hardware if the student feels it necessary. For this project, you can take details of
your own computer and note these. Assume that there are four of these in a network all with
the same specifications. You can allocate your own computer names.
A critical appraisal of the software that has been used, to include comments about more
appropriate software if the student feels it necessary. Here, I have asked you to use Microsoft
Access. You are encouraged to consider alternative databases, but your final design will have
to be in Access.
A log of all the problems that were encountered during the production of the solution. This log
should include a detailed description of the measures taken to solve the problems found. There
should be references to the evidence that the solutions had the desired effects. This part of the
work is so important and as I have said at the beginning you will need to maintain a logbook
during your project work.
(d) Documentation.
(1) Technical documentation. (10 marks)
The technical documentation is hard to pin down in a guide like this one. The reason being that
the content will differ massively dependent on the type of project produced.
However, there are some general rules that should be followed. The first is that the technical
documentation should be a stand-alone document. In other words, the finished item should be
capable of being useful without reference to any of the other documentation in the project.
The result of this is that if an item is deemed to be important enough for inclusion in the
technical documentation and that it already appears elsewhere in the project, it is necessary to
make a copy of it for inclusion here.
The technical documentation should be seen as being all the information that another analyst,
or programmer, or student would need to carry on and finish the project, or amend the project,
without reference being necessary to any more analysis or design.
The guide should be well presented, should ideally be bound separately from the main project
and should give the impression of being a seamless presentation, rather than simply a
collection of individual items.
Evidence:
A description of the records used and the fields within the records.
The types of data should be described as should the data structures used to hold the data. Any
data handling implies that data has been stored. Whether the project is based on programming
or on tailoring software, it is going to be necessary to explain how the data is being stored.
If a database solution has been produced, an explanation of the relationships between the
various files, or tables, and the linkages used.
The screens used and the menu system for the input of data along with the form designs
where these items are appropriate to the particular project.
A data dictionary or list of variables used and details of the formulae used, the queries
employed, and the algorithms for any coding, whether it be SQL in helping to analyse a
database, or another HLL which has been used to produce a piece of original software.
Any algorithms should be fully annotated and supported by annotated code, which takes
advantage of automatic annotation techniques like comments and indentations.
11

A listing of the recommended hardware and software configuration needed to run the system.
(ii) User documentation. (5 marks)
The first thing to realise is that there are two quite distinct types of user guide. A User guide is
simply that. It is a guide for the person who is intending to use the project to do something
useful.
Unlike the technician they do not want to understand how the solution works (indeed, the user
may well not be able to understand the logic behind the solution) but they do need to know
how to make it do something useful.
The two types of user guide are a guide in paper form and one, which is available on screen,
electronically. The first is useful because it can be used away from the computer, while the
second is useful because the contents required by the user are determined by the position in
the project where help was requested. In reality the best user guide will combine the two types.
Students should be wary about including details of the software that has been tailored. It is the
tailoring of the software that provides the solution to the problem, it is the tailoring of the
software that the user will use, and consequently, it will be the tailoring of the software that
should be documented here.
As a simple illustration, consider the case of a project that allowed the user to search a file of
data for all the people on the file who live in a certain town and then to mail merge their details
with a standard letter in order to send information to them about something happening in their
town.
If the solution is to be based on the use of a standard query from within the software package
itself, then the software has not been tailored properly and the inclusion of the necessary
techniques in the user guide would mean copying out chunks of the software guide which
would not be appropriate.
However, if the solution has involved the correct degree of tailoring then the user guide will
contain explanation of the forms that have to be completed and the type of data that is
required.
Examples of valid data would also be provided and the user would be presented with example
outputs so that it was known what to expect.
The user would not expect to see a long explanation about the way that the software created
the query and how it was dealt with.
Students should remember that there are a number of things that are important in the guide,
above and beyond the obvious `How to use it'.
The input requirements and the choices that the software will offer the user together with an
explanation of the results of those choices should be present.
Details of the outputs, both hard copy and to storage for the purposes of backing up the data
are important. In some circumstances it may be appropriate to go further and discuss the need
for archiving some of the data, particularly if the solution is based on a regular cycle, like the
start of the school year.
The solution may use a number of different pieces of software. In this instance the student
should ensure that they include an explanation of the different types of entry for different types
of data.
This will normally take the form of a menu screen offering the user one of a number of forms
that can be filled in with the data.
12

These different options should be understood. The user should be able to find their way around
the user guide with ease; consequently, an index is necessary (or at least a contents page).
The student should not lose sight of the fact that the final user will probably be largely
computer illiterate. This means that there are likely to be a number of terms used in the project
as a whole, and in the guide in particular, which will need to be explained.
A glossary of terminology used (like a short dictionary) is valuable.
Don't lose sight of the fact that for full marks there should be an on-screen help guide (however
rudimentary) to supplement the paper one.
Evidence:
A contents page and possibly an index.
Details of input requirements including examples of valid and invalid data with explanations,
examples of the input screens so that the user knows what the screen will look like.
How to move from input to input on the screen, how to show that the screen input is completed
Methods of output. How to select them, where the output will appear, how to facilitate output,
even simple things like `ensure that the printer is switched on. If there is a choice of hardcopy
output, how is the choice made and what criteria are used to decide on which output device to
use?
Explanation of the error messages that may appear. In most projects these will tend to be
related either to the printer or to data that has failed a validation test on input to the system.
Back-up routines and data archiving strategies.
Methods that have been used to protect the data. For example passwords on files.
A certain amount of on-screen helps. This may take the form of error messages or may be
more active, allowing the user to access advice about a particular part of the solution from
within the solution. Screen dumps or photographs of these on-screen help facilities will be
needed as evidence.
A glossary of any words or terms that a typical user of the system may find confusing.
(e) Evaluation.
(i) Discussion of the degree of success in meeting the original objectives. (10 marks)
By the time this stage has been reached it is assumed that the end-user has seen the
completed piece of work, and that an attempt has been made to run the solution, either with
real data rather than test data, or with a real user rather than the student.
This section centres on a comparison of the hopes that were originally identified for the
solution way back in section 1 and what was achieved by the end of the work.
Each of the requirements that were originally agreed with the end user should be compared
with the final outcome and an assessment made of how well the project has worked, taking
into account any limitations that had been identified.
Evidence:
A clear matching up of the agreed objectives of the project, taken from the requirements
specification, with evidence that the objectives have been met.
13

For each objective a discussion about the degree of success that the student believes has
been achieved (with reference to the evidence in the rest of the report), any shortcomings that
the student has been able to identify and the reasons why such shortcomings occurred.
The results that were obtained upon using `real' data rather than manufactured test data. It is
understood that any problems outlined earlier about restrictions because of the Data Protection
Act or similar are still accepted. The distinction between the two types of data should be seen
as: test data has been specially chosen to have a certain characteristic which can be used to
test a specific area of the software solution, while real data is the sort of data that will arise in
operation of the system.
(ii) Evaluate the User's Response to the System. (5 marks)
The end user needs to use the finished system. Here we will have another interview, 5
minutes, no more for me to use your system.
Ideally the end user will be presented with the user guide and a machine that has been
switched on with the software loaded up, and left to get on with it.
This is a bit unreasonable, and the student should be on hand to answer any questions and to
help in the use of the software as the end user will not have been trained yet. However, the
principle that the end user should use the solution (and not just sit and watch the student make
it work) is an important one.
There should be evidence that the end-user has used the system, probably in the form of print
outs of completed tasks and a letter from the end-user stating how well they think the solution
has met the specification. It is often helpful to present the end user with a worksheet to follow
so that they are led through the system gently and so that there are no areas of the software
that they fail to use.
Evidence:
A letter from the end-user stating that they have used the software solution and listing the
things that they managed to do and those that they could not, or that still need work to improve
them.
Some evidence to support the letter. For example a printout showing an amendment to a
record in the file.
Some indication of the degree of success that the student has achieved in the opinion of the
end user.
(iii) Recommended further work. (5 marks)
The student should be aware that no system is ever finished.
However well a system works there are always going to be extra things that could be done,
rough edges that could be smoothed out, new hardware that could be used to give an
improved finished product etc.
The intention of this section is to show that the student is aware that however good their
project is, and however wonderful their end user said it was, there is always something that
could have been better.
The students should also be prepared to give themselves a pat on the back when they get
something right. This ability to recognise that a part of the work is successful is an important
point about the production of a system because it is necessary to have the skill to know that
there is nothing to gain from continuing this part of the system and that efforts would more
profitably be spent on something else.
14

Evidence:
Lists of those parts of the system that the student believes are satisfactorily completed.
A list of those areas that have not been successful. A reason why the student holds that
opinion and what should be done about it if there was enough time to rectify the situation.
Areas within the system where previously identified limitations have had a marked effect on the
results.
A clear indication that the student realises that, although the project is finished, the solution is
not and that there are a number of possibilities for extending the solution with brief outlines
about what would be involved in such extensions.
15