How to Write an A-Level IT Project

General Guidance

Objectives of Coursework

There are two main objectives to completing a project:

  1. To increase and improve understanding about the use of ICT
  2. To gain as high a grade as possible at A Level

The first will be achieved through good selection of a project and adequate use of software tools in solving the problem.

The second is more complicated.  It requires not only a good project, but also a project that is well presented, with all the marking points easy to find and that covers the criteria.  It is easiest to achieve this by layout and presentation.

Layout and Appearance of Projects

The following are recommendations for presentation of a project.  The main point to be aware of is consistency and clarity.  Whatever you do, it must the same throughout the project - keep headings the same so that the examiner will know what they are looking at, keep the spacing and justification the same so that it is easier to read.  Clarity is achieved by use of white space, including line spacing, bullet points and numbering and adequate selection of font type and size.  It makes the project easier to read, and a consequence of this is more marks.

The following guidelines allow a project to be easy to read and mark.

  • A simple title page containing the name of the project, the name and number of the centre, and the candidate name and number.  There is no need for clipart or graphics on the title page.

·         A contents page, listing all the sections.  The listing should be easily cross referenced to the marking scheme.  Word will automatically create a table of contents for you, providing you use styles.

  • A header/footer should be on every page.  It is irrelevant which you use, but one of them should be present.   The header/footer should contain, at the very least, page numbers.  Anything else is useful but not essential.  It would be useful to have the name/number of the candidate and centre name/number - especially if the project is loosely bound; and the section name.  For appearances, a line separating the header/footer from the body of text is needed.
  • Font and font size should be consistent.  Headings, sub heading and body text size should be thought about before embarking on the write-up and used throughout the project.  Do not use a large size or a font which is difficult to read - ideally Times New Roman or Arial as a font, and size 10/11/12 as a font size for body text, with sub headings size + 2 and headings +2 again.  So you might end up with body text as size 11, sub headings at 13 and headings at 15.  
  • Paragraph formatting should be consistent - whether you use indents at the beginning of paragraphs, 1.4 or 1.6 line spacing, justified text or merely left aligned, it should all be consistent.  The recommendation is to use no indents at the beginning of paragraphs and a blank line between them.  The text should ideally be fully justified.
  • No printouts should be included without annotation.  Every image should be explained and be relevant.  If there is no justification for its inclusion, then it should not be there.  The same rule can be applied to any text.  Do not include anything for the sake of it being there - there must always be a valid reason for inclusion.
  • Wherever possible you should capture images and screen pictures using appropriate software – physically cutting and pasting should be a last resort.
  • If you have lots of information of the same type, it is useful to create appendices to hold the data - if you have many questionnaires or interview transcripts, these can be placed in the appendices and referenced from within the main body of the project. 

There is a sample handout for pupils in the appendices, detailing a set of guidelines for laying out a project.

Evidence To Submit

The examiner can only moderate what has been submitted.  If you create a fantastic project but do not include evidence of it in the documentation, it cannot be marked and you will lose out.  Similarly, if you miss out one of the sections, you will lose marks. The only way to make sure you get the marks is to submit work under each section and make sure you have covered every mark point.

You may not submit disks or CD-ROMs.  The bulk of your evidence will be written evidence on paper.  However you may submit photographs, videotape, and audiotape as evidence.  Although this is permissible, paper based evidence is usually the best method and recourse to the other methods should only be done if there is no other possible solution.  You may submit references to web pages, so if your project is to design and build a web site, along with the paper copies, you can include a reference to the site itself.

A final point to remember is that a lot of the coursework is about jumping through hoops.  To get the marks you must meet certain criteria.  These may not seem right, you may not agree with them, but if you do not meet them you will not get the marks.


Criteria for Selecting a Project

What makes a suitable project?

This is a key question to consider before starting the project.  If you make the wrong choice of project, it can take weeks to backtrack to correct it.  In the very worst case scenarios, it might not be possible to do anything about it and as a result your grades will suffer.

