MODULE 1: Building Information Systems

WHAT IS SYSTEM?
Decisions - It is difficult to observe the decision process, though we can see and review the results of a
decision.
Transactions and processing - Transactions are usually more visible, though many current systems use
computer programs, which are not easy to understand, to process transactions.
Information and its flow - In principle, an observer can see information and its flows
Individuals or functions involved - Individuals can also be observed, but it is not always easy to figure
out what information processing functions they perform.
Communications and coordination - Systems also have implications for the way individuals
communicate and for coordinating a firm's activities.
Much of systems analysis and design consists of developing a sufficient understanding of a system to
document it.

MULTI-USER vs SINGLE-USER
Single-user design
Multi-user systems should be contrasted with a more personal system designed by the eventual user.
Individuals frequently develop systems for their personal computers. These applications do not have the
same requirements as multi-user systems because the systems designer is the systems user. He or she
does not have to worry about developing a system for others to use nor does the system have to meet the
needs of many different individuals.

Multi-user design
We have examined multi-user systems, those used by a number of individuals in the organization. One
group usually develops these systems for use by another group of employees. As such, development
requires input from the individuals who are likely to be affected by the application.

A SYSTEM DESIGN LIFE CYCLE

Inception
The idea for a new information system is stimulated by a need to improve existing procedures or take
advantage of a new opportunity.
This leads to a preliminary survey to determine if a system can be developed to meet the objectives of the
individuals suggesting it.
Feasibility study
If the results of the survey are positive, it is refined to produce a more detailed feasibility study.
From the outcome of the feasibility study, a decision is made whether to proceed with the design of a
system.
If a positive decision is made, one of the alternatives sketched in the feasibility study is chosen for
development.
System analysis
In systems analysis, the existing information processing procedures are documented in detail.
During requirements analysis, designers attempt to learn what users expect the new system to do.
One major task during this phase is to define the boundaries of the system. Does the problem concern
only inventory control, or should any new system also consider problems in purchasing when inventory
has to be replenished?
During analysis, data are also collected on the volume of transactions, decision points, and existing files.
Design
The most challenging and creative part of the life cycle is the design of a new system. One approach to
this task is to develop an ideal system relatively unconstrained by cost or technology.
This ideal system is then refined until it becomes feasible.
Specifications
Designers must prepare detailed specifications for the system being designed. They specify the exact
logic to be followed in processing and the content structure of the file.
Designers select input and output methods, and develop the formats for input and output.
These requirements for processing, inputs, and outputs lead to the specification of programming
requirements, which can then be turned over to a programming staff for coding.
Building
In the building stage, we develop the components needed to construct the system.
Often this involves writing computer programs to perform the logical operations of processing.
In some firms, this task is done by a separate group of programmers. Other organizations use analyst-
programmers: The same individuals who perform the systems analysis and design also code the resulting
programs.
Testing
Programs have to be tested carefully, first as units and then in combined modules.
Usually a programming task is broken down into a series of smaller subtasks or modules. All the
individual modules must operate together if the system is to work properly.
During the final stages of testing, there will be some type of acceptance test in which users verify that the
system works satisfactorily.
Training
Since one purpose of the new information processing system is to change existing procedures, training is
crucial. All individuals have to understand what is required by the new system.
Conversion/Installation
When training has been completed, it is possible to undertake conversion; it may be necessary to write
special programs to convert existing files into new ones or to create files from manual records.
Finally, after all these stages are complete, a team installs the system.
The operational stage begins after the problems of installation are resolved and the organization has
adjusted to the changes created by the new system.
Operations
The system now operates on a routine basis.
This does not mean we do not change the system; however, there is a constant need for maintenance and
enhancements.
Maintenance is required because programs inevitably have errors that must be corrected when they
appear.
USER ROLES DURING SYSTEM DESIGN
Inception
• Initiate study,
• Suggest application,
• Sketch information needs, describe existing processing procedures.
Feasibility study
• Help evaluate existing system and proposed alternatives,
• Select alternative for design.
System analysis
• Help describe existing system,
• Collect and analyze data.
Design
• Design output, input, processing logic,
• Plan for conversion and forecast impact on users,
• Design manual procedures,
• Remain aware of file structures and design.
Specifications
• Review specifications,
• Help develop specifications for manual procedures.
Building
• Monitor progress.
Testing
• Generate test data and evaluate results.
Training
• Develop materials,
• Conduct training sessions.
Conversion/Installation
• Phase conversion,
• Provide resources,
• Conduct a post-implementation audit.
Operations
• Provide data and utilize output,
• Monitor system use and quality,
• Suggest modifications and enhancements.

