Modern Systems Analysis

and Design
Chapter 9
Structuring System Data Requirements

Structuring Sys Requirements

Process (Ch 7: DFD)
Data (Ch 9: ERD)

9-2

Conceptual Data Modeling

A detailed model that captures the overall

structure of data in an organization
Independent of any database management
system (DBMS) or other implementation
considerations

9-3

Process of Conceptual Data

Modeling

Develop a data model for the current system

Develop a new conceptual data model that
includes all requirements of the new system
In the design stage, the conceptual data model
is translated into a physical design

9-4

Deliverables and Outcome

Entity-relationship diagrams or class diagrams

Set of entries about data objects to be stored
in repository or project dictionary.

Repository is the mechanism that links data,

process, and logic models of an information
system.
Data elements included in the DFD must appear in
the data model and vice versa.
Each data store in a process model must relate to
business objects (data entities) represented in the
data model.

9-5

Sample Conceptual
Data Model

9-6

Entity-Relationship Modeling

Entity-Relationship Diagram (ERD)

A detailed, logical representation of the entities,

associations and data elements for an organization
or business

Notation uses three main constructs

Data entities
Relationships
Attributes

9-7

Relationship: association between the instances of one or

more entity types

Entity: person, place, object, event or concept

about which data is to be maintained
Entity type/class: collection of entities with
common characteristics (e.g. STUDENT or
EMPLOYEE)
Entity instance: a single occurrence of an
entity type (e.g. one of hundreds of
employees listed in a database; also a row or
record in a table)

Attribute:
named
property or
characteristic
of an entity
(e.g. a
column or a
field in a
table)

ERD Example

Entities?

_________________________________

Relationship?

_________________________

Attributes?

_________________________

9-9

Identifier Attributes

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.
One candidate key for EMPLOYEE is Employee_ID.
A second is the combination of Employee_Name and

Address (assuming no two employees with the same

name live at the same address).
When there is more than one candidate key, the
designer must choose one of them as the identifier.

Identifier

Next Slide

Identifier

Identifier Attributes
(cont.)

A candidate key that has been selected as the

unique identifying characteristic for an entity type
aka primary key
A field, or a collection of fields, whose values uniquely

identify each entity instance (row or record in a table)

e.g. the primary key, Employee_ID, uniquely indentifies
each employee in a table

Shown in a diagram by underlining the

appropriate attribute (Employee_ID)

Entity and Identifier Attribute

Simple attributes

Employee_Name

Employee_ID

EMPLOYEE
Identifier attribute showing
each employee has a unique
ID (underlined).
9-12

Primary
key

A Sample Table

Entity or
table name
Attributes
(columns
or fields)

Entity
instances
(rows or
records)

Entity

Key Terms in Table

Generalized class of people, places, or things

(objects) for which data is stored and maintained

Field or attribute

Column in a table
Characteristic of an entity

Primary key

Field that uniquely identifies each record

Record

Row in a table
Collection of related data fields

9-14

Degree of Relationship
Degree: number of entity types that participate in a
relationship
Three cases

Unary: between two instances of one entity type (also

called a recursive relationship)
Binary: between the instances of two entity types
Ternary: among the instances of three entity types

9-15

1:1

1:M

9-16

M:M

Cardinality
Count or number of instances of entity B that can or
must be associated with each instance of entity A

1:1

or

1:M

or

M:M

Minimum Cardinality

The minimum number of instances of entity B that must be

associated with each instance of entity A

Maximum Cardinality

The maximum number of instances of entity B that can be

associated with each instance of entity A

Mandatory vs. Optional Cardinalities

Specifies whether an instance must exist or can be absent in

the relationship
If minimum cardinality is zero, then optional; 1, mandatory.

9-17

Cardinality Symbols
vertical hash mark

oval

9-18

Note that many means zero, one, or many!

Unary Relationship Example

A common unary relationship is called a bill-of-materials

