systems analysis and design in a changing world, fourth edition

Systems Analysis and Design in a Changing World, Fourth Edition

LEARNING OBJECTIVES

Describe the activities of the systems analysis life cycle phase

Determine system requirements through review of documentation, interviews, observation, prototypes, questionnaires, vendor research, and joint application design sessions

Describe the difference between functional and nonfunctional system requirements

2

LEARNING OBJECTIVES (CONTINUED)

Describe the kind of information that is required to develop system requirements

Identify and understand the different types of users who will be involved in investigating system requirements

Discuss the need for validation of system requirements to ensure accuracy and completeness and the use of a structured walkthrough

Explain the effect of business process reengineering on activities of the analysis phase

3

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

THE ACTIVITIES OF THE ANALYSIS PHASE (FIGURE 4-1)

5

THE ANALYSIS PHASE IN MORE DETAIL

Gather information – Fact Finding

Define system requirements

Functional and nonfunctional

Prioritize requirements

Prototype for feasibility and discovery

Generate and evaluate alternatives

Review recommendations with management6

ZACHMAN FRAMEWORK FOR ENTERPRISE ARCHITECTURE (FIGURE 4-3)

7

FACT-FINDING TECHNIQUES

The Zachman Framework Zachman Framework

for Enterprise Architecture

Helps managers and users understand the model and assures that overall business goals translate into successful IT projects 8

ACTIVITIES OF THE ANALYSIS PHASE AND THEIR KEY QUESTIONS (FIGURE 4-2)

9

FACT-FINDING

Fact-Finding Overview First, you must identify the information you need Develop a fact-finding plan

Who, What, Where, When, How, and Why? Difference between asking what is being done

and what could or should be done

10

THEMES FOR INFORMATION-GATHERING QUESTIONS (FIGURE 4-7)

11

FACT-FINDING TECHNIQUES

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

12

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

13

SAMPLE ORDER FORM FOR RMO

14

INTERVIEWS

Step 1: Determine the People to Interview Informal structures

Step 2: Establish Objectives for the Interview Determine the

general areas to be discussed

List the facts you want to gather 15

INTERVIEWS

Step 3: Develop Interview Questions Creating a standard list of interview questions

helps to keep you on track and avoid unnecessary tangents

Avoid leading questions Open-ended questions Closed-ended questions Range-of-response questions

16

INTERVIEWS

Step 4: Prepare for the Interview Careful preparation is essential because an

interview is an important meeting and not just a casual chat

Limit the interview to no more than one hour Send a list of topics Ask the interviewee to have samples available

17

INTERVIEWS

Step 5: Conduct the Interview Develop a specific plan for the meeting Begin by introducing yourself, describing the

project, and explaining your interview objectives Engaged listening Allow the person enough time to think about the

question After an interview, you should summarize the

session and seek a confirmation

18

INTERVIEWS

• Step 6: Document the Interview– Note taking should be kept to a minimum– After conducting the interview, you must record

the information quickly– After the interview, send memo to the

interviewee expressing your appreciation– Note date, time, location, purpose of the

interview, and the main points you discussed so the interviewee has a written summary and can offer additions or corrections

19

INTERVIEWS

Step 7: Evaluate the Interview In addition to recording the facts obtained in an

interview, try to identify any possible biases Unsuccessful Interviews

No matter how well you prepare for interviews, some are not successful

20

INTERVIEWING AND LISTENING (CONT.)

21

SAMPLE CHECKLIST TO PREPARE FOR USER INTERVIEWS (FIGURE 4-9)

22

A SAMPLE OPEN-ITEMS LIST (FIGURE 4-11)

23

INTERVIEWING GROUPS

Drawbacks to individual interviews Contradictions and inconsistencies between

interviewees. Follow-up discussions are time consuming. New interviews may reveal new questions that require

additional interviews with those interviewed earlier.

24

INTERVIEWING GROUPS (CONT.)

Interview several key people together Advantages

More effective use of time.Can hear agreements and disagreements

at once.Opportunity for synergies.

DisadvantagesMore difficult to schedule than individual

interviews.

25

NOMINAL GROUP TECHNIQUE (NGT) A facilitated process that supports idea

generation by groups. Process

Members come together as a group, but initially work separately.

Each person writes ideas. Facilitator reads ideas out loud, and they are

written on a blackboard or flipchart.

26

NOMINAL GROUP TECHNIQUE (NGT)

Group openly discusses the ideas for clarification.

Ideas are prioritized, combined, selected, reduced.

NGT exercise used to complement group meetings or as part of JAD effort.

27

OTHER FACT-FINDING TECHNIQUES

• Observation– Seeing the system in

action gives you additional perspective and a better understanding of the system procedures

– Plan your observations in advance

– Hawthorne Effect28

DIRECTLY OBSERVING USERS Direct Observation

Watching users do their jobs Obtaining more firsthand and objective measures

of employee interaction with information systems.

Can cause people to change their normal operating behavior.

Time-consuming and limited time to observe.

29


Questionnaires and Surveys When designing a

questionnaire, the most important rule of all is to make sure that your questions collect the right data in a form that you can use to further your fact-finding

Fill-in form

30


Interviews versus Questionnaires Interview is more familiar and personal Questionnaire gives many people the

opportunity to provide input and suggestions Brainstorming Structured brainstorming Unstructured brainstorming

31


Sampling Systematic sample Stratified sample Random sample Main objective of a sample is to ensure that it

represents the overall population accurately

32


Research Can include the

Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments

Site visit

33

DOCUMENTATION

The Need for Recording the Facts Record information as soon as you obtain it Use the simplest recording method Record your findings in such a way that they can

be understood by someone else Organize your documentation so related material

is located easily

34

