1

Chapter 2
OVERVIEW OF STRUCTURAL
SYSTEM ANALYSIS AND DESIGN
APPROACH

1.1 6/7/2024
 SDLC
2

 System Planning and Selection

 System Analysis
 System Design
 System Implementation and Operation

6/7/2024
3

6/7/2024
4

IS Project Identification and Selection

First phase in the SDLC

6/7/2024
 Project identification
5

 Need Identification or Assessment which is focusing

on different sources and forms of projects request and
checking the validity of requests through request
clarification is done at this phase.
 There are two approaches to project identification:
 Top-down approaches
◼ Top management
◼ Steering committees
 Bottom-up approaches
◼ User departments
◼ Development group

6/7/2024
 Project selection
6

 Next to identifying the possible area for system

development, selection of a project that do need
immediate attention by considering its link with the
major objective of the institution and other issues is
another point to consider.
 Identified projects are classified and ranked and
selected for the next phase based on important criteria.
◼ The project that weighed more move to the initiation phase.
◼ The possible criteria are shown in the next slide.

6/7/2024
 Project selection
7

6/7/2024
8

Project Initiation and planning

6/7/2024
 Project Initiation
9

 Project initiation focuses on activities that will help

organize a team to conduct project planning.

6/7/2024
 Planning the project activities
10

6/7/2024
 Conducting a Feasibility Study
11

 Assessing feasibility means answering questions relating to

the utility and viability/practicality of the system that is
going to be developed.
 Economic Feasibility
 Assessing economic feasibility involves comparing the costs of
the information systems development project with the benefits
the information system is going to have for the organization
once it has been developed.
 Benefits of an information system project can be tangible or
intangible.
 Tangible benefits are those benefits that can be translated in to
monetary values (such as Birr or Dollar).
 Intangible benefits are the benefits the proposed IS would give to the
organization but which cannot easily be measured in monetary terms.

6/7/2024
 Cont…
12

Technical Feasibility
 Assessing technical feasibility means checking weather the
organization has got the technical capability to develop
the proposed IS.
 We can assess the technical feasibility of IS development
projects based on the following factors:
 The size of the project
 The extent of structure the problems to be solved using the IS have
 The familiarity of the IS development team with the technology to
be used in the project
 The familiarity and experience of users with system development
in general and the application area

6/7/2024
 Cont…
13

Operational Feasibility
 Refers to weather the proposed system can be
implemented and operated with the staff the
organization have and meet its intended purpose.
 Thus operational feasibility requires checking weather
the IS will be operational or not.
 The difference between technical and operational
feasibility is that while technical feasibility is technology
oriented, operational feasibility is people oriented.

6/7/2024
 Cont…
14

 Technical feasibility answers:

◼ Can we build the proposed system with the proposed
technology? (That is, is the technology practical?
◼ Do we have access and expertise to that technology?)

 Operational feasibility answers:

◼ willthe proposed system solve the problem if put in
operation?
◼ do we have the necessary staff to make it operational?

6/7/2024
 Building Baseline Project Plan
15

 All the information collected during project initiation

and planning is collected and organized into a
document called the baseline project plan.
 Contains four major sections
◼ Introduction
◼ System description
◼ Feasibility assessment
◼ Management issues

6/7/2024
 16

Systems Analysis

6/7/2024
1-17 6/7/2024
18

Requirements Determination
 During requirements determination, analysts gather

information on what the system should do from as

many sources as possible.
Such sources include - users of the current system,
reports, forms, and procedures.
All of the system requirements are carefully
documented and made ready for structuring.

6/7/2024
19

Requirements Structuring

taking the system requirements you find during

requirements determination and ordering them into
diagrams, data-flow diagrams (DFDs), which make
them easier to translate into technical system
specifications.

6/7/2024
 Performing Requirements Determination
20

 Characteristics for gathering requirements

 Impertinence
◼ Question everything
 Impartiality
◼ Find the best organizational solution
 Relaxation of constraints
 Attention to detail

 Reframing
◼ View the organization in new ways

4.20 6/7/2024
 Traditional Methods for Determining
21
Requirements

6/7/2024
22

 Traditional methods for determining a system’s

requirements are still used by analysts to collect
important information.
 Today, however, additional techniques are available
 Modern techniques can support effective information
collection and structuring while reducing the amount
of time required for analysis.

