CHAPTER 4 Slides

Systems Analysis
Introduction
 The presentation will address the following questions:

 What is systems analysis and how does it relate the term to the
survey, study, and definition phases of the FAST methodology?
 What are the systems analysis strategies for solving business
system problems?
 How do you describe the survey, study, and definition phases in
terms of your information system building blocks?
 How do you describe the survey, study, and definition phases in
terms of objectives, roles, inputs, outputs, techniques, and steps?
Prepared by Kevin C. Dittman for

Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
1
Systems Analysis
What is System Analysis?
 What is System Analysis?

 A Formal Definition:
 Systems analysis is the dissection of a system into its
component pieces for purposes of studying how those

component pieces interact and work.
 Systems analysis is done for the purpose of subsequently
performing a systems synthesis.
 Systems synthesis is the re-assembly of a system’s component
pieces back into a whole system – hopefully an improved

system.

2
Systems Analysis

 For this presentation we will use the following definition:
 Systems analysis is (1) the survey and planning of the system
and project, (2) the study and analysis of the existing business
and information system, and (3) the definition of business
requirements and priorities for a new or improved system. A
popular synonym is logical design.
 Systems analysis is driven by business concerns, specifically,
those of system users.

3
Systems Analysis
SYSTEM ANALYSIS
1
Survey and
plan the
project
Documentation
Repository
Project and 2
System Scope Study and Documentation
analyze the
existing
system
Documentation
System
Improvement
3
Objectives
Define
and priortize Business
to the design phase
the business Requirements
requirements
Business
Requirements to the configuration phase

4
Systems Analysis
 What is a Repository?
 A repository is a collection of those places where we keep all
documentation associated with the application and project.
 Although the Previous figure shows only one project repository, it
is normally implemented as some combination of the following:
 A disk or directory of word processing, spreadsheet, and other
computer-generated files that contain project correspondence,

reports, and data.
 One or more CASE local repositories.
 Hardcopy documentation (stored in notebooks, binders, and
system libraries).

5
Systems Analysis
 The Repository and FAST

 FAST is a repository-based methodology.
 Phases (and activities included in phases) communicate across
a shared repository.
 Work in one phase can and should overlap work in another
phase, so long as the necessary information is already in the

repository.
 This permits the developer to backtrack when an error or
omission is discovered.

6
Systems Analysis
Strategies for Systems Analysis and Problem Solving
 Modern Structured Analysis

 Structured analysis was one the first formal strategies developed
for systems analysis of information systems and computer
applications.
 Modern structured analysis is a process-centered technique
that is used to model business requirements for a system. The

models are structured pictures that illustrate the processes,
inputs, outputs, and files required to respond to business
events.

7
Systems Analysis

 Structured analysis introduced an overall strategy that has been
adopted by many of the other techniques – model-driven
development.
 A model is a representation of reality. Just as ‘a picture is
worth a thousand words’, most models use pictures to represent

reality.
 Model-driven development techniques emphasis the drawing
of models to define business requirements and information

system designs. The model becomes the design blueprint for
constructing the final system.

8
Systems Analysis

 Modern structured analysis is simple in concept.
 Systems and business analysts draw a series of process models
called data flow diagrams that depict the essential processes of

a system along with inputs, outputs, and files.
 Because these pictures represent the logical business
requirements of the system independent of any physical,

technical solution, the models are said to be a logical design for
the system.

9
Systems Analysis
Club
Member order response
Member
Accounts
Process
Credit rating and limit Member
Orders
Credit rating
and limit
Credit
rating
and
Process
limit Bonus Club
Bonus
Order Member
Orders
Process
Automatic Order
Orders to be
filled
Order to be
Warehouse Order to be filled
filled
Existing order details Orders Revised automatic order

10
Systems Analysis
 Information Engineering (IE)

 Today, many organizations have evolved from a structured
analysis approach to an information engineering approach.
 Information engineering is a data-centered, but process-
sensitive technique that is applied to the organization as a

whole (or a significant part therefore – such as a division),
rather than on an ad-hoc, project-by-project basis (as in
structured analysis).
 The basic concept of information engineering is that information
systems should be engineered like other products.

11
Systems Analysis

 The phases are the following:
 Information Strategy Planning (ISP) applies systems analysis
methods to examine the business as a whole for the purpose of

defining an overall plan and architecture for subsequent information
systems development.
 Based on the strategic plan, business areas are ‘carved out’ and
prioritized.
• A business area is a collection of cross-organizational business processes
that should be highly integrated to achieve the information strategy plan
(and business mission).
• A Business Area Analysis (BAA) uses systems analysis methods to study
the business area and define the business requirements for a highly
streamlined and integrated set of information systems and computer
applications to support that business area.
12
Systems Analysis

 The phases are the following: (continued)
 Based on the business area requirements analysis, information
system applications are ‘carved out’ and prioritized.

• These applications become projects to which other systems analysis
and design methods are applied to develop production systems.
 Information engineering is said to be a data-centered paradigm.
 Since information is a product of data, that data must be planned
first!
 Data models are drawn first.
 In addition to data models, information engineers also draw
process models similar to those drawn in structured analysis.

13
Systems Analysis
Member placed by; is enrolled under;

Member Agreeement
Order places applies to
sells; generates; established by;

is sold on generated by established
is featured in; sponsors;

Product Promotion Club
features is sponsored by

14
Systems Analysis
 Prototyping
 Prototyping is an engineering technique used to develop partial,
but functional versions of a system or applications. When
extended to system design and construction, a prototype can
evolve into the final, implemented system.
 Two ‘flavors’ of prototyping are applicable to systems analysis:
 Feasibility prototyping is used to test the feasibility of a
specific technology that might be applied to the business

problem.
 Discovery prototyping (sometimes called requirements
prototyping) is used to ‘discover’ the users’ business

requirements by having them react to a ‘quick-and-dirty’
implementation of those requirements.
15
Systems Analysis
 Joint Application Development (JAD)

 Joint application development (JAD) uses highly organized and
intensive workshops to bring together system owners, users,
analysts, designers, and builders to jointly define and design
systems. Synonyms include joint application design and joint
requirements planning.
 A JAD-trained systems analyst usually plays the role of
facilitator for a workshop.

 A JAD workshop will typically run from three to five full
working days.
• This workshop may replace months of traditional interviews and
follow-up meetings.

16
Systems Analysis
 Business Process Redesign (BPR)

 Business process redesign (also called business process
reengineering) is the application of systems analysis (and design)
methods to the goal of dramatically changing and improving the
fundamental business processes of an organization, independent of
information technology.
 BPR projects focus almost entirely on non-computer processes.
 Each process is studied and analyzed for bottlenecks, value-
returned, and opportunities for elimination or streamlining.

 Once the business processes have been redesigned, most BPR
projects conclude by examining how information technology

might best be applied to the improved business processes.
 This creates new application development projects.

17
Systems Analysis
 Object-Oriented Analysis (OOA)

 Data and the processes that act upon that data are combined or
encapsulated into things called objects.
 The only way to create, delete, change, or use the data in an object
(called properties) is through one of its encapsulated processes
(called methods).
 Object-oriented analysis (OOA) techniques are used to (1) study
existing objects to see if they can be reused or adapted for new
uses, and to (2) define new or modified objects that will be
combined with existing objects into a useful business computing
application.

18
Systems Analysis
 FAST Systems Analysis Strategies

 The FAST methodology does not impose a single technique on system
developers. Instead, it integrates all of the popular techniques:
structured analysis (via process modeling), information engineering
(via data modeling), prototyping (via rapid application development),
and joint application development (for all methods).
 Progressive FAST developers can use object-oriented analysis in
conjunction with object technology for prototyping to fully exploit the
object paradigm
 The FAST methodology supports different types of projects including:
 application development, information strategy planning, business
area analysis, decision support system development, and business

process redesign.

19
Systems Analysis
The Survey Phase of Systems Analysis
 Introduction
 The first phase of a FAST project is to survey the project.
 The purpose of the survey phase is threefold.
 First, the survey phase answers the question, “Is this project