structure. The structure here can be represented as M:M.
Many manufactured products are made of subassemblies,
which in turn are composed of other subassemblies and
parts, and so on. The relationship here is Has_components.
The attribute Quantity, which is a property of the relationship,
indicates the number of each component that is contained in
a given assembly. For example, a bike item TX100 may
contain items BR450 (quantity 2) & DX500 (quantity 1).

Binary Relationship Examples

PROJECT is an
optional
participant in the
relationship since
the minimum
number of
projects is zero.
Description
EMPLOYEE Is_assigned_to PROJECT. Each PROJECT has at
least one assigned EMPLOYEE (some projects have more
than one). Each EMPLOYEE may or (optionally) may not be
assigned to any existing PROJECT, or may be assigned to
several PROJECTs.

Binary Relationship Examples contd

PATIENT HISTORY
and PATIENT are
mandatory
participants since
the minimum # of
each in the
relationship is one.
Description
PATIENT Has PATIENT_HISTORY. Each patient has one or
more patient histories (we assume that the initial patient visit
is always recorded as an instance of PATIENT_HISTORY).
Each instance of PATIENT_HISTORY belongs to exactly one
PATIENT.
9-21

Associative Entities
An entity type that associates the instances of one or
more entity types and contains attributes that are
peculiar to the relationship between those entity
instances.
An associative entity is:

An entity
A relationship

This is the preferred way of illustrating a relationship

with attributes
For, example, having a M:M relationship broken into
two 1:M relationships.
9-22

Associative Entities contd

A relationship with an attribute

as an associative entity

9-23

The diamond is
included within the
entity rectangle as a
reminder that the entity
was derived from the
relationship.

Associative Entities contd

Ternary relationship

as an associative entity

Identifier:
Shipment_ID
9-24

Supertypes and Subtypes

Supertype

A generic entity type that has a relationship with

one or more subtypes

Subtype

A subgrouping of the entities in an entity type that

shares common attributes or relationships distinct
from other subtypes

Example

The supertype STUDENT has two subtypes,

GRADUATE STUDENT and UNDERGRADUATE
STUDENT.

9-25

Rules for Supertype/Subtypes

Relationships

Total specialization
an entity instance of the supertype must be an
instance of one of the subtypes
Partial specialization
an entity instance of the supertype may or may not be
an instance of one of the subtypes
Total specialization is shown on the ERD by a double
line from the supertype to the circle.
Partial specialization is shown on the ERD by a single
line from the supertype to the circle.
9-26

Rules for Supertype/Subtypes

Relationships contd

Disjoint: an entity instance of the supertype can be

an instance of only one subtype

Disjoint rule specifies that if an entity instance of the

supertype is a member of one subtype, it cannot
simultaneously be a member of any other subtype.

Overlap: an entity instance of the supertype may be

an instance of multiple subtypes

The overlap rule specifies that an entity instance can

simultaneously be a member of two (or more) subtypes.

Disjoint versus overlap is shown by a d or an o in

the circle in an ERD diagram, respectively.

Disjointness/overlap is not expressed in Microsoft Visio

9-27

Supertypes/
Subtypes

9-28

Which attributes
are relevant for
PERSON, and
only for
STUDENT (i.e.
inheritance)?

Previous Slide

A PERSON must be (total specialization) an

EMPLOYEE, an ALUMNUS, or a STUDENT or
any combination of these subtypes (overlap).
An EMPLOYEE must be a FACULTY or a
STAFF (disjoint) or may be just an
EMPLOYEE (partial specialization).
A STUDENT can be only a GRADUATE
STUDENT or an UNDERGRADUATE
STUDENT and nothing else (total
specialization and disjoint).
9-29

Packaged Data Models

Generic data models that can be applied and

modified for an organization
Two categories

Universal
Applicable to nearly any business or organization, e.g.

functions (purchasing, accounting, receiving, etc.) or

