systems analysis and design in a changing world, fourth edition
TRANSCRIPT
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
OTHER FACT-FINDING TECHNIQUES
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
OTHER FACT-FINDING TECHNIQUES
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
OTHER FACT-FINDING TECHNIQUES
Sampling Systematic sample Stratified sample Random sample Main objective of a sample is to ensure that it
represents the overall population accurately
32
OTHER FACT-FINDING TECHNIQUES
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
ANALYZING PROCEDURES AND OTHER DOCUMENTS (CONT.)
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
ANALYZING PROCEDURES AND OTHER DOCUMENTS (CONT.)
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
ANALYZING PROCEDURES AND OTHER DOCUMENTS (CONT.)
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
ANALYZING PROCEDURES AND OTHER DOCUMENTS (CONT.)
41
ANALYZING PROCEDURES AND OTHER DOCUMENTS (CONT.)
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
ANALYZING PROCEDURES AND OTHER DOCUMENTS (CONT.)
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
SYSTEM REQUIREMENTS CHECKLIST
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
SYSTEM REQUIREMENTS CHECKLIST
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
SYSTEM REQUIREMENTS CHECKLIST
Performance The system must support 25 users online
simultaneously Response time must not exceed four seconds
48
SYSTEM REQUIREMENTS CHECKLIST
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