Systems Analysis Focus is the logical view

Systems Analysis • Focus is the logical view of the system, not the physical • “What” the system is to accomplish, not how • Tools: – data flow diagrams – data dictionary – process specification – entity-relationship diagrams

What is a Data Flow Diagram? • Known as DFDs • A way to model a real world situation • They are the interface between the real world activities and an understanding of how this can be converted into a computer system.

Data Flow Diagram: "a network representation of a system. The system may be automated, manual, or mixed. The DFD portrays the system in terms of its component pieces, with all interfaces among the components indicated. " - Tom De. Marco hence DFDs: focus on the movement of data between external entities and processes, and between processes and data stores

Example Data Flow Diagram data store data flow process external entity

Data Flow Diagrams are: • Used to perform structured analysis to determine logical requirements • A graphical tool, useful for communicating with users, managers, and other IS personnel • Useful for analyzing existing as well as proposed systems • A relatively simple technique to learn and use

Why do we use DFDs? • It is a way of taking the physical view and converting it into a logical view. • The physical view - all documents involved • The logical view - the data they contain • Their main purpose is to communicate with the user, the analyst’s understanding of the scope of the required system

Levelling • DFDs are expanded or decomposed into levels. • Separating each process into sub processes • Uncovers more and more detail

Conventions Balancing Process at lower level should have identical data flows if they flow out of a process Modelling Data Stores Only use DATA STORES used within this process on the diagram Numbering 1 - 1. 1. 1 1. 2 - 1. 2. 1 Labels Should carry as much meaning as possible

Decomposition and Abstraction • Decomposition - Divide and subdivide into manageable size problems • Abstraction - Concentrate on the important issues and ignore the irrelevant

Sources/Sinks (external entities) • Any class of people, an organization, or another system which exists outside the system you are studying. • Form the boundaries of the system. • The system and external entities exchange data in the form of data flows. • Must be named, titles preferred to names of individuals - use a noun source / sink

Data Flows • data in motion • marks movement of data through the system - a pipeline to carry data • connects the processes, external entities and data stores • Unidirectional • originate OR end at a process (or both) • name as specifically as possible - reflect the composition of the data - a noun • do not show control flow! Control flow is easy to identify- a signal with only one byte - (on/off). • HINT: if you can't name it: either it's control flow, doesn't exist or you need to get more information!

Processes • transform incoming data flows into outgoing data flows • represent with a bubble or rounded square • name with a strong VERB/OBJECT combination; examples: create_exception_report validate_input_characters calculate_discount process

Data Stores • data at rest • represents holding areas for collection of data, processes add or retrieve data from these stores • name using a noun (do not use ‘file’) • only processes are connected to data stores • show net flow of data between data store and process. For instance, when access a DBMS, show only the result flow, not the request data store

Data Flow Diagram Don’ts 1. 2. 3. 4. BLACK HOLES MIRACLES Let it get too COMPLEX: 7 ± 2 processes Leave things UNLABELED (corollary: labels should have meaning) 5. Data stores that are “SOURCES” or “SINKS” 6. Data flows that are UNASSOCIATED with a PROCESS 7. Expect your diagram to be “perfect” the first time!

Data Flow Diagram Don’ts process stuff 1. ‘Black Hole’ 2. ‘It’s a Miracle’

Data Flow Diagram Don’ts ds-1 A. 2 data 4. Leave Things Unlabeled Corollary: Labels Should Have Meaning

Data Flow Diagram Don’ts data store 5. Miracle data source 5. Black hole data source

Data Flow Diagram Don’ts 6. Data Flows Unassociated With a Process data store to entity or reverse data store to data store entity to entity

Diagramming A System • multiple DFDs are required to represent a system • DFDs are created at increasing levels of detail

Different Types of DFDs • Context diagram • Level-0 diagram (system diagram) • Level-n diagram • Primitive diagram

Context Diagram • defines the scope of the system by identifying the system boundary • contains: – one process (which represents the entire system) – all sources/sinks (external entities) – data flows linking the process to the sources and sinks (external entities)

Example Context Diagram student course selections schedule Registration System Registration details business office

Constructing a Context Diagram • identify and list sources/sinks (external entities) • identify and list inputs to and outputs from sources/sinks (external entities) • create context diagram

Level-0 Diagram • describes the overall processing of the system • show one process for each major processing step or functional requirement • data flows from the context appear on system diagram also (level balancing) • can show a single data store to represent all data in aggregate at this level • can draw duplicate sources, sinks and data stores to increase legibility

Drawing a Level-0 Diagram • list the major data stores • list major business steps • draw a segment for each business step • assemble into single DFD • re-organize until satisfied • number processes