POTENTIAL PITFALLS IN THE CYCLE

Difficulty 1

 First, the stages tend to focus attention on a particular design approach. We shall see several
alternatives to conventional design in subsequent chapters.
Difficulty 2

 The steps in the life cycle also imply that the analyst is in control of the design process. If a
design team works under this impression, there will be too little participation by users.
Difficulty 3

 A very serious shortcoming of the life cycle model is that many analysts seem to interpret it as
requiring the development of only one alternative. Users and managers need to have a series of
options from which to choose. They are poorly served by designers who provide a single design
for a new system rather than one with alternatives to the status quo.
Difficulty 4

 Not all of the stages may be necessary in developing a system. There may be ways to shorten the
life cycle and to skip certain stages. Most discussions of the life cycle do not suggest shortcuts in
development. The systems life cycle provides a complete list of tasks, but we need to be flexible
in how those tasks are accomplished and in what alternatives are presented to management.

DESIGN TEAM
Team Leader: A User

 Having a user in charge makes the user's role apparent, ensures time will be available from other
users, and demonstrates a strong commitment to users on the part of the information services
department. Normal job activities should be reduced for the user in charge of the design team.
Liaison Representative

 In case there are too many individuals for all of them to be involved, liaison representatives are
suggested. These people interview other users and brief them on the system as it is developed.
They are responsible for soliciting participation in the phases where it is meaningful.
The Users

 The actual analysis and design work is done by the users with the assistance of the analyst, which
is the opposite of how it is done in conventional systems design.
The Lead Systems Designer

 The IS department's systems designer guides the design team, teaching the tools and techniques
necessary to complete the design and providing required technical advice and support, for
example, by developing detailed file structures after users complete the logical database design
Systems Designers

 Systems designers monitor the project, describe the different stages, and help to schedule them.

The spiral model defines four major activities within its lifecycle:

 Determine the system's objectives, constraints, and alternatives; what processes does it affect?
What products does it produce?
 Evaluate alternatives and identify major sources of project risk.
 Define the product and processes involved.
 Plan the next cycle; partition the system into subsystems and consider terminating the project if it
is too risky.
The Spiral Model

 The spiral model features iterative development beginning at the centre of the circle and working
outward. Successive iterations follow as more complete versions of the software are built.
Unlike a linear trip through the systems life cycle, the spiral model makes it clear that design is a
circular process.
 One designs the overall objectives of a system, and then divides it into subsystems, each of which
has a life cycle or spiral of its own.
The model is a guide that can help deliver systems faster to the client; it is based on a continuous
refinement of a system, not unlike a prototyping approach.
 Explicit points to assess risk are a way to help manage development.
The model recognizes that you cannot know everything in advance and that you will discover
more information on each cycle.

 Models like this are used infrequently in business organizations because professionals are not
always aware of them and because they require time to use.
The high failure rate of projects, however, is a good argument to try something new like the spiral
model.

DATA COLLECTION FOR ANALYSIS AND DESIGN

Technique 1

 Observe the process

Technique 2

 Interacting with others, be prepared

Technique 3

 Obtain data from a relatively large number of people at a reasonable cost

Comparing the techniques

 Both questionnaires and interviews are important for the analyst

THE ROLE OF STRUCTURED DESIGN

Top-down Design

The major purpose of this approach is to improve understanding and communication.

DATA FLOW DIAGRAMS

In addition, because adding detail makes the drawing cluttered, the analyst should take one process or
subsystem and explode its detail on a separate sheet of paper. DFDs can easily be read and prepared by
users.
One of their most important contributions is to facilitate understanding among all of those involved in a
design project.
OBJECT-ORIENTED DESIGN
Objects

 An object is a representation of some real world thing and a number of specific instances of that
thing.
Classes

 A class describes a group of objects with similar properties, common behavior, and common
relationships with other objects.
Methods/procedure

 There are methods or procedures associated with each class; they apply to the objects in the class
and change some attribute.
Links

 A link connects different object instances; for example, Mary Smith (an object) works for (a link)
the Widget Company (an object).
Messages

 Objects communicate by sending messages.

As a result, one object cannot directly access the object in another class, which means that objects
are encapsulated or protected from damage from other objects.
BUILDING AN OBJECT-ORIENTED MODEL

 To build an object-oriented model, you identify the classes and objects in the problem domain.
 Class diagrams contain classes and show their relationships, while object diagrams show how
