Data Flow Diagrams

What a manager wants to know about a system

When analysing an existing system the main questions a manager wants to answer are these: Is the system operationally efficient? Does it deliver outputs on time? Are there too many sequential tasks? Is there any unnecessary duplication of effort? Can tasks be left undone? Is the system effective? Was it designed to do what I need to do my job? Produce information as well as documents Produce information on demand Enhance decision making Automate decision making Enable easy downloading of data into models? Where are the scope and boundaries of the system? Does it require/follow a particular form of organisation? Could/should it be integrated with other systems? Internal External Is the system technically efficient? Have recent developments in IT made the system obsolete? Suitability for telecommunications Multiplatform capability Adoption of standards Suitability for direct user access Data currency Data redundancy Is the system cost efficient? Could there be labour/capital substitution? What is the best way to evaluate the investment? Potential for cost reduction or for revenue improvement? Cost effective/cost benefit? When redesigning a system, a manager thinks largely about how to

Improve the cost, technical and operational efficiency of the system Improve management decision making capability Improve or transform business processes Help collaborate with other businesses Improve Competitivity

Purpose of a Data Flow Diagram (DFD)

A Dataflow Diagram (DFD) is a diagrammatic representation of the information flows within a system showing how information enters and leaves the system what changes the information where information is stored The purpose of a DFD is to show the scope and boundaries of a system to show that the whole system has been considered may be used as a communications tool between a systems analyst and any person who plays a part in the system to act as the starting point for redesigning a system

Stages of creating a DFD

The normal stages are 1. Model the current system as it is presently implemented. It is rare that a system is designed to do something entirely new. Normally the intention is to make an existing system efficient by automating it to streamline more than one system by integrating them to replace a sequence of tasks with a new process The DFD drawn at the end of this stage is called the Current Physical System. The main characteristics of a Physical DFD are that a user will recognise how a system currently operates, warts and all. It should not attempt to improve the system, although it may document problems. 2. The essential activities of the system are extracted. What is now left is just the data, information stores and starts and destinations. What is removed is physical things like any IT used, the media on which the data is recorded and stored, and

who does what. The idea is to focus attention on what is being done to the data and free the mind from such considerations as whether the data is paper-based or on an electronic file; whether the data is stored in a filing cabinet or on a disk; whether data is transmitted electronically or by post, and so on. The DFD remaining is called the Current Logical System. 3. The current logical system is examined alongside a list of prioritised requirements and redesigned to satisfy those requirements subject to any resource constraints told to the designer by the person commissioning the system. The new DFD is called the Required Logical System. To move to a logical DFD you do things like: Get rid of references to physical implementation Remove references to 'Who', 'When', 'Where', and 'How' a job is done or Data is stored Rename Data Stores so that the name reflects the content Remove processes that reflect how a person does their job Make minor improvements in the logic of stored data Combine references to data stores using replicated data Remove data stores which are only used because of inefficiencies in the present system 4. Eventually the new system takes physical shape according to factors like the existing IT platform it will have to operate on, the data model adopted by the organisation and organisational procedures favoured within the corporate culture. On this module it is unlikely that you will be required to go as far as drawing a full required physical DFD, although you should develop the ability to deduce the main physical implications of implementing a systems you design. This is not a systems analysis module. The purpose of learning about DFDs is that most managers will at some time be expected to participate in a systems analysis and design exercise. Some will initiate such exercises. Either way, a manager needs tools to enable the existing system to be analysed, and a potential new system to be visually sketched. The DFD performs these functions. It is not the only tool used, and it has some serious limitations. Nevertheless, it is the most important one, and probably the first one to be used.

Main Benefits of the DFD.

A DFD Provides easy presentation and communication between technical and non technical staff. It is Easy to understand No technical knowledge is assumed Easy to draw and amend There are only four symbols Easy to expand to different levels Useful to different type of staff Clarifies the system. It shows at a glance the Scope and Boundaries Interface with other systems

Limitations of DFDs
Clearly DFDs cannot tell the WHOLE story. Indeed, they only reveal a part of the requirements listed above. The most important things they do not reveal are The sequence in which processes occur The time intervals at which processes occur Entity Life History modelling (ELH) is needed The structure of processes and data stores Logical Data Structure modelling (LDS) is needed How often a process is repeated Also, analysis of a DFD does not reveal important business aspects: Whether or not the system is a business enabler for competitive advantage The technical aspects IT Platform Data Structures Costs (except by implication)

Components of a DFD
There are four basic elements. The notation used here is that employed by the Structured System And Design Method (SSADM). Some textbooks use a different notation, but are easily comparable with this one. External entity This is whatever or whoever donates data/information to the system or receives data/information from it. (From now on, for simplicity, the term data will be used for either data or information). An external entity therefore resides outside the boundaries of the system, meaning that the system has no formal control over data issued by one, or over data once it has been received by one.

