Analysis Phase Finalization

Course Objective or Competency	Module Objectives or Competency
The student will learn that systems analysis may also involve the "make or buy" decision, which in turn may impact hard selection. Students will be able to explain the critical factors that go into each of these decion-making processes.	The student will be able to list and explain the factors that go into the decision as to whether the computer software is to be built from scratch or purchased.
	The student will be able to list and explain the factors involved in hardware selection.

Analysis Phase

Involves converting the requirements specification into a problem specification.
The analyst uses data modeling, process modeling, or object-oriented modeling techniques, such as
- data flow diagrams
- data dictionary
- UML diagrams
DFDs, data models, data dictionaries, UML diagrams, etc., are used to develop a problem specification and a system proposal.
During this phase, analysts have their last chance to correct errors and omissions easily and cheaply.

Phase Name: Analysis
Major Function:	To determine the system requirements of a proposed new system.
Input:	Requirements specification
Output:	Problem specification System proposal
Principal Tools:	data dictionary data flow diagrams data models system models prototyping system flowcharts
Personnel & Tasks:	Users must continue to be heavily involved. The analyst diagrams the functions of the new system without specifying exactly how those functions are performed. The analyst may prepare a prototype of the system.

At the end of the analysis phase the decision must be made as to whether the computer software is to be built from scratch or purchased.
Much of the design phase can be omitted if the decision is made to purchase.
The analyst evaluates available software packages to see if any closely fit the users' needs.
It is economically more feasible for many businesses, especially smaller ones, to buy rather than to build software.

Only rarely will it precisely meet the needs of the users.
It may not be compatible with existing software applications in the organization.
Different applications from different vendors mean that each application will have a different user interface. With custom programming, all of the user interfaces can be designed to be similar.
There may be no in-house expert on board since the programmers and analysts may be no more familiar with the new software than are the users.
Commercial software packages often cannot be easily modified if the needs of the users change in the future.

How closely does the package fit with what is needed? Will it be necessary to modify the programs, or the proposed system procedures, or both?
How stable is the software vendor?
Does the vendor give prompt, courteous, and reliable support when problems arise?
Will the vendor be providing ongoing enhancements and upgrades to the software? At what cost?
Are source programs supplied so that the organization can do its own modifications?
Is there a trial period during which the package can be returned for a full refund?
How many other installations have used the software package? For how long? Who are they?
How flexible is the software? Can it change along with the changing business environment?
Is the software user-friendly? Is the documentation clear, complete, and easy to read?
With what other applications currently used by your organization does this application communicate?

Only after collecting data on the various software packages available does the analyst begin to worry about choosing the hardware.
The software is really what determines how well the computer system meets the user's needs.

Organizations must know comparative costs of the various system solutions in both hardware and software selection.
Cost-benefit analysis is performed at various stages of a system's development.
First performed during the feasibility study to compare various alternatives.
Used at this stage…
- to support the new system proposal, and/or
- to help choose between hardware/software alternatives