A blog that's neither blue nor square

unit2

a clear specification for the spreadsheet clearly identifying what’s required with a technical justification for the ways you’ve opted to approach this. This should link to objectives and success criteria – this is Part 1 – Specification

a working spreadsheet which produces all the outputs required. You might want to consider having this saved as a template (to allow reusability) and having a version saved as an unused sheet

screenshots (or PDF versions) of example outputs would be helpful – possibly annotated to show how you’ve covered the requirements of the specification

designs for each worksheet and user form used. These need to cover all the markgrid sections

probably some kind of discussion of how you’ve covered elements such as “user efficiency”, “accessibility”, “usability” and possibly aspects such as validation – these might not be immediately apparent from the spreadsheet itself. This will fit in with the technical documentation section of Part 7 – Documentation

testing evidence (see below)

If you can try to produce as much of this evidence as possible at this stage it will save an awful lot of time and effort in the future. Promise. In particular you might be able to cover a lot of the Documentation section at this point – the technical element of that anyway.

test prototypes – i.e. test your designs and test some rough versions to show that you’ve got feedback on what works and what doesn’t work. Screenshots would be helpful here – you need evidence that you got feedback and made changes as a result of that feedback

The element testing should test each individual possible input and process. So, for example, if I press a button then what should happen? You want to be clear about exactly what you’re testing and what should happen as a result. I’ll put more detail about this on the web soon.

Hopefully your detailed specification stuff is now done. Certainly you should have dealt with inputs, processes and outputs (and processes should probably include storage requirements as well). There may be odds and ends such as security that you want to add to that.

The job for today is probably to complete an Information Flow Diagram and then move on to objectives and, probably, success criteria.

The IFD certainly needs to make sure it includes all the inputs and outputs from the specification. It’d be a good idea to double check these against the exam board scenario stuff afterwards as well.

We spent some time noting that the consultant (Tracy) phones up the Admin Assistant (Derek). No data gets transferred automatically within the computer system – it’s done by phone. So:

the spreadsheet produces a list of all the products ordered (e.g. 4 bottles of vanishing cream)

the consultant rings up the admin assistant and dictates the list of products ordered over the phone

the admin assistant enters this into the database

the database produces a dispatch note

the order is picked and sent back with the dispatch note

Make sure this is in your IFD clearly – and then reflected in the objectives.

The database also needs to be able to:

store details of orders (but not customers)

have new product details entered into it

have new consultant details added to it (and, therefore, store consultant details)

produce dispatch notes

produce low stock reports

produce certificates

These need to be clear – and are obvious objectives.

Objectives:

The more detailed you make these the better. Probably. I don’t know how many you should end up with – I would imagine at least 15, quite possibly 20 or more. That’s OK – the more detail you have here the more obvious it is that you’ve broken the job down into sections.

We might end up adding some objectives in – things related to security or accessibility for example.

Success Criteria:

Each objective needs at least one success criteria. This should be a “can do” statement that I should be able to look at and say “yes, my system can do this”. If you have detailed objectives then you may find that you have only one success criteria per objective. If your objectives are a bit vaguer you may have multiple success criteria for some of them. That’s OK

Expect to come back to the success criteria at some point.

Next jobs:

Finish off all the specification stuff, including objectives and success criteria. I could probably use seeing information flow diagrams and perhaps objectives and success criteria.

At some point we need to come back to the Technical Justification section as well.

The aim is that by next Tuesday we can get on to actually designing the darned system…

We started by fixing the url problem the exam board had with their scenario web pages and quickly demonstrating what css is. That might come in handy for the e-portfolio stuff briefly.

Outputs:

Then we talked about the outputs that Dawn’s system needs. We decided that Tracy the Consultant would produce some outputs, probably at the party (hosted, if you remember, by Gwen) and using the Spreadsheet system. Derek the Admin assistant would also produce some outputs using the Database.

We talked briefly about how there was a link between Tracy and Derek – Tracy phoning in the orders (using the list) and Derek sending the completed orders back to Tracy (with a Dispatch Note in the package). We talked about what sorts of information would need to be on each of the outputs as well.

I think we decided that there were at least 6 outputs that were needed. I’m not going to list them here as there are marks for doing that sort of thing…

Advantages of ICT solutions:

I showed you some examples of invoices and receipts at this point. Some were nice, others were hand written – these will be linked on the internets once I get a chance. We did talk about some of the advantages of using an ICT solution for the sales receipt – points like readability, speed, reliability of calculations, ability to change prices quickly, consistency of style and branding for example. Some of these were good reasons to use a spreadsheet – these will be handy in the Technical Justification section of the specification.

Inputs:

Then we talked about the inputs needed into the system. Tracy will need to input some stuff. She’d certainly need to input the details of an individual order (say when Daisy orders the products she wants) and probably input a few other details as well – perhaps some personal details and maybe the details of the host etc…

Derek would then take Tracy’s phone call and she’ll be dictating the party order over the phone to him. He’ll need to input that in some way into the Database. He also needs to be able to input things like new products and new consultants details into the database.

Data flows:

I think I probably mentioned the data flows between the two systems again. It would be a really, really good idea to come up with an Information Flow Diagram at some point fairly soon. This is a good summary for the specification section and will help you envisage the system. I even showed you how to do this more easily using a Drawing Canvas in Word (and, while I think about it, it’s probably a good idea to use a fairly small font size for this btw…).

We explored the exam board scenario for Natural Beauty with Dawn at Home – finding out who Dawn was, what she did, where she operated and so on. The scenario contains contact details and a website address that doesn’t exist (yet…) as well as a nice logo. We sort of decided what the company was called.

We thought about things like Dawn’s ICT skills and experience and decided that we probably don’t know very much about what skills and experience she has in this area. Although I’m not sure she’s ever going to touch a computer in the scenario you’ve been given.

We then explored the whole information flow, particularly for the Sales section. This is quite complex and needs some very specific outputs. It looks like the consultants will do most of the data work on the spreadsheet. We decided there are questions we don’t know the answers to:

what experience do consultants have with computers – what are their skill levels?

what ICT equipment will the consultants have? What OS? What spreadsheet software?

what format do the outputs need to be in?

how many items can people order at a party?

how many of each item can they order at a party?

These last two questions might be important when you’re setting validation rules at some later date perhaps?

We sort of hinted at the need for a GUI which is going to be easy to use, particularly as can’t assume that any of the consultants have very much geek when it comes to ICT use.

We also partly explored the Database aspect of this, but left some of that for a later date as it got quite complex with a certificate and stuff. We do know, though, that Dawn has an admin assistant to do some of the jobs but nothing about that persons ICT skills.

Jobs to do:

Start the specification – the very general bit and then thinking about the more detailed bit. These are on the internets.