Systems Analysis & Design

System
Analysis AND
DESIGN
Lecture 5
1

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

IS 431 : Lecture 3

System Development

IS 431 : Lecture 3

System Analysis

IS 431 : Lecture 3

Systems Analysis vs.

Systems Design

Systems Analysis: development phases in a project

that primarily focus on the business problems, i.e.,
WHAT the system must do in terms of Data,
Processes, and Interfaces, independent of any
technology that can or will be used to implement a
solution to that problem.
Systems Design: development phases focus on the
technical construction and implementation of the
system (HOW technology will be used in the
system.)

IS 431 : Lecture 3

Context of System
Analysis

IS 431 : Lecture 3

Model-Driven Analysis
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
an improved system.

IS 431 : Lecture 3

Model-Driven Methods
Structured Analysis: a model-driven, PROCESScentered technique to analyze an existing system
and define business requirements for a new system.
The models illustrate the systems components:
processes (functions, tasks) and their associated
inputs, outputs, and files.

IS 431 : Lecture 3

A Simple Process Model

IS 431 : Lecture 3

Model-Driven Methods
Information Engineering (IE):a model-driven
and DATA-centered, but process-sensitive (context
specific) technique to plan, analyze, and design
information systems.
IE illustrate and synchronize the systems data and
processes.

IS 431 : Lecture 3

10

A Simple Data Model

IS 431 : Lecture 3

11

Model-Driven Methods
Object-oriented Analysis (OOA): a model-driven
technique that integrates data and process concerns
into constructs called OBJECTS.
OOA illustrate the systems objects from various
perspectives such as structure and behavior.

IS 431 : Lecture 3

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()
+Graduate()1

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()

IS 431 : Lecture 3

13

Accelerated Systems
Analysis

Systems Analysis approaches

Accelerated
emphasize the construction of prototypes to more
rapidly identify business and user requirements for
a new system.

Discovery Prototyping
Rapid Architected Analysis

IS 431 : Lecture 3

14

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 Ill 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
IS 431 : Lecture 3

15

Rapid Architected
Analysis

Rapid Architected Analysis derive system

models from existing systems or discovery
prototypes.
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.

IS 431 : Lecture 3

16

Agile Methods
Agile Method the integration of various approaches
of systems analysis and design for applications as
deemed appropriate to the problem being solved and
the system being developed.
Most commercial methodologies do not impose a single
approach (structured analysis, IE, OOA) on systems analysts.
Instead, they integrate all popular approaches into a
collection of agile methods.
System developers are given the flexibility to select from a
variety of tools and techniques to best accomplish the tasks at
hand,

IS 431 : Lecture 3

17

Classic Systems
Analysis Phases
Scope Definition Phase
Is the project worth looking at, for WHAT?

Problem Analysis Phase

Is a new system worth building, for WHAT?

Requirements Analysis Phase

WHAT do the users need and want from the new system?

Logical Design Phase

WHAT must the new system do?

Decision Analysis Phase

WHAT is the best solution among others?

IS 431 : Lecture 3

18

Systems Analysis Phases

Scope Definition Phase : WHAT PROBLEM
Is the project worth looking at to solve problem?

Problem Analysis Phase: WHAT ISSUES

Is the new system worthwhile to build?

Requirements Analysis Phase: WHAT REQUIREMENTS

What do users need and want from the new system?

Logical Design Phase: WHAT TO DO

What the new system must do to satisfy users needs?

Decision Analysis Phase: WHAT SOLUTION

What is the best available solution for the business?

IS 431 : Lecture 3

19

Scope Definition Phase

IS 431 : Lecture 3

20

Scope Definition Tasks

IS 431 : Lecture 3

21

1. Scope Definition
Phase
Task 1.1: Identify Problems, Opportunities, and
Directives (POD)
Input: Request for System Service (Fig 5.7)
Deliverable: Preliminary Problem Statement (Fig 5.8)
Urgency, Visibility, Benefits, Priority, Possible
Solutions

