SEG3560 Introduction to
E-Commerce
Tutorial 3 – System Analysis & Design
GAO Wei, Rm711, ERBII, Email:[email protected]
Outline
• Overview of SDLC
– project phases
• Process Modeling
– context diagram, data flow diagrams
• Architecture Design
– tiered architectures, nonfunctional
requirements
PART I: Overview of SDLC
Key Ideas
• Many failed systems were abandoned because
analysts tried to build wonderful systems without
understanding the organization.
• The primary goal is to create value for the
organization.
• The systems analyst is a key person analyzing
the business, identifying opportunities for
improvement, and designing information systems
to implement these ideas.
• It is important to understand and develop through
practice the skills needed to successfully design
and implement new information systems.
The Systems Development Life
Cycle (SDLC)
• The project --
– Moves systematically through phases where each phase has a
standard set of outputs
– Produces project deliverables
– Uses deliverables in implementation
– Results in actual information system
– Uses gradual refinement
• Project phases:
– Planning (Why build the system? How should the team go about
building it?)
– Analysis (Who uses system, what will it do, where and when will
the system be used?)
– Design (How will the system work?)
– Implementation (System delivery)
Planning
• Identifying business value
– Gain an appropriate understanding of the business problem domain
– Estimate the investment and reward on the project
– e.g. the percentage of cost reduction paid in warehousing
• Analyze feasibility
– Technical, economical and organizational
– Analyzes the information needs of the end users
– e.g. co-ordination among sales, warehouse keeper, merchandiser
or more parties
• Develop work plan
– Decide the sequence of process completion
– PERT Chart
• Staff the project
• Control and direct project
– Prioritize - requirements can be classified as ‘mandatory’, ‘desirable’,
or ‘optional’.
Analysis
• Analysis strategy
– As-is system and to-be system
– Iterative cycle of steps until they are considered accurate and complete
– e.g. integration of old and future system
• Gathering business requirements
• Requirements definition use cases
– Specify these requirements without expressing computer alternatives and
technology details; at this point, keep analysis at the business level.
• Process modeling
– Representing how business operates
– Data flow diagram (DFD)
– e.g. Data flow for the login system
• Data modeling
– Balance with process models
– Entity-Relationship Diagram (ER diagram)
– e.g. Relationship between attributes for warehouse keeper and
merchandiser
Design
• Design selection
– transform the business requirements from the definition phase into
a set of technical design blueprints for construction
– e.g. Microsoft .NET framework or J2EE
• Architecture design
– specifications for the hardware, software, network infrastructure
and data resources
– detailed structure for N-tiers system
• Interface design
– specifies how the users will move through the system,
navigation methods (menus, buttons, etc.), forms, reports.
• Data storage design
– defines what and how data will be stored. RDBMS, XML, raw text
file, etc.
• Program design
– defines programs to be written, what each program will do.
Implementation
• Construction
– Program building
• creates and programs the final system
– Program and system testing
• evaluates the system's actual functionality in relation to
expected or intended functionality
• Done systematically and results documented carefully
• Avoid patches delivery after software release
• Installation
– Conversion strategy
• Direct, parallel or pilot conversion
– Training plan
• Helping users accomplish their tasks
– Support plan
• On-demand training , online support or helpdesk
Processes and Deliverables
Process Product
System Request
Planning
Feasibility Analysis
Workplan
System Proposal
Analysis
System
Specification
Design
New System and
Implementation
Maintenance Plan
Waterfall Development
Methodology
Pros and Cons of the
Waterfall Methodology
Pros Cons
Identifies systems Design must be
requirements long specified on paper
before programming before programming
begins begins
Minimizes changes to
Long time between
requirements as
system proposal and
project progresses
delivery of new
system
Parallel Development
Methodology
Pros and Cons of Parallel
Development Methodology
Pros Cons
Reduces Schedule Still Uses Paper
Time Documents
Less Chance of Sub-projects May Be
Rework Difficult to Integrate
Phased Development Methodology
Pros and Cons of Phased
Development Methodology
Pros Cons
Users Get a System
To Use Quickly Users Work with a
System that is
Intentionally
Users Can Identify
Incomplete
Additional Needs
For Later Versions
Prototyping Methodology
Pros and Cons of Prototyping
Methodology
Pros Cons
Users Interact with Tendency to do
Prototype Very Quickly Superficial Analysis
Users Can Identify Initial Design
Needed Changes Decisions May
And Refine Real Be Poor
Requirements
Throwaway Prototyping
Pros and Cons of Throwaway
Prototyping Methodology
Pros Cons
May Take Longer
Risks are Minimized
Than Prototyping
Important Issues are
Understood Before the
Real System is Built
Agile Development: Extreme
Programming
Pros and Cons of Agile
Methodologies
Pros Cons
Fast Delivery of Results Requires Discipline
Works Best in
Works Well in Projects Small Projects
With Undefined or
Changing Requirements Requires Much
User Input
PART II: Process Modeling
Process Modeling
• 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 diagram (DFD)
– A popular technique for creating process models
– Logical process models describe processes without
suggesting how they are conducted (You need to do
in project phase 1!)
– Physical process models include process
implementation information
Reading a DFD
External
entity
Data flow
Data store
Process
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
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.
Naming and Drawing DFD
Elements
Process
Data flow
Data store
External
entity
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
• Balancing involves insuring that information
presented at one level of a DFD is accurately
represented in the next level DFD.
Relationship Among DFD levels
Context diagram
Level 0 diagram
Level 1 diagram
Level 2 diagram
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
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
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
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
Example: Problem Description
• When a student wants to enroll in a course, he makes a class
request to the enrollment department. There are 3 officers in the
enrollment department. After receiving the request, one officer enroll
the student in the course (details of enrollment are described in the
next paragraph) and store the student and course data into a
student-class file. Another one is responsible for collecting student
fee payment, issuing receipts and handling payment information of a
student payments file. There is one more officer producing different
reports to different people. He will produce a student schedule to the
student who has been enrolled in a course, produce a class roster to
the corresponding professor, and produce enrollment statistics to
register.
• After a student has raised a request, the officer needs to check for an
open section from a classes offered file. If a section is available, he
will check prerequisites of the student by referring the student master
file and course master file. After this checking is completed, he helps
the student enrolling in the course by updating the classes offered
file and the student class file.
Context Diagram
Student
Student Schedule / Class Request /
Receipt Payment
Class Course Enrollment
Roster Enrollment Statistics
Professor System Registrar
Level 0: The course enrollment system
Class 1.0
Request Enroll
Student Student
Student
in Class
Payment
Student
Receipt Student and
Schedule
Course Data
Student Student
2.0 3.0
Class Class
Collect Produce
Student Class Record
Student Fee Record Student
Payement Record
Schedule
Student
Class
Payment Record
Information Student 5.0
4.0 Class Produce
Student Produce Record Enrollment
Payments Class Summary
Roster Report
Class Enrollment
Roster Statistics
Professor Registrar
Level 1: Process 1.0 -- Enroll student in
class
Classes Student
Student
Offered Class Record
Class Openings
Request Remaining
Student
Openings Course
Remaining Record
1.1 1.3
Check for Enroll
an open student
section in class
Open Class
Request Valid
Class Request
Student 1.2 Course
Student Record Check Record Course
Master Pre-requisites Master
met
PART III: Architecture Design
Architecture Design -- Key
Definitions
• Architecture design
– Plans for how the system will be distributed
across computers and what the hardware and
software will be used for each computer
• Hardware and software specification
– Describes the hardware/software components
in detail to aid those responsible for
purchasing those products.
Architectural Components
(Functions) of Software
• Data storage
• Data access logic
– Processing required to access stored data
• Application logic
– Processing logic of the application
• Presentation logic
– Information display and user command
processing
Architectural Design Purpose
• Determine what parts of the application software will be
assigned to what hardware.
• Hardware options:
– Clients
• Input/output devices employed by users
• PCs, laptops, handheld devices, cell phones
– Servers
• Larger computers storing software
• Accessible by many users
– Alternative Servers
• Mainframe
• Minicomputer
• Microcomputer (personal computer)
– Alternative Clients
• Terminals
• Microcomputer (personal computer)
• Special purpose terminals (ATMs, Palm Pilots, and many others)
Architecture Choices
• Server-based Architecture
• Client-based Architecture
• Client-server based Architecture
Server-Based Architecture
Client-Based Architecture
Two-Tiered Client-Server Architecture
(Thick Client-Server)
Client-Server Attributes
• Benefits • Limitations
– Scalable – Complexity
– Works with multiple – New programming
vendors/products languages and
through middleware techniques (adds
– Improved modularity stress for personnel)
of web-based – More complex to
systems update
– No central point of
failure
Three-Tiered Client-Server Architecture
(Thin Client-Server)
Four-Tiered Client-Server
Architecture
N-Tiered versus 2-Tiered
Client-Server Architectures
• Benefits • Limitations
– Separates processing – Greater load on the
to better balance load network
on different servers – More difficult to
– More scalable program and test
Selecting an Architecture Design
• Lower costs often used to justify choice of
client-server
• Recommended selection process:
– Expand nonfunctional requirement details
– Base architecture selection on the detailed
nonfunctional requirements
Operational Requirements
Requirement Definition Example
Technical Special hardware, software, Always-on network
Environment and network requirements connection permitting real-
imposed by business time database updates
requirements
System The extent to which the The system will read and
Integration system will operate with write to the main inventory
other systems database
Portability The extent to which the The system may need to
system will need to operate operate with handheld
in other environments devices
Maintainability Expected business changes The system must
to which the system should accommodate new
be able to adapt manufacturing plants
Performance Requirements
Requirement Definition Example
Speed Time within which the system Network transaction
must perform its function response time <= 7
seconds
Capacity Total and peak number of users Maximum of 100-200
and the volume of data expected simultaneous users at
peak times
Availability and Extent to which the system will 99% uptime performance
Reliability be available to the users and the
permissible failure rate due to
errors
Security Requirements
Requirement Definition Example
System Value Estimated business value of A complete loss of all
Estimates the system and its data system data would cost $20
million
Access Control Limitations on who can Inventory changes can be
access what data made only by department
managers
Encryption and Defines what data will be Data will be encrypted from
Authentication encrypted where and the user’s computer to the
whether authentication will Web site to provide secure
be needed for user access ordering
Virus Control Controls to limit viruses All uploaded files will be
checked for viruses before
being saved in the system
Cultural/Political Requirements
Requirement Definition Example
Multilingual The language(s) the The system will operate in
system users will need English, French, and Spanish
Customization Specification of what Country managers will be able to
aspects of the system define new fields in the product
can be changed by local database to capture country-
users specific information
Making Explicitly stating All weights will be stated in
Unstated assumptions that differ kilograms
Norms Explicit from country to country
Legal The laws and regulations Personal customer information
that impose system cannot be transferred from
requirements European Union countries to US
Nonfunctional Requirements
and the Architecture Design
References
• Systems Analysis and Design, 2nd Edition
by Alan Dennis and Barbara Haley Wixom,
published by John Wiley's & Sons Inc.,
2003. Ch1,5,9.
• System Analysis and Design Methods, 6th
Edition
by Jeffrey L. Whitten, Lonnie D. Bentley
and Kevin Dittman, published by Irwin
McGraw-Hill.