Process A process transforms or manipulates data within a system. Each process box contains the name and very brief description of the process ( like 'Do this', 'Do that'), a numerical identifier, and a location (e.g. 'Manager', 'Accountant', 'Production Department'). In order to show a process in more detail we need a different modelling technique. There are three main ones, which are Decision Tables, Decision Trees and Pseudocode (Structured English). Typical processes are recording data, classifying and coding data, checking, sorting documents into some order, collating documents, merging one batch of documents with another, matching one document with another, calculating, creating a new document, and so on).

Data Store A data store is where data is held for a time within the system, probably awaiting the arrival of more data before it can be processed, or awaiting being used to produce a report, or before being transmitted to some other system). In a Current Physical DFD, data stores represent real-world stores such as computer files, card indexes, ledgers and so on. The store symbol is deliberately simple. There should be no intention to show 'How' the data is structured. One Data Store may eventually yield a database of several files. During system design, the techniques of Logical Data Structuring (LDS) and Normalisation may be employed to do this.

Data Flow A data flow represents a set of data being transmitted between objects on the DFD. It is important to note the following: Data ALWAYS flows to or from a process. The other end may be an external entity, a data store or another process. This means data CANNOT flow from Data Store to another. This is obvious when you think about it - a process needs to be performed to make the data flow. A data flow is just a line with an arrow showing the direction of flow and a name. Data flows to and from a store can be shown as two way.

Construction of the DFD

Consider the following example:

This is called a Context Diagram (or level 0 DFD). It is often used as a starting point, just showing the whole system as a "Black Box" - a single named process into which and from which the data flows are shown associated with their external entities. The next stage is to break this down into a number of basic processes like this:

This is called a level 1 DFD. Typically a level 1 DFD shows up to 6 processes, although there is no formal limit. Remember, the aim is clarity of presentation. When the diagram is not clear, stop. Also in the interests of clarity, note that the same data store or an external entity may be shown more than once on a DFD. This is signalled by the additional bar on the symbol. This is feasible because the DFD does not attempt to show time dependency of data flows. (There is a technique to do this called the Entity Life History). Likewise, the numbers are used for identification only. Note that the same location may be shown on successive processes (e.g. Order Clerk in the case of processes 1 and 3). This may be the case even where both processes are carried out at the same time. The reason for breaking them down is to show that a decision is taken and the second process is dependent on that. In this case, for example, not ALL orders result in activation of the reorder process - only those where the order requires new stock to be ordered. On a required logical DFD, the location box is often left empty. Any of these processes can be decomposed to a higher level, and then higher again. For example, box 1 of the level one dfd for order processing dfd we have just introduced, might be decomposed like this:-

At any level, the data flows and data stores must balance (you cannot introduce new flows into or out of the process). Also, it is easy to tell which process has been decomposed by the numbering system. E.g. Sub processes of Process 2 are 2.1, 2.2, and so on. At this level, we see that the DFD is incomplete, it does not tell the whole story. For example, the customer does not seem to be notified of the acceptance of the order. The DFD does not tell us what happens if a credit check fails. The stock file does not seem to be updated at all in the system. It is commonsense that if data is shown being read from a data store but not written to it, then either the system is incomplete, or that the process of updating the file lies outside the boundaries of the system (which sometimes is most unlikely). The process of decomposition may be represented like this:

Here, process number 3 at level one is decomposed to two processes 3.1 and 3.2 at level 2.

Checking a DFD
There are some basic checks to try to make sure that a DFD is consistent and complete. Does each process receive all the data it requires? Does any data store have data flowing out but not in? Or vice versa? Is this reasonable? Are decomposed DFDs consistent with the lower level ones from which they were derived? Do ALL the external entities appear on the context diagram? Are all the data flows labelled? Are any processes named within data flows?

Analysing a system using a DFD - A worked example

Consider this narrative of this system for administering a hypothetical estate agency. "The Estate Agency is run by two senior partners, one junior partner and a receptionist. Both senior partners are well versed in all aspects of the business, but only one is engaged in valuing properties, while the other handles the clients' everyday business. The receptionist will shortly be leaving to take up a better paid post elsewhere. The Agency has tended to deal predominantly with domestic property transactions with a few commercial properties and a little domestic property management for absentee owners. An increasing and significant volume of business is coming from a number of speculators trading in investment properties. Enquiries are received from prospective vendors by telephone or personal call at the High Street office. Details are recorded by the receptionist on a standard form which is then placed in the In Tray of the valuer, a senior partner of the agency. The receptionist agrees a time for the property to be valued after consulting the diary of the valuer. The appointment is then written in the diary. The valuer duly calls at the time agreed, taking the form as the basis of the property valuation. She writes her valuation on the form, and verbally informs the prospective purchaser if asked. On returning to the office she gives the form to the receptionist, who informs the prospect in writing in a standard letter, enclosing the terms of the agency for selling the property. She then places the form in a pending tray awaiting action from the prospective vendor. On receiving written instructions from the owner to sell the property, the receptionist transfers the form to a tray awaiting the attention of another senior partner. This partner usually becomes the regular account manager for each vendor.