objects send and receive messages.
 Over time, one builds class libraries: an objective of this approach is to reuse software. For
example, a class and its objects for an inventory system might also be used in a production
control system.
 Reuse is intended to reduce the amount of time spent and the cost of developing applications.
 Programmers implement object-oriented systems with languages such as C++.
STEPS FOR OBJECT-ORIENTED MODEL
There are four steps to undertake in object-oriented analysis.
 1. Define classes and objects to form the highest "layer" of the analysis.
2. Proceed to define the detailed structure of classes and objects such as one-to-many relationships
(very similar to entity-relationship models) and inheritance.
3. Define the methods to be performed and the messages that will trigger methods.
4. Define the attributes of classes.
DESIGN DOCUMENT FOR OBJECT-ORIENTED MODEL
There are a variety of design documents that serve the same role as Data Flow Diagrams in structured
design.
An Object Structure Diagram

 The first of these is an object structure diagram shown here.

 This model identifies the object classes involved in an application and relationships between
objects.
 The diagram can be used to show inheritance, aggregation, and attributes of objects.

Object Interaction Diagram

This example shows an object interaction diagram. We see the objects involved in recording the
assignment of a vehicle to an employee and arranging the repair of that vehicle when necessary.
A Transactions Sequence Diagram
A transactions sequence diagram, sometimes called a "use case," models the possible ways of using a
system.
The key points from this module are:

 Systems analysis and design is an activity that requires teamwork among managers, the
information services staff, and users. It is a creative and exciting process that can bring about
substantial change in the organization.
 It is important to appreciate the difference between designing an application for yourself, say,
using a spreadsheet on a PC, and designing an application that will be used by a number of
individuals in the organization.
 Traditionally, we have conducted multi-user design following a life cycle model.
 In designing applications, managers, users, and the professional designers all have important roles
to play.
 The life cycle model, while useful for thinking about design, has problems that can be addressed
by extensive user involvement and influence in design and by adaptations like prototyping.
 There are a variety of ways to collect the information that you need for design. Interviews are the
most popular method.
 Structured design techniques focus on top-down design. They employ data flow diagrams and
entity-relationship models to describe a system.
 Object-oriented design is the newest approach. It concentrates on data in the form of objects that
communicate by passing messages. Objects, their attributes, and methods or procedures that act
on the objects are encapsulated together.
 The tasks of learning user requirements and determining the functions for a new system are the
most difficult part of design, regardless of whether you use structured or object-oriented
approaches to describe the system.
MODULE 2: Systems Design – The Early Stages

EARLY STAGES
Stage 1: Preliminary Study and Feasibility Study
We begin the development process with a preliminary survey and the feasibility study.
Stage 2: Select an Alternative
The output from these two studies is used to determine whether to proceed with the design of an
information system and to select a single processing alternative if the system is approved.
Stage 3: Analysis and Design
If a system is feasible, the analysis and design stages are undertaken, and the design team prepares
detailed specifications.

SYSTEM ANALYSIS
Analysis is the study of a problem, generally done before undertaking some action to solve the problem.
In the case of systems analysis there are three major tasks.
The First Task: Understanding Existing Information Processing Procedures
The first task is understanding and describing existing information processing procedures in the area of
the proposed new system.
Many of the techniques recommended in the previous module can be used to document our understanding
of the present processing system, such as data flow diagrams. In many instances it will be hard to identify
any organized set of procedures that represent the existing information processing system.
We should identify decisions that have to be made and the responsible decision maker. What are the
inputs and outputs, what is the frequency of the decision, and what are the costs involved?
The Second Task: Identifying Crucial Information Flows
Next, we should identify crucial information flows, including the source, frequency, and volume of
information.
For example, we can look at the form in which data are gathered and processed, either written or verbal.
If documents are involved, how many are there and what is their information content? What types of
decisions are supported?
We also need to identify how information is processed as it flows through a system. Who processes the
information? What are the peak and average loads?
A study should identify the critical communications between organizational subunits and individuals. We
need to understand what role the system plays in coordinating work flows and other activities.
The Third Task: Identifying Current Cost
Finally, we should estimate the current cost of information processing.

SURVEY AND FEASIBILITY STUDY

