Transcript Document 7154223

C H A P T E R
5
SYSTEMS ANALYSIS
1
Chapter Five Systems Analysis
 Define systems analysis and relate the term to the scope definition,
problem analysis, requirements analysis, logical design, and decision
analysis phases of this book’s systems development methodology.
 Describe a number of systems analysis approaches for solving business
system problems.
 Describe the scope definition, problem analysis, requirements analysis,
logical design, and decision analysis phases in terms of your information
system building blocks.
 Describe the scope definition, problem analysis, requirements analysis,
logical design, and decision analysis phases in terms of purpose,
participants, inputs, outputs, techniques, and steps.
 Identify those chapters and modules in this textbook that can help you
learn specific systems analysis tools and techniques.
2
Chapter Map
3
Systems Analysis
Overview
 Systems Analysis vs. Systems Design
 Systems Analysis Approaches
 Systems Analysis Phases (purposes, participants, inputs,
outputs, techniques, and steps)
–
–
–
–
–
Scope Definition
Problem Analysis
Requirements Analysis
Logical Design
Decision Analysis
 User Requirements Discovery
4
Systems Analysis vs.
Systems Design
Systems analysis: a problem-solving technique that
decomposes a system into its component pieces for the
purpose of studying how well those component parts work
and interact to accomplish their purpose.
 Describe the early stages (next slide) of systems development (25%
of project time)
 Decomposition and hierarchy chart for abstraction
Systems design: a complementary problem-solving technique
to systems analysis that reassembles a system’s component
pieces back into a complete system
5
Context of System
Analysis
6
Model-Driven Analysis
Use model-driven methodology (strategy or approach)
Model-driven analysis emphasizes the drawing of
graphical system models to document and validate both
existing and/or proposed systems.
 Ultimately, the system model becomes the blueprint for
designing and constructing a system.
7
Model-Driven
Structured analysis (methodology): a model-driven,
PROCESS-centered technique to analyze an existing system
and define business requirements for a new system.
The models illustrate the system’s components: processes
(functions, tasks) and their associated inputs, outputs, and
files.
Data Flow Diagram (DFD)
8
A Simple Process Model
9
Model-Driven
Information engineering (IE) (methodology): a modeldriven and DATA-centered, but process-sensitive (context
specific) technique to plan, analyze, and design information
systems.
IE illustrate and synchronize the system’s data and
processes.
Entity-Relationship Diagram (ERD)
10
A Simple Data Model
11
Model-Driven
Object-oriented analysis (OOA) (methodology): a modeldriven technique that integrates data and process concerns
into constructs called OBJECTS.
OOA illustrate the system’s objects from various
perspectives such as structure and behavior.
Encapsulation Diagram of data and process in an object
Use Case Diagram was an initial methodology of OOA
12
A Simple Object Model
STUDENT
-ID Number
-Name
-Grade Point Average 0..*
COURSE
has record for>
+Admit()
+Regsiter for Classes()
+Withdraw()
+Change Address()
+Calculate GPA()
1
+Graduate()
0..*
-Subject
-Number
-Title
-Credit
+Create a Course()
+Delete1from Course Master()
+Change in Course Master()
TRANSCRIPT COURSE
-Semester
-Division
-Grade
+Add()
+Drop()
+Complete()
+Change Grade()
13
Automated Tools and
Technology
 Computer-aided systems engineering (CASE)
 Application development environments (ADEs)
 Process and project managers
14
Computer-Aided Software
Engineering (CASE)
Computer-aided systems engineering (CASE) – the
use of automated software tools that support the drawing
and analysis of system models and associated
specifications. Some CASE tools also provide prototyping
and code generation capabilities.
 CASE repository – a system developers’ database where developers
can store system models, detailed descriptions and specifications,
and other products of system development. Synonyms include
dictionary and encyclopedia.
15
CASE Tool Architecture
16
Application Development
Environments
Application development environments (ADEs) – an
integrated software development tool that provides all
the facilities necessary to develop new application
software with maximum speed and quality (Visual
Studio.Net). A common synonym is integrated
development environment (IDE)
– ADE facilities may include (read textbook):
 Programming languages or interpreters
 Interface construction tools
 Middleware
 Testing tools
 Version control tools
 Help authoring tools
 Repository links
17
CASE tools
 Each different model can be drawn using general-purpose
graphics SW
– Sybase PowerDesigner 9.5
– Oracle Designer 2000
18
Accelerated Systems
Analysis
• Accelerated systems analysis approaches
emphasize the construction of prototypes to more
rapidly identify business and user requirements for a
new system.
 (Discovery) Prototyping
 Rapid Architected Analysis
19
(Discovery) Prototyping
(Discovery) prototyping – a technique used to identify the
users’ business requirements by having them react to a
quick-and-dirty implementation of those requirements.
– Advantages
 Prototypes cater to the “I’ll know what I want when I see it” way of
