That Blue Square Thing

WJEC Applied ICT A Level Unit 2 - eSkills

Note: this page applies to the legacy WJEC Applied ICT A level specification which has now been withdrawn (last resit opportunity in 2019). A new syllabus is available to schools in Wales that seems similar.
I no longer teach A Level Applied ICT but I'll leave these pages up as an archive which might still be helpful for someone, somewhere.

Part 1 - Specification

You need to start by showing that you understand exactly what you need to do to solve the ICT problems of the client.

Note that although this section is only worth 5 marks it's incredibly important as it underpins the whole of the testing and review sections. Without a proper specification you really can't access the higher marks in those sections.

It's also crucial because it shows that you understand what you have to do - and without that you're not going to solve the problems very effectively...

Describing the Organisation

Briefly summarise what the organisation does, who does what and how they do it at present.

You'll find this information embedded throughout the exam board scenario documentation. You may find you need to read it several times to get a handle on exactly who does what...


Now summarise exactly what's required. You should probably think about what you need to produce and what each product need to do exactly as well as who it need to do it for.

Write this up first and then think in more detail about questions such as:

What data need to be inputted? Who's going to do the inputting? Where, when and how? Do we need to check data input for errors? Are we going to preload the systems with any sets of data? Does the user need to be able to change these or add to them at all?

What data about transactions needs to be stored? For how long? Can we simplify storage at all? Do our systems need to be reusable or do we need to keep on adding to them?

What outputs need to be produced? Who are they for? How many copies do we need? What output will go to the screen?

Do we know anything about the users? Can we infer anything at all about the users and their technical competence and abilities? Does the system need to be "foolproof" or are we building it for an expert?

Do the systems need to be secure at all? Perhaps to comply with the data protection act? If so, who needs to be able to access them?

An Information flow diagram might be really useful here to help you get a handle on what the project needs are.

Write this up, using whatever method you prefer to split any tasks up. Your aim here is to clearly summarise the purpose of the project first of all so you may not include all of the detail you've thought about. That's OK, it'll come in handy in the next section....

Technical Justification

Once you have a clear summary of the purpose of the project, you need to identify the methods you'll use to implement the project and describe them. And you need to justify those methods technically - i.e. say why the approach you're going to take is a good one.

It's OK if this section is a bit vague for now - you can come back to it and beef it up as you get a better handle on exactly what you're producing and how you might go about producing it. Even if you have a pretty good idea to start with, the chances are that you're going to want to come back to this particular section at some point and add a bit more detail.

Objectives and Success Criteria

You need to come up with a list of clear objectives. These will summarise exactly what your ICT solutions need to do if the project is going to be a success. This is where you'll use the detail you thought about in the previous section!

Each objective needs to have a success criteria associated with it. This is what you test to see if the project is successful or not. Your tests that you define in the Testing section (part 6) will depend on these. And your Review (part 8) will be largely based on how well you met the objectives. So it needs to be done well...

I would suggest a tabular sort of approach might work quite nicely here...

Obj # Objective Success Criteria
1 The operator has to be able to print a copy of the invoice for the customer The spreadsheet system will print a single copy of the invoice
2 The invoice must look professional The invoice will include the customers details and the details of their holiday
The invoice will fit on one side of A4
The invoice will have been tested to check that it looks professional
3 The system must be secure because customers details are held within it and the organisation must comply with the data protection act A password will be placed on the spreadsheet to restrict access
4 The system will be simple to use ...

Numbering the objectives will make your life a lot easier when you come to test and review them. Note that it's perfectly OK to have multiple success criteria for some of your objectives if you need to.

I would expect you to want to keep coming back to the objectives and success criteria and tweaking them a little if necessary. That's OK as well.

The Markgrid

Markgrid for Unit 2 Part 1

PDF iconSpecification markgrid - PDF version of markgrid

Note: this markscheme is a copy of one made available freely By WJEC as part of their CPD programme. It is copyright WJEC (probably) and reproduced here simply to make access easier for students. No attempt to claim copyright is being made, although I could have copied the text into my own interpretation...