In this section, we present recommendations for the contents of the preliminary survey and feasibility
study. Basically, each of these documents consists of two parts: the present system and an alternative.
A feasibility study presents several potential alternatives and evaluates them on technical, economic, and
operational criteria. We must estimate technical and operational feasibility and compare costs with
benefits.
Management usually insists on a cost benefit justification for a system.
You will generally find that the categories for benefits differ considerably, depending on the type of
system planned.

Costs and Benefits of New Systems

The tangible and concrete benefits for some systems, particularly strategic applications, are likely not to
exceed their costs.
Management may decide to develop the system anyway and the cost benefit analysis helps assess the
risks involved.
In examining costs versus benefits, there are a large number of costs to consider, here are a few;

Development costs are the actual cost of analysis, design, and installation for the system. These costs are
highly sensitive to the amount of time necessary to develop the system and are directly proportional to the
number of analysts, programmers, and users, and the length of their involvement.
Historically, professional estimates of the time required to design and install a system have been far too
low.
Operating Costs
When assessing total costs, we should not forget the expenses of operating a new system. A new system
may require the use of part of the time available on an existing computer, an upgrade on the present
system, or a new computer or network.
Incremental staff in the IS department and users may be required to operate the system.
Maintenance Costs
Finally, there are the costs of routine maintenance and modifications. No system is ever finished; "bugs"
will need to be eliminated, and users will request periodic enhancements as they work with a system.

COST AND BENEFITS OF NEW SYSTEMS

Reduction in Personnel
The savings are often measured by the reduction of workers currently employed or by an estimate of the
number of future employees who must be hired without the system.
It should be noted that many times, savings projected in personnel prove illusory.
More Efficient Processing
Tangible savings also come from more efficient processing.
For example, an inventory control system may reduce inventory balances while maintaining service
levels. The firm saves the interest charges on the money previously required to finance the inventory level
needed before the computer system was introduced.

Tangible cost savings can be difficult to estimate in some cases. It has been suggested that taking the
value of perfect information to provide an upper bound on possible benefits.
For Example: In a forecasting application, what is the maximum benefit from having a perfect forecast of
sales, that is, mowing in advance exact future sales?
If the cost of developing the system exceeds the maximum benefit under perfect information, the
application will undoubtedly be rejected immediately.
If, however, the benefits appear higher than the costs, we can make various assumptions about the impact
of less-than-perfect forecasts from the proposed system.

Benefits
The following list of benefits may prove helpful in this analysis.
1. Improvements in operations.
2. Reduction in clerical activity.
3. Improvements in quality and accuracy.
4. Improvements in decision making.
5. Better communications and coordination in the firm.
6. Improvements in customer service.
7. Creation of ties with customers and suppliers.
8. Reductions in cycle time.
9. Contribution to corporate strategy.
10. Improvements in competitiveness.
Intangible Benefits
The benefits in the previous slide are benefits that have actually been obtained by a firm as a result of
systems design.
Many organizations use subjective techniques to determine whether a project is desirable from a cost
benefit standpoint.
They argue that with uncertain intangible benefits, one still has to decide whether a system appears
justified.
These decision makers use their subjective feelings of what a reasonable figure would be for the benefits
provided by the system.
Definition of Intangible Benefits: Intangible benefits are positive effects that cannot be held in hand,
measured or given a monetary value

IDENTIFYING SYSTEM ALTERNATIVES

One of the major activities during the survey or feasibility study is to sketch possible alternatives for a
new information processing system.
Given the wide range of technology available, it is difficult not to be able to provide some assistance for a
problem. The issue is not so much whether a system is feasible as what alternative is desirable.
During a feasibility study, a design team should develop alternatives and criteria for evaluating the
alternatives. For a particular situation, a user may take the least expensive and most rapidly implemental
system.
In another case, a user may opt for a very comprehensive system to be custom programmed. The
important point is this: As a user, insist on seeing some alternatives!

1. Packages
For many proposed systems, an applications package offers an alternative. Frequently, large amounts of
money and time can be saved by using one of these packages, though there can be a number of
drawbacks.
An applications package is an over-the-counter program or system of programs purchased as an end
product. The package vendor tries to make the product very general. Users supply the data parameters
that apply to their situation, and the package does the processing.
Since computer power is constantly becoming cheaper per computation, it makes sense in many instances
to acquire a package that may use computer hardware inefficiently in order to have an application
functioning earlier.
2. Organizational Impact
You should attempt to estimate the effect of each alternative system on the organization.
What departments and individuals will be affected by the system, and what jobs will it change?
What will happen to any employees who are replaced by a system?
Does the application create new links with customers and/or suppliers?
Does technology make it possible to restructure the organization or some part of it?
Is part of the intent of this application to support the IT organization design variables to move toward a
new structure.
3. Technological Feasibility
A proposed system may stretch the capabilities of modern technology, but may be the one that provides
the firm with a great advantage.
The design team needs to evaluate if a new system is technologically feasible.
An American railroad company developed an extensive prototype of a train scheduling system in one
region of the country to provide information on technological feasibility and to estimate costs and benefits
if the system was installed across its entire service area.
This system wide decision involved a capital expenditure of more than $300 million.
Prototyping and testing, however, are appropriate even when smaller investments are involved. It makes
sense in many instances to acquire a package that may use computer hardware inefficiently in order to
have an application functioning earlier.