The project is worth 20% of your final grade and it is vital to get the choice correct from the very beginning.  The project should take approximately 80 hours to complete – this is the recommendation from the board and you should try and stick  this amount of time.

Some points to consider in the selection of appropriate projects are given below and should be looked at and read before beginning the project.

The project should fit the syllabus

This is a general statement but important.  The project should be able to meet all the requirements of the syllabus and be of sufficient complexity to allow the top marks to be reached.  If you read the marking scheme for the syllabus, it is possible to achieve all the required elements with a very simple project.  It is because of this that the problem itself must have a certain degree of complexity – it must be of A Level standard.  What then does this mean – A level standard?  The truthful answer is that no one knows until it is finished.  It is very easy to look at a completed project when marking it and to say that it does not come up to the standard required for a B grade at A Level for example.  But this is of no use to you – you need to know before you begin.  If you cover the following points you will end up with a project that is of A level standard.  The other guidance is that it should be harder than the GCSE project and above the level of difficulty required for the structured practical ICT tasks.

The project should not be a single problem to solve, but should have several different elements to it.

Take the example in the specification of a school bank providing access to statements via the Internet.  There are several problems – giving the right person the statement, updating details, security, link with mail merge for overdrawn individuals etc.  There is more than a single problem.

The project should enable the student to achieve all areas of the marking criteria

In the evaluation section, there are four marks available for “desirable extensions”.  If your project is a complete unit with no extensions, you will not be able to achieve marks in this area.  Therefore, you must make sure that when you are stating the problem you do not solve all of it, but leave room for extension at a later date.

A suitable problem with end user interaction

The project work ideally requires user interaction – that is, there should be a real problem to solve and people to help you.  It is recognised that it is not always possible for you to solve a real problem, but you should try and get real people to help you.  By real people, it refers to people who actually work in the area where your problem lies.  The people need to be prepared to help you with questionnaires, interviews and testing of the final solution. 


The following is a standard document that you might use when discussing the project with a third party.  It details what the third party’s involvement in the project is going to be and the likely dates.

Sample Layout of User Involvement

Approximate Date

People Involved

What is Involved

Location

1/7/01

All staff

Filling in Questionnaires

Office

5/7/01

Mr Jones

Interviews

Office

8/7/01

All staff

Allowing Observation

Office

10/9/01

Mr Jones, Mrs Adams

Discussion and agreement of design specification

Office

10/1/02

Mrs Adams, Mrs Lynch

Testing of the system

School

2/2/02

Mr Jones

Letter of faults, implementation and acceptance

Postal

Figure 0.1

 

A project that can supply documentation

The analysis section requires sample documents from the current system.  You must try and make sure that the project covers an area where you can get these documents.  There is a real difference between documents that are made up by you and those that are used within a company.  It is better to select a project area where the original documents are available and get it right from the beginning.

Work within the limits of the available hardware and software

You may have an excellent problem, brilliant design but unfortunately find that you do not have either the hardware of the software to implement it.  It is a balancing act to make sure that the solution does what you want within the resources available.

An organisation or a person?

The size of the organisation is always a question that arises.  You can create a project that gets full marks even if there is only one person.  The size of the organisation is not important – it can be a multi national company, or one person.  What is important is that you differentiate between the end user and the person in charge.  Even if there is only one person in the organisation, they may have to “put on different hats” to help you with different parts of the project – some parts require an end user response, some require a “management” contribution.  Even if this is the same person, there will be no problems as long as you make this distinction.


Final points to consider:

Interest

You will be working on this project for a considerable period of time.  It must be something that will hold your interest for that length of time – if you become bored of it in three months time and still have another five months to go, it may affect the quality of the work you produce.

Teacher supervision

At all times, the teacher must be convinced that the work you are producing is your own work and no body else’s.  This can be a problem if you do the majority of work at home.  It is essential that throughout the project each component is monitored by the teacher.

