1. Data Flow Diagrams Continued

2. Checking Your Diagram Label flows uniquely. Put boundaries onto each diagram. Data flows are data only – not orders. Each process should have a unique reference number. Each datastore should have a unique number and name. All diagrams should be labelled. Check levelling on diagrams. A data flow should have a process as a source or sink.

3. What to leave out Enquiry processes –These processes neither add nor take away data. They do not show the flow of data through the system. They are not included in a data flow diagram. Process triggers –Show only data flow, not control flow

4. 8 Physical SystemLogical System CPDFD Current Physical How the existing system works RPDFD Required Physical How the new system is to be implemented RLDLD Required Logical What the new system has to do CLDFD Current Logical What the existing system does Current System Required System Stages of DFDs

5. Physical DFDs Symbols on the diagram represent physical objects the user can recognise. Data flows or stores. –Bits of paper, telephone call, ledger book, filing cabinet. Material flows. –Physical stock changing hands carries implicit data with it. –It may be easier for a user to understand the physical flow.

6. Physical DFDs Show how the current system is implemented. –Who does a particular job. –Where it is done. –When it is done. –How. A flow is communicated – e.g. By telephone. Data is stored (box, list, etc). Sequence of data stored. Nature of the storing document.

7. CPDFD Describes how the system works now. Includes manual data stores. –E.g. The price list on the wall. Can include material flows. –E.g. The stock going out of Joe’s Yard.

8. DFD Logicalisation Remove physical aspects. –Remove references to ‘who’, ‘when’, ‘where’, ‘how’ a job is done or data is stored. –Remove material flows, retaining implicit data flow. –Remove current processes that are merely mechanisms to support the current physical realisation of the system.

9. DFD Logicalisation Improve logic of stored data. –If several data stores contain the same data, combine / rearrange them. –If a single data store contains everything, split it into logical entities. –Remove transient data stores (i.E. Datastores that are used temporarily during the running of the system).

10. CLDFD in summary The physical aspects of the system are removed. The data flows and stores are abstracted to give logical data flow. The data stores may be split, merged or renamed.

11. Presentation of Current System The current physical and logical systems are presented to the user. The user describes further requirements. The user gives a list of problems with the current system. The designer lists the future requirements and current problems.

12. Metamorphosis The designer designs a solution to what has to be done. Ideally, this is independent of how it is to be done. –The only point that needs to be ascertained here is that the proposed solution is feasible. The designer formulates a required logical Data flow diagram.

13. RLDFD Describes what the new system has to do. –includes all that is in the CLDFD. –includes new requirements for the new system. –solves any current problems. This is a Logical diagram. –There are no manual data stores. –There are no physical flows.

14. RPDFD Describes how the new system will work. Which parts are automated or manual. What physical devices will be used. What input and output forms used. Not all stages may be needed or produced. Required physical data flow. –Which parts remain manual. –Which physical devices will be used. –Input / output forms used.

15. Current Physical DFD