6/7/2024
 Modern Methods for Determining
23
Requirements
 Joint Application Design (JAD)
 Brings together key users, managers and systems analysts
 Purpose: collect system requirements simultaneously from key
people
 Conducted off-site

 Prototyping
 Repetitive process
 Elementary version of system is built
 Replaces or augments SDLC
 Goal: to develop concrete specifications for ultimate system

4.23 6/7/2024
 Types of Requirements
24

 we have three types of requirements that we should determine and

document in a form of system requirement specification document.
1. Functional requirements
▪ Major functionalities of the system that it should possess
▪ Actions of the system
2. Non-Functional requirements
▪ User visible aspects of the system not directly related to functional
behavior. E.g. performance, quality, security
3. Pseudo requirements
▪ Requirements imposed by the users on the developers
▪ That do not have that much close relation ship with the functionalities of
the system
 Thus a document that contains such requirements is the most
referenced document through out the system development process
and is referred as System Requirement Specification(SRS).
6/7/2024
25

6/7/2024
 Structuring requirement
26

Usually separate models are used to structure the data,

logic and process aspects of the proposed system in a
structured approach.
Accordingly we have three different modeling in
structured approach.
• Process modeling
• Logic Modeling
• Data (conceptual) Modeling

6/7/2024
 27

Structuring System Requirements:

Process Modeling

6/7/2024
 Process Modeling
28

 Graphically represent the functions, or processes

that capture, manipulate, store and distribute data
between a system and its environment and among
system components

 One common process modeling tool is Data flow

diagram (DFD)

5.28 6/7/2024
 Data flow diagrams (DFDs’)
29

DFDs’ are used to organize information gathered

during requirements determination into a meaningful
representation of the information system that exists
and of the requirements desired in a replacement
system.

Graphically illustrate movement of data between

external entities and the processes and data stores within
a system

6/7/2024
 Process Modeling
30

 Data flow diagramming mechanics

 Four symbols are used

6/7/2024
 Data Flow Diagramming Mechanics
31

 Data Flow
 Depicts data that are in motion and moving as a unit
from one place to another in the system.
 Drawn as an arrow

 Select a meaningful name to represent the data

5.31 6/7/2024
 Data Flow Diagramming Mechanics
32

 Data Store
 Depicts
data at rest
 May represent data in
◼ File
folder
◼ Computer-based file
◼ Notebook
 Drawn as two horizontal parallel lines
 The name of the store as well as the number are
recorded in between lines

6/7/2024
 Data Flow Diagramming Mechanics
33

 Process
 Depicts work or action performed on data so that they
are transformed, stored or distributed
 Drawn as a circle

 Number of process as well as name are recorded

5.33 6/7/2024
 Data Flow Diagramming Mechanics
34

 Source/Sink
 Depicts the origin and/or destination of the data
 Sometimes referred to as an external entity

 Drawn as a square symbol

 Name states what the external agent is

 Because they are external, many characteristics are not

of interest to us

6/7/2024
 Data Flow Diagramming Definitions
35

 Context Diagram
 A data flow diagram (DFD) of the scope of an
organizational system that shows the system boundaries,
external entities that interact with the system and the major
information flows between the entities and the system
 Level-O Diagram
 A data flow diagrams (DFD) that represents a system’s
major processes, data flows and data stores at a higher
level

6/7/2024
 Developing DFDs: An Example
36

 Hoosier Burger’s automated food ordering system

 Context Diagram contains no data stores
 Next step is to expand the context diagram to show
the breakdown of processes

5.36 6/7/2024
 Context Diagram
37

6/7/2024
 Expanding context diagram (Level-0 DFD)
38

6/7/2024
 Data Flow Diagramming Rules
39

 Basic rules that apply to all DFDs

 Inputs
to a process are always different than outputs
 Objects always have a unique name
◼ Inorder to keep the diagram uncluttered, you can repeat
data stores and data flows on a diagram

5.39 6/7/2024
 Data Flow Diagramming Rules
40

 Process  Data Store

A. No process can have D. Data cannot be moved
only outputs (a from one store to
miracle) another.
B. No process can have E. Data cannot move from
only inputs (black hole) an outside source to a
C. A process has a verb data store
phrase label F. Data cannot move
directly from a data
store to a data sink
G. Data store has a noun
phrase label
5.40 6/7/2024
41