Teacher expertise

Although your teachers will have many skills, they will not be an expert in every piece of software written and every problem.  You must be aware that if you require assistance and support but have chosen software in which your teacher is not an expert, then you will need to find it from elsewhere and this may impinge upon the teacher supervision of the project.  The advice is to choose carefully and weigh up the advantages of using software that your teacher is not an expert in using.

Reference to real data

You must be careful when entering data into the system that you do not enter real data.  If you are entering names and addresses, one way around this is to pick a name from an address book a different address and a different telephone number.  This way the data entered will not relate to a “living identifiable human being” and contravene any of the principles of the Data Protection Act.

Programming and customisation

A common question is “how much programming must I do in the project?” and the answer, unfortunately, varies.  It will depend on the project.  It may be none, or it may be a fair amount.  However, to gain the highest grade it is expected that there is some programming and it must be appropriate.  You are more likely to customise an existing software package. 

The course is ICT, it is not computing and the examiner is not expecting a custom written solution in a programming language.  They will be expecting you to take an existing package – spreadsheet, word processor, database etc and tailor it to your solution.  This may involve creating menus, toolbars, macros and some programming. 

The specification states that the projects will seldom involve programming, but for the highest marks, it is anticipated that there will be some.  The only exception to this is projects relating to the Internet.  They will require programming in HTML, JAVA or ASP for example.

Types of Problems

There are many different types of problems that you could choose, but in general, they can be divided in four categories:

Database

This involves accessing a database, and sorting and searching data.  You will be required to print reports and maybe mail merge document.


Examples of database type projects include:

Video Shop – storing data on customers and videos and hiring and reservation of videos

Hotel – booking rooms in a  hotel and calculating the bill

Employment agency – matching vacancies to people

These are only a few examples and are not complete.  You would need to develop the project and complete all the sections listed below to score marks.

You are better of choosing a topic where you will be able to complete all section of the documentation with a database or spreadsheet that is fairly simple than having a very complicated database or spreadsheet and not being able to completely document it.

Keeping a Diary

You need to be keeping a diary as you go through the project – it can be on computer or on paper.  It needs to show what you are doing during the lessons and what problems you encounter.  It also needs to show how you go solved the problems.


Definition, Investigation and Analysis

There is a total of 25 marks available for this section:  5 for the definition of the problem and 20 for the investigation and analysis. 

As this is the opening section of the project, impressions are important. This is the first part of the project the examiner will read, so it is important to get it right.  If it is vague, waffly, indistinct or incorrect it will set up an unfavourable impression in the mind of the examiner that may be difficult to contradict later in the project.  Imagine opening up a project to find it untidy, spelling mistakes, different font types and font sizes all over the page.  What would your initial impression be?   Perhaps it is not fair that impressions contribute to the mark, but they do, and it is in your best interests to follow the guidelines to gain the highest mark you can.

The amount of work involved in this first section is disproportionate to the number of marks available.  However, a lot of the work done here will be re-used in the design and evaluation sections.  From your own point of view, this section is very important – it will allow you to clarify, in your own mind, what the problem is and what you will be developing as the solution.  You will not be able to produce a good project unless what the problem is and what your solution is going to do are clear to you prior to attempting the design.

Overview of Section

The section can be broken down into five stages.

1.      Problem definition:  A new computer system must have a purpose.  There will be a problem, or perhaps several problems, which the system you create will be required to solve.  The problem must first be defined, so that a system can be selected which will solve it.

2.      The gathering and analysis of data about the current system: This involves detailed fact finding and identifying why the problems with the current system have arisen.  It includes confirmation of the problem.

3.      Establishing objectives for the new system:  Once the existing problem has been defined, and data about the current situation has been gathered, the next step is to decide what the new system will be designed to achieve. 

 

