Systems Analysis and
Design
Rabie A. Ramadan
Slides by Roberta M. Roth
University of Northern Iowa
Questionnaires
2
Questionnaires
A set of written questions, often sent to a large number
of people
May be paper-based or electronic
Select participants using samples of the population
Design the questions for clarity and ease of analysis
Administer the questionnaire and take steps to get a
good response rate
Questionnaire follow-up report
Good Questionnaire Design
•Begin with non-threatening and interesting questions
•Group items into logically coherent sections
•Do not put important items at the very end of the questionnaire
•Do not crowd a page with too many items
•Avoid abbreviations
•Avoid biased or suggestive items or terms
•Number questions to avoid confusion
•Pretest the questionnaire to identify confusing questions
•Provide anonymity to respondents
Document Analysis
Document Analysis
Study of existing material describing the current system
Forms, reports, policy manuals, organization charts
describe the formal system
Look for the informal system in user additions to
forms/report and unused form/report elements
User changes to existing forms/reports or non-use of
existing forms/reports suggest the system needs
modification
Observation
Observation
Watch processes being performed
Users/managers often don’t accurately recall
everything they do
Checks validity of information gathered other ways
Be aware that behaviors change when people are
watched
Be modest (seems to be shy)
Identify peak and lull (quite) periods
Selecting the Appropriate RequirementsGathering Techniques
Type of information
Depth of information
Breadth of information
Integration of information
User involvement
Cost
Combining techniques
Your turn
Design a Questionnaire for the project ?
Report your observations on the current
projects and usabilities ?
Collect at least 5of them
The System is the Data
At the core: any system is defined by
the data obtained, stored, and displayed
Data flow analysis is the center/core/key
Before we start
Evaluate the following questioner?
Context Diagram
Shows the context into which the system fits
Shows the overall business process as just one
process
Shows all the outside entities that receive
information from or contribute information to the
system
Context Diagram of Alibris
Bibliographic
Sources
of Catalog Data
WWW Customers
Used
Book
Sellers
New Book
Publishers
and Distributors
Library
Customers
Alibris
Systems
Sales Channels
(BN.com, Borders, Amazon,
eBay, Chapters, Ingram, …)
Context of Quicken – 1995 (?)
Quicken
On PC/Mac
Quicken
User
Slide 15
Quicken - 2006
Banks
Quicken
On PC/Mac
Quicken
User
VISA/MC
Vendors
(check writing)
Slide 16
Brokerage
Your turn
Draw the context diagram for e-learning
system ?
Slide 17
Key Definitions
Process model
A formal way of representing how a business
operates
Illustrates the activities that are performed
and how data moves among them
Data flow diagramming
A popular technique for creating process
models
6 - 18
Key Definitions
Logical process models describe
processes without suggesting how they
are conducted.
Physical process models include process
implementation information.
6 - 19
DATA FLOW DIAGRAMS
6 - 20
Reading a DFD
6 - 21
DFD Elements
Process
An activity or function performed for a
specific business reason
Manual or computerized
Data flow
A single piece of data or a logical collection of
data
Always starts or ends at a process
6 - 22
DFD Elements
Data Store
A collection of data that is stored in some way
Data flowing out is retrieved from the data store
Data flowing in updates or is added to the data
store
External entity
A person, organization, or system that is external
to the system but interacts with it.
6 - 23
Naming and Drawing DFD
Elements
Process
Data flow
Data store
External
entity
6 - 24
Name the Entities of the DFD?
6 - 25
5 - 26
Depicting Business Processes with
DFDs
Business processes are too complex to be
shown on a single DFD
Decomposition is the process of
representing the system in a hierarchy of
DFD diagrams
Child diagrams show a portion of the parent
diagram in greater detail
6 - 27
Key Definition
Balancing involves insuring that
information presented at one level of a
DFD is accurately represented in the next
level DFD.
6 - 28
Relationship Among DFD levels
Context diagram
Level 0 diagram
Level 1 diagram
Level 2 diagram
6 - 29
Context Diagram
First DFD in every business process
Shows the context into which the business
process fits
Shows the overall business process as just one
process (process 0)
Shows all the external entities that receive
information from or contribute information to
the system
6 - 30
Level 0 Diagram
Shows all the major processes that comprise
the overall system – the internal components
of process 0
Shows how the major processes are
interrelated by data flows
Shows external entities and the major
processes with which they interact
Adds data stores
6 - 31
Level 1 Diagrams
Generally, one level 1 diagram is created for every
major process on the level 0 diagram
Shows all the internal processes that comprise a
single process on the level 0 diagram
Shows how information moves from and to each
of these processes
If a parent process is decomposed into, for example,
three child processes, these three child processes
wholly and completely make up the parent
process
6 - 32
Level 2 Diagrams
Shows all processes that comprise a single process on
the level 1 diagram
Shows how information moves from and to each of
these processes
Level 2 diagrams may not be needed for all level 1
processes
Correctly numbering each process helps the user
understand where the process fits into the overall
system
6 - 33
Data Flow Splits and Joins
A data flow split shows where a flow is broken into
its component parts for use in separate processes
Data flow splits need not be mutually exclusive nor
use all the data from the parent flow
As we move to lower levels we become more precise
about the data flows
A data flow join shows where components are
merged to describe a more comprehensive flow
6 - 34
Alternative Data Flows
Where a process can produce different data flows
given different conditions
We show both data flows and use the process
description to explain why they are alternatives
Tip -- alternative data flows often accompany
processes with IF statements
6 - 35
Your Turn
At this point in the process it is easy to lose track of the
“big picture”.
Describe the difference between data flows, data stores,
and processes.
Describe in your own words the relationship between
the DFD and the ultimate new application being
developed.
Process Descriptions
Text-based process descriptions provide more
information about the process than the DFD alone
If the logic underlying the process is quite complex,
more detail may be needed in the form of
Structured English
Decision trees
Decision tables
6 - 37
Structured English
Common Statements
Example
Action Statement
Profits = Revenues - Expenses
Generate Inventory Report
Add Product record to Product Data Store
If Statement
IF Customer Not in Customer Data Store
THEN Add Customer record to Customer Data Store
ELSE Add Current Sale to Customer’s Total Sales
Update Customer record in Customer Data Store
For Statement
FOR all Customers in Customer Data Store, do
Generate a new line in the Customer Report
Add Customer’s Total Sales to Report Total
Case Statement
6 - 38
CASE
If Income < 10,000: Marginal tax
If Income < 20,000: Marginal tax
If Income < 30,000: Marginal tax
If Income < 40,000: Marginal tax
ELSE Marginal tax rate = 38%
ENDCASE
rate
rate
rate
rate
=
=
=
=
10%
20%
31%
35%
Decision Trees
Graphical way of depicting if-then-else
logic
6 - 39
Decision Tables
Represent very complex processes with
multiple decision rules
6 - 40
Explain the following decision tree ? When should I take a
decision not to buy?
5 - 41
CREATING DATA FLOW
DIAGRAMS
6 - 42
Integrating Scenario Descriptions
DFDs start with the use cases and requirements
definition
Generally, the DFDs integrate the use cases
Names of use cases become processes
Inputs and outputs become data flows
“Small” data inputs and outputs are combined
into a single flow
6 - 43
Use Case Analysis
5 - 44
Key Ideas
Use cases are a text-based method of describing
and documenting complex processes
Use cases add detail to the requirements outlined
in the requirement definition
Systems analysts work with users to develop use
cases
Systems analysts develop process and data
models later based on the use cases
5 - 45
Role of Use Cases
A use case is a set of activities that produce
some output result
Describes how the system reacts to an event that
triggers the system
Trigger -- event that causes the use case to be
executed
Event-driven modeling – everything in the
system is a response to some triggering event
5 - 46
Role of Use Cases
All possible responses to the event are
documented
Use cases are helpful when the situation is
complicated
5 - 47
Elements of a Use Case
Basic information
Name, number and brief description
Trigger – event that causes the use case to being
External trigger – some from outside the system
Temporal triggers – time-based occurrences
Viewpoint of the use cases should be consistent
Major inputs and outputs
Sources and destinations
Goal is to be all inclusive
Details
Steps performed and the data inputs and outputs
5 - 48
Sample Use Case
Building Use Cases
5 - 50
Process of Developing Use Cases
Identify the major use cases
Identify the major steps within each use
case
Identify elements within steps
Confirm the use case
Cycle through the above steps iteratively
5 - 51
Step 1 –
Identify the major use cases
Activities
•Start a use case form
for each use case
•If more than nine,
group into packages
Typical Questions Asked
•Ask who, what, and where about the tasks and
their inputs and outputs:
•What are the major tasks performed?
•What triggers this task? What tells you to perform
this task?
•What information/forms/reports do you need to
perform this task?
•Who gives you these information/forms/reports?
•What information/forms/reports does this
produce and where do they go?
5 - 52
Step 2 - Identify the major steps within
each use case
Activities
•For each use case, fill
in the major steps
needed to process the
inputs and produce
the outputs
Typical Questions Asked
•Ask how about each use case:
•How do you produce this report?
•How do you change the information on
the report?
•How do you process forms?
•What tools do you use to do this step (e.g.,
on paper, by email, by phone)?
5 - 53
Step 3 –
Identify elements within steps
Activities
Typical Questions Asked
•For each step, identify •Ask how about each step
its triggers and its
•How does the person know when to perform this
step?
inputs and outputs
•What forms/reports/data does this step produce?
•What forms/reports/data does this step need?
•What happens when this form/report/data is not
available?
5 - 54
Step 4 –
Confirm the use case
Activities
•For each use case,
validate that it is
correct and complete
5 - 55
Typical Questions Asked
•Ask the user to execute the process using
the written steps in the use case – that is,
have the user role-play the use case
Summary
Use cases contain all the information
needed for process modeling, but are
easier for users to comprehend
Use cases are created in an iterative cycle
of steps until they are considered accurate
and complete
5 - 60
Some of the Use Cases to work on
Registration Use Cases
Grades recording Use Case
Uploading lectures Use Case
Exams Use Case
5 - 61
Steps in Building DFDs
Build the context diagram
Create DFD fragments for each use case
Organize DFD fragments into level 0 diagram
Decompose level 0 processes into level 1
diagrams as needed; decompose level 1
processes into level 2 diagrams as needed; etc.
Validate DFDs with user to ensure
completeness and correctness
6 - 62
Build the Context Diagram
Draw one process representing the entire
system (process 0)
Find all inputs and outputs listed at the top of
the use cases that come from or go to external
entities; draw as data flows
Draw in external entities as the source or
destination of the data flows
6 - 63
A Context Diagram Example
6 - 64
Creating DFD Fragments
Each use case is converted into one DFD
fragment
Number the process the same as the use
case number
Change process name into verb phrase
Design the processes from the viewpoint
of the organization running the system
6 - 65
Creating DFD Fragments
Add data flows to show use to data stores
as sources and destinations of data
Layouts typically place
processes in the center
inputs from the left
outputs to the right
stores beneath the processes
6 - 66
A DFD Fragment Example
6 - 67
Creating the Level 0 Diagram
Combine the set of DFD fragments into
one diagram
Generally move from top to bottom, left
to right
Minimize crossed lines
Iterate as needed
DFDs are often drawn many times before being
finished, even with very experienced systems analysts
6 - 68
A Level 0 DFD Example
6 - 69
Creating Level 1 Diagrams (and
Below)
Each use case is turned into its own DFD
Take the steps listed on the use case and depict
each as a process on the level 1 DFD
Inputs and outputs listed on use case become
data flows on DFD
Include sources and destinations of data flows
to processes and stores within the DFD
May also include external entities for clarity
6 - 70
Creating Level 1 Diagrams (and
Below)
Input data flows shown on a parent DFD are
often unbundled on the child diagram using
splits
Output data flows shown on a child DFD are
often bundled using joins and shown as a
larger data flow on the parent diagram
When to stop decomposing DFDs?
Ideally, a DFD has at least 3 processes and no
more than 7-9.
6 - 71
Validating the DFD
Syntax errors – diagram follows the rules
Assure correct DFD structure
For each DFD:
Check each process for:
A unique name: action verb phrase; number; description
At least one input data flow
At least one output data flow
Output data flow names usually different than input data flow names
Between 3 and 7 processes per DFD
6 - 72
Validating the DFD
For each DFD:
Check each data flow for:
A unique name: noun; description
Connects to at least one process
Shown in only one direction (no two-headed arrows)
A minimum number of crossed lines
Check each data store for:
A unique name: noun; description
At least one input data flow
At least one output data flow
Check each external entity for:
A unique name: noun; description
At least one input or output data flow
6 - 73
Validating the DFD
Across DFDs:
Context Diagram:
Every set of DFDs must have one Context Diagram
Viewpoint:
There is a consistent viewpoint for the entire set of DFDs
Decomposition:
Every process is wholly and complete described by the processes on
its children DFDs
Balance:
Every data flow, data store, and external entity on a higher level DFD
is shown on the lower level DFD that decomposes it
No data stores or data flows appear on lower-lever DFDs that do not
appear on their parent DFD
6 - 74
Validating the DFD
Semantics errors – diagram conveys correct meaning
Assure accuracy of DFD relative to actual/desired
business processes
To verify correct representation, use
User walkthroughs
Role-play processes
Examine lowest level DFDs to ensure consistent
decomposition
Examine names carefully to ensure consistent use of
terms
6 - 75
Summary
The Data Flow Diagram (DFD) is an essential
tool for creating formal descriptions of business
processes.
Use cases record the input, transformation, and
output of business processes and are the basis for
process models.
Eliciting use cases and modeling business
processes are critically important skills for the
systems analyst to master.
6 - 76
When databases are used , we need
schema translation ?
5 - 77
Schema Translation
78
Extended Entity Relationship(EER)
Model
The ER model has been widely used but does not have some
shortcomings.
It is difficult to represent cases where an entity may have
varying attributes dependent upon some property.
ER model has been extended into Extended Entity Relationship
model
It includes more semantics such as generalization, categorization and
aggregation.
79
Cardinality: One-to-one relationship
A one-to-one relationship between set A and set
B is defined as:
For all a in A, there exists at most one b in B such that a and
b are related, and vice versa.
Example
• A president leads a nation.
80
Cardinality: One-to-one relationship
Relational Model:
Relation President (President_name, Race, *Nation_name)
Relation Nation (Nation_name, Nation_size)
Where underlined are primary keys and "*" prefixed are foreign keys
Extended Entity Relationship model
81
In Election System : One-to-one
relationship !!!!!
Person and ID
Persons’ and Vote
Judge and Box
Username and Person
82
Cardinality: Many-to-one relationship
A many-to-one relationship from set A to set B
is defined as:
For all a in A, there exists at most one b in B such that a and
b are related,
and for all b in B, there exists zero or more a in A such that
a and b are related.
Example A director directs many movies.
83
Cardinality: Many-to-one relationship
Relational Model:
Relation Director (Director_name, Age)
Relation Movies (Movie_name, Sales_volume, *Director_name)
Extended entity relationship model:
84
In Election System : many to one
relationship !!!!
Box and judge
President position and candidates
Candidate and votes
Candidate and position
85
Cardinality: Many-to-many
relationship
A many-to-many relationship between set
A and set B is defined as:
For all a in A, there exists zero or more b in B such
that a and b are related, and vice versa.
Example
Many students take many courses such that a student
can take many courses and a course can be taken by
many students.
many-many
86
Cardinality: Many-to-many relationship
Relational Model:
Relation Student (Student_id, Student_name)
Relation Course (Course_id, Course_name)
Relation take (*Student_id, *Course_id)
Extended entity relationship model:
87
In Election System : many to many
relationship !!!!
Boxes and judges at the same place
Security table contains many user names and passwords for many
persons
88
Data Semantic: Is-a (Subtype) relationship
The relationship A isa B is defined as:
A is a special kind of B.
Example
Father is Male.
89
Data Semantic: Is-a (Subtype) relationship
Relational Model:
Relation Male (Name, Height)
Relation Father (*Name, Birth_date)
Extended entity relationship model
90
Data Semantic: Disjoint Generalization
The process of generalization is to classify similar entities
into a single entity.
More than one isa relationship can form data abstraction (i.e. superclass and
subclasses) among entities.
A subclass entity is a subset of its superclass entity.
There are two kinds of generalization.
The first is disjoint generalization such that subclass entities are mutually
exclusive.
The second is overlap generalization such that subclass entities can overlap
each other.
Example of Disjoint Generalization
A refugee and a non-refugee can both be a boat person, but a refugee cannot
be a non-refugee, and vice versa.
91
Data Semantic: Disjoint Generalization
Relational Model:
Relation Boat_person (Name, Birth_date, Birth_place)
Relation Refugee (*Name, Open_center)
Relation Non-refugee (*Name, Detention_center)
Extended entity relationship model:
92
Data Semantic: Overlap Generalization
Example of Overlap Generalization
A computer programmer and a system analyst can
both be a computer professional, and a computer
programmer can also be a system analyst, and vice
versa.
93
Data Semantic: Overlap Generalization
Relational Model:
Relation Computer_professional (Employee_id, Salary)
Relation Computer_programmer (*Employee_id, Language_skill)
Relation System_analyst (*Employee_id, Application_system)
Extended entity relationship model:
94
Data Semantic: Categorization Relationship
In cases the need arises for modeling a single
superclass/subclass relationship with more than one
superclass(es), where the superclasses represent different entity
types.
In this case, we call the subclass a category.
95
Data Semantic: Categorization Relationship
Relational Model:
Relation Department (Borrower_card, Department_id)
Relation Doctor (Borrower_card, Doctor_name)
Relation Hospital (Borrower_card, Hospital_name)
Relation Borrower (*Borrower_card, Return_date, File_id)
Extended Entity Relationship Model
96
Data Semantic: Aggregation Relationship
Aggregation is a method to form a composite object from its
components.
It aggregates attribute values of an entity to form a whole entity.
Example
The process of a student taking a course can form a composite entity
(aggregation) that may be graded by an instructor if the student completes
the course.
97
Data Semantic: Aggregation
Relationship
Relational Model:
Relation Student (Student_no, Student_name)
Relation Course (Course_no, Course_name)
Relation Takes (*Student_no, *Course_no, *Instructor_name)
Relation Instructor (Instructor_name, Department)
Extended Entity Relationship Model
98
Data Semantic: Total Participation
An entity is in total participation with another entity provided
that all data occurrences of the entity must participate in a
relationship with the other entity.
Example
An employee must be hired by a department.
99
Data Semantic: Total Participation
Relational Model:
Relation Department (Department_id, Department_name)
Relation Employee (Employee_id, Employee_name, *Department_id)
Extended entity relationship model:
100
Data Semantic: Partial Participation
An entity is in partial participation with another entity provided
that the data occurrences of the entity are not totally participate
in a relationship with the other entity.
Example
An employee may be hired by a department.
101
Data Semantic: Partial Participation
Relational Model:
Relation Department (Department_id, Department_name)
Relation Employee (Employee_no, Employee_name, &Department_id)
Where & means that null value is allowed
Extended entity relationship model:
102
Data Semantic: Weak Entity
The existence of a weak entity depends on its strong entity.
Example
A hotel room must concatenate hotel name for identification.
103
Data Semantic: Weak Entity
Relational Model:
Relation Hotel (Hotel_name, Ranking)
Relation Room (*Hotel_name, Room_no, Room_size)
Extended entity relationship model
104
Cardinality: N-ary Relationship
Multiple entities relate to each other in an n-ary relationship.
Example
Employees use a wide range of different skills on each project they are
associated with.
105
Cardinality: N-ary Relationship
Relational Model:
Relation Engineer (Employee_id, Employee_name)
Relation Skill (Skill_name, Years_experience)
Relation Project (Project_id, Start_date, End_date)
Relation Skill_used (*Employee_id, *Skill_name, *Project_id)
Extended entity relationship model:
106
Example
name
addr
Bars
name
Sells
Beers
license
Note:
license =
beer, full,
none
107
Frequents
name
Drinkers
Likes
addr
manf
Bars sell some
beers.
Drinkers like
some beers.
Drinkers frequent
some bars.
Example
For the relationship Sells, we might
have a relationship set like:
Bar
Joe’s Bar
Joe’s Bar
Sue’s Bar
Sue’s Bar
Sue’s Bar
108
Beer
Bud
Miller
Bud
Pete’s Ale
Bud Lite
Example
name
addr
name
license Bars
Beers
Preferences
Drinkers
name
109
addr
manf
A Typical Relationship Set
Bar
Drinker
Joe’s Bar
Ann
Sue’s Bar
Ann
Sue’s Bar
Ann
Joe’s Bar
Bob
Joe’s Bar
Bob
Joe’s Bar
Cal
Sue’s Bar
Cal
110
Beer
Miller
Bud
Pete’s Ale
Bud
Miller
Miller
Bud Lite
Your Assignment
Build Entity-relationship model
Relation Order
(Order_code,
Order_type,
Our_reference,
Order_date, Approved_date, *Head, *Supplier_code)
Relation Supplier
(Supplier_code, Supplier_name)
Relation Product
(Product_code, Product_description)
Relation Department (Department_code, Department_name)
Relation Head
(Head, *Department_code, Title)
Relation Order_Product (*Order_code, *Product_code, Qty, Others, Amount)
Relation Note
(*Order_code, Sequence#, Note)
where underlined are primary keys and prefixed with ‘*’ are foreign keys.
111