1. 7. ANALYZING REQUIREMENTS- (Data Flow Diagrams)
System Analysis And Design
7. ANALYZING REQUIREMENTS- (Data Flow Diagrams)
Program: BSCS II (Advent Semester – 2014)
Lecturer: Rebecca Asiimwe

2. 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 it contains.

3. 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.

4. 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.

5. 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.

6. 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 requirement document.

7. 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

8. 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.

9. 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.

10. 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.

11. 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 top-bottom representation of a system, which makes it easier for users and analysts to envisage the system as a whole.

12. 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;
External entities
Data stores
Processes
Data flows
Each Element has a symbol and there are two schools of thought for these symbols.

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

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

15. Data Flow Diagram Symbols

16. Data Flow Diagram Symbols Cont’d

17. 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

18. 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

19. 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

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

21. Source/Sink: Correct/Incorrect?21

22. 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.

23. 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

24. Process
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

25. 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

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

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

28. Process: Correct/Incorrect?28

29. 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

30. 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

31. 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
A data flow has a noun phrase label 31

32. Data Flow: Correct/Incorrect?32

33. 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

34. 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

35. 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

36. 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.

37. 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.

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

39. 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

40. Data Store: Correct/Incorrect?40

41. List the errors in this DFD
3.0
DF7 41

42. DFD Example Student Supervisor Reviewed Proposal Revised Proposal 3.0
Receive Project Proposals
Project Proposal D1
Project Proposals
Project Proposal
Student
Project Proposal
Reviewed
Proposal
3.0
Review Project Proposals
Project Proposal
Supervisor
Reviewed Proposal

43. 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

44. 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

45. 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

46. Layers of DFD Abstraction

47. 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

48. 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)

49. 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.

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

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

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

53. 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

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

55. 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

56. 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 7. Validate DFDs with users.

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

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

59. 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.

60. 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.

61. Q & A