thinking that is characteristic of many users and managers.
– Disadvantages
 Can become preoccupied with final “look and feel” prematurely
 Can encourage a premature focus on, and commitment to, design
 Users can be misled to believe that the completed system can be built
rapidly using prototyping tools
20
Rapid Architected
Analysis
Rapid architected analysis (in real world: Reverse
engineering) – derive system models from existing
systems or discovery prototypes.
 Blending of model-driven and accelerated approach
 Reverse engineering – the use of technology that reads the
program code for an existing database, application program,
and/or user interface and automatically generates the equivalent
system model.
– First IBM compatible PC by Compaq
– Data modeling by reverse engineering
21
Systems Analysis Phases
 Scope Definition Phase : WHAT PROBLEM
– Is the project worth looking at ?
 Problem Analysis Phase: WHAT ISSUES
– Is the new system worth building
 Requirements Analysis Phase: WHAT REQUIREMENTS
– What do users need and want from the new system?
– Details in chapter 6
 Logical Design Phase: WHAT TO DO
– What the new system must do
 Decision Analysis Phase: WHAT SOLUTION
– What is the best available solution ?
Rest of slides are self-explanatory…..
22
1. Scope Definition Phase
 Objective
– Preliminary investigation step
– Determine the value of the project
– Create a plan to complete those projects deemed worthy
of a detailed study and analysis
 Work with systems owners and users
 Detail tasks
– see following slides…
 Deliverable
– A project charter that is approved by the steering
committee
23
1. Scope Definition Phase
24
1. Scope Definition Tasks
Next
25
1. Scope Definition
Phase
Task 1.1: Identify Problems, Opportunities, and
Directives (apply PIECES framework)
• Input: Request for System Service
• Deliverable: Problem Statement
− Urgency, Visibility, Benefits, Priority, Possible
Solutions
• primary technique: fact-finding with system users
26
Problem Statements
27
1. Scope Definition
Phase ...
Task 1.2: Negotiate Baseline Scope
•Deliverable: Statement of Project Scope (boundary of the
project)
•What types of DATA to be studied
•What business PROCESSES to be included
•How the system INTERFACE with users, locations,
and other systems
•Note: if later the scope changes, the budget and schedule
should be changed accordingly
28
1. Scope Definition
Phase …
Task 1.3: Assess Baseline Project Worthiness
•“Is this project worth looking at ?”
•Cost/benefit analysis
•Decision
•Approve project
•Cancel project
•Renegotiate the scope of project (with adjusted
budget and schedule)
29
1. Scope Definition
Phase …
Task 1.4: Develop Baseline Schedule and Budget
• Deliverables: Project Charter
• Master plan for the whole project: schedule and
resource assignments
• Detail plan and schedule for completing the next
phase
30
1. Scope Definition
Phase …
Task 1.5: Communicate the Project Plan
• Present and defend the project and plan before steering
committee
• Formally launch the project and announce the project,
goals, and schedule
• Deliverable: Project Charter (participants, problems,
scope, methodology, statement of work to be completed,
deliverables, quality standards, schedule, budget)
31
2. Problem Analysis Phase
 Objective
– Are the problems really worth solving?
– Is a new system really worth building?
 Continue to work with systems owners and users
and other IS management and staff
 Detail tasks
– See following slides…
 Deliverable
– Systems improvement objectives (next slide)
32
System Improvement
Objectives
• Objective – a measure of success. It is something
(measurable) that we expect to achieve, if given sufficient
resources.
 Reduce the number of uncollectible customer accounts by 50
percent within the next year.
 Increase by 25 percent the number of loan applications that
can be processed during an eight-hour shift.
 Decrease by 50 percent the time required to reschedule a
production lot when a workstation malfunctions.
• Constraint – something that will limit our flexibility in
defining a solution to our objectives. Essentially, constraints
cannot be changed.




The new system must be operational by April 15.
The new system cannot cost more than $350,000.
The new system must be web-enabled.
The new system must bill customers every 15 days.
33
2. Problem Analysis Phase
34
2. Problem Analysis Tasks
Next
35
2. Problem Analysis
Phase
Task 2.1: Understand the Problem Domain
•Understanding of the problem domain and business
vocabulary
•DATA: currently stored data, their business terms
•PROCESSES: current business events
•INTERFACES: current locations and users
•Deliverables: definition of system domain / models of
current systems
36
2. Problem Analysis
Phase …
Task 2.2: Analyze Problems and Opportunities
•Study causes and effects of each problem (Note: an effect
may be the cause of other problems)
•Deliverables: updated problem statements and the causeeffect analyses for each problem and opportunities (Fig
5.11)
37
2. Problem Analysis
Phase …
Task 2.3: Analyze Business Processes (for BPR)
•Measure the value added or subtracted by each process
as it relates to the total organization
•Volume of throughput, response time, bottlenecks,
cost, value added, consequences of eliminating or
streamline of the process
•Deliverable: current business process models
38
2. Problem Analysis
Phase …
Task 2.4: Establish System Improvement Objectives
•Define specific system improvement objectives and
constraints for each problem
•Objectives to be precise, measurable
•Constraints in terms of schedule, cost, technology, policy
•Deliverable: System Improvement Objectives and
Recommendations Report
39
PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX
40
2. Problem Analysis
Phase …
Task 2.5: Update or Refine the Project Plan
•Update project:
•Reduce the scope to keep only higher priority
objectives to meet a deadline/budget
•Expanse the scope and adjust schedule and budget
accordingly
•Deliverable: updated project plan
41
2. Problem Analysis
Phase …
Task 2.6: Communicate Findings and
Recommendations
•Deliverable: system improvement objectives
•Decision: continue/adjust/cancel current project
42
3. Requirements Analysis
Phase
 Objective