6/7/2024
 Data Flow Diagramming Rules
42

 Source/Sink  Data Flow

H. Data cannot move J. A data flow has only
directly from a one direction of flow
source to a sink between symbols.
I. A source/sink has a K. A fork means that
noun phrase label exactly the same
data go from a
common location to
two or more
processes, data
stores or
sources/sinks
5.42 6/7/2024
43

6/7/2024
 Data Flow Diagramming Rules
44

 Data Flow (Continued)

L. A join means that exactly the same data come 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

5.44 6/7/2024
45

6/7/2024
 Decomposition of DFDs
46

 Functional decomposition
 Act of going from one single system to many component
processes
 Repetitive procedure

 Lowest level is called a primitive DFD

 Level-N Diagrams
 A DFD that is the result of n nested decompositions of a
series of subprocesses from a process on a level-0 diagram

5.46 6/7/2024
 Level-1 DFD
47

6/7/2024
 Balancing DFDs
48

 When decomposing a DFD, you must preserve inputs

to and outputs from a process at the next level of
decomposition
 This is called balancing
 Example: Hoosier Burgers
 In Figure below, notice that there is one input to the system,
the customer order
 Three outputs:
◼ Customer receipt
◼ Food order
◼ Management reports

5.48 6/7/2024
49

6/7/2024
 Balancing DFDs
50

 Example (Continued)
 Notice Figure below. We have the same inputs and
outputs
 No new inputs or outputs have been introduced

 We can say that the context diagram and level-0 DFD

are balanced

5.50 6/7/2024
51

6/7/2024
 Balancing DFDs
52

 An unbalanced example
 The next Figure
 In context diagram, we have one input to the system, A
and one output, B
 Level 0 diagram has one additional data flow, C

 These DFDs are not balanced

5.52 6/7/2024
53

6/7/2024
 54

Structuring System Requirements:

Logic Modeling

6/7/2024
 Logic Modeling
55

 Data flow diagrams do not show the logic inside the

processes
 Logic modeling involves representing internal
structure and functionality of processes depicted on
a DFD
 Common techniques in logic modeling
 Structured English
 Decision Tables
 Decision trees

5.55 6/7/2024
 Modeling Logic with Structured English
56

 Modified form of English used to specify the logic

of information processes
 Uses a subset of English
 Actionverbs
 Noun phrases

 No adjectives or adverbs

 No specific standards

5.56 6/7/2024
 Modeling Logic with Structured English
57

Appropriate technique to use when the process logic

involves formulas or iterations or when the decisions are
not complex (simple)

It can be used to represent the 3 basic types of

programming logic:
Sequence - with no special order
Conditional - with conditions using If ….Else
Repetition - with some repetition based on condition,
using Do…until, etc

6/7/2024
 I. Sequence
58

Eg.
BEGIN Process 1. Step 1
Step 2
Process 2. Step x
END Step y
…

6/7/2024
 II. Condition
59

IF flight exist THEN

IF seat is available THEN
Reserve is ok
ELSE
Waiting list
ELSE
There is no flight source to destination

6/7/2024
 III. Repetition
60

DO
Reserve seat

WHILE (seat is available)

6/7/2024
 Modeling Logic with
61
Decision Tables
 A matrix representation of the logic of a decision

 Specifies the possible conditions and the resulting

actions

 Best used for complicated decision logic

5.61 6/7/2024
 Modeling Logic with
62
Decision Tables
 Consists of three parts
 Condition stubs
◼ Lists condition relevant to decision
 Action stubs
◼ Actions that result for a given set of conditions
 Rules
◼ Specify which actions are to be followed for a given set of
conditions

5.62 6/7/2024
 Modeling Logic with
63
Decision Tables
 Indifferent Condition
 Condition whose value does not affect which action is taken
for two or more rules
 Standard procedure for creating decision tables
 Name the condition and values each condition can assume
 Name all possible actions that can occur
 List all rules
 Define the actions for each rule
 Simplify the table

5.63 6/7/2024
64

Example: - Decision table from payroll system

Employee type: S = salaried, H= hourly
Condition stubs Conditions/ Course Rules
of Action 1 2 3 4 5 6

Employee type S H S H S H
Hours worked <40 <40 40 40 >40 >40
Pay base salary X X X
Action stubs
Calculate hourly wage X X X

