System Analysis And Design 7 ANALYZING REQUIREMENTS Data Flow

System Analysis And Design 7. ANALYZING REQUIREMENTS(Data Flow Diagrams) Program: BSCS II (Advent Semester – 2014) Lecturer: Rebecca Asiimwe Email: rasiimwe@technology. ucu. ac. ug

Lecture Objectives • Explain the structured analysis process and identify its elements • Describe the symbols used in the Data Flow Diagrams and explain the rules for their use. • Explain the sequence of data flow diagrams, from general to specific, and what each data flow contains. • Explain how to level a set of data flow diagrams • Draw a complete set of data flow diagrams for an information system. • Describe how a data dictionary is used and what 2 it contains.

Requirements Analysis • Requirements analysis is done after requirements have been collected. Collected information is analyzed to make sense of it. • Requirements analysis enables the analyst identify the requirements of a client in order to design a solution. 3

Requirements Analysis • This process is usually characterized by the following activities: – What outputs will the system produce – What inputs will be needed – What processing steps will be necessary to transform inputs into outputs – What data stores (files or databases) will have to be maintained by the system. 4

Structured Analysis • Structured Analysis (SA) in software engineering and its allied technique, Structured Design(SD), are methods for analyzing and converting business requirements into specifications and ultimately, a computer program, hardware configurations and related manual procedures. • Structured analysis and design techniques are fundamental tools of system analysis • Examines inputs, outputs, and processes of the system & uses three main tools to model processes, data and logic of the system. 5

Structured Analysis • The three tools include; – Data Flow Diagrams (DFDs) – Data Dictionary – Process (Transformation) Descriptions • Objective of structured Analysis – To document all the end user requirements for the proposed information system and present these requirements in the systems 6 requirement document.

Components of Structured Analysis • Data dictionary; description of all data used in the system • Graphical Symbols; icons and conventions for identifying and describing the components of a system and the relationship among components • Procedures and process description; formal statements using techniques and languages that enable system analysts to describe important activities that make up the system • Rules- Standards for describing and documenting the system correctly and completely 7

Process Modeling with DFDs • Process modeling describes the business processes- activities that people do and can be used to describe both the as-is system (current system) and to-be system (proposed system) • Process modeling is an activity of representing processes so that the current system may be analyzed and improved • Data flow Diagram(DFD) is one the most commonly used process modeling Technique and will be discussed in the following slides. 8

Process modeling- Data Flow Diagrams(DFDs) • DFD is a graphical tool that allows analysts (and users) to depict the flow of data in an information system. • DFDs are the most commonly used way of documenting the processing of as-is and to-be system. • It’s a pictorial way of showing the flow of data into, around and out of a system. 9

Data Flow Diagrams Cont’d • Data Flow Diagram (DFD) – A graphical system model that shows all of the main requirements for an information system: inputs, outputs, processes and data storage – Everyone working on the project (and end users) can see all the aspects of the project in the diagram with minimal training (simple – only 5 symbols). Can be understood by users and are less prone to misinterpretation than textual description. 10

Data Flow Diagrams Cont’d • Data Flow Diagrams (DFDs) are graphical aids that describe an information system. • They represent a logical model that shows what a system does, not how it does it. • A complete set of DFDs provides a compact topbottom representation of a system, which makes it easier for users and analysts to envisage the system as a whole. 11

Elements of Data Flow Diagram • • • The language of DFDs include a set of symbols and syntax rules. There are four elements in the DFD Language; 1. External entities 2. Data stores 3. Processes 4. Data flows Each Element has a symbol and there are two schools of thought for these symbols. 12

DFD Symbols (Gane & Sarson) Process Data Flow Data Store Source/Sink (External Entity) 13

DFD Symbol (De. Marco & Yourdon) Process Data Flow Data Store Source/Sink (External Entity) 14

Data Flow Diagram Symbols 15

Data Flow Diagram Symbols Cont’d 16

DFD- Components External Entities • External Entities are sources of data that enter the system or recipients of data that leaves the system. – Outside the context of the system – Any class of people, organization or another system. – Function is to supply data or receive data – Also called source and sink (Origin and destination) – Are originators or receivers of information outside the scope of the IS, portrayed in the data flowing. – Has a name and description 17

