MIS485 1

An.

SystemRequirementHandout.pdf

Home >Information Systems homework help >MIS485 1

MIS485: Capstone Project in MIS

2MGT 400 - Project Management

Textbook: Farrell, P. J., (2017). IT Capstone

Project (3rd Edition), Kendall Hunt

Publishing.

Fact Finding Techniques and Determining System

Requirements

Introduction:

Three main steps:

1. Identifying potential development projects

2. Classifying and ranking IS development projects

3. Selecting IS development projects

At the end of the systems planning and selection phase of the SDLC:

• Management Can grant permission to pursue development of a new System.

• A project is initiated and planned. • System analyst begin determining what the

new system Should do….

Systems development life cycle with

analysis phase highlighted

Performing Requirements Determination

In the analysis phase, we need to:

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

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 characteristic or 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, portability

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 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.

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.

Performing Requirements Determination (Cont.)

• Characteristics of analysts while gathering requirements • Impertinence

• Question everything

• Impartiality • Find the best organizational solution

• Relaxation of constraints • Assume anything is possible and eliminate the infeasible

• Attention to detail • Every fact must fit with every other fact

• Reframing • View the organization in new ways

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

– 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

 Interviewing individuals and groups

 Observing workers

 Studying business documents

Traditional Methods for Determining Requirements: Traditional Fact-Gathering Finding techniques

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

 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

Traditional Methods for Determining Requirements (continued)

Analyzing Procedures (Cont.)

Example of a procedure

Analyzing Procedures (Cont.)

FIGURE 6-3 Example of a procedure (cont.)

 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

Traditional Methods for Determining Requirements (continued)

Analyzing Procedures and Other Documents (Cont.)

Figure 5-4 An invoice form from

Microsoft Excel

(Source: Microsoft Corporation.)

 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

Traditional Methods for Determining Requirements (continued)

Analyzing Procedures and Other Documents (Cont.)

Figure 5-5 An example of a report-

An accounting balance sheet

 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.

Traditional Methods for Determining Requirements (continued)

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

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