Calculate over time X

Produce Absence X
Report

Are there any Indifferent Conditions?

6/7/2024
 Simplified decision table
65

Rules
Conditions/ course of
Action 1 2 3 4
Employee type S H H H
Hours worked - <40 40 >40
Pay base salary X
Calculate hourly wage
X X X
Calculate overtime
X
Produce Absence Report
X

6/7/2024
 Modeling Logic with
66
Decision Trees
 A graphical representation of a decision situation
 Decision situation points are connected together by
arcs and terminate in ovals.
 It has two main components
 Decision points: represented by nodes
 Actions: represented by ovals

6/7/2024
 How to create decision trees
67

 It is read from left to right

 Each node has a number corresponding to a
numbered choice on a legend.
 All possible actions are listed on the far right
 Identify all conditions and actions and their order and
timing
 Begin building the tree from left to right while making
sure you are complete in listing all possible
alternatives before moving over to the right.

6/7/2024
 Example decision tree representation of the decision
logic in the decision table we have seen before;
68

6/7/2024
 69

Structuring System Requirements:

Conceptual Data Modeling

6/7/2024
70

Data-flow diagrams show how, where, and when

data are used or changed in an information
system, but they do not show the definition,
structure, and relationships within the data.

Data modeling develops this missing, and crucial,

piece of the description of an information system

6/7/2024
71

the characteristics of data captured during data modeling

are crucial in the design of databases, programs,
computer screens, and printed reports.

data rather than processes are the most complex aspects

of many modern information systems.

6/7/2024
 Conceptual Data Modeling
72

 Representation of organizational data

 Purpose is to show rules about the meaning and interrelationships
among data
 Entity-Relationship (E-R) diagrams are commonly used to show
how data are organized in a IS
 Main goal of conceptual data modeling is to create accurate E-R
diagrams
 Methods such as interviewing, questionnaires and JAD are used
to collect information

6.72 6/7/2024
73

Consistency must be maintained between process

flow, decision logic and data modeling descriptions.
because each describes different but complementary views
of the same information system.
For example, the names of data stores on primitive-level
DFDs often correspond to the names of data entities in
entity-relationship Diagrams.

6/7/2024
 Process of Conceptual Data Modeling
74

 First step is to develop a data model for the system

being replaced
 Next, a new conceptual data model is built that
includes all the requirements of the new system
 In the design stage, the conceptual data model is
translated into a physical design
 Project repository links all design and data modeling
steps performed during SDLC

6.74 6/7/2024
 Introduction to Entity-Relationship (E-R)
75
Modeling
 Notation uses three main constructs:
 Data entities
 Relationships
 Attributes

 Entity-Relationship (E-R) Diagram

A detailed, logical and graphical representation of the
data for an organization or business area
 There exists several E-R notations, here we have adopted
Crow’s foot notation.

6.75 6/7/2024
 Entity-Relationship (E-R) Modeling
Key Terms
76

 Entity
 A person, place, object, event or concept in the user
environment about which the organization wishes to maintain
data
 An entity has a unique identity by which it is separated from
other entities.

6/7/2024
77

❖ Entity Type
A collection of entities that share common properties or
characteristic.
❖ Entity instance (or instance)
is a single occurrence of an entity type. An
entity type is described just once in a data model, whereas
many instances of that entity type may be represented by
data stored in the database.

6/7/2024
78

 Attribute
 A named property or characteristic of an entity that is of
interest to an organization
 We use nouns in naming attributes

6/7/2024
 Entity-Relationship (E-R) Modeling
Key Terms
79

 Candidate keys and identifiers

 Each entity type must have an attribute or set of
attributes that distinguishes one instance from other
instances of the same type
 Candidate key
◼ Attribute (or combination of attributes) that uniquely
identifies each instance of an entity type
Some entities may have more than one candidate key.

6.79 6/7/2024
 Entity-Relationship (E-R) Modeling
Key Terms
80

 Identifier
 A candidate key that has been selected as the unique
identifying characteristic for an entity type
 Selection rules for an identifier
1. Choose a candidate key that will not change its value
2. Choose a candidate key that will never be null
3. Avoid using intelligent keys , whose structure indicates
classifications, locations, and other entity properties.
4. Consider substituting single value surrogate keys for large
composite keys

