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.
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.
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.
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…