System Analysis and Design

CSE 307
Instructor: Sabrina Alam

Lecture 02
Understanding and Modeling
Organizational Systems
Learning Objectives
 Understand that organizations and their members are
systems and that analysts need to take a systems
perspective.
 Depict systems graphically using context-level data
flow diagrams, and entity-relationship models, use
cases, and use case scenarios.
 Recognize that different levels of management require
different systems.
 Comprehend that organizational culture impacts the
design of information systems.
Three Main Forces Interacting to Shape
Organizations

 Levels of management
 Design of organizations
 Organizational cultures
Organizations Are Composed of
Interrelated Subsystems
 Influenced by levels of management decision
makers that cut horizontally across the
organizational system
 Operations
 Middle management
 Strategic management
 Influenced by organizational cultures and
subcultures
Major Topics
 Organizations as systems
 Depicting systems graphically
 Data flow diagram
 Entity-relationship model
 Use case modeling
 Levels of management
 Organizational culture

2-5
Organizations as Systems
 Conceptualized as systems designed to
accomplish predetermined goals and
objectives
 Composed of smaller, interrelated systems
serving specialized functions
 Specialized functions are reintegrated to form
an effective organizational whole
Interrelatedness and Independence
of Systems
 All systems and subsystems are interrelated and
interdependent
 All systems process inputs from their environments
 All systems are contained by boundaries separating
them from their environments
 System feedback for planning and control
 An ideal system self-corrects or self-regulates itself.
System Outputs Serve as Feedback that
Compares Performance with Goals (Figure 2.1)
Organizational Environments
 Community
 Physical location
 Demographic profile (education, income)
 Economic
 Market factors
 Competition
 Political
 State and local government
 Legal
 Federal, state, regional, local laws, and guidelines
Openness and Closedness
 Open
 Free flow of information
 Output from one system becomes input to another
 Closed
 Restricted access to information
 Limited by numerous rules
 Information only on a “need to know” basis
Virtual Organizations and Virtual
Teams
 A virtual organization has parts of the
organization in different physical locations
 Computer networks and communications
technology are used to bring virtual teams
together to work on projects
Benefits of Virtual Organizations and
Teams
 Possibility of reducing costs of physical
facilities
 More rapid response to customer needs
 Helping virtual employees to fulfill their
familial obligations to children or aging
parents
Taking a Systems Perspective
 Allows system analyst to understand
businesses before they begin their tasks
 It is important that members of subsystems
realize that they are interrelated with other
subsystems
 Problems occur when each manager thinks that
his/her department is the most important
 Bigger problems may occur when that manager
rises through the ranks
Taking a Systems Perspective
(Figure 2.2)
Outputs from one
department serve as
inputs for another such
that subsystems are
interrelated.
Perspective of Functional
Managers (Figure 2.3)
Enterprise Resource Planning
 Enterprise Systems or Enterprise Resource
Planning (ERP) describes an integrated
organizational information system
 Software that helps the flow of information
between the functional areas within the
organization
Enterprise Resource Planning
 ERP systems include:
• manufacturing components
• sales and operations planning

• distribution

• managing the supply chain

ERP and the Organization
 ERP can affect every aspect of the
organization, including:
 Design of employees’ work
 Skills required for job competency
 Strategic positioning of the company
Issues to be Overcome for ERP
Success
 Many issues must be overcome for the ERP
installation is to be declared a success:
 User acceptance
 Integration with legacy systems and the supply
chain
 Upgrading functionality (and complexity) of ERP
modules
 Reorganizing work life of users and decision
makers
 Expanded reach across several organizations
 Strategic repositioning of the company
Depicting Systems Graphically
 Context-level data flow diagrams
 Entity-relationship model
 Use case modeling
Context-Level Data Flow
Diagrams
 Focus is on the data flowing into and out of
the system and the processing of the data
 Shows the scope of the system:
 What is to be included in the system
 The external entities are outside the scope of the
system
The Basic Symbols of a Data Flow
Diagram (Figure 2.4)
Airline Reservation System
(Figure 2.5)

A context-level data
flow diagram
for an airline
reservation system
Entity-Relationship Model
 Focus is on the entities and their relationships
within the organizational system
 Another way to show the scope of a system
Relationships
 Relationships show how the entities are
connected
 Three types of relationships:
 One-to-one
 One-to-many
 Many-to-many
Entity-Relationship Example
(Figure 2.7)

An entity-
relationship
diagram
showing a many-
to-one
relationship
Examples of Different Types of
Relationships in E-R Diagrams (Figure 2.8)
Entities
 Fundamental entity
 Associative entity
 Attributive entity
Three Different Types of Entities Used in
E-R Diagrams (Figure 2.9)
Attributes
 Data attributes may be added to the diagram.

Patron Name
Patron Patron address
Patron phone
Patron credit card
Creating Entity-Relationship
Diagrams
 List the entities in the organization
 Choose key entities to narrow the scope of
the problem
 Identify what the primary entity should be
 Confirm the results of the above through data
gathering
A More Complete E-R Diagram Showing Data
Attributes of the Entities (Figure 2.12 )
Use Case Modeling
 Describes what a system does without
describing how the system does
 A logical model of the system
 Use case is a view of the system requirements
 Analyst works with business experts to
develop requirements
Use Case Diagram
 Actor
 Refers to a particular role of a user of the system
 Similar to external entities; they exist outside of the
system
 Use case symbols
 An oval indicating the task of the use case
 Connecting lines
 Arrows and lines used to diagram behavioral