6.80 6/7/2024
81

For each entity, the name of the identifier is

underlined on an E-R diagram.

6/7/2024
 Entity-Relationship (E-R) Modeling
Key Terms
82

 Multivalued Attribute
 An attribute that may take on more than one value for each
entity instance
 Suppose that, Skill is one of the attributes of EMPLOYEE. If
each employee can have more than one Skill, then it is a
multivalued attribute.

6.82 6/7/2024
83

 Represented on E-R Diagram in two ways:

◼ double-lined ellipse (curly bracket)
◼ weak entity

6/7/2024
 Entity-Relationship (E-R) Modeling
Key Terms
84

 Relationship
 An association between the instances of one or more
entity types that is of interest to the organization
 Association indicates that an event has occurred or that
there is a natural link between entity types
 Relationships are always labeled with verb phrases

6.84 6/7/2024
 Degree of Relationship
85

 Degree
 Number of entity types that participate in a relationship
 Three cases
 Unary
◼ A relationship between the instances of one entity type
 Binary
◼ A relationship between the instances of two entity types
 Ternary
◼ A simultaneous relationship among the instances of three entity
types
◼ Not the same as three binary relationships

6.85 6/7/2024
86

6/7/2024
 Cardinality in Relationships
87

 Suppose that two entity types, A and B, are

connected by a relationship.
The cardinality of a relationship is the number of
instances of entity B that can be associated with
each instance of entity A
 Minimum Cardinality
 The minimum number of instances of entity B that may be
associated with each instance of entity A
 Maximum Cardinality
 The maximum number of instances of entity B that may
be associated with each instance of entity A
6.87 6/7/2024
88

A video store stocking DVD of a given movie.

The zero through the line near the DVD entity means a
minimum cardinality of zero, whereas the crow’s-
foot notation means a “many” maximum cardinality.

6/7/2024
 Associative Entity
89

 An entity type that associates the instances of one

or more entity types and contains attributes that are
strange to the relationship between those entity
instances

6.89 6/7/2024
90

For example, suppose an organization wishes to record

the date (month and year) when an employee completes
each course. Some sample data follow:

6/7/2024
91

6/7/2024
 92

System Design
Designing Databases

6/7/2024
93

6/7/2024
 Logical and physical database design has
94
five purposes:
 1. Structure the data in stable structures
 2. Develop a logical database design that reflects the
actual data requirements that exist in the forms and
reports an IS
 3. Develop a logical database design from which we can
do physical database design.
 4. Translate a relational database model into a

technical file and database design.

 5. Choose data-storage technologies (such as

hard disk, CD-ROM, or flash disk) that will efficiently,

accurately, and securely process database activities.

6/7/2024
 Process of Database Design
95

 Logical Design
 Based upon the conceptual data model
 Four key steps
1. Develop a logical data model for each known user interface
for the application using normalization principles.
2. Combine normalized data requirements from all user
interfaces into one consolidated logical database model
3. Translate the conceptual E-R data model for the application
into normalized data requirements
4. Compare the consolidated logical database design with the
translated E-R model and produce one final logical database
model for the application

9.95 6/7/2024
 Step 1
96

6/7/2024
97

Step 2 Step 3

6/7/2024
98

Step 4 (Normalized relations are the primary

deliverable from logical database design.

6/7/2024
 Process of Database Design
99

 It is important to remember that relations do not

correspond to computer files.

 In physical database design, you translate the

relations from logical database design into
specifications for computer files.

 In most systems, these files will be tables in a

relational database.

6/7/2024
 Process of Database Design
100

 Physical Design
 Based upon results of logical database design
 Key decisions
1. Choosing storage format for each attribute from the logical
database model
2. Grouping attributes from the logical database model into
physical records
3. Arranging related records in secondary memory (hard disks
and magnetic tapes) so that records can be stored, retrieved
and updated rapidly
4. Selecting media and structures for storing data to make
access more efficient

9.10 6/7/2024
0
 Deliverables and Outcome
101

 Logical database design must account for every

data element, system input or output
 Normalized relations are the primary deliverable

 Physical database design results in converting

relations into files

Normalization is the process of converting complex
data structures into simple, stable data structures

9.10 6/7/2024
1
102

Reading Assignment
 Designing Human Interface

6/7/2024