The partner periodically examines the tray and extracts the forms relating to the new properties for sale. He draws upon the details on the form together with his local knowledge in order to create a detailed description of the property in a standard form. As the agency has grown quite rapidly and expanded its vendor property catchment area, more and more details about the locality have been recorded in a loosely structured file. The detailed description is typed; (usually onto less than two sides of A4 paper), duplicated; a coloured photograph is attached; and copies are placed in a rack until the property is sold. One copy is placed in the In-Tray of the valuer, who is also responsible for advertising. Once a week she produces an abstract of the standard details of all properties which the agency has been asked to sell during the previous week. These abstracts form the basis of advertisements which are placed in local papers and a regional property guide subscribed to by a number of small independent estate agencies. She decides on the advertising strategy for each property after consultation with the Account Manager and agreement with the vendor. (Advertising is an additional selling cost). After the Standard Details have been prepared, the junior partner compares them with the Buyer Requirements file. If a match is found, a copy of the Standard Details is sent to that prospective buyer. In the great majority of cases, the criteria for a match are some combination or permutation of locality, type of property, price range, number of bedrooms and age. Very occasionally, an overriding preference is expressed (such as the need for a fitted kitchen, a second bathroom, a ground floor bedroom or a granny annexe)." First, notice how difficult it is to grasp the essentials of the system from the narrative as it stands. A DFD makes this task so much easier, thus:

The DFD highlights the following problems: 1. Communication is sequential, creating a serious time lag in processing. The symptoms are that forms are left in trays but the trays are not automatically checked at regular intervals. There are no automatic "triggers" between any of the processes. When people are busy, processes may get overlooked. 2. Communications are poor, such as the diary system, where there is no feedback to those affected, or controls to see if they have executed what they are supposed to. 3. There is too much form filling. There is a lot of scope for loss, error and confusion. 4. This type of document centred system makes a very poor foundation for producing management information. None is produced automatically, and with the documents at different stages of processing and in different geographic locations it would be almost impossible to derive reports without wasteful transcription and duplication of effort. The type of information required to control the business and to measure performance includes

number of enquiries turned into instructions to sell number of potential buyers attracted % of potential buyers turned into actual buyers number of recommendations by satisfied customers average time to sell a property effectiveness of advertising strategy number of customer complaints 5. The receptionist's function is a bottleneck. Actions could be taken to relieve this, such as letting the valuer inform the seller directly about recommended price decisions. 6. The DFD does not tell the whole story about the matching process, such as how often it is done. To get the complete picture about the system, further work is necessary. The business has to be looked at within the context of its mission, its industry, its market and competition. The organisational and management structures also need to be analysed. Something like this might emerge: "This system has been in operation for the past five years, and until recently has worked very well. However, cracks are beginning to appear in it. They have not produced disastrous consequences - yet. Some of the symptoms include: Difficulties in making valuation appointments outside of normal working hours. Poor communications between Reception and the Valuer leading to Diary clashes. Lengthening periods between the filing of the valuation and the production of the Standard Details. Slow communication of matches between the agency and prospective buyers. Missed matches - resulting in embarrassing telephone calls from prospective buyers. Wrong matches - with similar results. To make things worse, a rival Estate Agent from the next town has announced the intention of opening a branch office in the next block. At first, the partners were not worried. They know that they have strengths and local knowledge which a business rival will take time to acquire. For example, the Account Manager feels they have a better than average success rate in achieving the asking price in the middle price range of properties. The partner in charge of advertising is convinced that they

are much more successful in the exclusive localities than in the estates favoured by first time buyers. The Account Manager advocates a strategy of countering the competition by specialising in the areas of the market in which they are most successful - but admits he does not know if success in selling in a sector is correlated with profitability. The valuer feels that a better strategy would be to diversify into commercial properties and rented accommodation, which she says is more profitable". Other problems emerging: 1. The business processes are broken into tasks depending upon the interests of the partners, not the customers (eg advertising, valuation). Each partner could handle all aspects of an account, thereby giving a more personal service, and facilitating the handling of customer progress enquiries. 2. The junior partner seems to be underworked, according to the DFD and yet he is apparently making serious errors in the matching process, a core and key process. Maybe he is bored, and needs better career development, or he too might leave. 3. The receptionist wanting to leave is worrying. Is it really for better pay, or is she just feeling over-worked and under-rated? 4. Lack of hard information can mean different people get a totally different feel for what is going right and what is not. For example, whteher the domestic proprty market is more profitable than the commercial one. 5. There is little or no exploitation of information technology. This probably, but not necessarily, means that the system is costly to operate. However, the inefficiencies in the system almost certainly mean it is directly costly, and also indirectly costly, in that it may be inhibitting the generation and execution of business. What we can learn from this case for the general situation includes 1. The DFD is good at presenting a system in an easily digestible way. 2. A systems analysis requires observation and interviews and business analysis as well as a DFD. The aim is to give a amanger what s/he wants to know about a system.