Source/Sink (External Entity) • External entity that is origin or destination of data (outside the system) • Is the singular form of a department, outside organization, other IS, or person • Labels should be noun phrases • Source – Entity that supplies data to the system • Sink – Entity that receives data from the system 18

Rules for External Entities • External people/ systems • Reside outside the system, but interact with system • Either a) receive information from system, b) trigger system into motion, or c) provide new information to system • e. g. Customers, managers • Not clerks or other staff who simply move data 19

Rule: Source/Sink • Must be connected to a process by a data flow 20

Source/Sink: Correct/Incorrect? 21

Process • A process is an activity or function that is performed for some specific business reason • Every process has a name that starts with verb and ends with a noun • Names should be short, yet contain enough information for users to understand • Each process performs one activity • They portray the transformation of input data flows to output data flows in DFDs. 22

Process • Work or actions performed on data (inside the system internal to the system) • Labels should be verb phrases • Receives input data and produces output (no process can have only outputs – a miracle-, & no process can have only inputs –black hole) 23

Process n Logical process models omit any processes that do nothing more than move or route data, thus leaving the data unchanged. Valid processes include those that: ¨ Perform computations (e. g. , calculate grade point average) ¨ Make decisions (determine availability of ordered products) 24

Process ¨ Sort, filter or otherwise summarize data (identify overdue invoices) ¨ Organize data into useful information (e. g. , generate a report or answer a question) ¨ Trigger other processes (e. g. , turn on the furnace or instruct a robot) ¨ Use stored data (create, read, update or delete a record) 25

Rule 1: Process • Can have more than one outgoing data flow or more than one incoming data flow 26

Rule 2: Process • Can connect to any other symbol (including another process symbol) 27

Process: Correct/Incorrect? 28

Data flow • Data flow; represents the movement of data. Can be a single piece of data or logical collection of several pieces of information • Every data flow has a descriptive name that is a noun and description • Data flows are generally shown as one-way only and those between external entities are shown as dotted lines • At least one data flow must enter and exit each process 29

Data Flow • Data in motion, moving from one place to another in the system – From external entity (source) to system – From system to external entity (sink) – From internal symbol to internal symbol, but always either start or end at a process 30

Rule: Data Flow • A data flow has only one direction of flow between symbols • A fork means that exactly the same data goes from a common location to two or more processes, data stores or sources/sinks • A join means that exactly the same data comes from any two or more different processes, data stores or sources/sinks to a common location • A data flow cannot go directly back to the same process it leaves • A data flow to a data store means update • A data flow from a data store means retrieve or use 31 • A data flow has a noun phrase label

Data Flow: Correct/Incorrect? 32

Rules for Data Flow • Data Flow That Connects YES NO A process to another process A process to an external entity A process to a data store An external entity to another external entity An external entity to a data store A data store to another data store 33

Data Store • Depicts data at rest • Is used in a DFD to represent data that the system stores • Internal to the system • Include in system if the system processes transform the data – Store, Add, Delete, Update • Every data store on DFD should correspond to an entity on an ERD 34

Data Store Cont’d • Labels should be noun phrases • May represent data in – File folder – Computer-based file • The name of the store as well as the number are recorded in between lines 35

Data store • Data store represents stores of data within the system • A temporary or time delayed repository or collection of data • Processes can add data to, or retrieve data from these stores • Are either manual or automated inventories of data, e. g. computer files or database, file cabinets & card files. 36

Data store • Data stores Each store is given a reference letter D - indicates a permanent computer file M - indicates a manual file T – indicates a transient (Temporary) store, one that is deleted after processing. • To avoid complex flows, the same data store may be drawn several times on a diagram. Multiple instances of the same data store are indicated by a double vertical bar on their left hand edge. 37

Rule: Data Store • Must have at least one incoming and one outgoing data flow 38

Rule: Data Store (2) • Data cannot be moved directly from one store to another • Data cannot move directly from an outside source to a data store • Data cannot move directly from a data store to a data sink 39

Data Store: Correct/Incorrect? 40

List the errors in this DFD DF 7 3. 0 DF 7 41