Functional Decomposition • similar to a series of more detailed maps • iterative process of breaking the description of a system into finer and finer detail to create a set of charts in which one process on a given chart is explained in greater detail on another chart • referred to as exploding, partitioning, or leveling • must use your judgment to decide what goes on each level • show error and exception handling on lower levels (if at all)

Lower Level Diagrams • explode the processes shown on the level-0 diagram • each process is represented by its own DFD • balance data – data flows on upper level appear on lower level, or – data flows on upper level are broken into component pieces with components shown on lower level • each lower level shows greater and greater detail • follow numbering convention

Balancing DFDs • conserve data from level to level inputs and outputs on the higher level must appears somewhere on the lower level

Advanced Rules • Composite data flow on one level can be split into its component data flows on the next level - but new data cannot be added and all data in the composite must be included in the sub-flows • The inputs to a process must be sufficient to produce the outputs. • Lowest level DFDs may add new data flows to represent exception handling, i. e. , error messages • May repeat data stores or sources/sink to avoid crossing lines

Additional Guidelines • the inputs to a process are different from the outputs of that process • objects in a set of DFDs have unique names • do not change data flow names on lower levels unless you are decomposing a data flow into component pieces. • never explode a single process into another single process. If you cannot partition the process, then the lower level DFD is not needed. • expect to iterate, put down the DFD and go back to it a few times to create something satisfactory.

Other Questions about Lower level diagrams 1. How deep? (how many levels? ) – if the process has only one input or one output, probably cannot partition further; – can you describe the process in English in about 1/2 page? 2. How broad? (how many processes on a level? ) – 7 ± two is a reasonable heuristic – may temporarily place much of the system on a single diagram then re-draw into separate levels

Quality Guidelines • Completeness – all components included & in project dictionary • Consistency – between levels: balancing, leveling • Timing considerations – assume system never starts and never stops • Iterative nature – revisions are common • Drawing primitives (lowest level) – when to stop?

The Elements The four main elements of DFDs notation Data Flows, with a label to indicate what data is flowing Processes, that handle the data Data stores, within the system (diary, filing cabinet or computer file) Outside entities, outside sources of data

The Levels • Context - Overview - contains only one process • Level 1 - Utilises all four elements • Level 2 - A breakdown of a level 1 process • Level 3 - A breakdown of a level 2 process • There is no rule as to how many levels of DFD that can be used.

Rules Sequence not important - getting the Process correct is • Context or Level 0 - Identifies the system/ boundary/External Links • Level 1 - Overview of function • Level 2 - Breakdown to Understand Hard to know where to stop Rule of Thumb If there are more than 8 data flows break it Process of Identifying major Processes

Production planning Design Supplier Maintain stock system Factory Purchasing

Process 3 Level 2 3 Client a Clie a Hair Details Hair/Reception 3. 1 Hairdresser Conduct Appointment Details M 2 3. 2 Diary Hairdresser Inform Reception Change of Hair Details 3. 3 Receptionist Complete Appointment M 3 Client Card

Where to Begin Creating DFDs • Start with the data flow from an external entity and work forwards • Start with the data flow to an external entity and work backwards • Examine the data flows into or out of a data store • Examine data flows, entity connections and data stores associated with a particular process • Note fuzzy, ill-defined areas of the system for further clarification

What to Avoid in DFDs 4 Processes with no outputs or no inputs Perform Repair Processes whose inputs are obviously inadequate to yield outputs Connecting data stores directly to each other Courses Class List Students Having data flows terminate at data stores Connecting entities to anything other than processes Making the data flow diagram too cluttered (e. g. 9 processes) Many processes with a single input and output (linear flow) Payroll Department Employees 1 2 3 Process A Process B Process C

DFD Example: Bus Garage Repairs Buses come to a garage for repairs. A mechanic and helper perform the repair, record the reason for the repair and record the total cost of all parts used on a Shop Repair Order. Information on labor, parts and repair outcome is used for billing by the Accounting Department, parts monitoring by the inventory management computer system and a performance review by the supervisor. • Key process (“the system”): performing repairs and storing information related to repairs • External Entities: Bus, Mechanic, Helper, Supervisor, Inventory Management System, Accounting Department, etc. • Processes: – Record Bus ID and reason for repair – Determine parts needed – Perform repair – Calculate parts extended and total cost – Record labor hours, cost

DFD Example: Bus Garage Repairs (cont’d) • Data stores: – – Personnel file Repairs file Bus master list Parts list • Data flows: – – – Repair order Bus record Parts record Employee timecard Invoices

Bus Garage Context Diagram Bus Fixed mechanical problems Mechanical problem to be repaired Helper Labor 0 Bus Repair Process Labor Mechanic Labor, parts cost details Repair summary List of parts used Supervisor Inventory Management System Accounting

Bus Garage Diagram 0 DFD

Bus Garage Diagram 0 DFD (cont’d)