IS 431 : Lecture 3

22

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
The
The
The

new
new
new
new

system
system
system
system

must be operational by April 15.

cannot cost more than $350,000.
must be web-enabled.
must bill customers every 15 days.

IS 431 : Lecture 3

23

Problem Statement

IS 431 : Lecture 3

24

1. Scope Definition
Phase ...

Task 1.2: Negotiate Preliminary 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
IS 431 : Lecture 3

25

1. Scope Definition
Phase
Task 1.3: Assess 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)
IS 431 : Lecture 3

26

1. Scope Definition
Phase
Task 1.4: Schedule and Budget Plan for Project
Deliverables: Project Charter
Master plan for the whole project: schedule and
resource assignments
Detail plan and schedule for completing the next
phase

IS 431 : Lecture 3

27

1. Scope Definition
Phase
Task 1.5: Present the Project and 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)

IS 431 : Lecture 3

28

Problem Analysis Phase

IS 431 : Lecture 3

29

Problem Analysis Tasks

IS 431 : Lecture 3

30

2. Problem Analysis
Phase

Task 2.1: Study 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 System

IS 431 : Lecture 3

31

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)

IS 431 : Lecture 3

32

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

IS 431 : Lecture 3

33

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

IS 431 : Lecture 3

34

PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX

IS 431 : Lecture 3

35

2. Problem Analysis
Phase

Task 2.5: Update 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

IS 431 : Lecture 3

36

2. Problem Analysis
Phase

Task 2.6: Present Findings and Recommendations

Deliverable: system improvement objectives
Decision: continue/adjust/cancel current project

IS 431 : Lecture 3

37

Requirements Analysis
Phase

IS 431 : Lecture 3

38

Requirements Analysis
Tasks

IS 431 : Lecture 3

39

3. Requirements
Analysis Phase

Task 3.1: Identify 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
IS 431 : Lecture 3

40

3. Requirements
Analysis Phase
Task 3.2: Prioritize 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.

IS 431 : Lecture 3

41

3. Requirements
Analysis Phase
Task 3.3: Update the Project Plan
If requirements exceed original vision: reduce the scope
or increase the budget
Deliverable: consolidated system requirements
(completed requirements and priorities)

IS 431 : Lecture 3

42

Logical Design Phase

IS 431 : Lecture 3

43

Logical Design Tasks

IS 431 : Lecture 3

44

4. Logical Modeling
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.
IS 431 : Lecture 3

45

4. Logical Modeling
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

IS 431 : Lecture 3

46

Consolidated
Requirements Statement

IS 431 : Lecture 3

47

Decision Analysis Phase

IS 431 : Lecture 3

48

Decision Analysis Tasks

IS 431 : Lecture 3

49

5. Decision Analysis
Phase
Task 5.1: Identify Candidate Solutions
Identify all possible candidate solutions
Deliverable: candidate systems (solutions) matrix (Fig
5.19)

IS 431 : Lecture 3

50

Candidate Systems Matrix

IS 431 : Lecture 3

51

Candidate Systems Matrix..

IS 431 : Lecture 3

52

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 (TOES)

IS 431 : Lecture 3

53

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?
IS 431 : Lecture 3

54

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 (Fig 5.20)
Deliverable: recommended solution

IS 431 : Lecture 3

55

Feasibility Matrix

IS 431 : Lecture 3

56

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

IS 431 : Lecture 3

57

5. Decision Analysis
Phase
Task 5.5: Recommend a Solution
Deliverable: System Proposal

IS 431 : Lecture 3

58

The Importance of
Requirements Discovery

System requirement (business requirement) is a

description of the needs and desires for an information
system. A requirement may describe functions, features
(attributes), and constraints.
Functional requirements: functions or features that
must be included in an information system in order to
satisfy the business need and be acceptable to the users.
Nonfunctional requirements: features, characteristics,
and attributes of the system as well as any constraints
that may limit the boundaries of the proposed solution.
Use PIECES framework for classification.
IS 431 : Lecture 3