areas (customers, products, accounts, etc.)

Industry-specific

Benefits

Reduced implementation time and cost

High-quality modeling

9-30

Packaged data
models provide
generic models
that can be
customized for a
particular
organizations
business rules
9-31

Modern Systems Analysis

and Design
Chapter 12
Designing Interfaces and
Dialogues

SDLC
Design Phase:
Selection of a
solution and
specification of
hardware, software,
etc. for that solution

9-33

9-34

User Interface (UI)

User interface (UI)

Layout (of widgets, text, and table data)

Widgets like buttons, radio buttons, etc.

Structuring data entry (tab order)

Controlling data input (validation & format controls)
Feedback (prompting, status, warning, and error
messages)
Dialogue sequencing (discussed later)
Usability (defined later)

9-35

Sample Design: Forms/Tables

Visual Basic
.NET and other
development
tools provide
computer aided
GUI form and
report
generation.

9-36

Interface Methods
Interface: the method by which a user interacts
with IS, including both software and hardware
Common interaction methods

Command-line
Menu
Form
Object-based (GUI)
Natural language (speech-recognition)
Multitouch and wearable
Augmented reality
Gesture-recognition
Holographic

9-37

Command-line Interaction

Users enter explicit statements into a system

to invoke operations
Includes keyboard shortcuts and function keys
Command Prompt

Mainframe look and feel

9-38

Menu Interaction

A list of system options is provided and specific

command is invoked by user selection of a menu
option
Two common menu types:

Pop-up: menu placed near current cursor position,

also called a dialog box
Example: Print dialog box

launched when you select File menu | Print

Drop-down: access point to menu placed at top line of

display, menu drops down when access point clicked
Menus (e.g. File menu, etc.)
Right-mouse click

9-39

E.g. of One Menu Configuration

Drop-down menu

9-40

Form Interaction

Allows users to fill in the blanks when working with a

system
Commonly used method for data entry and retrieval
in business-based systems
Measures of an effective design:

Self-explanatory title and field headings

Fields organized into logical groupings
Distinctive boundaries
Default values
Displays appropriate field lengths
Minimizes the need to scroll windows

9-41

9-42

Object Interaction (GUI)

Symbols are used to represent commands or

functions
Hallmark of graphical user interface (GUI)
Icons:

Graphic symbols that look like the processing

option they are meant to represent
Use little screen space
Can be easily understood by users

9-43

Natural Language Interaction

Inputs to and outputs from system are in a

conventional speaking language like English
Based on research in artificial intelligence

Speech-recognition

Dragon Systems Naturally Speaking

Transcriptions from natural speech, i.e. no pauses between

spoken words
http://www.nuance.com/naturallyspeaking/

Siri (virtual personal assistant) in iPhone

9-44

Other Types of Interfaces

Multitouch

Pinch, pan, swipe across screen with fingers

Write and draw on the screen
iPhone and iPad

Wearable interface

OmniTouch
Demo (1st minute):

http://www.youtube.com/watch?v=Pz17lbjOFn8

Augmented reality

Superimposes or adds another layer of info on a

user's existing view of the real world
Google glasses

http://www.youtube.com/watch?v=9c6W4CCU9M4&feature=player_embedded
9-45

Other Types of Interfaces

Gesture-recognition

Facilitates natural interactions with humans without

mechanical devices and follows commands based
on gestures and body movements
Kinect for Xbox
Demo: http://www.youtube.com/watch?v=p2qlHoxPioM

Holographic

Microsoft HoloLens
https://www.youtube.com/watch?v=Qm2gnnyyvEg

9-46

What is a Dialogue Sequencing?

A sequence of interactions between the

system and a user
Modality

Require user to finish action before proceeding

(e.g. cancel or save before closing a window)

Dialogue design involves

Designing a dialogue sequence

Building a prototype
Assessing usability
Usability includes user-friendliness of a system and

how well it responds to and meets user needs

