Anaysis Systems

Determining Requirements

The Objective is

To gather & record facts about the current system whether it is manual or computer based What is required to support business needs.

Analysis Systems
Determining Requirement
Analyzing Requirement

Evaluating Alternatives & Strategies

Preliminary Investigation Report

S y s t e m s A n a l y s i s

Determine the Facts

Objective: To get the facts

Analyze the Facts

Objective: To study the facts

Make a Decision
Objective: To prepare the systems requirements document

Next Phase or Terminate the poject

Determining Requirements

Emphasizes the process of gathering facts about the current system & proposed changes

Gather information on what system should do from many sources

Users Reports Forms Procedures

Types of deliverables:
Information collected from users Existing documents and files Computer-based information Understanding of organizational components

Business objective Information needs Rules of data processing Key events

Tips
To be successful during systems analysis, you must have both skils: Critical-Thinking Skill Interpersonal Skill

The 5 Magic Questions :

Who
What When Why ?

Where
How

Examples:

Who?

Who performs each of the procedures within the systems? Why? Are the correct people performing the activity? Could other people perfom the tasks more eefectively? What is being done? What procedures are being followed?Why is this process necessary?(often, procedures have been followed for many years & no knows why. You should question why a procedure is being followed at all)

What?

Where?

Where are operations being performed?why? Where could they be performed? Could they be performed more efficiently elsewhere? When is a prosedure performed?why is it being performed at this time? Is this the best time?

When?

How?

How is a procedure performed?why is it performed in this manner?could it be performed better, more efficiently, or less expensively in some other manner?

Requirement Determination
What is done? Where is it done? When is it done? Who does it? How is it done? Why is it done? Why is it done? Why is it done then Why does this person do it? Why is it done this way?

Requirement Analysis
What should be done? Where should it be done? When should it be done? Who should do it? How should it be done?

Determining Requirements

Systems Requirement Interviews Other Fact-Finding Techniques Recording The Facts Other Systems Development Techniques

Determining Requirements Systems Requirements

Outputs Inputs Processes Timing Controls Volumes, Sizes & Frequencies

Determining Requirements Interviews

Determine the People to Interview Establish Objectives for Interview Prepare for the Interview Conduct the Interview Document the Interview Evaluate the Interview Unsuccessful Interview

Determining Requirements Other Fact-Finding Techniques

Document Review Observation Questionnaires Sampling Work & Work People Graphics Research

Determining Requirements Recording The Fact

The Need for Recording the Facts Software Tools

Determining Requirements Other Systems development Techniques

Join Application Design (JAD) Prototyping Business Process Reengineering (BPR) Rapid Application Development (RAD) Object Oriented Systems Development

JAD Join Application Design

Brings together key users, managers and systems analysts (who document and record the result & decisions) Purpose: collect system requirements simultaneously from key people The Objective : analyze the existing system, work on potential solutions & agree on requirements for the new system. The JAD team usually meets over of days or weeks, in a spesial conference room or at an offsite location.

JAD Participants
Participants
Session Leader Users Managers Sponsor Systems Analysts Scribe IS Staff

JAD End Result

End Result
Documentation detailing existing system Features of proposed system

Prototyping
Repetitive process Rudimentary version of system is built Replaces or augments SDLC Goal: to develop concrete specifications for ultimate system

Prototyping
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 Most useful when:

User requests are not clear Few users are involved in the system Designs are complex and require concrete form History of communication problems between analysts and users Tools are readily available to build prototype

Prototyping - Drawbacks
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

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

Identification of processes to reengineer

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 Disruptive technologies

Technologies that enable the breaking of longheld business rules that inhibit organizations from making radical business changes

Rapid Application Development (RAD)

RAD is a general strategy rather than a single methodology Goals

To analyze a business process rapidly To design a viable system solution through intense cooperation between users and developers To get the finished application into the hands of the users quickly

Traditional SDLC steps are followed, but phases are combined Iteration is limited to design and development phases

RAD Components
User involvement is key to success Prototyping is conducted in sessions similar to Joint Application Design (JAD) Prototyping screens become screens within the production system CASE tools are used to design the prototypes

RAD - CASE and Visual Development Environments

Types of CASE tools

Diagramming tools Computer display and report generators Analysis tools used to check for incomplete, inconsistent or incorrect specifications A central repository Documentation generators Code generators CASE tools that support the creation of system forms and reports in order to prototype how systems will look and feel to users

Form and report generators

Code Generators

CASE tools that enable the automatic generation of program and database definition code directly from the design documents, diagrams, forms and reports stored in the repository

Approaches to RAD
James Martins pillars of RAD
Tools People Methodology Management

Approaches to RAD
Software Tools

Case tools can be used for

Prototyping Code generation

Martins RAD Life Cycle

Systems requirement determination is done in context of a discussion of business problems and business areas User Design

End users and IS professionals participate in JAD workshops CASE tools are used to support prototyping Designer creates code using code generator End user validates screens and other aspects of design New system is delivered to end users

Construction

Cutover

SUMMARY
Interviews
Open-ended and close-ended questions Preparation is key

Questionnaires
Must be carefully designed Can contain close-ended as well as open-ended questions

Other means of gathering requirements

Observing workers Analyzing business documents

Joint Application Design (JAD) Prototyping Business Process Reengineering (BPR)

Disruptive technologies

RAD