Contents and Format for a Study

The contents of one possible format for a survey or feasibility study are outlined in this table.
The summary presents a brief overview of the reasons for the study and ranks each processing alternative,
including the present system, on the criteria established by a steering committee.
This summary is the primary input for decision making.
Existing systems should be described according to the analysis above.
Finally, the report presents each alternative in detail. Here it is helpful to include a scenario or a
reasonable projection of how the system will actually be used, including by management, users, and IS
department activities, under each alternative.

Determining Feasibility
Choosing a system alternative is not always a simple task, and requires input from both the technical staff
and the personnel who will be operating the system.
Navigate the tabs to read about a traditional problem with information systems design and a potential
solution to the problem presented.

A Traditional Problem: Not Enough User Involvement

At one time, the information services department usually decided what applications to undertake. As
demands for service increased, problems began to develop because some user requests had to be denied.
As more systems of importance to the organization developed, many IS departments felt they were placed
in a difficult situation if forced to choose among competing applications.
The IS department is not in a position to decide whether a system is feasible or which processing
alternative should be chosen if a system is to be developed.
The Solution: The Selection Committee
One answer to the problem of choosing information systems is to convene a selection committee of users,
other managers, and IS department personnel.
When representatives of various functional areas are included, each department is able to see why certain
decisions are made. The selection of applications alternatives seems less arbitrary under these conditions.
With management guidance, the committee can select applications and processing alternatives consistent
with functions currently emphasized in the organization.

As an example, suppose one user department has proposed an inventory control system.
The alternatives might include:
Alternative One
Doing nothing is the first alternative, and continue using the system currently in place.
Alternative Two
Purchasing a packaged program from a vendor is the second alternative. This can be a cost effective
alternative, but custom coding may be needed to bring the system to the specifications required.
Alternative Three
Building a custom system - the business could decide to build a custom inventory control system to their
own specifications. This is the most costly alternative.
Each of these alternatives for an inventory control system meets some percentage of user needs at
different costs. Probably three to five alternatives for each proposed application are sufficient. However,
there should always be more than one alternative for a new system.

UNDERTAKING SYSTEMS DESIGN

The most creative part of the systems life cycle is the design of new alternatives for processing. Although
these ideas were sketched in the preliminary survey or feasibility study, the design team has to develop
them in far more detail now.
The information in the feasibility study is general. The details of that system must be designed before
programming can begin.
What equipment is required?
What are the screen formats, the database design, and the kind of queries and transactions to be
processed?

Results of the Design Process

The results of the feasibility study should be complete specifications for the new system.
Designers will then decide whether to design the system according to either Structured Design techniques
or Object - Oriented Design Techniques.
Navigate the tabs to read more about Structured and Object - Oriented Design;
Structured Design
In structured design we usually begin by specifying the desired output.
How does the user interact with the system? Then it is necessary to determine what input is required to
produce this desired output.
A comparison of input and output identifies the data that must be maintained in the database.
Next, we consider processing. How are the input data transformed and used to modify the database? How
often do data have to be updated? How are the input and the contents of the database processed to
produce the desired output?
Also, at this point the design team should specify manual procedures for other activities associated with
the system.
Object-Oriented Design
For object-oriented design, the process will be different; it follows the description and generates the
design documents shown in the last chapter.
In particular, the design team needs to identify familiar business objects associated with the application.
Examples of a business object are a customer, a supplier, an invoice, a product, or a service. You need to
identify classes into which you can group the objects along with attributes that describe them.
The actual processing of information takes place through message passing so it is necessary to delineate
the key messages that travel between objects.
Transactions sequence diagrams or "use case" scenarios help describe the new system.

General Design Considerations