9-47

Dialogue Diagramming
A formal method for designing and representing humancomputer dialogues using box and line diagrams

9-48

Dialogue
diagrams
depict the
sequence,
selection
(conditional
branching),
and iteration
(repetition of
dialogues).

9-49

Dialogue Diagram for

the Customer
Information System

9-50

Design
in
Action
Googles homepage

Plain white background? (Marissa Mayer, 19th employee)

Shades of blue
Research on testing 41 gradations or shades of blue for links
Why? Clicks = revenue stream!

Apple

iMac: why unique in 1998?

Industrial design/er
Jonathan Jonny Ive
Principal designer of iMac, iBook, iPod, iPhone, iPad, etc.

Influenced by German industrial designer, Dieter Rams

(associated with Braun consumer products)
Documentary Objectified: Rams sees Apple following his

9-51

design principles; Ive speaks about product design

Demo: http://www.objectifiedfilm.com/objectified-trailer/

Modern Systems Analysis

and Design
Chapter 13
Finalizing Design
Specifications

9-53

The Process of Finalizing Design

Specifications
Less costly to correct and detect errors
during the design phase
Two sets of guidelines:

The quality requirements statements

The quality requirements themselves

Deliverable

9-54

A set of design specifications for the entire

system, with detailed functional
descriptions of each system component

Example of a Poorly Written

Requirements Statement

The product shall provide status messages at

regular intervals not less than every 60
seconds.

Ambiguous?
What is the product?
Information about the timing of the messages is not
clear.
Requirement itself is incomplete
Description lacks information necessary for the

9-55

developer to convert this specification into a working

system feature.

Revised Example of Requirements

Statement contd

1. Status Messages

The Background Task Manager shall display status

messages in a designated area of the user interface at
intervals of 60 plus or minus 10 seconds.
2.
If the background processing is progressing normally, the
percentage of the background task processing that has
been completed shall be displayed.
3.
A message shall be displayed when the background task
in completed.
4.
An error message shall be displayed if the background
task has stalled.
Example: download message (online)
1.

9-56

Characteristics of Quality
Requirement Statements
Correct
accurately describe functionality to develop
Feasible
possible within time and resource constraints
Necessary
something the users really need
Prioritized: ranked based on level of importance
Unambiguous: clear to anyone who reads the description
Verifiable: possible to determine if requirement has been
met
9-57

Design Specification Document contains

Overall system description

Functions, operating environment, types of users,

constraints, assumptions and dependencies

Interface requirements

User/hardware/software/communication interfaces

System features

Feature 1 description, Feature n description

Nonfunctional requirements

Performance, safety, security, software quality,

business rules

Other requirements
9-58
Supporting
diagrams and models

Methods for Representing Design

Specifications

Specification document (next)

Prototyping

Evolutionary prototyping
Throwaway prototyping

Rapid application development

Agile methodologies

eXtreme Programming (XP)

9-59

Computer-based requirements management

tools make it easier to keep requirements
documents up to date, add additional
requirements and link related requirements
9-60

DOORS Enterprise Requirements Suite

Prototyping
Prototyping is the construction of a model of a system
Practice is borrowed from engineering, whereby there
is construction of scale models of objects to be built
Prototyping allows developers and users to test
certain aspects of the overall design, checking
functionality, appearance, and usability

Iterative process

Two kinds
Evolutionary prototyping: iterations result in refinements
and changes based on design tests of model; prototype
then serves as the basis for the production system itself
Throwaway prototyping: prototype serves only as a
model, which is used as a reference for the construction of
the actual system and is then discarded after it has been
used
9-61

Evolutionary Prototyping
Begin by modeling parts of the target system.
If successful, evolve remaining system from prototype.
Prototype becomes actual production system.
Often, difficult parts of the system are prototyped first.
Exception handling must be added to prototype.
Prototypes only handle typical cases so exceptional
cases have to added to the prototype as it is converted
to the production system