relationships
Actor
 Divided into two groups
 Primary actors:
 Supply data or receive information from the system
 Provide details on what the use case should do

 Supporting actors:
 Help to keep the system running or provide help
 The people who run the help desk, the analysts,
programmers, and so on
A Use Case Always Provides
Three Things
 An actor that initiates an event
 The event that triggers a use case
 The use case that performs the actions
triggered by the event
Use Case Relations
 Behavioral relationships
 Communicates
 Used to connect an actor to a use case
 Includes
 Describesthe situation in which a use
case contains behavior that is common to
more than one use case
Use Case Relations
 Behavioral relationships (continued)
 Extends
 Describesthe situation in which one use
case possesses the behavior that allows
the new case to handle a variation or
exception from the basic use case
 Generalizes
 Impliesthat one thing is more typical
than the other thing
Four Types Of Behavioral Relationships And The
Lines Used To Diagram Each
(Figure 2.13)
Some components of use case diagrams showing actors,
use cases, and relationships for a student enrollment
example (Figure 2.14)
Scope
 System scope defines its boundaries:
 What is in or outside the system
 Project has a budget that helps to define scope
 Project has a start and an end time
 Actors are always outside of scope
 Communication lines are the boundaries and
define the scope
Developing Use Case Diagrams
 Review the business specifications and identify the
actors involved
 May use agile stories
 Identify the high-level events and develop the primary
use cases that describe those events and how the actors
initiate them
 Review each primary use case to determine the
possible variations of flow through the use case
 The context-level data flow diagram could act as a
starting point for creating a use case
A Use Case Diagram Representing a System
Used to Plan a Conference (Figure 2.15 )
Developing the Use Case Scenarios
 The description of the use case
 Three main areas:
 Use case identifiers and initiators
 Steps performed
 Conditions, assumptions, and questions
A Use Case
Use case Scenario
name: Register Is Divided into Three Sections
for Conference UniqueID: Conf (Figure
RG 003 2.16)
Area: Conference Planning

Actor(s): Participant
Stakeholder Conference Sponsor, Conference Speakers
Level Blue

Description: Allow conference participant to register online for the conference using a secure Web site.
Triggering Event: Participant uses Conference Registration Web site, enters userID and password, and clicks the
logon button.
Trigger type:  External  Temporal
Steps Performed (Main Path) Information for Steps

1. Participant logs in using the secure Web server userID, Password

More steps included here…

12. Successful Registration Confirmation Web page is sent to the Registration Record Confirmation
participant Number

Preconditions: Participant has already registered and has created a user account.
Postconditions: Participant has successfully registered for the conference.
Assumptions: Participant has a browser and a valid userID and password.
Success Guarantee: Participant has registered for the conference and is enrolled in all selected
sessions.

Minimum Guarantee: Participant was able to logon.

Requirements Met: Allow conference participants to be able to register for the conference using a
secure Web site.
Outstanding Issues: How should a rejected credit card be handled?

Priority: High
Risk: Medium
Use Case Header Area
 Has a name and a unique ID
 Include application area
 List actors
 Include stakeholders
 Include the level
 Has a brief description of the use case
Alternative Scenarios

 Extensions or exceptions to the main use case

 Number with an integer, decimal point, integer
 Steps that may or may not always be used
Use Case Footer Area
 Preconditions—need to be met before use case
can be performed
 Postconditions or the state of the system after
the use case has finished
 Assumptions
 Minimal guarantee
 Success guarantee
 Outstanding issues
 Optional priority and risk
Four Steps Used to Create Use Cases
 Use agile stories, problem definition
objectives, user requirements, or a features
list
 Ask about the tasks that must be done
 Determine if there are any iterative or looping
actions
 The use case ends when the customer goal is
complete
Why Use Case Diagrams Are Helpful
 Identify all the actors in the problem domain
 Actions that need to be completed are also
clearly shown on the use case diagram
 The use case scenario is also worthwhile
 Simplicity and lack of technical detail
The Main Reasons for Writing Use Cases Are Their
Effectiveness in Communicating with Users and Their
Capturing of User Stories (Figure 2.18)
Management in Organizations Exists on Three Horizontal Levels:
Operational Control, Managerial Planning and Control, and Strategic
Management (Figure 2.19)
Operations Control
 Make decisions using predetermined rules
that have predictable outcomes
 Oversee the operating details of the
organization
Managerial Planning and Control
 Make short-term planning and control
decisions about resources and organizational
objectives
 Decisions may be partly operational and
partly strategic
Strategic Management
 Look outward from the organization to the
future
 Make decisions that will guide middle and
operations managers
 Work in highly uncertain decision-making
environment
 Define the organization as a whole
Managerial Levels
 Different organization structure
 Leadership style
 Technological considerations
 Organization culture
 Human interaction
 All carry implications for the analysis and
design of information systems
Organizational Culture
 Organizations have cultures and subcultures
 Learn from verbal and nonverbal symbolism
Verbal Symbolism
 Myths
 Metaphors
 Visions
 Humor
Nonverbal Symbolism
 Shared artifacts
 Trophies, etc.
 Rites and rituals
 Promotions
 Birthdays, etc.
 Clothing worn
 Office placement and decorations
Summary
 Organizational fundamentals
 Organizations as systems
 Levels of management
 Organizational culture
 Graphical representation of systems
 DFD
 ERD
 Use case diagrams and scenarios
Summary (continued)
 Levels of managerial control
 Operational
 Middle management
 Strategic
 Organizational culture
Copyright © 2014 Pearson Education, Inc.  
Publishing as Prentice Hall

1-62
 End of
Lecture 02

04/24/21 63