CSE1IS Information Systems
Week 5
Data Analysis and Representation

Reference: Chapter 4 & Toolkit part 5 of S.C.&R.

This lecture is concerned with displaying the data requirements as determined through the fact-finding stage into a format that the user can understand.

Introduction:

• Requirements engineering or systems analysis is normally seen as the process by which software requirements are identified and specified and can be described as a ’process of discovery, refinement, modelling and specification.’
• Both the user and the analyst take an active role in this process.
• Systems analysis is critical to the success of a systems implementation and it has long been accepted that many system faults can be traced back to inaccurate or ambiguous specifications. 
• The user may only bring a vague or unclear notion of the system needs and the challenge is take the imprecise and incomplete ideas of the user group and refine them through a process of debate and elicitation into a precise and formal specification.
• To do this we must firstly to attempt to gather and understand the system requirements, and then be able to communicate our understanding to both the user group and the system builder.
• System modelling is a useful tool in this process.
  We can create models to express our understanding of a current system problem, to identify areas for change or to describe the final product to be built.
• These may be developed from differing perspectives and can express both functional and behavioural aspects of a system.
• They allow  the  partitioning of complex system problems into smaller and more manageable units.
• They also can be used as a basis for communication and validation with the users.
• Many of these modelling techniques use a semi-formal diagramming technique supported by explanatory text.
• One common approach is the use of Data Flow Diagrams and a modelling approach use this technique can be referred to as data flow analysis.
• A second useful representation of the processes within an organisation are Functional Decomposition Diagrams.
• An increasingly common approach is Unified Modelling Language (UML)

Functional Decomposition Diagrams (FDD):

• A top-down representation of the functions and processes that occur within a project.
• Similar to an Organisation Chart in structure
• Shows the hierarchy of the processes
• These processes tend to become program modules when developing the system
• Fig 3-9 of S.C.&R. is a good example for a library system:
  

Data Flow Analysis

• Data flow analysis is a technique for documenting your understanding of a current system problem and can be used to identify areas of change .
• Data flow analysis allows you to communicate/confirm your understanding
  • with other systems professionals.
  • with users/management.
• Data flow analysis allows you to develop a model of a system, emphasizing that flow and processing of data within a system
• In data flow analysis the focus is on the flow of data , where it is processed (transformed) and where it is at rest (i.e. stored)
• The main diagramming tool used is the data flow diagram.

Data Flow Diagrams (DFD):

• The model is a set of data flow diagrams supported by a data dictionary.
• The data dictionary documents and explains the detail in the data flow diagrams.
• As your understanding of the system increases the more detailed the diagrams become.
• Two sets of the documentation may be drawn up:
  1. the current system
  2. the proposed system

A graphical representation of the flow of data.
Fig 4-16 is a DFD (Level-0) of an ordering system similar to Housewares Warehouse:

Components of DFDs:

(i)  External Entity (rectangle):

In complicated diagrams it may be necessary to duplicate an entity
- indicate a duplicated entity with a diagonal line through the bottom-right corner

(ii) Process (Circle)

   
Processes are uniquely numbered sequentially.

(iii) Data flows (arrows)

The data that flows between entities and processes
eg.     
Conventions:

• data only, not physical items
• names represent data and what we know about it

(iv) Data Store (parallel lines)

• could be temporary or permanent
• correspond to filing cabinet, cardbox, computer file
• eg.   Customers Store, Accounts Receivable (unpaid orders store)
  
• data Stores are uniquely numbered sequentially, usually with prefix 'D'.

DFDs exist in a hierarchy.

• The level of detail and understanding increases as you down this list.
• The focus in this subject will be on only the context and level 0 diagrams.

The Context Diagram:

Purpose:

• To document the system inputs and system outputs.
• To document where these inputs come from
  (i.e. the source or origin) and where the outputs go to
  (i.e. their destination or sink)
• To identify and document the boundary of the system
• Context Diagram only shows external entities and their associated inputs/outputs
• The entire system is shown as a single process (shaped as a circle or circular rectangle) that transforms the inputs into the outputs
• Data stores are internal to system process so they never appear in the context diagram.
• If stored data is external to the system then it would be documented as an external entity (i.e. as another information system).
• Fig 4-13 shows a sample context diagram for the order system:

Drawing Hints and Technical Errors

• Label all data flows and external entities.
• Avoid the use of double headed arrows. Clearly identify the direction of each data flow i.e. is it an input or is it an output?
• Do not have data flowing directly from one external entity to another. This indicates that the data flow is not part of the system under consideration (i.e. is not processed by the system).

Level-0 DFD:

The purpose of the level 0 diagram is to document the major system processes . It may also introduce the major system data stores provided they are shared between two or more of the processes.