4.      Analysing alternative systems:  There will always be several different ways of designing a system to meet the stated objectives.  Several different options need to be thought up, analysed and evaluated. The alternative systems that are analysed may not necessarily be computer systems.

5.      Systems selection: This requires you to select the alternative that seems to best meet the system objectives within given limitations.  The system selection needs to include both hardware and software.

There should be a continuous process of re-examining and re-assessment of each stage of the system selection process, until the preferred system is eventually selected.  In other words, you should be continually asking:

·         Has the problem been properly defined?

·         Has all the relevant data about the current system been gathered and analysed correctly?

·         Have the objectives for the new system been satisfactorily defined?

·         Have all the available system alternatives been identified and properly evaluated?

You should not be asking these questions in isolation, but in conjunction with the end user – the project should be a partnership.

Everything you do must be documented – interviews, questionnaires and subsequent analysis of the data collection and conclusions reached.  If you make mistakes and the re-examining process brings these to light, it is very tempting to change the project to make it seem that you got it right in the first place.  Don’t do this, document the process and show what has changed.  You will not lose marks for getting it wrong, as long as you show why and what you have done to correct it.

Figure 1.1: Diagram showing how re-examination fits into the life cycle.


Background Information

There are many different problems and many situations and circumstances from which you can select your project.  The examiner will not be familiar with all of them.  This introductory section is your opportunity to make the examiner familiar with the particular scenario on which your own project is based.

You should begin with an introduction to the organisation.  Sample question that you might choose to ask in order to complete the section might include:

Sample Questions For Background Information

1.      What is the name of the organisation? 

2.      What does it do? 

3.      Where is it located? 

4.      How many people does it employ? 

5.      How many shops/head offices are there?

6.      What are the names and positions held of people who are going to be involved with the project?

Figure 1.2

The level of detail required is not great, as long as you give enough information for the examiner to understand the outline of the scenario into which your project will fit. 

No project is going to cover all areas of a organisation - the scope would be too vast.  It is therefore important to narrow down the scope of your project to a specific area.  Having set the general background, you can move into the specific area that your project will cover and give more specific details about the particular area you will be working in.

It would be useful if you could show how the area you are working in is related to the whole company.  This could be done through the use of an organisational diagram.

Example of Linking Specific area to General Area

If you are covering stock ordering, how is that specific area linked to with the whole company and the department of purchasing, planning, manufacturing etc.  An organisational diagram will show how the various departments are interrelated.  (See appendices for details of diagrams)

Figure 1.3


Problem Definition

The assumption of the project is that the organisation has a problem to be solved.  It is necessary to know what that problem is in order to solve it.  The problem definition has three components:

1.             Initial statement of the problem

2.             Investigation into the current system to find more information about the problem

3.             Restate the problem based on investigation

Initial Statement of the Problem

An initial statement of the problem is required and needs to be documented.  This is usually in the form of a statement from the organisation – a letter perhaps, or a written statement of the problem.

Example of Initial Statement of Problem

The example given below is for a small library in a village.

We currently have a paper-based system for holding details on who has what book.  We have difficulties finding overdue books and when we do, we have to handwrite a letter to the borrower.  We have attempted to put in a reservation system for books but this had difficulties.

An alternative way of writing this, which would be just as acceptable, is:

The problem is:

  • We have difficulties finding overdue books
  • We have to handwrite letters to borrowers with overdue books
  • We want a reservation system that works
Figure 1.4 Investigation into the current system to find more information about the problem

The problem given to you cannot be believed without confirmatory evidence.   You must find the evidence to confirm the problem that has been given, or to find out what the problem really is.

You will do this by investigating the current system (the current system is the system that is in place at the moment).

To investigate the current system you will need to find out the facts and then record them.  These steps are known as “Fact Finding” and “Fact Recording”.

Fact Finding

Methods of fact finding include questionnaires, interviews, observations of the current system, reading any manuals and personal knowledge of the situation.  You may need to use more than one method in order to find out what you want.