9-62

Throwaway Prototyping

Prototype is not preserved. It is developed quickly to

demonstrate unclear aspect of system design.
9-63
CASE tools aid in this approach.

Rapid Application Development (RAD)

Methodology to decrease design and implementation
time
Rapid = IS developed in as little as one quarter of the
usual time, resulting in cost savings
Involves: prototyping, JAD, CASE tools, and code
generators (which may be part of a CASE tool)
Heavy iteration between design (where requirements
are captured) and construction (where the system is
designed and built)
Developers and customers work together to define
requirements during the design phase, and customers
are also involved in the construction effort.
9-64

Agile Methodologies
Requirements functional design code
Design specifications come from code instead
of verbal text descriptions
e.g. eXtreme Programming

Pair programming
Teams of two programmers who continuously code and

test

Two techniques:
Simple design: uncomplicated program component
to solve current (not anticipated) problem
Refactoring: make a program simpler after new
features have been added (since additional features
complicate the existing system and its code)
9-65

Factors Distinguishing Agile and

Traditional System Development
Agile

Traditional

Size

Smaller

Larger

Criticality

Better for low

critical

Better for highly

critical

Dynamism

High dynamism

High stability

Personnel

Experts needed
throughout

Experts only
needed earlier

Culture

High degree of
freedom

Well-established
procedures

9-66

Modern Systems Analysis

and Design
Chapter 15
System Implementation

9-68

Purpose of System Implementation

To convert final physical system specifications
into working and reliable software
To document work that has been done
To provide help for current and future users
Six major activities:

9-69

Coding
Testing
Installation
Documentation
Training
Support

The Process of Coding, Testing and

Installation
Coding

Physical design specifications are turned into

working computer code.

Testing

Tests are performed using various strategies.

Testing can be performed in parallel with coding.

Installation

The current system is replaced by the new

system.

9-70

Software Application Testing

A master test plan is developed during the
analysis phase.
During the design phase, unit, system and
integration test plans are developed.

Unit testing: each module is tested alone in an

attempt to discover any errors in its code.
Integration testing: testing all modules in program
Modules are typically integrated in a top-down,

incremental fashion

System testing: testing all programs in a system

Test cases
9-71

User Acceptance Testing

Actual users test a completed information

system.
End result is the users final acceptance of the
system.
Alpha testing

Uses simulated data

Beta testing

Uses real data in real user environment

9-72

Types of Alpha Tests

Recovery testing

Forces software (or environment) to fail in order to verify that

recovery is properly performed

Security testing

Verifies that protection mechanisms built into the system will

protect it from improper penetration

Stress testing

Tries to break the system

Example writing incomplete records to a a database or
having extreme online transaction loads/high concurrent
users

Performance testing

Determines how the system performs on the range of

possible environments in which it may be used, such as
different hardware configurations, networks, operating
systems, etc.

9-73

Installation

The organizational process of changing over from

the current information system to a new one
Four installation strategies:

17.74
9-74

Direct Installation
Parallel Installation
Single-location installation (or pilot)
Phased Installation

Turning off the old system when the new one is turned on
9-75

Running the old and new information systems at the same

time until management decides the old system can be turned
off
9-76

or pilot installation

Trying out an information system at one site, then deciding if

and how the new system should be deployed throughout the
organization. Also known as location or pilot installation.
9-77

Changing from the old information system to the new one

incrementally, starting with one or a few functional
components and then gradually extending the installation to
9-78
cover
the whole new system. a.k.a staged installation.

Documenting the System

System documentation

Detailed information about a systems design

specifications, its internal workings and its
functionality
Intended audience: maintenance programmers

User Documentation

Written or other visual information about an

application system, how it works, and how to use it

9-79

9-80

User documentation is typically in the form of online help

Training Information Systems Users

Training users

9-81

By far
9-82the most common training method is informal, via
interaction with an in-house expert on the software