ANALYZING PROCEDURES AND OTHER DOCUMENTS Document Analysis

Review of existing business documents Can give a historical and “formal” view of system

requirements Types of information to be discovered:

Problems with existing system Opportunity to meet new need Organizational direction

35

ANALYZING PROCEDURES AND OTHER DOCUMENTS (CONT.)

Names of key individuals Values of organization Special information processing circumstances Reasons for current system design Rules for processing data

36


Useful document: Written work procedure For an individual or work group. Describes how a particular job or task is

performed. Includes data and information used and created

in the process.

37


38

ANALYZING PROCEDURES AND OTHER DOCUMENTS (CONT.) Potential Problems with Procedure

Documents: May involve duplication of effort. May have missing procedures. May be out of date. May contradict information obtained through

interviews.

39


Useful document: Business form Used for all types of business functions. Explicitly indicate what data flow in and out

of a system and data necessary for the system to function.

Gives crucial information about the nature of the organization.

40


41


Useful document: Report Primary output of current system. Enables you to work backwards from the

report to the data needed to generate it. Useful document: Description of current

information system

42


43

DOCUMENTATION

Software Tools CASE Tools Productivity

Software Graphics modeling

software Personal information

managers Wireless

communication devices

44

SYSTEM REQUIREMENTS CHECKLIST

Outputs The Web site must report online volume statistics

every four hours, and hourly during peak periods The inventory system must produce a daily

report showing the part number, description, quantity on hand, quantity allocated, quantity available, and unit cost of all sorted by part number

45


Inputs Manufacturing employees must swipe their ID

cards into online data collection terminals that record labor costs and calculate production efficiency

The department head must enter overtime hours on a separate screen

46


Processes The student records system must calculate the

GPA at the end of each semester As the final step in year-end processing, the

payroll system must update employee salaries, bonuses, and benefits and produce tax data required by the IRS

47


Performance The system must support 25 users online

simultaneously Response time must not exceed four seconds

48


Controls The system must provide logon security at the

operating system level and at the application level

An employee record must be added, changed, or deleted only by a member of the human resources department

49

DEFINE SYSTEM REQUIREMENTS

Are all of the capabilities and constraints that the new system must meet or Define the functions to be provided by a system.Analyst divide system requirements into two categories:Functional requirements: that describes an:

Activities system must perform (use cases) (e.g. Calculate commission amount, calculate payroll tax…etc.)

Based on procedures and business functions Documented in analysis models (e.g. all new

employee must fill out a W-4 form) Other business rules more difficult to find like an

additional 2 percent commission rate is paid to order takers on telephone sales for special promotions

50

SYSTEM REQUIREMENTS… CONTINUED Nonfunctional requirements: are characteristics of the system

other than activities it must perform, and support. Types of Nonfunctional requirements:

Technical requirements : (operational characters related to environment) hardware, software, of the organization.

Performance requirements : (Measures) workload, such as response time( one-half second response on all screens.

Usability requirements: (Users) user interface, related work procedures, online help… etc.).

Reliability requirements: describe the dependency of the system- incorrect processing and how it detects and recovers from those problem.

Security requirements: what system function under what conditions

51

SYSTEM REQUIREMENTS… CONTINUED The modeling process is a learning process for an

analyst. Modeling continues while information is gathered. Analyst continually reviews the models with end users

to verify that each model is completed. Types of system models: Logical Model: shows what the system is required to

do in great detail without committing to any one technology.

Focus of this model what information the users need. Using it in the analysis phase Physical Model: show how the system will actually be

implemented Using it in the design phase.

52

RELATIONSHIP BETWEEN INFORMATION GATHERING AND MODEL BUILDING (FIGURE 4-6)

53

REASONS FOR MODELING

Learning from the modeling process. Reducing complexity by abstraction. Remembering all of the details. Communicating with other and development

team members. Communicating with a variety of users and

stakeholders.. Documenting what was done for future

maintenance/ enhancement.

54

MODELS CAN CATEGORIZED INTO THREE DIFFERENT MODELS

1. Mathematical Models: a series of formulas that describe technical aspects of the system (Calculate the response time).

2. Descriptive Model: narrative memos, report, or lists that describe some aspect of the system. E.g. figure 4-4 page 127.

3. Graphical Models: Diagram and schematic representations of some aspect of the system like screen design or report layout design

55

PRIORITIZE REQUIREMENTS

Establish which of the function and technical requirements are most crucial for the systems.

Why prioritize the functional requested?• Resources are always limited.• Analyst must be prepared to justify the scope

of the systems• Systems requirements tends to expand as

users make more suggestions( scope creep)

56

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

57

STAKEHOLDERS INTERESTED IN NEW SYSTEM DEVELOPMENT (FIGURE 4-4)

58

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

59

Activity Diagram Symbols (Figure 4-12)

60

ACTIVITY DIAGRAMTHAT MODELS A WORKFLOW (FIGURE 4-13)

61

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

62

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

63

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

64

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)

65

A JAD FACILITY (FIGURE 4-16)

66

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

67

USEFUL TECHNIQUES IN VENDOR RESEARCH

Technical specifications from vendor

Demo or trial system

References of existing clients

On-site visits

Printout of screens and reports68

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

69

PREVIEW OF LOGICAL MODELING At the conclusion of requirements modeling,

systems developers should have a clear understanding of business processes and system requirements

The next step is to construct a logical model of the system

IT professionals have differing views about systems development methodologies, and no universally accepted approach exists

70

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

71

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

72

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?

73

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

74

systems analysis and design in a changing world, fourth edition

Documents

changing world

editionsystems analysis

analysis phase figure

editionthe analysis

system requirementsidentify

existing business documents

details of business

business domain users