Fact finding is concerned with four main areas:

·         input

·         processing

·         output

·         files

Fact finding is about looking for answers for questions.  The questions you should be trying to answer are based around the four areas above.

Sample questions may include:

a)      What data is collected for processing?

b)      How does this data originate and how is it collected and recorded?

c)      How often is it collected?

d)      How is it processed?

e)      Who processes it?

f)       How often is it processed?

g)      What volumes of data are processed?

h)      Is the data processed in batch mode or on demand?

i)        What information is produced?

j)        Who receives the information?

k)      How is it transmitted/presented?

l)        How often is the information provided?

m)    What is the information used for?

n)      How often is the information used?

o)      How reliable and accurate is the information?

p)      Is the information presented clearly, so that it can be easily understood?

q)      What master files/reference files are kept, and how often are they updated?

r)       Do users have on-line enquiry facilities to access these files?

s)       What does the system cost to operate?

t)        What benefits does the system provide?

These questions are guidelines only.  You do not have to use them, in fact there may be other questions which are more appropriate for your system. 

Figure 1.5

Fact Recording

Once you have found the information, it must be properly recorded so that it can be analysed.  Methods of fact recording include flowcharts, textual descriptions, graphs and charts and relevant system diagrams.

The flowchart and systems diagrams of the exiting system may include:

Context Model:

The context model shows the boundaries of the system.  It shows what is to be included within the system you are investigating and what is outside.  This will assist you in limiting what you do to those sections of the organisation that are relevant.

Data Flow Model:

This shows how data is processed by a system.  The ‘boxes’ refer to the functional processing, data stores and data movement.  Data flow models show how data flows through a sequence of processing steps.  The processing may not necessarily be carried out by a computer, but may, at present, be carried out by people.

Data Model:

This is used in systems that have large collections of related data either on computer or on paper.  (a database).  It is a form of entity relation attribute modelling.   The model shows the links and relationships that exist between the data.  If in use, the data dictionary should also be included.

It is not necessary to use all of the above models, they are examples and you should use the ones that are appropriate to your specific scenario. 

For more information in each model type, symbols and examples, refer to the appendices.

The only one you must use is the data flow model and it is vital that the following are recorded for each type of data used within the current system in the model:

1.      What type of data is it? (string, Boolean, integer, etc)

2.      Where does it come from?  (If there are input documents, these should be included.)

3.      What format is it stored in?  (Data structures currently used - file on disk, on paper in filing cabinet- give filename)

4.      What happens to it?

This is best completed in the form of a table:

  Table of Data Within the System

Type of Data

Comes From

Format

What happens to it

Text

Customer Application Form

Customer name

30 chars

Stored in filing cabinet on Customer application form

Boolean

Customer Application Form

Male/Female

1 char

Stored in filing cabinet on Customer application form

Integer

Customer Application Form

Age of customer

18 - 130

Stored in filing cabinet on Customer application form

  Figure 1.6 Restatement of the Problem

Based on the investigation into the current system you will need to restate the problem.  This may be a simple restatement of the original problem given by the management, it may be a slight alteration of the problem, or in some circumstances, it is a completely different problem.

Whichever one of the three it is, you must show how you have come to your conclusions.  The evidence you give will be based on the investigation into the original system.  This is the difference between the initial statement of the problem and the restatement – the original statement requires no evidence, in the restatement you must show that the evidence used to reach the conclusion.

 


Mark Scheme for Definition

Ensure you check this prior to submission

 (i)  Definition - nature of the problem solved                                                 [5 marks]

A candidate should not expect the examiner to be familiar with the theory and practice in the area of the chosen system.  There should be a brief description of the organisation (e.g. firm or business) involved and the current methods used in the chosen areas that may form the basis of the project.  A clear statement of the origins and form of data should be given. At this stage the exact scope of the project may not be known and it may lead to an interview with the user.

1 - a vague description of the organisation.