Supporting Information Systems Users

Support is extremely important to users,
e.g.

User questions and problems

Recovery and backup
PC maintenance

Help desk
One approach is through automation

9-83

Internet-based online support forums

Voice response systems
Knowledge bases

Project Close-Down
Evaluate team

Reassign members to other projects

Notify all affected parties that the

development project is ending and that
you are switching to operation and
maintenance mode
Conduct post project reviews
Close out customer contract

9-84

Formal signoff

Modern Systems Analysis

and Design
Chapter 16
Maintaining Information
Systems

9-86

The Process of Maintaining

Information Systems
Process of returning to the beginning of the
SDLC and repeating development steps
focusing on system change until the change is
implemented
Maintenance is the longest phase in the SDLC
Four major activities:

9-87

Obtaining maintenance requests

Transforming requests into changes
Designing changes
Implementing changes

Maintenance is like a mini-SDLC

9-88

4 Types of System Maintenance

4 types of system maintenance

Corrective, adaptive, perfective, and preventive

Corrective maintenance

Changes made to a system to repair flaws in its design,

coding, or implementation
e.g. diagnose and fix logic errors; replace defective
network cable; restore proper configuration settings; debug
program code; update drivers; install software patch

Adaptive maintenance

Changes made to a system to evolve its functionality to

changing business needs or technologies
e.g. add online capability; create new reports; add new
data entry field to input screen; install links to web site;
create employee portal

9-89

4 Types of Sys. Main. contd

Perfective maintenance

Changes made to a system to add new features or to

improve performance
e.g. install additional memory; write macros to handle
repetitive tasks; compress system files; optimize user
desktop settings; develop library for code reuse; install
more powerful network server

Preventive maintenance

Changes made to a system to avoid possible future

problems
e.g. install new antivirus software; develop standard
backup schedule; implement regular defragmentation
process; analyze problem report for patterns; tighten all
cable connections

9-90

By far, most maintenance is corrective, and therefore urgent

and non-value adding.
9-91

Maintenance Tasks

Backup procedures
Monitor system performance
Identify and solve problems
Update software and hardware to meet
changing needs
etc.

9-92

The Cost of Maintenance

Many organizations allocate eighty
percent of information systems budget
to maintenance

9-93

Conducting System Maintenance

Managing Maintenance
Number of people working in maintenance has
surpassed number working in development.
Three possible organizational structures:

Separate
Maintenance group consists of different personnel than
development group.
Combined
Developers also maintain systems.
Functional
Maintenance personnel work within the functional
business unit.

9-94

Advantages and Disadvantages

Maintenance
Organization
Type

Advantages

Disadvantages

Separate

Improved system
Ignorance of critical
and documentation undocumented
quality
information

Combined

Maintenance group Less emphasis on

knows all about
good documentation
system

Functional

Personnel have
vested interest

9-95

Limited job mobility

and human or
technical resources

Assignment of Maintenance Personnel

Maintenance work is often viewed negatively
by IS personnel.
Organizations have historically have
rewarded people involved in new
development better than maintenance
personnel.
Organizations often rotate personnel in and
out of maintenance roles in order to lessen
negative feelings about maintenance.
9-96

Conducting System Maintenance

Measures of Effectiveness
Important factors to consider

Number of failures
Time between each failure
Type of failure

Mean time between failures (MTBF)

9-97

A measurement of error occurrences that can be

tracked over time to indicate the quality of a
system
The MTBF metric shows the average length of
time between the identification of one system
failure and the next.

Expect lots of failures early,

but as corrective
maintenance takes place,
error rate should decrease
rapidly

9-98

Configuration Management
The process of assuring that only authorized
changes are made to the system
Baseline modules

Software modules that have been tested,

documented, and approved to be included in the
most recently created version of a system

System librarian

A person responsible for controlling the checking

out and checking in of baseline modules when a
system is being developed or maintained

9-99