– Identify what the new system is to do without the
consideration of technology
 Actively work with systems owners and users and
other IS professionals
 Detail tasks
– See following slides…
 Deliverable
– Business requirements statement
43
3. Requirements
Analysis Phase
44
3. Requirements
Analysis Tasks
Next
45
3. Requirements
Analysis Phase
Task 3.1: Identify and Express System Requirements
• Functional requirements: activities and services
providing by a system: business functions, inputs,
outputs, stored data.
• Nonfunctional requirements: features, characteristics
defining a satisfactory system: performance,
documentation, budget, ease of use and learn, cost saving,
time saving, security
•Deliverable: draft functional and nonfunctional
requirements: improvement objectives and related input,
output, processes, stored data to fulfill the objectives
46
3. Requirements
Analysis Phase …
Task 3.2: Prioritize System Requirements
• Mandatory vs. desirable requirements
• Time boxing: deliver the system in a set of subsequent
versions in a time frame. The first version satisfies
essential and highest prioritized requirements.
47
3. Requirements
Analysis Phase …
Task 3.3: Update or Refine the Project Plan
•If requirements exceed original vision: reduce the scope
or increase the budget
•Deliverable: consolidated system requirements
(completed requirements and priorities)
48
3. Requirements
Analysis Phase …
Task 3.4: Communicate the Requirements Statement
• On-going task…
49
4. Logical Design
(Modeling) Phase
Extension of Business Requirements –
DFD, ER, user interface, OD….
50
4. Logical Design Phase
51
4. Logical Design Tasks
Next
52
4. Logical Design Phase
• Task 4.1: Analyze Functional Requirements
•Logical systems models: WHAT the system must do (not
HOW)
•Separation of business concerns from technical solutions
will help considering many different ways for business
processes improvement and alternative technical solutions
•Build prototypes to establish user interface requirements
•Deliverables: Data models (ERD), Process models
(DFD), Interfaces models (Context diagram, Use case
diagram), Object models (UML diagrams) of the proposed
system.
53
4. Logical Design Phase
• Task 4.2: Validate Functional Requirements
•Completeness check, revisit, make changes and additions
to system models and prototypes to assure that
requirements are adequately defined.
•Associate nonfunctional requirements with functional
requirements
54
5. Decision Analysis Phase
 Objective
– Transition the project from business concerns to technical
identifying, analyzing, and recommending a technical
system solution.
– Borderline between business and technical system
 Work with appropriate participants
– System designers/builders, vendors, consultants….
 Detail tasks
– See following slides…
 Deliverable
– System proposal
55
5. Decision Analysis Phase
56
5. Decision Analysis Tasks
57
5. Decision Analysis
Phase
Task 5.1: Identify Candidate Solutions
•Identify all possible candidate solutions
•Deliverable: candidate systems (solutions) matrix (Fig
5.19)
58
Candidate Systems Matrix
59
Candidate Systems Matrix..
60
5. Decision Analysis
Phase …
Task 5.2: Analyze Candidate Solutions
•Feasibility analysis is performed on each individual
candidate without regard to the feasibility of other
candidates
•Technical, operational, economic, schedule
feasibilities
61
Feasibility Analyses
 Technical feasibility. Is the solution technically practical?
Does our staff have the technical expertise to design and
build this solution?
 Operational feasibility. Will the solution fulfill the users’
requirements? To what degree? How will the solution
change the users’ work environment? How do users feel
about such a solution?
 Economic feasibility. Is the solution cost-effective?
 Schedule feasibility. Can the solution be designed and
implemented within an acceptable time period?
62
5. Decision Analysis
Phase …
Task 5.3: Compare Candidate Solutions
•Select the candidate solution having the “best overall”
combination of technical, operational, economic, and
schedule feasibilities
•Feasibility matrix
•Deliverable: recommended solution
63
Feasibility Matrix
64
5. Decision Analysis
Phase …
Task 5.4: Update the Project Plan
•Input: recommended solution
•Review and update the latest project schedule and
resource assignments
•Deliverable: updated project plan
65
5. Decision Analysis
Phase …
Task 5.5: Recommend a Solution
•Deliverable: System Proposal
66