worth looking at?”

 The survey phase must define the scope of the project and the
perceived problems, opportunities, and directives that triggered

the project.
 The survey phase must also establish the project team and
participants, the project budget, and the project schedule.

 The survey phase is concerned with the system owner’s view of
the overall information system, which includes very few details.

20
Systems Analysis
INFORMATION SYSTEMS FRAMEWORK
FOCUS ON FOCUS ON FOCUS ON FOCUS ON FAST

SYSTEM SYSTEM SYSTEM SYSTEM
DATA PROCESSES INTERFACES GEOGRAPHY Methodology
Business Subjects Business Functions System Context Operating Locations Survey Phase
(establish scope
Accounts
Receivable
Database
Mark etin g
Customers order zero,
and project plan)
Credit
SYSTEM one, or more products.

OWNERS Products may be ordered Order
Picking
by zero, one, or more

Customer Order Management Warehouse
Ad v e rtis in g Sa le s System
Order
customers.
(scope) Credit
Voucher
Ord e rs C an c ella tio n s Se r v ic e s

Bank
data scope process scope other systems geographic scope
SYSTEM
S
USERS
Y
S
(requirements)
T
E
M
A
N
A
L
Y
S
T SYSTEM
S DESIGNERS
(specification)
SYSTEM
BUILDERS
(components)
Existing
Interfaces Existing
Existing
Existing and Networks
Applications
Databases Technology and
and Technology
and Technology
Technology

21
Systems Analysis
 Introduction
 A FAST activity diagram shows the activities or work that must
be completed in order to accomplish a FAST phase.
 Solid lines indicate information and documentation flows.
 Dashed lines indicate flow of control based on specific criteria.
 A small, shaded circle at the beginning of any input or output
information flow indicates feasibility checkpoint.

 The survey phase is intended to be ‘quick.’ – the entire phase
should not exceed two or three days for most projects.

22
Systems Analysis
1.1
Request Survey Request
System
System for problems for
Owners
Owners system and system
and Users
services opportunities services
Request
problem
Project for
survey
charter system
statement
services
Project charter
1.4 1.2
Problem survey
Present Problem statement Negotiate
statement
the Scope statement project
project Project plan Repository scope scope
statement
Problem
statement
Project
plan
Scope
statement
1.3
Plan
Project templates
System the
and
Management project
Project standards

23
Systems Analysis
 Activity: Survey Problems, Opportunities, and

Directives
 Purpose:
 The purpose of this activity is to quickly survey and evaluate
each identified problem, opportunity, and directive with respect

to urgency, visibility, tangible benefits, and priority.
 Optionally, the participants can explore ‘possible’ solutions,
although everyone should be informed that other solutions may

and should be explored at later stages of the project.

24
Systems Analysis

Directives
 Roles:
 Project manager - facilitator
 System owner roles:
• executive sponsor
• user managers
• (optional) system managers
• project manager
 System user roles:
• (optional) business analysts
• other users are typically not involved in this activity at this time.

25
Systems Analysis

Directives
 Roles:
 System analyst roles:
• system modelers
 System designer roles are not typically involved in this activity
unless deemed appropriate by a system owner
 System builder roles are not typically involved in this activity

26
Systems Analysis

Directives
 Prerequisites (Inputs):
 This activity is triggered by a request for system services.
• This input implements the following two logical project triggers:

• a planned system project directive
• an unplanned system request