59

PIECES Classification of
System Requirements

IS 431 : Lecture 3

60

Results of Incorrect
Requirements

The system may cost more than projected.

The system may be delivered later than promised.
The system may not meet the users expectations and
that dissatisfaction may cause them not to use it.
Once in production, the costs of maintaining and
enhancing the system may be excessively high.
The system may be unreliable and prone to errors
and downtime.
The reputation of the IT staff on the team is tarnished
because any failure, regardless of who is at fault, will
be perceived as a mistake by the team.
IS 431 : Lecture 3

61

Relative Cost
to Fix an Error

IS 431 : Lecture 3

62

Criteria to Define System

Requirements
Consistent requirements are not conflicting or ambiguous.
Complete requirements describe all possible system inputs
and responses.
Feasible requirements can be satisfied based on the
available resources and constraints.
Required requirements are truly needed and fulfill the
purpose of the system.
Accurate requirements are stated correctly.
Traceable requirements directly map to the functions and
features of the system.
Verifiable requirements are defined so they can be
demonstrated during testing.
IS 431 : Lecture 3

63

The Process of
Requirements Discovery
Problem discovery and analysis
Requirements discovery
Documenting and analyzing requirements
Requirements management to handle
changes

IS 431 : Lecture 3

64

Ishikawa Diagram
The Ishikawa diagram: graphical tool to identify,
explore, and depict problems, causes and effects of
those problems. (Also called a cause-and-effect
diagram or a fishbone diagram.)

IS 431 : Lecture 3

65

Ishikawa Diagram
Four Ms:
Materials, Machines, Manpower, and Methods

Four Ps:
Places, Procedures, Policies, and People

Four Ss:
Surroundings, Suppliers, Systems, and Skills

IS 431 : Lecture 3

66

Context of
Requirements for an
Information System
ORGANIZATION

USER

SYSTEM

TASK

TOOL

IS 431 : Lecture 3

67

Analyzing
Requirements
Analyzing requirements to resolve problems of:

Missing requirements
Conflicting requirements
Infeasible requirements
Overlapping requirements
Ambiguous requirements

Formalizing requirements
Requirements definition document
Communicated to stakeholders or steering body

IS 431 : Lecture 3

68

Documenting
Requirements

A requirements definition document should consist of

the following:
The functions and services that the system should provide.
Nonfunctional requirements including the systems
features, characteristics, and attributes.
The constraints that restrict the development of the system
or under which the system must operate.
Information about other systems that the system must
interface with.

IS 431 : Lecture 3

69

Requirements
Management

Requirements management - the process of

managing change to the requirements.
Over the lifetime of the project it is very common for
new requirements to emerge and existing requirements to
change.
Studies have shown that over the life of a project as much
as 50 percent or more of the requirements will change
before the system is put into production.

IS 431 : Lecture 3

70

Fact-Finding Methods
Sampling of existing documentation, forms,
and databases.
Research and site visits.
Observation of the work environment.
Questionnaires.
Interviews.
Prototyping.
Joint requirements planning (JRP).
IS 431 : Lecture 3

71

Discovery Prototyping
Discovery prototyping the act of building a
small-scale, representative or working model of the
users requirements in order to discover or verify
those requirements.
Advantages
Disadvantages

IS 431 : Lecture 3

72

Joint Requirements
Planning

Joint requirements planning (JRP) a process

whereby highly structured group meetings (having
defined agenda, key representatives) are conducted
for the purpose of analyzing problems and defining
requirements.
JRP is a subset of a more comprehensive joint application
development or JAD technique that encompasses the
entire systems development process.

IS 431 : Lecture 3

73

Benefits of JRP
JRP actively involves users and management in the
development project (encouraging them to take
ownership in the project).
JRP reduces the amount of time required to develop
systems.
JRP incorporates the benefits of prototyping as a
means for confirming requirements and obtaining
design approvals.

IS 431 : Lecture 3

74