The dominant architecture today is client-server.
Design for this platform is complex because there are so many components involved, including clients,
servers, networks, user interfaces, and usually a database management system on the server.
Object-oriented design approaches are popular in the client-server environment.
The professional designer views this environment as consisting of four layers
1. The Application
The application is what interests you as a user. The application uses the client's user interface to present
information and the database on the server to extract and update information.
2. The Server
The professional designer is also concerned with sizing the server. How much capacity will be needed to
provide service to all the clients that might simultaneously make requests of the server?
3. The Client
Typically, about 75 percent of the program code will end up on the client for running the user interface.
4. The Network
The network refers to how the previous three layers interact with each other.

Graphical User Interfaces

The graphical user interface, as found in all windowing systems, has become the interface of choice for
users.
Virtually any system designed for modern hardware and software will feature a Graphical User Interface
(GUI).
Designers are faced with a number of challenges in developing this kind of interface.
The interface must be simple and it must be easy to learn and remember for the infrequent user. The user
should not have to go through a lengthy relearning process.
The interface should be fast and efficient for the frequent user and should not create awkward transitions
or the need to move frequently from keyboard entry to the pointing device.

There are a number of guidelines available to the designer for developing the Graphical User Interface
(GUI).

 Try to make the screen look like a familiar physical object; for example, a calculator should look
like a physical calculator. When the user clicks on a button, the result should mimic pressing the
key of a real calculator.
 Try to make the interface consistent across all applications. It also helps to make the interface
consistent with the windowing operating system interface and with popular applications that the
user already knows how to use.
 Remember that the user is in charge of the windows and the interface should feel natural to the
user.
 The mouse (or pointing device) is the primary mode for input, not the keyboard. The user will
manipulate objects on the screen directly by clicking on them.
 Use modal tools, that is, tools the user can click on to change subsequent mouse actions. An
example would be a drawing program where the user clicks on a line tool to draw a line or a
circle tool to draw a circle with the mouse.
 The interface should be intuitive enough that, with the assistance of on-line help, the user does
not have to revert to paper documentation about the application (most users will not open the
documentation anyway).
The major objective of the designer is to create an interface that feels natural and intuitive to the
user, a difficult task. Firms like Microsoft have usability laboratories where subjects unfamiliar
with software are observed trying to use it so designers can learn what is intuitive.
The same approach makes sense for developing custom applications. Create a prototype, and let
users work with it before choosing a final design.

What is Conversion Effectiveness?

Conversion effectiveness is defined as "the organization's success in converting IT into useful outputs."
Components of conversion effectiveness include top management commitment, experience with IT, user
satisfaction, and turbulence of the firm's political environment.
While these items undoubtedly influence the conversion of the IT investment into a successful project,
there are many more factors that influence success.
There are many variables that partially determine conversion effectiveness. A failure on any one of the
items listed on the next slide can doom a project even if every other aspect of development is successful.
Success Factors in Conversion Effectiveness
read the list below to learn about the factors that determine whether a system will convert successfully

 Size and scope of the project.

 Project management.
 User commitment and involvement.
 Senior management involvement.
 Threat to existing personnel and vested interests.
 Quality of the IT staff.

The key points from this module are:

 The early stages of the systems design process are the most crucial because the user has the most
involvement in these stages.
 Systems analysis is a major task of systems design and is always undertaken regardless of the
approach taken to design.
 A feasibility study presents potential alternatives and evaluates them on technical, economic and
operational criteria.
 Costs to consider include development costs, operational costs and maintenance costs.
 Benefits of new systems can include a reduction in personnel and more efficient processing.
 Intangible benefits must also be considered, these are positive effects that cannot be measured or
given monetary value.
 During the feasibility study, the design team should develop alternatives and criteria for
evaluating the alternatives.
 System users must examine several alternatives before deciding on a system.
 Alternatives to consider when deciding on a system include packages, organizational impact and
technological feasibility.
 A potential problem in systems design is not enough user involvement. This can be overcome by
convening a selection committee.
 Examples of systems alternatives include doing nothing, purchasing a packaged program and
building a custom system.
 The design team must decide on using either a structured approach or an object oriented
approach.
 A structured design approach is a top-down approach which begins by specifying the desired
output.
 An object-oriented approach begins by identifying the business objects associated with the
application.
 Virtually all systems feature a graphical user interface (GUI).
 There are a number of guidelines available for developing an effective GUI.
 Conversion effectiveness refers to the success in converting IT into useful outputs within the
organization.
 There are several variables which determine conversion effectiveness, including project
management, the IT staff and the management involved.