2 - some description of both the stages of study and organisation involved.

3 - a good description of either the area or organisation with some description of the

 other.

4 - a clear description with one element missing (e.g., origins of data).

5 - an excellent description with all elements present.

The report should contain:

• a description of the organisation that has the problem and the place of the problem within

it. This does not have to be in any great detail, as a guide, half a side of A4 should be

adequate

• a description of how the chosen problem is dealt with at the moment. This can only be a

sketchy description because, until the analysis section has been completed, it is not

possible to describe the area in any detail.

• a clear description of the data that is used in the area of the problem. The exact date that

will form part of the solution is not yet known because the problem has not yet 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.


Investigation and Analysis

So far you have concentrated on an examination of the existing system.  This section builds on that but is more concerned with the organisation’s requirements – what do they want the new system to do.

From the previous investigation, you know what the problem is, it is now time to begin to develop the solution.  There are two parts to the solution:

  1. The requirements of the solution
  2. The approach you are going to use to develop the solution – what software and hardware

 

It must be possible for the examiner to backtrack from each of the requirements listed, to the conclusions you have drawn from the data collection, back to the data itself. If you cannot justify a requirement with evidence, either remove the requirement, or document the evidence for that requirement.

It may be necessary to redo this section several times, each time revisiting the system to find more evidence.  This is acceptable as long as it is documented.  Do not fall to the temptation of making it seem as though you got it right the first time.  You will get more credit if you show your mistakes and how you have corrected them.

Requirements Specification

The end result of the data collection is a list of requirements for the new system.  This list is what the finished system must be able to do.

The requirements must describe the external behaviour of the system.  It should be written in terms understandable to the end user.  The requirements should not contain too much information but describe what the system should do:

For example, when describing an e-commerce site, the following requirements may apply:

Allow the user to log on using a password

Allow the user the opportunity to change their password

Be able to add and remove items from the shopping basket

Be able to change user details

Figure 1.7

The requirements specification details features of the system, the description does not say how they are to be implemented, or go into any detail as to the processing required.

If given any limitations or constraints, these form part of the requirements – for example, if you are told that it must be a menu driven system, then of the requirements is that it must be a menu driven system.

They may be several superficial requests from the user that are difficult to clarify: be “user friendly”, “easy to navigate”, “warm colours” etc.  It is not useful to list these as part of the requirements specification without adding more detail.

For example, instead of “easy to navigate”, this might be replaced with: no option is more than three mouse clicks away.  “User friendly” could be redefined as being appropriate error messages, readable user guides, tool tips on icons, accessible on line help etc.


For every requirement you state, it must be backed up with evidence of its need.

Sample Layout for Requirements Specification

Requirement:   State requirement

Evidence:         Give interview question and answer used to reach conclusion

                        Graphs of data from questionnaires

                        Evidence from observation

 

If you lay out the analysis in the above format, each requirement must be backed up with evidence. 

Figure 1.8

It has been suggested that you should be looking for approximately 20 requirements.  This may be too many for some candidates.  However, you cannot get away with a major project at A2 with only three or four requirements.  There needs to be a balance which is probably around 10-15 requirements.  It is vital that all the requirements are achievable as they will be used in the evaluation section of the project.   Once they have been listed, there should be agreement of these requirements by the organisation – a signed statement for example. 

Listed below is an outline requirement specification agreement with some examples of requirements.  The text in italics should be replaced with appropriate text.

Requirement Specification Agreement
  1. To be able to find all members with overdue books
  2. To Print a list of overdue members
  3. To order books using e-mail

I name, of organisation, have discussed the requirements and am in agreement that a system that delivers these will fulfil our requirements.

Signed:

Sign Name

Position

    Figure 1.9 Approach to be used

Several alternative designs should be considered and compared.  You should look at all the available systems from the point of view of:

1)      its feasibility - i.e. how will it operate, and how it will succeed in achieving the systems objectives;

2)      its expected costs and benefits.

