MIS360 2
MIS360 System Analysis
Chapter 5: Determining System Requirements
Learning Objectives
Describe options for designing and conducting interviews
Discuss planning an interview to determine system requirements
Explain advantages and disadvantages of observing workers and analyzing business documents to determine requirements
Learning Objectives (continued)
Learn about Joint Application Design (JAD) and Prototyping
Discuss appropriate methods to elicit system requests
Explain Business Process Reengineering (BPR)
Examine requirements determination for Internet applications
Introduction:
At the end of the systems planning and selection phase of the SDLC:
• Management Can grant permission to track development of a new System.
• A project is initiated and planned. • System analyst begin determining what the new
system Should do….
Three main steps:
1. Identifying potential development projects
2. Classifying and ranking IS development projects
3. Selecting IS development projects
(Determining Requirements)
Performing Requirements Determination
Systems development life cycle with
analysis phase highlighted
1. Get a good idea of
what the
requirements of the
system are.
2. Characterize them in
a structure that leads
amenably into a
system design
In the analysis phase, we need to:
Phase Description
• Systems analysis is the second phase in the SDLC.
• Will use fact-finding techniques which include interviewing, documentation review, observation, surveys and questionnaires, and sampling to study and understand the current system and then determine the requirements for the new proposed system.
• Will use requirements modeling, data and process modeling, and object modeling techniques to represent the new system
• Will consider various development strategies for the new system, and plan for the transition to systems design tasks
Systems Analysis Phase Overview
– The overall objective of the systems analysis phase is to Understand the proposed project,
Ensure that it will support business requirements
Build a solid foundation for system development
– You use models and other documentation tools to visualize and describe the proposed system
Part I: Understanding System Requirements
What is System Requirement? Type of system Requirements. Categories of System Requirements.
System Requirement:
Systems Requirements
- They are the feature that must be included in an
information system to satisfy business requirements,
and system improvement objectives and be acceptable
to users.
- System requirements serve as benchmarks to measure
the overall acceptability of the finished system
System Requirement:
Systems Requirements Types:
1. Functional Requirements: – are the descriptions of the system functions and services, – How the system should react to particular inputs – and how the system should behave in particular situations.
Examples of functional requirements: • Searching a record: The user shall be able to search either all of the initial
set of databases or select a subset from it. • Deletion of a record: The user shall be able to delete the existing record of
any patient. • Updating a record: The user shall be able to update the information of any
patient • Create new record: ….etc.
System Requirement: (Cont.)
Systems Requirements Types: 2. Non-Functional Requirements:
– are constraints on the services, or functions offered by the system – such as timing constraints, constraints on the development process,
standards, etc.
• Often described as the Usability : the system is user friendly (or easy to use) Reliability: the system is error free and maintains up to date databases. Performance: easy searching and updating of records Security: Only authorized users can access the system with user name
and password (or ID).
Other: scalability, availability, flexibility, configurability
System Requirements Categories examples:
• 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.
• 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
System Requirements Categories examples:
• 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 top management.
• Performance • The system must support 25 users online simultaneously • Response time must not exceed four seconds.
• Security and Controls • The system must provide login 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.
Part II: Performing Requirements Determination
Performing Requirements Determination
• During the requirements determination, system analysts gather information on what system should do from many sources: such as • Users of the current system • Reports • Forms • Procedures
• All of the system requirements are carefully documented and prepared for structuring.
Structuring means taking the system requirements you find during requirements determination and ordering them into tables, diagrams, and
other formats that make them easier to translate into technical system specifications.
Deliverables for Requirements Determination
• From interviews and observations • interview transcripts, observation notes, meeting minutes.
• From existing written documents • mission and strategy statements, business forms, procedure manuals, job
descriptions, training manuals, system documentation, flowcharts.
• From computerized sources • Joint Application Design session results, CASE repositories, reports from
existing systems, displays and reports from system prototype
Traditional Methods for Determining Requirements: Traditional Fact-Gathering Finding techniques
• Fact-Finding Overview
– First, you must identify the information you need
–
• Who, What, Where, When, How, and Why?
– Difference between asking what is being done and what could or should be done
Traditional Methods for Determining Requirements: Traditional Fact-Gathering Finding techniques
Interviewing individuals and groups
Observing workers
Studying business documents
Traditional Methods for Determining Requirements (Cont.)
Traditional Methods for Determining Requirements (Cont.)
Interviewing o One of the primary ways analysts gather information
about an information systems project.
• Gather facts, opinions, and speculations.
o Analysts need to
• Observe body language and emotions.
• Prepare an interview guide: is a document for
planning, developing, and conducting an interview.
Traditional Methods for Determining Requirements (Cont.)
Interviewing o Step 1: Determine the People to Interview
• Informal structures
o Step 2: Establish Objectives for the Interview
• Determine the general areas to be discussed
• List the facts you want to gather
Traditional Methods for Determining Requirements (Cont.)
Interviewing (Continued) o Step 3: Choosing/ developing Interview Questions
Each question in an interview guide can include both verbal and non- verbal information. Open-Ended Questions.
No pre-specified answers Used to probe for unanticipated answers
Close-Ended Questions. Respondent is asked to choose from a set of specified
responses Work well when the popular answers to questions are known Do not require a long period of time, and can cover a greater
number of topics
Traditional Methods for Determining Requirements (Cont.)
Interviewing o Step 4: Prepare for the Interview
• Careful preparation
• Limit the interview time
o 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
Traditional Methods for Determining Requirements (Cont.)
Interviewing o 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.
o Step 7: Evaluate the Interview
Traditional Methods for Determining Requirements (continued) Directly Observing Users
• Serves as a good method to supplement interviews
• Direct Observation
• Watching users do their jobs
• Used to obtain more firsthand and objective measures of employee interaction with information systems
• Often difficult to obtain unbiased data
• People often work differently when being observed
• Time-consuming and limited time to observe
Traditional Methods for Determining Requirements (continued)
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
• Title and names of key individuals
• Values of organization
• Special information processing circumstances
• Rules for processing data
Traditional Methods for Determining Requirements (continued)
Analyzing Procedures and Other Documents (Cont.)
Useful document to be analyzed:
1. Written work procedure
2. Business form
3. Reports
4. Description of current information system
Traditional Methods for Determining Requirements (continued)
Analyzing Procedures and Other Documents (Cont.)
1. 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
Analyzing Procedures (Cont.)
Example of a procedure
Analyzing Procedures (Cont.)
FIGURE 6-3 Example of a procedure (cont.)
Traditional Methods for Determining Requirements (continued)
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
• All of the above problems illustrate the difference between formal systems and informal systems.
Traditional Methods for Determining Requirements (continued)
Analyzing Procedures and Other Documents (Cont.)
• Formal Systems: the official way a system works as described in organizational documentation (i.e. work procedure)
• Informal Systems: the way a system actually works (i.e. interviews, observations)
Traditional Methods for Determining Requirements (continued)
Analyzing Procedures and Other Documents (Cont.) 2. Useful document: Business form
• Used for all types of business functions
• Explicitly indicates 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
Analyzing Procedures and Other Documents (Cont.)
Figure 5-4 An invoice form from
Microsoft Excel
(Source: Microsoft Corporation.)
Traditional Methods for Determining Requirements (continued)
Analyzing Procedures and Other Documents (Cont.) 3. Useful document: Reports
• Primary output of current system
• Enables you to work backwards from the report to the data needed to generate it
Analyzing Procedures and Other Documents (Cont.)
Figure 5-5 An example of a report-
An accounting balance sheet
Traditional Methods for Determining Requirements (continued)
Analyzing Procedures and Other Documents (Cont.) 4. Useful document: Description of current information system
• It is applied, If the current system is computer-based.
• Include the documents that describe how the system was designed and how it was work.
• A lot of different types of documents fit this description; everything from flowcharts to data dictionaries and CASE tool reports to user manuals.
Modern Methods and Techniques for Determining Requirements
Joint Application Design (JAD)
• Brings together key users, managers, and systems analysts
• Purpose: collect system requirements simultaneously from
key people
• Conducted off-site
Prototyping
• Repetitive process
• Rudimentary version of system is built
• Replaces or augments SDLC
• Goal: to develop concrete specifications for ultimate system
Joint Application Design (JAD)
• Participants • Session leader
• Users
• Managers
• Sponsor
• Systems analysts
• Scribe
• IS staff
Joint Application Design (JAD) (continued)
• End Result • Documentation detailing
• Existing system
• Features of a replacement system
Prototyping
• User quickly converts requirements to working version of system
• Once the user sees requirements converted to system, will ask for modifications or will generate additional requests
Prototyping (continued)
• Most useful when: • User requests are not clear
• Few users are involved in the system
• Designs are complex and require concrete form to evaluate fully
• History of communication problems between analysts and users
• Tools are readily available to build prototype
Prototyping (continued)
• Drawbacks • Tendency to avoid formal documentation
• Difficult to adapt to more general user audience
• Sharing data with other systems is often not considered
• Systems Development Life Cycle (SDLC) checks are often bypassed
Radical Methods For Determining System Requirements Whether Traditional Or Modern,
The Business Process Reengineering (BPR)
• Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services
• Goals • Reorganize complete flow of data in major sections of an
organization
• Eliminate unnecessary steps
• Combine steps
• Become more responsive to future change
Business Process Reengineering (BPR) (continued)
• Identification of processes to reengineer • Identifying Key business processes
• Set of activities designed to produce specific output for a particular customer or market
• Focused on customers and outcome
• Same techniques are used as were used for requirements determination
• Identify specific activities that can be improved through BPR
Business Process Reengineering (BPR) (continued)
• Identification of processes to reengineer • Disruptive Technologies
• Technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes
• See Table 5-5
Summary
• Interviews • Open-ended and close-ended questions
• Preparation is key
• Other means of gathering requirements are: • Observing workers
• Analyzing business documents
Summary (continued)
• Joint Application Design (JAD)
• Prototyping
• Business Process Reengineering (BPR) • Disruptive technologies