Transcript Lecture3

Karolina Muszyńska
Based on http://www.csun.edu/~dn58412/IS431/IS431_SP13.html

Systems Analysis vs. Systems Design

Systems Analysis Phases and Tasks

User Requirements Discovery

Systems Analysis Approaches
2
3


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.
4
5

Scope Definition Phase – WHAT PROBLEM
• Is the project worth looking at to solve problem?

Problem Analysis Phase – WHAT ISSUES
• Is a new system worth building?

Requirements Analysis Phase – WHAT REQUIREMENTS
• WHAT do the users need and want from the new system?

Logical Design Phase – WHAT TO DO
• WHAT must the new system do to satisfy users’ needs?

Decision Analysis Phase – WHAT SOLUTION
• WHAT is the best solution among others?
6
7
8

Task 1.1: Identify Problems, Opportunities, and
Directives
◦ Deliverable: Preliminary Problem Statement

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
9

Task 1.3: Assess Project Worthiness
◦ Cost/benefit analysis
◦ Decision: approve, cancel, renegotiate the scope

Task 1.4: Schedule and Budget Plan for Project
◦ Deliverables: Project Charter – schedule and resource
assignment

Task 1.5: Present the Project and Plan
◦ Deliverable: Project Charter (participants, problems,
scope, methodology, statement of work to be
completed, deliverables, quality standards, schedule,
budget)
10
11
Problem Analysis Tasks
12

Task 2.1: Study the Problem Domain
◦ DATA: currently stored data, their business terms
◦ PROCESSES: current business events
◦ INTERFACES: current locations and users
◦ Deliverable: definition of system domain/models of
Current System

Task 2.2: Analyze Problems and Opportunities
◦ Deliverables: updated problem statements and the causeeffect analyses for each problem and opportunities

Task 2.3: Analyze Business Processes
◦ Deliverable: current business process models
13

Task 2.4: Establish System Improvement
Objectives
◦ Deliverable: System Improvement Objectives and
Recommendations Report

Task 2.5: : Update the Project Plan
◦ Deliverable: updated project plan

Task 2.6: Present Findings and Recommendations
◦ Deliverable: system improvement objectives
◦ Decision: continue/adjust/cancel current project
14
15
Requirements Analysis Tasks
16
3. Requirements Analysis Tasks

Task 3.1: Identify System Requirements
◦ Functional requirements: activities and services
provided 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
17
3. Requirements Analysis Tasks

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.

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)
18
19
20

Task 4.1: Analyze Functional Requirements
◦ Logical systems models: WHAT the system must do (not
HOW)
◦ 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

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
21
22
23

Task 5.1: Identify Candidate Solutions
o

Deliverable: candidate systems
(solutions) matrix
Task 5.2: Analyze Candidate Solutions
o
Feasibility analysis is performed on each
individual candidate without regard to the
feasibility of other candidates - technical,
operational, economic, schedule feasibilities
(TOES)
24

Task 5.3: Compare Candidate Solutions
o

Task 5.4: Update the Project Plan
o
o

Deliverable: recommended solution
Review and update the latest project
schedule and resource assignments
Deliverable: updated project plan
Task 5.5: Recommend a Solution

Deliverable: System Proposal
25






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 operation, 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 of the team is
tarnished because any failure, regardless of who is
at fault, will be perceived as a mistake by the team.
26







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.
27




Problem discovery and analysis
Requirements discovery
Documenting and analyzing requirements
Requirements management to handle
changes
28

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
29
A requirements definition document should
consist of the following:
◦ The functions and services that the system should
provide.
◦ Nonfunctional requirements including the system’s
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.
30







Sampling of existing documentation,
forms, and databases.
Research and site visits.
Observation of the work environment.
Questionnaires.
Interviews.
Discovery Prototyping.
Joint requirements planning (JRP) / Joint
application development (JAD)
31
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).
32

Model-driven Analysis
• Structured analysis
• Information engineering
• Object-oriented analysis

Accelerated Systems Analysis
• Discovery prototyping
• Rapid Architected Analysis
33
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.
34



Structured Analysis: a 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
Information Engineering (IE): a DATA-centered, but
process-sensitive technique to plan, analyze, and
design information systems. IE illustrate and
synchronize the system’s data and processes.
Object-oriented Analysis (OOA): a 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.
35

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
36
Discovery Prototyping



Discovery Prototyping – a technique used to identify
the users’ business requirements by building a smallscale, representative or working model of the users’
requirements in order to discover or verify them.
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
37
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.
38