4

Systems Analysis and Design in a

Changing World, Fourth Edition
 4
Learning Objectives
Describe the activities of the systems analysis life
cycle phase
Explain the effect of business process
reengineering on activities of the analysis phase
Describe the difference between functional and
nonfunctional system requirements
Identify and understand the different types of
users who will be involved in investigating system
requirements

2
 4
Learning Objectives (continued)
Describe the kind of information that is required
to develop system requirements
Determine system requirements through review
of documentation, interviews, observation,
prototypes, questionnaires, vendor research, and
joint application design sessions
Discuss the need for validation of system
requirements to ensure accuracy and
completeness and the use of a structured
walkthrough
3
 4
Overview
Analysis phase of SDLC skills needed
Fact finding for investigation of system
requirements
Analyst should learn details of business processes
and daily operations
Analyst should become as knowledgeable as
business domain users to build credibility
Analyst brings fresh perspective to problem
Modeling of business processes based on system
requirements
4
 4
The Analysis Phase in More Detail
Gather information
Define system requirements
Functional and nonfunctional

Prioritize requirements
Prototype for feasibility and discovery
Generate and evaluate alternatives
Review recommendations with management
5
 4
The Activities of the Analysis Phase
(Figure 4-1)

6
 4
Activities of the Analysis Phase
and Their Key Questions (Figure 4-2)

7
 4
Business Process Reengineering
and Analysis
Fundamental strategic approach to organizing
company
Streamlines internal processes to be as efficient
and effective as possible
Questions basic assumptions for doing business
and seeks to find a better way
Uses IT as BPR enabler
Systems analyst may discover opportunities for
process improvement
Any project may include components of BPR
8
Zachman Framework for Enterprise Architecture 4
(Figure 4-3)

9
 4
System Requirements
New system capabilities and constraints
Functional requirements
Activities system must perform (use cases)
Based on procedures and business functions
Documented in analysis models
Nonfunctional requirements
Technical environment or performance objectives
Usability, reliability, and security requirements

10
 4
StakeholdersThe Source of
System Requirements
People with interest in successful system
implementation

Three primary groups of stakeholders

Users (use system)

Clients (pay for and own system)

Technical staff (ensure system operation)

Every type of stakeholder is identified by analyst

11
 4
Stakeholders Interested
in New System Development (Figure 4-4)

12
 4
More On Users as Stakeholders
Horizontal user roles information flow across
departments
Vertical user roles information needs of clerical
staff, middle management, and senior executives
Business users perform day-to-day operations
Information users need current information
Management users need summary information
Executive users need strategic information
External users may have access to system

13
 4
Techniques for Information Gathering
Analysis phase done to understand business
functions and develop system requirements
Original structured approach
Create model of existing system
Derive requirements from existing system model
Current approach
Identify logical requirements for new system
Balance the review of current business functions
with new system requirements

14
 Relationship Between Information 4
Gathering and Model Building (Figure 4-6)

15
 4
Themes for Information-Gathering
Questions (Figure 4-7)

16
 4
Fact-Finding Methods
Review existing reports, forms, and procedure
descriptions
Interview and discuss processes with users
Observe and document business processes
Build prototypes
Distribute and collect questionnaires
Conduct joint application design (JAD) sessions
Research vendor solutions

17
 4
Review Existing Reports, Forms,
and Procedure Descriptions
Source: External industry-wide professional
organizations and trade publications
Source: Existing business documents and
procedure descriptions within organization
Identify business rules, discrepancies, and
redundancies
Be cautious of outdated material
Obtain preliminary understanding of processes
Use as guidelines/visual cues to guide interviews

18
 4
Sample Order Form for RMO (Figure 4-8)

19
 4
Conduct Interviews and Discussions with Users
Effective way to understand business functions
and rules
Time consuming and resource expensive
May require multiple sessions to
Meet all users
Understand all processing requirements
Can meet with individuals or groups of users
List of detailed questions prepared

20
 4
Sample Checklist to Prepare for User
Interviews (Figure 4-9)

21
 4
A Sample Open-Items List (Figure 4-11)

22
 4
Observe and Document Business Processes

Varies from office walkthroughs to performing

actual tasks

Not necessary to observe all processes at same

level of detail

May make users nervous, so use common sense

Can document workflows with UML activity

diagrams

23
 4
Activity Diagram Symbols (Figure 4-12)

24
 4
Activity
Diagram
that
Models a
Workflow
(Figure 4-13)

25
 4
Build Prototypes
Preliminary working model of a larger, more
complex system component
Discovery, design, evolving prototypes
Prototype should be
Operative
Working model to provide look and feel
Focused to accomplish single objective
Quick
Built and modified rapidly with CASE tools

26
 4
Distribute and Collect Questionnaires
Limited and specific information from a large
number of stakeholders
Preliminary insight into business
Not well suited for gathering detailed information
Closed-ended questions direct person answering
question
Open-ended questions encourage discussion and
elaboration

27
 4
Conduct Joint Application Design Sessions

Expedites investigation of system requirements

Seeks to compress fact-finding, modeling, policy

formation, and verification activities into shorter
time frame

Critical factor is to have all important

stakeholders present

28
 4
Joint Application Design Participants
Session leader trained in group dynamics and
JAD group facilitation
Knowledgeable business and system users and
policy makers
Technical staff representatives to handle
Computer and network configurations
Operating environments
Security issues
Project team members

29
 4
Joint Application Design Facilities
Conducted in special room
Limit interruptions
May be off-site
Resources
Overhead projector, white board, flip charts, work
material
Electronic support (laptops)
CASE tools
Group support systems (GSS)

30
 4
A JAD Facility (Figure 4-16)

31
 4
Research Vendor Solutions
Many problems have been solved by other
companies
Positive contributions of vendor solutions
Frequently provide new ideas
May be state of the art
Cheaper and less risky
Danger
May purchase solution before understanding
problem

32
 4
Useful Techniques in Vendor Research
Technical specifications from vendor

Demo or trial system

References of existing clients

On-site visits

Printout of screens and reports

33
 4
Validating the Requirements
Make sure gathered information is correct
Structured walkthrough
Effective means of implementing quality control
early in project
Verify and validate system requirements
Review of findings from investigation and of
models based on findings
Project manager responsible for system quality
Systems analyst, project manager are partners

34
 4
Summary
Analysis phase activities
Gather information
Define system requirements
Prioritize requirements
Prototype for feasibility and discovery
Generate and evaluate alternatives
Review recommendations with management
BPR and Zachman Framework can help with the
analysis phase activities

35
 4
Summary (continued)
Gathering system requirements
Functional and nonfunctional
Work with various stakeholders (users, clients,
technical staff)
What kind of information do I need?
What are the business processes and operations?
How are the business processes performed?
What are the information requirements?

36
 4
Summary (continued)
Primary information-gathering techniques
Review existing reports, forms, and procedure
descriptions
Conduct interviews and discussions with users
Observe and document business processes
Build prototype working models
Distribute and collect questionnaires
Conduct JAD sessions
Research vendor solutions

37