Any alternative system you look at must be compared to the requirements specification.

The alternative approaches that you look at must be possible solutions.  For example, if you are looking at a solution that requires data handling, it is not appropriate to look at the use of a word processor.  You may be able to match it against the cost, training and other requirements but it is not a valid solution in the first place.  Make sure that all the alternative solutions that you are looking at could be used to solve the problem and deliver the requirements.

There may be constraints put upon the solution by the organisation - the solution must be developed in a specific package.  If this is the case, the alternative approached will be primarily based on differences in data structures. (relational v flat file, file sizes, etc), and these need to be taken into account.

Even if there is a limitation, this does not stop you from discussing alternative solutions.  The discussion can still take place, it is only the conclusion that is affected.

System Justification

A new system should not be recommended unless it can be justified.  The justification for a new system would have to come from:

a)      an evaluation of the costs and benefits of the proposed system; and/or

b)      other performance criteria.

The costs of the proposed system

In making a recommendation for a particular approach, a full study of the economics of the proposed system(s) should be made.  This is not possible for you, but some attempt at financial justification should be made. 

The costs of a new system may include:

a) Equipment costs (capital costs, leasing costs)

b) Installation costs

c) Development costs

d) Personnel costs

e) Operating costs

The benefits of a proposed system

The benefits from a proposed new system must also be evaluated.  As with financial costs, this may be difficult for you to do, but some effort should be made.  Benefits of a proposed approach can include:

  1. savings because the old system will no longer be operated. 
  2. extra savings or revenue benefits because of the improvements or enhancements that the new system should.
  3. possibly, some one off revenues benefits from the sale of equipment which the existing system uses, but which will no longer be required.  Second hand computer equipment does not have a high value but it does have a value.  It is also possible that the new system will use less office space (filing), and so there will be benefits from selling or renting the spare accommodation.

Some benefits might be intangible, or impossible to give a monetary value to.  These might include:

  1. greater customer satisfaction, arising from a more prompt service (e.g. because of a computerised sales and delivery service);
  2. improved staff morale from working with a better system


In general, you need to have addressed most, if not all of the following issues:

·         Expense

·         Time

·         Upgradeability

·         Upsizing

·         Experience

·         Usability

and evaluate them against the requirements specification. 

Once a general analysis of the potential approaches is considered, the evaluation against the requirements specification can be done in the form of a grid:

Grid for Software Selection

 

Software Packages Listed Across the top








Requirements can be listed down the side

 
 


Access

Excel

To printout newspaper deliveries by round (ie print reports)

Yes

No unless merging with MS Word

To allow entry of details for new customers.

Yes with forms.

Possible but cannot be made end-user friendly

  Figure 1.10

A final solution must be selected and reasons given for the choice.

Once a solution has been selected, it is possible to specify the hardware and software required.  This should not be a list, but a justified selection.  The hardware and software should be all the items required for a full installation of the solution.  It may be that you will not be doing a full installation - for example, a network installation on 20 machines in the office where there are currently no computers requires twenty machines, cabling, server, etc. This needs to be specified even though you will not be implementing all of the end product.

The software list must include the operating system, if a modem is to be used the additional software required (such as e-mail package, protocol etc) must be stated.  If a network is being used as part of the end product the software for the network needs to be given.

The hardware list must be fairly detailed.  Make sure that you have covered the input, processing and output requirements.  For input, you may need items such as keyboard, mouse, but what about scanner, optical mark reader or if receiving information via the network/internet you will need a modem/network card and appropriate software.  Do not forget to specify what sort of disk for input – floppy disk, zip disk, CD Rom and what monitor.

Output requirements may cover many of the same items as input –what disks are required – floppy disks, CD burner, zip disks, internet connection, network connection, also it may include printer – what type.

Processing requirements can include what is inside the machine – how much RAM, what hard disk drive, what processor?

More by this Author


Comments

No comments yet.

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working