Beruflich Dokumente
Kultur Dokumente
Software Engineering
Systems Analysis:
Requirements Structuring
Context & DFDs .
Instructor:
Dr. Ghazy Assassa
Software Engineering CSC 342/Dr. Ghazy Assassa
Slide 1
Objectives
Slide 2
Slide 3
Entity (1 or many)
0
System
Name
Entity 1
Name
Entity 2
Name
Slide 4
DF 2
DF 3
Entity 2
DF 4
0
System
Name
DF 5
Entity 4
DF 6
Entity 5
Slide 5
Context Diagram
System Interface
Birds view of the system
Context Diagram
Slide 6
0
Customer order
Customer
Receipt
Food
Processing
System
Food order
Kitchen
Management Reports
Management
Slide 7
Entity
Name
The person may be inside or outside the business unit under study
Slide 8
Entity
Name
Slide 9
Data in motion.
Ex:
Data on a an invoice
Data on a payroll check
Slide 10
Slide 11
7.0
Process
#7
verb
name
2.0
Process
#2
verb
name
Entity (1 or many)
Entity 1
Name
Entity 2
Name
Slide 12
Slide 13
DFD: Processes
1.0
Process
#1
verb
name
manual or computerised
A Process:
Slide 14
A process:
1.0
Process
#1
verb
name
Slide 15
2.2
2.3
Slide 16
DFD Level-2
P1
P2.1
P2
P3
P2.2
P2.2.1
P2.2.2
P4
P5
P2.3
P2.3.1
P2.3.2
Down
Software Engineering CSC 342/Dr. Ghazy Assassa
Slide 17
Balancing DFDs
Slide 18
Balancing DFDs
2.0
DF1
DF2
DF3
2.0
D1
2.1
2.3
2.2
DF1
DF2
DF3
Slide 19
Data at rest in
Slide 20
Slide 21
Data Store
Data is often stored for later use.
sens
or #
ed
r
i
u
q
rt re
repo
2
look-up
sensor
data
sensor #, type,
location, age
sensor number
D1
type,
location, age
sensor data
Slide 22
Slide 23
Slide 24
user
video
source
processing
request
digital
video
processor
requested
video
signal
monitor
NTSC
video signal
Slide 25
Office 1/ Person 1
Process 1:
Fill in required
courses
Office 2 / Person 2
Process 2:
Verify perquisites
Registration
info
Slide 26
Not relevant:
Slide 27
Wrong DFD
Slide 28
Correct DFD
Slide 29
Slide 30
Level-0 DFD
Slide 31
Slide 32
Slide 33
Slide 34
Slide 35
DFD Rules
Process
A. No process can have only outputs (a miracle)
B. No process can have only inputs (black hole)
C. A process has a verb phrase label
Data Store
D. Data cannot be moved directly from one store to another
E. Data cannot move directly from an outside source to a data
store
F. Data cannot move directly from a data store to a data sink
G. Data store has a noun phrase label
Slide 36
Source/Sink
H. Data cannot move directly from a source to a sink
I. A source/sink has a noun phrase label
Slide 37
Data Flow
J. A data flow has only one direction of flow between symbols
K. A fork means that exactly the same data goes from a common
location to two or more processes, data stores or sources/sinks
L. 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
M. A data flow cannot go directly back to the same process it leaves
N. A data flow to a data store means update
O. A data flow from a data store means retrieve or use
P. A data flow has a noun phrase label
Slide 38
Another example
Inventory Control System
for the previous Food
Processing Company
Slide 39
Slide 40
Slide 41
Slide 42
End of
Process Modelling
DFDs
Software Engineering CSC 342/Dr. Ghazy Assassa
Slide 43
Logic Modelling
Slide 44
System Modelling
Deliverables
Interface Modelling
Context diagram
Process Modelling
DFDs
Data Modelling
Structured English
Decision Tables
Decision Trees
Other diagrams ..
ER diagram
Now
Logic Modelling
(Process Logic)
Slide 45
Logic Modelling
Logic modelling:
Representing internal structure & functionality
of processes on a DFD
DFDs do not show the logic inside the processes
Logic modeling can also be used to show when
processes on a DFD occur
Slide 46
State-Transition diagrams
Sequence diagrams (OOAD)
Activity diagrams (OOAD)
Slide 47
Logic Modelling
Structured English /Pseudocode
If conditions
Case statements
Slide 48
Slide 49
DO
READ next Item Inventory record
BEGIN IF
IF Quantity-in-stock < minimum-reorder level
THEN generate order for this item
END IF
UNTIL end of file
Slide 50
Slide 51
Slide 52
C1 has n1 values
C2 has n2 values
........
Ci has ni values
.
Cm has nm values
=
Software Engineering CSC 342/Dr. Ghazy Assassa
i=1
(ni)
Systems Analysis: Requirements Structuring
Slide 53
Slide 54
Salaried S :
By hour H:
< 40
= 40
> 40
Number of rules = 6
Slide 55
Slide 56
Rules
R1
R2
R3
R4
<40
40
> 40
C1
Employee type
C2
Hours worked
A1
A2
A3
Calculate overtime
A4
X
X
Systems Analysis: Requirements Structuring
Slide 57
Logic Modelling:
Decision Tree
Software Engineering CSC 342/Dr. Ghazy Assassa
Slide 58
Slide 59
Slide 60
Slide 61
Structured
English
Decision
Tables
Decision
Trees
Determining
Conditions and
Actions
Second Best
Third Best
Best
Transforming
Conditions and
Actions into
Sequence
Best
Third Best
Best
Checking
Consistency and
Completeness
Third Best
Best
Best
Slide 62
Logic Modelling
Logic Modelling
End
Slide 63
Slide 64
What is software?
Software is:
Slide 65
Producing a product
Optimally
Highest quality
Minimum resources
Slide 66
Software Engineering
Concerned with developing:
Slide 67
Software costs
Hardware cost
Software cost
people cost
Slide 68
Slide 69
Slide 70
Product engineering
Software engineering
Slide 71
Software engineers
Slide 72
Slide 73
Slide 74
Project Initiation
Feasibility Study
Analysis
Design
Implementation
Coding + Documentation
+ Testing
+ Conversion
+ Training + Installation
Maintenance
Slide 75
Project Initiation
Feasibility Study
Analysis
Design
Coding
Testing
Implementation
Conversion
Training/Installation
Maintenance
System Death
Software Engineering CSC 342/Dr. Ghazy Assassa
Slide 76
Top management
Steering committee
Users
:
Software Engineering CSC 342/Dr. Ghazy Assassa
Slide 77
Alternative solutions
Economic feasibility (cost)
Technical feasibility (technology available)
Schedule feasibility (delivery date)
Human Resources feasibility ( New staff, Training)
Slide 78
Slide 79
Forms
Menus
Icons
Dialogue boxes, etc
Output design
Reports
Queries
Slide 80
Coding
Testing
Documentation
Data conversion (from old to new system)
Training
Installation
Slide 81
Slide 82
Slide 83
What is a model?
Slide 84
Slide 85
Waterfall model
Evolutionary development model
Formal transformation model
Integration from reusable components model
Slide 86
Roughly:
Slide 87
Slide 88
Model descriptions
Descriptions of graphical models which should be produced
Rules
Constraints applied to system models
Recommendations
Advice on good design practice
Process guidance
What activities to follow
Slide 89
Lower-CASE
Slide 90
Slide 91
Maintainability
Reliability
Efficiency
Usability
Slide 92
Legacy systems
Heterogeneity
Delivery
Slide 93
Slide 94