DFD Example Reviewed Proposal Revised Proposal 3. 0 Project Proposal Student Receive Project Proposals Project Proposal D 1 Project Proposals Project Proposal Supervisor Reviewed Proposal 3. 0 Review Project Proposals

DFD Example • The square is an external agent – A person or organization, outside the boundary of a system that provides data inputs or accepts data outputs • The rectangle with rounded edges is a process – A symbol that represents an algorithm or procedure by which data inputs are transformed into data outputs 43

DFD Example • The arrows are data flows – Represents movement of data • The flat three-sided rectangle are data stores (a file or part of a database) – A place where data is held 44

DFD Decomposition (Levels of Abstraction) • Most business processes are too complex to be explained in one DFD. Process models are therefore composed of a set of DFDs, this is referred to as decomposition – Other diagrams show the processing at a higher level (more general) or lower level (a more detailed view of one process) – Higher level processes in a DFD can be decomposed into separate lower level DFD • DFD is decomposed into other DFDs each representing a lower level of detail. Decomposition starts with context diagram, level 0, level 1 , level 2 etc

Layers of DFD Abstraction 46

Context Diagrams • Context Diagram: A DFD that summarizes all processing activity within the system in single process symbol – Describes highest level view of a system – All external agents and all data flows into and out of a system are shown in the diagram – The whole system is represented as one process 47

Context Diagram • Useful for showing system boundaries (scope) • External agents are outside the software scope (which is represented by the single process) • Data stores are not usually shown in the context diagram since they are considered to be in the system scope (i. e. the single process) • It is the highest level DFD • Context diagram does not show any details of what takes place within the system (i. e. that single process) 48

Context Diagram • Defines the scope of the system • Provides on “outward” looking view from the system. • Shows the other systems and/or groups of people that interact with the system • Shows the main flows of data. 49

Context Diagram 0 Entity 1 System Name Entity 3 Entity 2 50

Example 1 - Context Diagram Student course selections schedule Registration System Registration details Business Office 51

Example 2 - Context Diagram 0 Project Proposal Student Reviewed Proposal Revised Proposal Project Proposal Research Management System Reviewed Proposal Lecturer

Level 0 DFD • Shows all the processes at the first level of numbering • Shows all major high –level processes of the system and how they are interrelated • All process models have one and only one level 0 DFD • Key principle while decomposing: Balancing 53

Level 0 DFD 1 • . Input A Entity 1 General Process A DF B DF C Record A Entity 3 Record E Record A 3 Input B Output C D 2 Data store 2 D 1 Data store 1 Entity 2 2 General Process B General Process C Record E DF D 4 General Process D 54

Level 1 DFD • Level 0 hides some of the system complexity just like a context diagram does • Each process on the level 0 DFD can be decomposed into a more explicit DFD • Shows how a process operates in greater detail 55

Creating Data Flow Diagrams Creating DFDs is a highly iterative process of gradual refinement. General steps: 1. Create a preliminary Context Diagram 2. Identify Use Cases, i. e. the ways in which users most commonly use the system 3. Create DFD fragments for each use case 4. Create a Level 0 diagram from fragments 5. Decompose to Level 1, 2, … 6. Go to step 1 and revise as necessary 56 7. Validate DFDs with users.

General Rules for Drawing DFDs 1. Any data flow leaving a process must be based on data that is input to the process (outputs must be derivable from inputs) 2. All data flows are named and names reflects the data flowing between the processes, sources, and data stores (All elements must be named). 3. All processes have both inputs and outputs. 4. No physical items 57

General Rules for Drawing DFDs 5. All data needed to perform the process should be input to that process. 6. The process should be independent of any other in the system- each process has its own input and output. 7. Data must move through a process. 8. Different data flows may not merge. 58

More on DFD Guidelines • All DFD diagrams must have a Heading with – Name and Diagram No. (except for context diagram) • All process bubbles must have name and no. • Conservation of data flow Flow Out = Flow In + Amount Stored applies to transform bubbles and data stores. 59

More on DFD guidelines • Avoid infinite sinks i. e. a process with no outgoing data flows • Avoid spontaneous generation bubbles i. e. a process without any incoming data flows • Beware of read-only or write- only data stores. 60

Q&A 61