27
Systems Analysis
S o u n d S ta g e E n te r ta in m e n t C lu b
In fo r m a tio n S y s te m S e rv ic e s
P hone: 49 4 -0 6 6 6 F a x : 4 9 4 -0 9 9 9
In te rn e t: h ttp ://w w w .s o u n d s ta g e .c o m
In tra n e t: h ttp ://w w w .s o u n d ts ta g e .c o m /is s
D A T E O F R E Q U E S T S E R V IC E R E Q U E S T E D F O R D E P A R T M E N T (S )
J a n u a ry 1 0 , 1 9 9 7 M e m b e r S e r v ic e s , W a r e h o u s e , S h ip p in g
S U B M IT T E D B Y (k e y u s e r c o n ta c t) E X E C U T IV E S P O N S O R (fu n d in g a u th o r ity )
N am e S a ra h H a rtm a n N am e G a le n K ir k h o ff
T itle B u s in e s s A n a ly s t, M e m b e r S e r v ic e s T itle V ic e P r e s id e n t, M e m b e r S e r v ic e s
O ffic e B 035 O ffic e G 242
P h o n e 4 9 4 -0 8 6 7 P h o n e 4 9 4 -1 2 4 2
T Y P E O F S E R V IC E R E Q U E S T E D :
I n f o r m a tio n S tr a te g y P la n n in g E x is tin g A p p lic a t io n E n h a n c e m e n t
B u s in e s s P r o c e s s A n a ly s is a n d R e d e s ig n E x is tin g A p p lic a t io n M a in te n a n c e ( p r o b le m fix )
N e w A p p lic a tio n D e v e lo p m ent N o t S u re
O th e r ( p le a s e s p e c ify _ _ _ _ _______________________ __ __________________________________________
B R I E F S T A T E M E N T O F P R O B L E M , O P P O R T U N I T Y , O R D I R E C T I V E ( a t ta c h a d d itio n a l d o c u m e n t a t io n a s n e c e s s a r y )
T h e in f o r m a tio n s tr a te g y p la n n in g g r o u p h a s ta r g e t e d m e m b e r s e r v ic e s , m a r k e tin g , a n d o r d e r fu lfillm e n t ( in c lu s iv e o f
s h ip p in g ) f o r b u s in e s s p r o c e s s r e d e s ig n a n d in te g r a te d a p p lic a tio n d e v e lo p m e n t. C u r r e n tly s e r v ic e d b y s e p a r a te
in f o r m a tio n s y s te m s , th e s e a r e a s a r e n o t w e ll in te g r a te d to m a x im iz e e f fic ie n t o r d e r s e r v ic e s to o u r m e m b e r s . T h e
c u r r e n t s y s t e m s a r e n o t a d a p t a b le t o o u r r a p id ly c h a n g in g p r o d u c t s a n d s e r v ic e s . In s o m e c a s e s , s e p a r a t e s y s t e m s
e x is t f o r s im ila r p r o d u c t s a n d s e r v ic e s . S o m e o f t h e s e s y s t e m s w e r e in h e r it e d t h r o u g h m e r g e r s t h a t e x p a n d e d o u r
p r o d u c ts a n d s e r v ic e s . T h e r e a ls o e x is t s e v e r a l m a r k e tin g o p p o r tu n itie s to in c r e a s e o u r p r e s e n c e to o u r m e m b e r s .
O n e e x a m p le in c lu d e s In te r n e t c o m m e r c e s e r v ic e s . F in a lly , th e a u to m a tic id e n tif ic a tio n s y s te m b e in g d e v e lo p e d f o r
th e w a r e h o u s e m u s t f u lly in te r o p e r a te w ith m e m b e r s e r v ic e s .
B R IE F S T A T E M E N T O F E X P E C T E D S O L U T IO N
W e e n v is io n c o m p le t e ly n e w a n d s t r e a m lin e d b u s in e s s p r o c e s s e s th a t m in im iz e t h e r e s p o n s e tim e to m e m b e r o r d e r s
fo r p r o d u c t s a n d s e r v ic e s . A n o r d e r s h a ll n o t b e c o n s id e r e d f u lfille d u n til it h a s b e e n r e c e iv e d b y th e m e m b e r. T h e
n e w s y s t e m s h o u ld p r o v id e f o r e x p a n d e d c lu b a n d m e m b e r f le x ib ilit y a n d a d a p t a b ilit y o f b a s ic b u s in e s s p r o d u c ts a n d
s e r v ic e s .
W e e n v is io n a s y s te m th a t e x te n d s to th e d e s k to p c o m p u te r s o f b o th e m p lo y e e s a n d m e m b e r s , w ith a p p r o p r ia te
s h a r e d s e r v ic e s p r o v id e d a c r o s s th e n e tw o r k , c o n s is te n t w ith th e IS S d is tr ib u te d a r c h it e c tu r e . T h is is c o n s is te n t w ith
s t r a t e g ic p la n s t o r e t ir e t h e A S / 4 0 0 c e n t r a l c o m p u te r a n d r e p la c e it w it h s e r v e r s .
A C T IO N (IS S O ffic e U s e O n ly )
F e a s ib ility a s s e s s m e n t a p p r o v e d A s s ig n e d to S a n d ra S h e p h e rd
F e a s ib ility a s s e s s m e n t w a iv e d A p p ro v e d B u d g e t $ _ 4 5 0 ,0 0 0 _ _ _ _ _ _ _ _ _ _ _
S ta rt D a te _ _ A S A P _ _ _ _ _ _ _ _ D e a d lin e _ _ _ A S A P _ _ _ _ _ _ _ _
R e q u e s t d e la y e d B a c k lo g g e d u n til d a te : _ _ _ _ _ _ _ _ _ _ _ _ _ _
R e q u e s t r e je c te d R easo n : ________________________________________________
A u th o r iz e d S ig n a tu r e s :
_____________________________________ _______________________________________
C h a ir , IS S E x e c u tiv e S te e r in g B o d y P r o je c t E x e c u tiv e S p o n s o r
Systems Analysis & Design Methods 4ed F O R M IS S -1 0 0 -R F S S (L a s t r e v is e d D e c e m b e r , 1 9 9 6 )
28
Systems Analysis

Directives
 Deliverables (Outputs):
 The principle deliverable of this activity is a problem statement
which documents the problems, opportunities, and directives that

were discussed.
 Applicable Techniques:
 Fact Finding. Fact finding methods are used to interact with
people to identify problems, opportunities, and directives.

 Interpersonal Skills. Interpersonal skills are related to fact
finding skills. They impact the way we communicate and

negotiate with one another. Clearly, good interpersonal relations
are essential to this activity.
29
Systems Analysis
PROBLEM STATEMENTS
PROJECT: Member Services Information System PROJECT MANAGER: Sandra Shepherd

CREATED BY: Sandra Shepherd LAST UPDATED BY: Robert Martinez
DATE CREATED: January 15, 1997 DATE LAST UPDATED: January 17, 1997
Brief Statements of Problem, Opportunity, or Directive Urgency Visibility Annual Priority Proposed Solution
Benefits or Rank
1. Order response time as measured from time of order receipt to time of customer delivery ASAP High $175,000 2 New development
has increased to 15 an average of 15 days
2. The recent acquisitions of Private Screenings Video Club and GameScreen will further 6 months Med 75,000 2 New development
stress the throughput requirements for the current system.
3. Currently, three different order entry systems service the audio, video, and game divisions. 6 months Med 515,000 2 New development
Each system is designed to interface with a different warehousing system; therefore, the
intent to merge inventory into a single warehouse house been delayed.
4. There is a general lack of access to management and decision-making information. This 12 months Low 15,000 3 after new system is
will become exasperated by the acquisition of two additional order processing systems developed, provide users
(from Private Screenings and GameScreen). with easy-to-learn and -
use reporting tools.
5. There currently exists data inconsistencies in the member and order files. 3 months High 35,000 1 Quick fix; then new
development
6. The Private Screenings and GameScreen file systems are incompatible with the 6 months Med unknown 2 New development.
SoundStage equivalents. Business data problems include data inconsistencies and lack of Additional quantification
input edit controls. of benefit might increase
urgency.
7. There is an opportunity to open order systems to the Internet, but security and control is 12 months Low unknown 4 Future version of newly
an issue. developed system
8. The current order entry system is incompatible with the forthcoming automatic 3 months High 65,000 1 Quick fix; then new
identification (bar coding) system being developed for the warejhouse development

30
Systems Analysis

Directives
 Steps:
 The following steps are suggested to complete this activity:
• Step 1 - Collect and review all documentation submitted to begin

this project.
• Step 2 - Schedule and conduct a meeting of the people tentatively
assigned to the aforementioned roles for this activity. (Alternative:
Interview the people tentatively assigned to those roles.)
• Step 3 - Document problems, opportunities and constraints.

31
Systems Analysis
 Activity: Negotiate Project Scope

 Purpose:
 The purpose of this activity is to define the boundary of the
system and project.

• The boundary should be defined as precisely as possible to
minimize the impact of ‘creeping scope’.
– Creeping scope is the subtle, but significant increase of scope
that frequently occurs during system projects.
– By defining scope, we are not eliminating creeping scope, but
are merely providing a mechanism to document and track that
scope so that the impact on budget and schedule can be
continuously reassessed.

32
Systems Analysis

 Roles:
• user managers
• project manager
• other users are typically not involved in this activity at this time.

33
Systems Analysis

 Roles:
• system modelers

34
Systems Analysis

 This activity is triggered by a request for system services.
 The problem survey statement produced by the previous
activity can be a useful input for defining scope.

 The principle deliverable of this activity is a scope statement.

35
Systems Analysis

 Fact Finding. Fact finding methods are used to interact with
people to define scope. Typically, scope is defined by way of

interviews or a group meeting.
 Interpersonal Skills. Interpersonal skills are related to fact
finding skills. They impact the way we communicate and

negotiate with one another. Clearly, good interpersonal
relations are essential to this activity.

36
Systems Analysis

 Steps:
• Step 1 - Collect and review all documentation submitted to begin

this project.
• Step 2 - Schedule and plan a meeting of the people tentatively
assigned to the aforementioned roles for this activity. The meeting
or interviews should focus on ‘negotiating’ the scope in terms of
the four building blocks of information systems: DATA,
PROCESSES, INTERFACES, and GEOGRAPHY.
• Step 3 - Document scope.

37
Systems Analysis
 Activity: Plan The Project

 The initial project plan should consist of the following:
 A first-draft master plan and schedule for completing the entire
project. This schedule will be modified at the end of each phase

of the project. This is sometimes called a baseline plan.
 A detailed plan and schedule for completing the next phase of
the project (the study phase). In most cases this schedule will
be more accurate, but still subject to a lack of detailed
knowledge about the current system and user requirements.
 Purpose:
 The purpose of this activity is to develop the initial project
schedule and resource assignments.

38
Systems Analysis

 Roles:
• user managers
• system managers
• project manager
• (optional) steering body

39
Systems Analysis

 Roles:
 System analyst roles are not typically involved in this activity
unless deemed appropriate by the project manager.



40
Systems Analysis

 This activity is triggered by the completion of the problem
survey and scope definition activities.

• The problem statement and the scope statement, if formally
documented, are very helpful references for the project planning
group.
 The principle deliverable of this activity is the project plan.
This initial project plan consists of two components:

• a phase-level plan that covers the entire project
• an activity-level plan the details the study phase of the project

41
Systems Analysis

 Process Management. Process management defines the
standards for applying the methodology to a project. It defines

skill requirements and training for each role, CASE tool
standards, documentation standards, quality management
standards, and project management standards.
 Project Management. Project management builds on process
management by applying the methodology to specific projects

in the form of schedule planning, staffing and supervision,
progress reporting, management of expectations, budgeting,
and schedule management.

42
Systems Analysis

 Presentation Skills. The project charter and any verbal
presentations of the project and plan obviously require

presentation skills.
 Steps:
• Step 1 - Review system problems, opportunities, and directives; as

well as, project scope.
• Step 2 - Select the appropriate FAST project template. FAST
templates support different strategies and/or different system
development goals (e.g., purchase a package versus object-
oriented development).
43
Systems Analysis

 Steps:
(continued)
• Step 3 - Assign specific people to each FAST role.
• Step 4 - Estimate time required for each project activity, assign
roles to activities, and construct a schedule.
• Step 5 - (optional) Negotiate expectations.
• Step 6 - Negotiate the schedule with system owners, adjusting
resources, scope, and expectations as necessary.
• Step 7 - Write the project charter.

44
Systems Analysis
 Activity: Present The Project

 In most organizations, there are more potential projects than
resources to staff and fund those projects.
 If a project has not been predetermined to be of the highest priority
(by some sort of prior tactical or strategic planning process), then
it must be presented and defended to some sort of steering body
for approval.
 A steering body is a committee of executive business and
system managers that studies and prioritizes competing project

proposals to determine which projects will return the most
value to the organization and thus, should be approved for
continued systems development.

45
Systems Analysis

 Purpose:
 The purpose of this activity is to:
• (1) secure any required approvals to continue the project, and

• (2) to communicate the project and goals to all staff.
 Roles:
 Executive sponsor - facilitator
• user managers
• system managers
• project manager
• steering body
46
Systems Analysis

 Roles:
• business analysts
• all direct and indirect users
 System designers:
• any system analysts assigned to the project
• any system designers and specialists likely to be assigned to the
project
 System builders:
• any system builders likely to be assigned to the project
• (optional) representatives of any technology vendors whose
products are likely to be involved in the project
47
Systems Analysis

 This activity is triggered by the completion of the project
planning activity.
 The inputs include:
• problem statement
• scope statement
• project plan
• (optional) project templates
• project standards

48
Systems Analysis

 The key deliverable of this activity is the project charter.
• This charter is usually a formal consolidation of all of the inputs to

the activity. It might be thought of as an internal contract for the
project, should the project continue to the next phase.
 The final deliverable of the activity is the problem statement
and scope statement that become the triggers for various study
phase activities.
• They may take the form of a verbal presentation, a written
document (possibly the project charter or a summary thereof), a
letter of authority from the executive sponsor, or some
combination of these formats.

49
Systems Analysis
Project Feasibility Assessment Report
I. Executive summary (1 page)

A. Summary of recommendation
B. Brief statement of anticipated benefits
C. Brief explanation of report contents
II. Background information (1-2 pages)
A. Brief description of project request
B. Brief explanation of the summary phase activities
III. Findings (2-3 pages)
A. Problems and analysis (optional: reference problem statement matrix)
B. Opportunities and analysis (optional: reference problem statement matrix)
C. Directives and implications
IV. Detailed recommendation
A. Narrative recommendation (1 page)
1. Immediate fixes
2. Quick fixes
3. Enhancements
4. New systems development
B. Project Plan
1. Initial project objectives
2. Initial master project plan (phase level)
3. Detailed plan for the study or definition phase
V. Appendices
A. Request for System Services
B. Problem Statements Matrix
C. (other documents as appropriate)

50
Systems Analysis

 Interpersonal Skills. Good interpersonal skills are essential to
this activity. These include persuasion, sales (of ‘ideas’),

writing, and speaking.
 Steps:
• Step 1 - Review the deliverables of all prior activities.

• Step 2 - (optional) Reformat the project charter for presentation to
the steering body.
• Step 3 - Present the project proposal (charter) to the steering body.
Be prepared to defend recommendations, address issues and
controversies, and answer questions as posed by the steering body.
51
Systems Analysis

 Steps:
(continued)
• Step 4 - Plan an event to communicate the approved project to any
and all affected staff, or distribute the project charter or summary
over a cover letter of authority from the executive sponsor.
– This launch event presents the project and plan to both
participants and all interested parties.
– The executive sponsor’s visible support of the project can
prevent many ‘political’ problems from ever surfacing.

52
Systems Analysis
 Survey Phase Conclusion

 It is possible that the participants in the survey phase will decide
the project is not worth proposing.
 It is also possible that the steering body may decide that other
projects are more important.
 It is also possible that the executive sponsor might not endorse the
project.
 In each of these instances, the project is terminated. Little time and
effort has been expended.
 With the blessing of all system owners, the project can now
proceed to the study and/or definition phases.

53
Systems Analysis
The Study Phase of Systems Analysis
 Introduction
 The study phase provides the analyst with a more thorough
understanding of problems, opportunities, and/or directives.
 The study phase answers the questions:
 Are the problems really worth solving? and
 Is a new system really worth building?
 The study phase is rarely skipped.

54
Systems Analysis
FOCUS ON FOCUS ON FOCUS ON FOCUS ON FAST

SYSTEM SYSTEM SYSTEM SYSTEM
(establish scope
Acc ounts
Re ceivable
Data bas e
Marketing
and project plan)
Credit
SYSTEM one, or mor e products.

OWNERS Products may be ordered Order
Picki ng

Custome r Orde r Manageme nt Warehouse
Advertising Sales Sys tem
Orde r
customers.
(scope) Credit
Voucher
Orders Cancellations Services

Study Phase
Ba nk
(establish
system
Data Problems Process Problems Interface Problems Geographic Problems
and Opportunities and Opportunities and Opportunities and Opportunities improvement
objectives)
SYSTEM
S
USERS data capture throughput control service
Y
S
data access response time service cost and value
(requirements)
T data reliability cost and value integration response time
E
info accuracy efficiency interoperability accessibility
M
info timeliness service service security
A
N
A Database Scehma Application Schema Interface Schema Network Schema
L
Y
S
T SYSTEM
S DESIGNERS
(specification)
Database Structures Application Programs Component Programs Network Programs
SYSTEM
BUILDERS
(components)
Existing
Existing Interfaces Existing
Existing Applications and Networks
Databases and Technlogy and
and Technology Technology
Technology

55
Systems Analysis
2.1
Approval Model
System to the
Owners continue current 2.2
project Process models Analyze
system
the
business
processes
scope
statement
Detailed
Process anaysis
Study system models
Findings models
Process
analysis data
1.4 All prior 2.3

Present deliverables problem statement Analyze
the and problems
project revised Repository cause/effect and
project plan analysis opportunities
System
Project System models
plan models Cause/effect
analysis
cause/effect
analysis System
2.5 2.4
improvement
Modify system Establish
objectives and
project improvement system
constraints
scope and objectives improvement
plan and constraints objectives

56
Systems Analysis
 Activity: Model the Current System

 FAST suggests one of two modeling strategies for the study phase:
 a combination of high-level data, process, and geographic
models, or
 a combination of object and geographic models
 Purpose:
 The purpose of this activity is to learn enough about the current
system’s data, processes, interfaces, and geography to expand

the understanding of scope, and to establish a common
working vocabulary for that scope.

57
Systems Analysis

 Roles:
 Executive sponsor or systems analyst - facilitator
• user managers
• project manager
• business analyst
• all other users as needed to fully represent the business scope of
the project

58
Systems Analysis

 Roles:
• system modelers
unless deemed appropriate by a system owner.

59
Systems Analysis

 This activity is triggered by completion of the survey phase
activities and approval from the system owners to continue the

project.
 The key informational input is the project and system scope
statement that was completed as part of the survey phase.

60
Systems Analysis

 The principle deliverable of this activity are system models
that serve two purposes:

• (1) to expand understanding of scope, and
• (2) to verify the team’s consensus understanding of the business
situation.
 The overriding modeling strategy is information hiding.
• The principle of information hiding, as applied to system models,
suggests that models should hide inappropriate details in an effort
to focus attention on what’s really important.

61
Systems Analysis

 Fact Finding – By now, a common theme has emerged. Good
fact finding skills are absolutely essential to most activities in

the systems analysis phases.
• Fact finding skills include interviewing, sampling, questionnaires,
and research.
 Joint Application Development – The preferred technique for
gathering information as rapidly as possible is joint application
development (JAD).
• The requisite system models can be developed in one or two
facilitated group sessions with all of the participants.
 Data, Process, and Geographic Modeling
62
Systems Analysis

 Interpersonal Skills – And yet another common theme of
systems analysis emerges – good interpersonal skills are

essential to most systems analysis activities.
 Steps:
• Step 1 - Review the scope statement completed in the survey phase.

• Step 2 - Collect facts and gather information about the current
system.
– The preferred technique is JAD, but JAD sessions may be
preceded or followed by traditional fact finding and information
gathering activity.
63
Systems Analysis

 Steps:
(continued)
• Step 3 - Draw system models.
– The recommended sequence of models is (1) INTERFACE, (2)
DATA, (3) PROCESS, and (4) GEOGRAPHY.
• Step 4 - Verify the system models.
– The goal is to reach consensus agreement on ‘what’ the current
system is all about.

64
Systems Analysis
 (optional) Activity: Analyze Business Processes

 Purpose:
 Applicable only to business process redesign projects.
 The purpose of this activity is to analyze each business process
in a set of related business processes to determine if the process

is necessary, and what problems might exist in that business
process.

65
Systems Analysis

 Roles:
 Executive sponsor or systems analyst - facilitator
• user managers
• project manager
• all other users as needed to fully represent the business scope of
the project

66
Systems Analysis

 This activity is triggered by completion of the system models
from the previous activity.

 This activity is only interested in the process models.
• These process models are much more detailed than in other types
of projects. They show every possible work flow path through the
system, including error processing.

67
Systems Analysis

 The deliverables of this activity are process analysis models and
process analysis data.

• The process analysis models look very much like data flow
diagrams except that they are significantly annotated to show:
– (1) the volume of data flowing through the processes,
– (2) the response times of each process, and
– (3) any delays or bottlenecks that occur in the system.
• The process analysis data provides additional information such as:
– (1) the cost of each process,
– (2) the value added by each process, and
– (3) the consequences of eliminating or streamlining the process.
68
Systems Analysis

 Process Modeling
 Process Analysis
 Steps:
• Step 1 - If necessary, refine process models to include all possible work

flows and data flows that can occur in the business area under
examination.
• Step 2 - For each primitive business process, analyze throughput and
response time, as well as any average delays that may occur.
• Step 3 - For each primitive business process, analyze cost and value
added. Identify candidates for elimination, consolidation, and
optimization.
69
Systems Analysis
 Activity: Analyze Problems and Opportunities

 Purpose:
• (1) understand the underlying causes and effects of all perceived

problems and opportunities, and
• (2) understand the effects and potential side effects of all
perceived opportunities.

70
Systems Analysis

 Roles:
 Business process analyst - facilitator
• user managers
• project manager
• (optional) business analyst
• other user experts as necessary to fully analyze the problems and
opportunities
• systems analyst

71
Systems Analysis

 Roles:


72
Systems Analysis

 This activity is triggered by completion of the survey phase
activities and approval from the system owners to continue the

project.
 One key informational input is the problem statement that was
completed as part of the survey phase.

 Other key informational inputs are problems and opportunities,
and causes and effects which are collected from the business
analysts and other system users.
 The principle deliverable of this activity is the cause/effect
analysis.
73
Systems Analysis
PROBLEMS, OPPORTUNITIES, OBJECTIVES AND CONSTRAINTS MATRIX
Project: Member Services Information System Project Manager: Sandra Shepherd

Created by: Robert Martinez Last Updated by: Robert Martinez
Date Created: January 21, 1997 Date Last Updated: January 31, 1997
CAUSE AND EFFECT ANALYSIS SYSTEM IMPROVEMENT OBJECTIVES
Problem or Opportunity Causes and Effects System Objective System Constraint

1. Order response time is unaccept- 1. Throughput has increased while 1. Decrease the time required to proc- 1. There will be no increase in the
able. number of order clerks was down- ess a single order by 30%. order processing workforce.
sized. Time to process a single or-
2. Eliminate keyboard data entry for 2. Any system developed must be
der has remained relatively con-
as much as 50% of all orders. compatible with the existing Win-
stant.
dows 95 desktop standard.
3. For remaining orders, reduce as
2. System is too keyboard dependent.
many keystrokes as possible by re- 3. New system must be compatible
Many of the same values are keyed
placing keystrokes with point-and- with the already approved auto-
for most orders. Net result is (with
click objects on the computer dis- matic identification system (for bar
the current system) each order
play screen. coding).
takes longer to process than is
ideal. 4. Move data editing from a shared
computer to the desktop.
3. Data editing is performed by the
AS/400. As that computer has ap- 5. Replace existing picking tickets
proached its capacity, order edit re- with a paperless communication
sponses have slowed. Because or- system between member services
der clerks are trying to work faster and the warehouse.
to keep up with the volume, the
number of errors have increased.
4. Warehouse picking tickets for or-
ders were never designed to maxi-
mize the efficiency of order fillers.
As warehouse operations grew, or-
der filling delays were inevitable.
Page 1 of 5

74
Systems Analysis

 Fact Finding – Fact finding skills are necessary to both
identify and analyze the problems and opportunities.

rapid problem analysis is Joint Application Development

(JAD).
• The requisite analysis can usually be completed in one full-day
session or less.
• The JAD facilitator must be especially skilled at conflict
resolution because people tend to view problem analysis as
personal criticism.

75
Systems Analysis

 Interpersonal Skills – This activity can easily generate
controversy and conflict. Good interpersonal skills are

necessary to maintain a focus on the problems, and not the
personalities.
 Cause/Effect Analysis – Cause/effect analysis, when applied
with discipline, can help the team avoid a premature concern

with solutions.

76
Systems Analysis

 Steps:
• Step 1 - Review the problem statement completed in the survey

phase.
• Step 2 - Collect facts and gather information about the perceived
problems and opportunities in the current system.
– The preferred technique is JAD, but JAD sessions may be
preceded or followed by traditional fact finding and
information gathering activity.
• Step 3 - Analyze and document each problem and opportunity.
– The PIECES framework is most useful for cause/effect
analysis.

77
Systems Analysis
 Activity: Establish System Improvement Objectives and

Constraints
 Success should be measured in terms of the degree to which
objectives are met for the new system.
 An objective is a measure of success. It is something that you
expect to achieve, if given sufficient resources.

 Objectives represent the first attempt to establish expectations for
any new system.

 In addition to objectives, we must also identify any known
constraints.
 A constraint is something that will limit your flexibility in
defining a solution to your objectives. Essentially, constraints

cannot be changed.
78
Systems Analysis
 Activity: Establish System Improvement Objectives

and Constraints
 Purpose:
 The purpose of this activity is to establish the criteria against
which any improvements to the system will be measured, and

to identify any constraints that may limit flexibility in
achieving those improvements.

79
Systems Analysis

Constraints
 Roles:
 Project manager or systems analyst - facilitator
• user managers
• project manager
• other user experts as necessary to fully analyze the problems and
opportunities
• systems analyst
80
Systems Analysis

Constraints
 Roles:


 This activity is triggered by the completion of the two previous
activities.
 The inputs are the system models and the cause/effect analysis.
• Together, they define the context for establishing objectives and

constraints.
81
Systems Analysis

and Constraints
 The deliverable of this activity is system improvement
objectives and constraints.

 This deliverable also corresponds to the net deliverable of the
study phase, system objectives.

82
Systems Analysis

Constraints
rapid problem analysis is Joint Application Development (JAD).

• The requisite brainstorming can usually be completed in one full-day
session or less.
 Benefit Analysis – Whenever possible, objectives should be stated
in terms that can be measured.
 Interpersonal Skills – This activity can easily generate
controversy and conflict. Good interpersonal skills are necessary

to maintain a focus on what’s best for the organization.

83
Systems Analysis

and Constraints
 Steps:
• Step 1 - Review scope and problem analyses from the prior

activities.
• Step 2 - Negotiate business-oriented objectives to solve each
problem and exploit each opportunity.
– Ideally, each objective should establish the way you will
‘measure’ the improvement over the current situation.
– Measures should be as tangible (measurable) as you can
possibly make them.

84
Systems Analysis

and Constraints
 Steps:
(continued)
• Step 3 - Brainstorm any constraints that ‘may’ limit your ability to
fully achieve objectives.
– Use the four categories previously listed in this section (time,
cost, technology, and policy) to organize your discussion.

85
Systems Analysis
 Activity: Modify Project Scope and Plan

 Purpose:
 The purpose of this activity is to reevaluate project scope,
schedule, and expectations. The overall project plan is then

adjusted as necessary, and a detailed plan is prepared for the
next phase.

86
Systems Analysis

 Roles:
• (optional) executive sponsor

• (optional) user managers
• project manager
 System users are not typically involved in this activity unless
deemed appropriate by the project manager.
 Systems analyst, system designer, and system builder roles are
not typically involved in this activity unless deemed necessary by

the project manager.
87
Systems Analysis

 This activity is triggered by the completion of the system
modeling, problem analysis, and objective definition activities.

 The system models, cause/effect analysis, and system
improvement objectives and constraints are inputs for the

activity.
 The original project plan from the survey phase (if available) is
also an input.
 The principle deliverable of this activity is a revised project
plan. Additionally, a detailed definition phase plan may be

produced.
88
Systems Analysis

standards for applying the methodology to a project.




89
Systems Analysis

 Steps:
• Step 1 - Review the original plan.

• Step 2 - Review the system models, problems and opportunities,
causes/effect analyses, system improvement objectives, and scope.
Ask yourself two questions:
– Has the scope of the project significantly expanded?
– Are the problems, opportunities, or objectives more difficult to
solve than originally anticipated?
• Step 3 - Estimate time required for each project activity in the next
phase – the definition phase.

90
Systems Analysis

 Steps:
(continued)
• Step 4 - If necessary, refine baseline estimates for the overall
project plan.
• Step 5 - If necessary, renegotiate scope, schedule, and/or budget
with the system owner group.

91
Systems Analysis
 Activity: Present Findings and Recommendations

 Purpose:
 The purpose of this activity is to communicate the project and
goals to all staff. The report or presentation, if developed, is a

consolidation of the activities’ documentation.
 Roles:
 Business Analyst - facilitator

• user managers
• system managers
• project manager

92
Systems Analysis

 Roles:
• business analysts
• all direct and indirect users
 System analysts:
• any system analysts assigned to the project
 System designers are not typically involved in this activity.
 System builders are not typically involved in this activity.

93
Systems Analysis

 This activity is triggered by the completion of the system
objectives or project plan activity.

 The inputs include the system models, the cause/effect
analysis, the system improvement objectives and

constraints, and the revised project plan generated by the
prior activities.
 The key deliverable of this activity is the detailed study
findings. It usually includes a feasibility update and the revised

project plan.

94
Systems Analysis
Analysis of the Current ___________ System
I. Executive summary (approximately 2 pages)

A. Summary of recommendation
B. Summary of problems, opportunities, and directives
C. Brief statement of system improvement objectives
D. Brief explanation of report contents
II. Background information (approximately 2 pages)
A. List of interviews and facilitated group meetings conducted
B. List of other sources of information that were exploited
C. Description of analytical techniques used
III. Overview of the current system (approximately 5 pages)
A. Strategic implications (if the project is part of, or impacts an existing information
systems strategic plan)
B. Models of the current system
1. Interface model (showing project scope)
2. Data model (showing project scope)
3. Geographic models (showing project scope)
4. Process model (showing functional decomposition only)
IV. Analysis of the Current System (approximately 5-10 pages)
A. Performance problems, opportunities, and cause/effect analysis
B. Information problems, opportunities, and cause/effect analysis
C. Economic problems, opportunities, and cause/effect analysis
D. Control problems, opportunities, and cause/effect analysis
E. Efficiency problems, opportunities, and cause/effect analysis
F. Service problems, opportunities, and cause/effect analysis
V. Detailed recommendations (approximately 5-10 pages)
A. System improvement objectives and priorities
B. Constraints
C. Project Plan
1. Scope reassessment and refinement
2. Revised master plan
3. Detailed plan for the definition phase
VI. Appendices
A. Any detailed system models
B. (other documents as appropriate)
95
Systems Analysis

 Interpersonal Skills. Good interpersonal skills are essential to
this activity. These include persuasion, sales (of ‘ideas’),

writing, and speaking.
 Steps:
• Step 1 - Review the deliverables of all prior activities.

• Step 2 - Write the detailed study findings.

96
Systems Analysis

 Steps:
• Step 3 - Present the findings to the system owners. Be prepared to defend

recommendations, address issues and controversies, and answer
questions. One of the following decisions must be made:
– Authorize the project to continue, as is, to the definition phase.
– Adjust the scope, cost, and/or schedule for the project and then
continue to the definition phase.
– Cancel the project due to either (1) lack of resources to further
develop the system, (2) realization that the problems and opportunities
are simply not as important as anticipated, or (3) realization that the
benefits of the new system are not likely to exceed the costs.
• Step 4 - Present findings to all affected staff.

97
Systems Analysis
The Definition Phase of Systems Analysis
 Introduction
 The definition phase answers the question, ‘What does the user
need and want from a new system?’
 The definition phase can never be skipped.

98
Systems Analysis
FOCUS ON
SYSTEM
FOCUS ON
SYSTEM
FOCUS ON
SYSTEM
FOCUS ON
SYSTEM
FAST
Acc ounts
(establish scope
Re ceiva ble
Database
Ma rk etin g
and project plan)
Cred it
one, or more products.

SYSTEM
Products may be ordered
OWNERS Ord er
Picking

Custom er Orde r Ma nagem ent Wa reho use
Ad v e rtis in g Sa les Sy stem
Order
customers.
(scope) Cred it
Vo ucher
Ord e rs C a nc e lla tion s Se rv ic e s

Bank
Study Phase
(establish
Data Requirements Business Processes Interface Communication Reqts.
system
PR ODUC T
rejected order
Requirements E DI
or der
S t.
Louis
catalog P r oducts
improvement
objectives)
CUSTOMER product- no C ustomers
credit Check Cust
HQ
changes C atalog
credit
customer-no product- name Fi r ecr acker Sal es
customer-name unit-of -measure customer

SYSTEM
approved order
customer-rating unit-price number order w ith W est ship E ast
valid products Custom er s or der Custom er s
balance- due quantity-available
S USERS order Validate valid order Validate cr edit cr edit
Y customer products Orders
Indy
LA ship NY
S (requirements) ORD ER order w ithout prices
approved
order Office or der W ar e-
house
ship or der
Office
order-no valid
T order-date customer
picking
ser vice
product s-ordered
E
quantity R elease ticket
Definition Phase
P roducts Maintenance
quantities- ordered in stock order
Recor ds
M
data models process models interface models distribution models (establish and
A
N prioritize
A business system
L
Y requirements)
S
T SYSTEM
S DESIGNERS
(specification)
SYSTEM
BUILDERS
(components)
Existing
Existing Interfaces Existing
Applications and Networks
Existing
and Technology and
Databases
and Technology Technology
Technology

99
Systems Analysis
3.1
Approval Outline
System to Business
Owners continue Requirements
project
system
improvement
Revised
objectives
scope Revised
and plan requirements 3.2
plan statement Model
outline business
requirements system
statement outline requirements
3.5
Modify
project All prior
plan deliverables Repository
and system models
scope
System
models
Business Discovery prototypes
requirements' Business
priorities requirements
outline Requirements 3.3
statement Build
outline discovery
3.4
System prototypes
Prioritize
models
Business
Requirements
Discovery
prototypes

100
Systems Analysis
 Activity: Outline Business Requirements

 Purpose:
 The purpose of this activity is to identify, in general terms, the
business requirements for a new or improved information

system. A classic input-process-output framework should
prove sufficient to structure the activity.

101
Systems Analysis

 Roles:
 Business analyst or systems analyst - facilitator
• user managers
• (optional) project manager
• (optional) appropriate direct and indirect users
 System designers are not typically involved in this activity.

102
Systems Analysis

 This activity is triggered by approval from the system owners
to continue the project into the definition phase.

 The key input is the system improvement objectives from the
study phase.
 Any and all relevant information from the study phase should
be available for reference as needed.

103
Systems Analysis

 The only deliverable of this activity is a requirements
statement outline.
• In its simplest format, the outline could be divided into four
logical sections:
– (1) the original list of objectives,
– (2) inputs,
– (3) processes, and
– (4) outputs.

104
Systems Analysis

rapidly outlining business system requirements is joint

application development (JAD).
• The requisite analysis can usually be completed in less than one-
half a working day.
 Interpersonal Skills –Good interpersonal skills are necessary
to maintain a focus on the requirements.

105
Systems Analysis

 Steps:
• Step 1 - Review and refine the system improvement objectives.

• Step 2 - For each objective:
– Identify and document any business events or inputs to which the
system must respond. Briefly define each event or input, but do not
define the specific data content of any input.
– Identify and document any special business policies, processing, or
decisions that must be made to adequately respond to each event or
input.
– Identify and document the normal business outputs or responses to the
aforementioned business events or inputs.
– Identify and document any information that must be produced or made
available.
106
Systems Analysis

 Steps:
(continued)
• Step 3 - Compare the system improvement objectives and
requirements against the original problem statements from the
study phase.
– Are you still solving the original problems or is the scope of
the project growing?
– Increased scope is not necessarily wrong; however, an
appropriate adjustment of expectations (particularly schedule
and budget) my eventually become necessary.

107
Systems Analysis
 Activity: Model Business System Requirements

 The best systems analysts can develop models that provide no hint
of how the system will or might be implemented. This is called
logical or essential system modeling.
 Logical models depict what a system is, or what a system must
do – not ‘how’ the system will be implemented. Because

logical models depict the essence of the system, they are
sometimes called essential models.
 Logical models express business requirements – sometimes
referred to as the logical design.

108
Systems Analysis

 By focusing on the logical design of the system, the project team
will:
• (1) appropriately separate business concerns from their technical
solutions,
• (2) be more likely to conceive and consider new and different ways to
improve business processes, and
• (3) be more likely to consider different, alternative technical solutions
(when the time comes for physical design).
 Purpose:
 The purpose of this activity is model business system requirements
such that they can be verified by system users, and subsequently

understood and transformed by system designers into a technical
solution.
109
Systems Analysis

 Roles:
 Systems analyst - facilitator
• user managers
• project manager
• appropriate direct and indirect users
 System analysts roles:
• system architect

110
Systems Analysis

 Roles:
 System designers are not recommended since they tend to talk
in technical terms that intimidate and frustrate the users and

user managers.
 System builders are not typically involved in this activity. On
the other hand, programmers who are skilled in user interface

construction might be invited to observe the activity as a
preface to constructing rapid prototypes of user interfaces for
later activities.

111
Systems Analysis

 This activity is usually triggered by completion of the
requirements statement outline.

 The deliverable of this activity are the system models.
• Data models are used to model the data requirements for many
new systems.
• Process models are frequently used to model the work flow
through business systems.

112
Systems Analysis

 The deliverable of this activity are the system models.
(continued)
• Interface Models such as context diagrams, depict net inputs to
the system, their sources, net outputs from the system, their
destinations, and shared databases.
• Distribution models serve as a starting point for designing the
communication systems for distributing the data, processes, and
interfaces to the various geographical locations.

113
Systems Analysis
Past
Member
Accounts
Resubscription
Order
Prospective
Subscription Order
Member
Member Promotion
The Unanticipated Backorder

Member
Current
Member Order Services Picking Order
Member
Information
System
Referral Order Sales Warehouse

Reports
Membership
Subscription and
Reports and
Plan Analyses
Analyses
New Monthly
Promotion
Member
Marketing
Services
Division
Division
PRODUCT SHIPMENT

114
Systems Analysis

 Data Modeling – Data modeling the most popular technique for
expressing the business requirements for data that will be stored

in a system’s database.
 Process Modeling – Arguably, process modeling is the oldest
and most widely practiced technique for expressing both

business process requirements, work flow, inputs, and outputs.
 Distribution Modeling – Distribution modeling is used to
express the business geography to be supported by a system.

 Object Modeling – Object modeling is being driven by the
growing use of object technology and object-oriented analysis

methods to exploit that technology.
115
Systems Analysis

 Fact Finding – You can’t build models without facts. These
techniques are taught in Part Five, Module B, Fact Finding and

Information Gathering.
 Joint Application Development – JAD has become the most
popular technique for quickly constructing system models in

direct cooperation with system owners and system users. JAD
techniques merge the model construction and verification into
the same meetings to accelerate the project.

116
Systems Analysis

 Steps:
• Step 1 - Review the system improvement objectives and requirements

statement outline.
• Step 2 - Collect or retrieve any system models that may have been
developed in prior projects.
• Step 3 - (optional) If the appropriate CASE technology is available,
consider reverse engineering existing databases or applications into
physical system models. Then translate those physical models into
more business-friendly logical system models.
• Step 4 - Draw the interface model.
– The interface model establishes the scope and boundary for the
entire project.
117
Systems Analysis

 Steps:
(continued)
• Step 5a - If you practice structured analysis:
– Construct and verify the process models.
– Construct and verify data models.
– Synchronize process and data models. This synchronization
ensures that the models are consistent and compatible with one
another.
– Construct and verify distribution models.

118
Systems Analysis

 Steps:
(continued)
• Step 5b - If you practice information engineering :
– Construct and verify data models.
– Construct, verify, and synchronize the process models.
– Construct and verify the distribution models.
• Step 5c - If you practice object-oriented analysis:
– Identify use-cases. Use-cases are an object method that connects
objects to familiar business events. Use-cases are taught in the
object modeling chapter.
– Construct and verify object models. Several popular object model
standards exist.
119
Systems Analysis
 (optional) Activity: Build Discovery Prototypes

 An alternative or complementary approach to system modeling of
business requirements is to build discovery prototypes.
 Prototyping is the act of building a small-scale, representative,
or working model of the users’ requirements for purposes of

discovering or verifying the users’ requirements.
 Prototyping is typically used in the requirements definition phase to
establish user interface requirements.
 User interface prototypes are often called discovery prototypes.
 Discovery prototypes are simple mock-ups of screens and
reports that are intended to help systems analysts discover

requirements. The discovered requirements would normally be
added to system models. A synonym is requirements prototypes.
120
Systems Analysis

 Prototypes are developed using fourth generation languages
(4GLs), most of which include rapid application development
(RAD) facilities for quickly ‘painting’ screens, forms, and reports.
 Purpose:
 The purpose of this optional activity is to:
• establish user interface requirements, and

• discover detailed data and processing requirements interactively
with users through the rapid development of sample inputs and
outputs.

121
Systems Analysis

 Roles:
 Business analyst or systems analyst- facilitator
 System owners usually do not elect to participate unless they
are also system users.

• direct system users
 Systems analyst roles – systems analysts facilitate, observe,
and assist this activity. It should be recognized that many
systems analysts have the skills necessary to play the system
designer and builder roles described below.

122
Systems Analysis

 Roles:
 System designer roles:
• (optional) user interface specialist

 System builders roles:
• prototyper
• (optional) programmer

123
Systems Analysis

 This activity is not triggered by any event.
 It uses the system requirements outline and any system
models as they are developed.

 The deliverable of this activity are discovery prototypes of
selected inputs and outputs.

124
Systems Analysis

 Prototyping – Prototyping is predominantly considered to be a
design technique because it is based on design and construction

of actual program components.
 Technology – The actual use of prototyping will require an
investment in learning the technology to be used. Fortunately,

most of today’s visual programming languages are easy to
learn and use as prototyping tools.
• (Note – It will take a much greater knowledge of these languages
to complete the application’s development beyond the prototype.)

125
Systems Analysis

 Steps:
• Step 1 - Review the system improvement objectives and requirements

statement outline.
• Step 2 - Study any system models that may have been developed.
• Step 3 - (optional) Working directly with system users, construct a
simple, single-user prototype of the database and load it with some
sample data. Do not become preoccupied with data editing and
perfection.
• Step 4 - Working directly with the system users, construct input
prototypes for each business event. Do not worry about input editing,
system security, etc. – the focus is completely on business requirements.
Do not spend too much time on any one input since this stage does not
develop the final system.
126
Systems Analysis

 Steps:
• Step 5 - Working directly with system users, construct output

prototypes for each business output. Do not worry about whether
the data is real or whether or not it makes sense. Focus on
identifying the columns, totals, and graphs the users are seeking.
– If you built a sample database in step 3, and used step 4 to
collect data for that database, you can probably use that
database prototype to quickly generate sample reports.
• Step 6 - Return to the system modeling activity to formalize the
requirements that have been discovered through the above
prototyping steps.

127
Systems Analysis
 Activity: Prioritize Business Requirements

 Prioritization of business requirements also enables a popular
technique called timeboxing.
 Timeboxing is a technique which develops larger fully
functional systems in versions. The development team selects

the smallest subset of the system that, if fully implemented,
will return immediate value to the system owners and users.
That subset is developed, ideally with a time frame of 6-9
months or less. Subsequently, value-added versions of the
system are developed in similar time frames.
 Purpose:
 The purpose of this activity is to prioritize business
requirements for a new system.

128
Systems Analysis

 Roles:
 Business analyst or project manager - facilitator

• user managers
• project manager
• appropriate direct and indirect users

129
Systems Analysis

 Roles:
 Good system analysts listen to discussion and answer questions
during this activity. User ‘buy-in” to priorities is critical to the

political feasibility of any new system if a systems analyst or
project manager facilitates this activity.
 System designers are not typically involved in this activity
because they tend to influence priorities for technical, non-

business reasons.

130
Systems Analysis

 This activity can begin in parallel with the other definition
phase activities.
 The inputs are business requirements as expressed in the
updated business requirements outline, system models, and

discovery prototypes.
 The deliverable of this activity are business requirements’
priorities as recorded in the repository.

131
Systems Analysis

 There are no special techniques for prioritizing requirements.
 Steps:
• Step 1 - For each system input and output, categorize it as

mandatory, optional, or desirable.
• Step 2 - For each desirable requirement above, rank it with respect
to the other desirable requirements. Make note of any
dependencies that exist between requirements.
• Step 3 - For each optional requirement, rank it with respect to the
other optional requirements. Make note of any dependencies that
exist between requirements.
132
Systems Analysis

 Steps:
• Step 4 - (optional) Define system versions. A recommended

scheme follows:
– Version one consists of all mandatory requirements.
– Versions two through X consist of logical groupings of
desirable requirements.
– Optional requirements are usually added to versions as time
permits, or deferred to maintenance releases of the system.
Many such requirements are for new reports.

133
Systems Analysis
 Activity: Modify the Project Plan and Scope

 Purpose:
• modify the project plan to reflect changes in scope that have

become apparent during requirements definition, and
• secure approval to continue the project into the next phase.
– (Note: Work may have already started on the configuration or
design phases; however, the decisions still require review.)

134
Systems Analysis

 Roles:
 Project Manager - facilitator
• user managers
• project manager
 Other system analysts are not usually involved in this activity

135
Systems Analysis

 Roles:
 System designer roles:
• database administrator
• network administrator
• application administrator
 System builders are not involved in this activity.

136
Systems Analysis

 This activity is triggered by initial completion of the system
models, discovery prototypes, and the business

requirements priorities.
 The deliverable of this activity is a revised project plan that
covers the remainder of the project.

• Additionally, a detailed configuration plan and design plan could
be produced.

137
Systems Analysis

standards for applying the methodology to a project.




138
Systems Analysis

 Steps:
• Step 1 - Review the original plan.

• Step 2 - Review the up-to-date business requirements outline, system
models, discovery prototypes, and business requirements’ priorities.
Ask yourself two questions:
– Has the scope of the project significantly expanded?
– Are the requirements more substantial than originally anticipated?
• Step 3 - Estimate time required for each project activity in the next
phase – the definition phase.
• Step 4 - If necessary, refine baseline estimates for the overall project
plan.

139
Systems Analysis

 Steps:
• Step 5 - (optional) If the answer is yes, renegotiate scope,

schedule, and/or budget with the system owner group.

140
Systems Analysis
 Some Final Words about System Requirements

 A consolidation of all system models, discovery prototypes, and
supporting documentation is sometimes called a requirements
statement.
 All elements of the requirements statement are stored in the
repository, but most systems analysts find it useful to keep a

printed copy of that documentation for reference and reporting.

141
Systems Analysis
The Next Generation of Requirements Analysis
 Some predictions:
 CASE technology will continue to improve making it easier to
model system requirements. Two CASE technologies will lead the
charge.
 CASE tools will include object modeling to support emerging
object-oriented analysis techniques.

 CASE tools that support reverse engineering technology will
improve our ability to more quickly generate first draft system

models from existing databases and application programs.
 CASE technology and RAD technology will continue to
complement one another.

142
Systems Analysis
The Next Generation of Requirements Analysis
 Some predictions:
 Object-oriented analysis is poised to eventually replace structured
analysis and information engineering as the methods of choice.
 Process modeling will still be required because of business
process redesign projects.

143
Systems Analysis
Summary
 Introduction
 Strategies for Systems Analysis and Problem
Solving
 The Survey Phase of Systems Analysis
 The Study Phase of Systems Analysis
 The Definition Phase of Systems Analysis
 The Next Generation of Requirements Analysis

144

CHAPTER 4 Slides

Uploaded by

Copyright:

Available Formats

CHAPTER 4 Slides

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CHAPTER 4 Slides

Uploaded by

Copyright:

Available Formats

Systems Analysis

 The presentation will address the following questions:

Prepared by Kevin C. Dittman for

 What is System Analysis?

component pieces for purposes of studying how those

pieces back into a whole system – hopefully an improved

Prepared by Kevin C. Dittman for

 What is System Analysis?

Prepared by Kevin C. Dittman for

Prepared by Kevin C. Dittman for

computer-generated files that contain project correspondence,

 Hardcopy documentation (stored in notebooks, binders, and

Prepared by Kevin C. Dittman for

 The Repository and FAST

phase, so long as the necessary information is already in the

Prepared by Kevin C. Dittman for

 Modern Structured Analysis

that is used to model business requirements for a system. The

Prepared by Kevin C. Dittman for

 Modern Structured Analysis

worth a thousand words’, most models use pictures to represent

of models to define business requirements and information

Prepared by Kevin C. Dittman for

 Modern Structured Analysis

called data flow diagrams that depict the essential processes of

requirements of the system independent of any physical,

Prepared by Kevin C. Dittman for

Existing order details Orders Revised automatic order

Prepared by Kevin C. Dittman for

 Information Engineering (IE)

sensitive technique that is applied to the organization as a

Prepared by Kevin C. Dittman for

 Information Engineering (IE)

methods to examine the business as a whole for the purpose of

 Information Engineering (IE)

system applications are ‘carved out’ and prioritized.

 In addition to data models, information engineers also draw

process models similar to those drawn in structured analysis.

Prepared by Kevin C. Dittman for

Member placed by; is enrolled under;

sells; generates; established by;

is featured in; sponsors;

Prepared by Kevin C. Dittman for

specific technology that might be applied to the business

prototyping) is used to ‘discover’ the users’ business

 Joint Application Development (JAD)

facilitator for a workshop.

Prepared by Kevin C. Dittman for

 Business Process Redesign (BPR)

 Each process is studied and analyzed for bottlenecks, value-

returned, and opportunities for elimination or streamlining.

projects conclude by examining how information technology

Prepared by Kevin C. Dittman for

 Object-Oriented Analysis (OOA)

Prepared by Kevin C. Dittman for

 FAST Systems Analysis Strategies

area analysis, decision support system development, and business

Prepared by Kevin C. Dittman for

worth looking at?”

perceived problems, opportunities, and directives that triggered