• Main task is to specify the main processes - usually about 3-5.
• The level 0 diagram must be balanced with the context diagram.
  • This means that all inputs, outputs and external entities that appear in the context diagram must appear in the level 0 diagram.
  • They also must be labelled using the same label.
  • i.e. drawing a lasso around the internal processes, with the external entities on the outside, should redefine the Context Diagram.
• Each different data flow, external entity, process and data store should have a unique name.
• In other words if two components of a DFD (data flow diagram) have the same name then we are assuming that they are the same thing.
• Sometimes a data store and an external entity might have the same name.
  • They can distinguished from each other because one is external to the system and the other represents stored data.
• Fig 4-16 is an example of the Level-0 diagram for the order system.

It is important to realise several things about data analysis

• There is no one correct set of DFDs for a system problem.
  • Several models could be developed for the one problem depending on the way you view the problem.
  • One may contain more information than another, or it may better express how the system works or better highlight the interface between the manual and computerised components of the system than the others.
  • However it doesn't mean that it is the 'correct'  view and that all others are wrong. It might simply be a better view of the system problem.
• On the other hand the development of a set of data flow diagrams is a semi-formal process.
  • This means that there is set of rules and a syntax to the modelling process.
  • Thus a data flow diagram may contain technical errors.
  • For example a level 0 data flow diagram that is not balanced with the corresponding context diagram is technically incorrect.
  • You should realize that DFDs that have technical errors are wrong.
• Finally it is possible to develop a set of technically correct data flow diagrams that make no sense. This is similar  to something being logically incorrect.

Lower-Level Diagrams:

• Each process specified in the Level-0 diagram may contain a number of subprocesses
• Similar to how the Level-0 shows subprocesses of the Context diagram
• To help identify processes:
  • Data entry screens usually require:
    • one process to to create the screen (usually a functional primitive process - see below)
    • another process to save the data - often requiring multiple steps = multiple processes
  • Reports often only require one process to collate and generate
• External entities are usually left out of lower level diagrams
• Each diagram should be balanced with its parent process
  • i.e., all of the input/output data flows of the lower-level should match the same data flows in and out of the process in the parent level diagram
• Fig 4-17 and Fig 4-18 (below) show the Level-1 diagram for the '1.Fill Order' process of the Order System's Level-0 diagram (Fig 4-16):
  
   
• Similar Level-1 diagrams can be created for the '2.Create Invoice' and '3.Apply Payment' processes on the Level-0 diagram
• number the sub-process to show parent process
  eg.  For process 1 of Level-0 diagram:
  • 1.3  for first expansion (Level-1 diagram)
  • 1.3.2 for second expansion (of process 1.3 in Level-2 diagram)

Functional Primitive:

• Bottom level processes are called FUNCTIONAL PRIMITIVES which cannot be expanded anymore.
  eg. � verify order form �
• Guidelines for defining a functional primitive:
  • name consists of strong action verb and a single concrete object.
  • allocated work can be described in a page or less
  • generally only performs a single task
• For each functional primitive we have a process description (mini spec)
• These processes may include logic or "decision making":
  • eg.: the order is verified according to 3 criteria:
       1. credit status of customer
       2. credit waiver from general manager
       3. product is in stock
  • credit acceptance/rejection decision is made according to the values of these criteria.
• Structured English, Decision Tables and Decision Trees are common forms for specifying such conditions and actions.
• Example of simple Decision Table for Verifying and Order (S.C.&A. Fig4-38):
  
   
• Fig4-39 and Fig4-40 are also good examples of Decision Tables.

Hierarchy for DFD:

1. Context Diagram
2. Level-0 Diagram
3. other levels
4. Functional Primitives

Incorrect DFD structures:

Although DFDs do not follow a strict syntax there are some logically incorrect structures:

Working External Entities:

• An external entity cannot directly enter/retrieve data into/from a data store.
• Data must flow via a process.

Data Store to Data Store:

• data must flow via processes, so data cannot flow directly from one data store to another.

Black Hole

• a process with inputs but no outputs

Spontaneous Generation:

• A process with outputs but no inputs

Gray Hole:

• A process with input(s) and output(s), but where the outputs obviously cannot be generated from the inputs.

Checking your DFD:

• Money and cheques flow out as deposit to bank. 
  Are there depositable items flowing in?
• Profile of customer surely has name and address on it. 
  Does this information flow in from somewhere?

References:

• Shelly, Cashman & Rosenblatt, Systems Analysis and Design, 6th Edition,  Course Technology, 2006.

copyright © 2006 Brian Retallick. This page last updated on Thursday 14 August 2008 by Noel McEwan, La Trobe University, Bendigo