4

Systems Analysis and Design in a

Changing World, Fifth Edition
 4
Learning Objectives
 Describe the activities of systems analysis

 Explain the difference between functional and

nonfunctional system requirements

 Describe three types of models and reasons for

creating models

 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, joint application design sessions, and
vendor research

 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

6
 4
Activities of the Analysis Phase
and Their Key Questions

7
 4
System Requirements
 System requirements – specifications that define the
new system
 Functional requirements
 Activities system must perform (use cases)
 Based on procedures and business functions
 Documented in analysis models

8
 4
System Requirements (cont)
 Nonfunctional requirements
 Technical requirement – hardware and software
 Performance requirement – workload measures
 Usability requirement – user interface, workflow
 Reliability requirement – outages, error detection
 Security requirement – access & protection

9
 4
Models and Modeling
 Analyst describes information system requirements
using a collection of models
 Complex systems require more than one type of
model
 Models represent some aspect of the system being
built
 Process of creating models helps analyst clarify and
refine design
 Models assist communication with system users

10
 4
Reasons for Modeling

11
 4
Types of Models
 Different types of models are used in information
systems development

 Mathematical – formulas that describe technical

aspects of the system

 Descriptive – narrative memos, reports, or lists that

describe aspects of the system

 Graphical – diagrams and schematic representations

of some aspect of the system

12
 4
Some Descriptive Models

13
 4
Overview of Models Used
in Analysis and Design
 Analysis activities named “define system
requirements”
 Logical models
 Provide detail without regard to specific technology
 Design models
 Physical models
 Provide technical details
 Extend logical models

14
 4

Models
Created
During
Analysis

15
 4
Stakeholders—The 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

16
 4
Stakeholders Interested
in New System Development

17
 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

18
 4

RMO
Stakeholders

19
 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

20
Relationship Between Information 4
Gathering and Model Building

21
 4
Themes for Information-Gathering
Questions

22
 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

23
 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

24
 4
Sample Order Form for RMO

25
 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

26
 4
Sample Checklist to Prepare for User
Interviews

27
 4

Sample
Agenda for
Interview

28
 4
A Sample Open-Items List

29
 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

30
 4
Activity Diagrams
 Workflow – sequence of steps to process a business
transaction
 Activity Diagram – workflow diagram to describe
sequence of steps
 Synchronization bar – symbol to control splitting or
merging of a path on an activity diagram
 Swimlane – bounded area that contains activities of a
single agent

31
 4
Activity Diagram Symbols

32
 4
Activity
Diagram
that
Models a
Workflow

33
 4
Activity Diagram with Concurrent
Paths

34
 4
Build Prototypes
 Prototype - 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

35
 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

36
 4

Sample RMO
Questionnaire

37
 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

38
 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

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

40
 4
A JAD Facility

41
 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

42
 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

43
 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

44
 4

Structured
Walkthrough
Form

45
 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

46
 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?

47
 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

48