Professional Documents
Culture Documents
Information Systems 201 (2015) PDF
Information Systems 201 (2015) PDF
1997.
Registration Certificate No. 2000/HE07/008
LEARNER GUIDE
MODULES: INFORMATION SYSTEMS 201 (1ST SEMESTER)
PREPARED ON BEHALF OF
PC TRAINING & BUSINESS COLLEGE (PTY) LTD
TABLE OF CONTENTS
TOPICS
SECTION A: PREFACE
PAGE NO.
3-11
1. Welcome
2. Title of Modules
3. Purpose of Module
4. Learning Outcomes
5. Method of Study
7. Notices
6-8
10
11
12-87
15-32
33-45
3. Requirements Modeling
46-59
60-68
5. Object Modeling
69-72
6. Development Strategies
73-87
SECTION A: PREFACE
1. WELCOME
Welcome to the Department of Media Information and Communication Technology at PC
Training & Business College. We trust you will find the contents and learning outcomes
of this module both interesting and insightful as you begin your academic journey and
eventually your career in the business world.
This section of the study guide is intended to orientate you to the module before the
commencement of formal lectures.
Please note that this study guide covers the content of various academic programmes at
different levels of the NQF and HEQF. Your lecturers will provide further guidance and
additional study materials covering parts of the syllabi that may have been omitted from
this study guide. Learners who are undertaking the Higher Certificate or Diploma
Qualification may use the non-compulsory material supplied as additional reading. This
will however not be directly examinable.
The following lectures will focus on the common study units described:
SECTION A: WELCOME & ORIENTATION
Study unit 1: Orientation Programme
Introducing academic staff to the learners by academic head.
Introduction of institution policies.
Study unit 2: Orientation of Learners to Library and Students
Facilities
Lecture 1
Lecture 2
Lecture 3
Lecture 4
Lecture 5
1st Semester
Title Of Module:
Code:
NQF Level:
Credits:
Mode of Delivery:
Bachelor Of Science In
Information Technology
Management
3. PURPOSE OF MODULE
3.1 INFORMATION SYSTEMS
The purpose of this module is to introduce learners to the main issues, concepts and tools
of System Analysis and Design.
3.2 INFORMATION SYSTEMS 201 (1st Semester)
This module provides learners with system analysis skills as part of systems development
in the business.
4. LEARNING OUTCOMES
On completion of these modules the student will be able to:
Understand the role, function and skills of system analyst.
Differentiate between System Development and Information Systems Development
and discuss the perspective of each stakeholder group.
Fundamental knowledge of the Systems Development Life Cycle and
Methodology.
Fundamental knowledge of the eight principles of System Development.
Informed understanding of the role of CASE tools in Systems Development.
Fundamental knowledge of the process of System Analysis in terms of the FAST
methodology, phases and activities that need to be performed.
Ability to differentiate between logical and physical systems models.
Understand the process modelling.
Discuss data modelling and its benefits.
Understand network modelling and its importance.
5. METHOD OF STUDY
The sections that have to be studied are indicated under each topic. These form the basis
for tests, assignments and examination. To be able to do the activities and assignments for
this module, and to achieve the learning outcomes and ultimately to be successful in the
tests and examination, you will need an in-depth understanding of the content of these
4
library. Learners are advised to make copies or take notes of the relevant information, as
the content matter is examinable.
8.3
Independent Research:
allowed any extra time. Your learner registration card must be in your possession at all
times.
9.4
Final Assessment
The final assessment for this module will be weighted as follows:
Continuous Assessment Test 1
Continuous Assessment Test 2
40 %
Assignment 1
Total Continuous Assessment
40%
Semester Examinations
60%
Total
100%
9.5 Key Concepts in Assignments and Examinations
In assignment and examination questions you will notice certain key concepts (i.e.
words/verbs) which tell you what is expected of you. For example, you may be asked in a
question to list, describe, illustrate, demonstrate, compare, construct, relate, criticize,
recommend or design particular information / aspects / factors /situations. To help you to
know exactly what these key concepts or verbs mean so that you will know exactly what
is expected of you, we present the following taxonomy by Bloom, explaining the concepts
and stating the level of cognitive thinking that theses refer to.
COMPETENCE SKILLS DEMONSTRATED
observation and recall of information
knowledge of dates, events, places
knowledge of major ideas
mastery of subject matter
Knowledge
Question
Cues
list, define, tell, describe, identify, show, label, collect, examine,
tabulate, quote, name, who, when, where, etc.
understanding information
grasp meaning
translate knowledge into new context
interpret facts, compare, contrast
order, group, infer causes
Comprehension
predict consequences
Question
Cues
summarize, describe, interpret, contrast, predict, associate,
distinguish, estimate, differentiate, discuss, extend
use information
use methods, concepts, theories in new situations
solve problems using required skills or knowledge
Application
Questions
Cues
7
Analysis
Synthesis
Evaluation
LIFE SKILLS
Manage Personal Finance
Driving Skills
Basic Life Support & First
Aid
Entrepreneurial skills
Counselling skills
Time Management
Working in Teams
Problem Solving Skills
Attitude & Goal Setting
Etiquettes & Ethics
Communication Skills
WORK
READINESS
PROGRAMM
E
EMPLOYMENT SKILLS
CV Writing
Interview Skills
Presentation Skills
Employer / Employee
Relationship
End User Computing
Email & E-Commerce
Spread Sheets
Data base
Presentation
Office Word
It is in your interest to attend these workshops, complete the Work Readiness Log Book
and prepare for the Working World.
10
SECTION B
Registered with the Department of Higher Education as a Private Higher Education Institution under the Higher Education Act, 1997.
Registration Certificate No. 2000/HE07/008
LEARNER GUIDE
MODULE: INFORMATION SYSTEMS 201 (1ST SEMESTER)
TOPIC 1 :
TOPIC 2 :
TOPIC 3 :
REQUIREMENT MODELING
TOPIC 4 :
TOPIC 5 :
OBJECT MODELING
TOPIC 6 :
DEVELOPMENT STRATEGIES
12
BSC
in IT
Lecture
6-12
Lecture
12-18
Le19
21-23
Lecture
24-38
Lecture
28-33
Lecture
34-38
13
6.3 Outsourcing
6.4 User Applications
6.5 Selecting a Software Alternative
6.6 Completion Of Systems Analysis
6.7 Transition To Systems Design
6.8 The relationship between logical and physical design
6.9 The Relationship between Analysis and Design
6.10 Overview Of Systems Design
Review Questions
14
TOPIC 1
1. INTRODUCTION TO SYSTEM ANALYSIS AND DESIGN
_______________________________ _________________________________
LEARNING OUTCOMES
After studying this topic you should be able to:
Discuss the impact of information technology on business strategy and success.
Define and information system and describe its components.
Use profiles and models to understand business functions and operations.
Explain how the Internet has affected business strategies and relationships.
Identify various types of information systems and explain who uses them.
Explain systems development tools, including modeling, prototyping and CASE tools.
Distinguish between structured analysis and object-oriented methodology.
Describe the systems development life cycle.
Discuss the role of the information technology department and the systems analysis
who work there.
INTRODUCTION
Companies use information as a weapon in the battle to increase productivity, deliver
quality products and services, maintain customer loyalty, and make sound decisions. In a
global economy with intense competitions, information technology can mean the difference
between success and failure.
Introduce you to the role of information technology in todays dynamic business environment. You
will learn about the development of information systems, systems analysis and design
concepts, the systems development life cycle, and various systems development methods,
tools, and techniques.
1.1 THE IMPACT OF INFORMATION TECHNOLOGY
Information technology (IT) refers to the combination of hardware and software products
and services that people use to manage access, communicate, and share information.
Successful firms treat information as a vital asset that just be used effectively, updated
constantly, and safeguard carefully.
1.1.1 The Future of IT
More than ever, business success depends on information technology. In are port titled Digital
Economy 2003, the U.S. Department of Commerce stated that, After two years of
retrenchment, IT producing industries now show signs of resuming the dynamic role they paid
during 1996-2000. The report estimated that the IT sector accounted for almost 30
percent of economic growth during 2003, and pointed out that IT has created a new
economy, where advances in hardware, software, and connectivity provide unprecedented
15
benefits to business and individuals around the world. According to the report, an
explosion in Internet use is driving this growth. Although economic trends affect IT
spending levels, most business give IT budgets are relatively priority, in good times or
bad. The reason in simple-during periods of growth, companies cannot afford to lag
behind the IT curve. Conversely, when the economy slows down, firms often use it reduce
operating costs and improve efficiency.
1.1.2 The Role of Systems Analysis and Design
Systems analysis and design is a step-by-step process for developing high-quality
information systems. An information system combines information technology, people,
and data to support business requirements. For example, information systems handle daily
business transaction, improve company productivity, and help managers make sound
decisions. The IT department team includes systems analysts who plan, develop, and
maintain information systems. With increasing demand for talented people, employment
experts predict a shortage of qualified applicants to fill IT positions.
1.1.3 Who develops Information Systems?
Traditionally, a company developed its own information systems, called in-house
applications, or purchased systems called software packages from outside vendors.
Today, the choice is much more complex. Options include Internet-based application
services, outsourcing, custom solutions from IT consultants, and enterprise-wide software
strategies. Regardless of the development method, launching a new information system
involves risks as well as benefits. The greatest risk occurs when a company tries to decide
how the system will be implemented before determining what the system is supposed to
do. Instead of putting the cart before the horse, a company must begin by outlining its
business needs and identifying possible IT solutions. Typically, this important work is
performed by systems analysts and other IT professionals. A firm should not consider
implementation options until it has a clear set of objectives. Later on, as the system is
developed, a system analysts role will vary depending on the implementation option selected.
1.2 INFORMATION SYSTEMS COMPONENTS
A system is a set of related components that produces specific results. For example,
specialized systems route Internet traffic, manufacture microchips, and control complex
events like the Mars mission. A mission-critical system is one that is vital to a companys
operations. An order processing system, for example, is mission-critical because the
company cannot do business without it. Every system requires input data. For example,
your computer receives data when you press a key or click a menu command. In an
information system, data consists of basic facts that are the systems raw material.
Information is data that has been transformed into output that is valuable to users. When a
sales representative enters data (customer number, product code, and quantity ordered),
the system creates a customer order with all the necessary information. Large businesses
with thousands or millions of sales transaction require company-wide information
systems and powerful servers. An information system has five key components:
hardware, software, data, process, and people.
16
1.2.1Hardware
Hardware consists of everything in the physical layer of the information system. For
example, hardware can include servers, workstations, networks, tele-communications
equipment system, fiber-optic cables, handheld computers, scanners, digital capture devices,
and other technology-based infrastructure. As new technologies emerge, manufacturers
race to market the innovations and reap the rewards. Hardware purchasers today face a
wide array of technology choices and decisions. Almost 40 years ago, a concept called
Moores Law accurately predicted that computer processing power would double every
18 to 24months. Fortunately, as hardware became more powerful, it also became less
expensive.
1.2.2Software
Software refers to the programs that control the hardware and produce the desired
information or results. Software consists of system software and application software.
System software manages the hardware components, which can include a single
workstation or a global network with many thousands of clients. Either the hardware
manufacturer supplies the system software or a company purchases it from a vendor.
Examples of system software include the operating system, security software that
protects the computer from intrusion, device drivers that communicate with hardware
such as printers, and utility programs that handle specific tasks such as data backup and
disk management. System software also includes a network operating system (NOS),
which controls the flow of data, provides data security, and manages network accounts.
In todays interconnected business world, network software is vitally important.
Application software consists of programs that support day-to-day business functions
and provide users with the information they require. Application software can serve one
user or thousands of users throughout the organization. Example of company-wide
applications, called enterprise applications, includes order processing systems, payroll
systems, and company communications network. On a smaller scale, individual users
increase their productivity with tools such as spreadsheets, word processors, and
database management systems. Application software includes horizontal and vertical
systems; a horizontal system is a system, such as an inventory or payroll application,
that can be adapted for use in many in many different types of companies. A vertical
system is designed to meet the unique requirements of a specific business or industry,
such as a Web-based retailer, a medical practice, or a video chain. Most companies use a
combination of software that is acquired at various times. When planning an information
system, a company must consider how a new system will interface with older systems,
which are called legacy systems. For example, a new human resources system might
need to exchange data with an older payroll application.
1.2.3Data
Data is the raw material that an information system transforms into useful information.
An information system can store data in various locations, called table. By linking the
tables, the system can extract specific information.
17
1.2.4Processes
Processes describe the task and business functions that users, managers, and IT staff
members perform to achieve specific results. Processes are the building blocks of an
information system, because they represent actual day-to day business operations. To
build a successful information system, analysis must understand business process and
document them carefully.
1.2.5People
The primary purpose of an information system is to provide valuable information to
users. Users, sometimes called end users, are the people who interact with an
information system, both inside and outside the company. Internal users include
administrators, managers, technicians, sales staff, and corporate officers. External users
include customers system to plan their manufacturing schedules. The success or failure
of a system usually depends on whether users are satisfied with the systems output and
operations. To serve users, successful information systems depend on skilled
professional, such a systems analysts, programmers, network administrators, and other
IT staff members.
1.3 Business Information Systems
A system analyst must understand a companys business information systems needs. For
example, the requirements of a Web-based music retailer are very different from those
of a hotel chain or a truck manufacturer. An analyst builds a business profile by
investigating a companys mix of products and services and its ability to use the Internet
to conduct business. The analyst also studies the interactivity among information
systems, system boundaries, and specialized business information needs, as well as the
companys size and future growth projections.
1.3.1Categories of Companies
Traditionally, companies have been identified as production-oriented or serviceoriented. A new category includes companies that depend on the Internet as a primary
business channel.
Production-oriented companies primarily manufacture and sell products, such as the
microchips. Motorola, Intel and Compaq are examples of production-oriented
companies.
Service-oriented companies primarily offer information or services, or sell goods
produced by others. AT & T, United Airlines, and Wall-Mart are examples of service
companies. Some companies offer a mix of products, services, information, and
technical resources to customers. For example, IBM reported in a recent financial
statement that more that 58 percent of its total revenue was derived from the sale of
software, services, and maintenance, compared with42 percent from hardware sales.
Although IBM still manufactures and sells technology products, it also operates and
international consulting division, a leasing unit, and a financial services branch. A new
category of company is the
Internet-dependent firm , which is often described as a dot-com (.com) company because
it bases its primary business n a commercial Web site rather than using traditional
18
profitability. A break down in any one system can affect companies rely on
telecommunications and the Internet for mission-critical systems.
A companys information system also can interface with a system operated by another
firm, such as when a payment is made by one companys accounts payable system to
another companys accounts receivable system. This process, known as electronic data
interchange (EDI), involves the computer-to-computer transfer of data between
companies. EDI has expanded rapidly as companies form closer working relationships
with their suppliers and customers. In the past, EDI was used mainly for processing
transactions between two companies, such as purchasing or payments. Today, EDI can
help a firm plan its production, adjust inventory levels, or stock up on raw materials using
data that comes from another companys information systems.
2. What are the systems boundaries?
A system boundary indicates where one system ends and another system begins. The
boundary between two systems is not always clear-cut. For example, when are customer
payments part of the accounts receivable system, and when are they included in the
finance system? If customer payments need to be adjusted, must the adjustments take
place in both systems? Who makes the adjustments? What processes and files are
involved? Complex systems have many interfaces with other systems; the system analyst
must carefully plan and design theses systems to design their boundaries correctly.
3. Will the system handle specialized business needs?
Many firms require specialized systems for information management that is unique to
their company or industry. At a college, for example, specialized systems handle class
registration, classroom scheduling, and student grading. At a hospital, specialized systems
manage patient admissions, room scheduling, and insurance billing. Firms in the banking,
insurance, airlines, and telecommunications industries require complex systems to run
their businesses. If a specialized system is available as a vertical software package, a
company can purchase and customize the package. Otherwise, a company must develop
specialized in-house systems.
4. What size are the company and what growth is forecast?
Large and small companies in the same industry have different information systems
requirements. For example, banks range in size from local operations with one or two
branches to multinational banks with branches in many states and foreign countries. All
banks handle loan processing and checking accounts. A multinational bank, however, has
a much higher volume of customers, transactions, and accounts. A large banks systems
are more complex because they consolidate information from banking centers around the
world, handle currency exchange issues, and offer a wide array of products and services.
20
information systems (MISs) primarily managers used them. Today, employees at all
levels need information to perform their jobs, and they rely on information systems for
that support.
An information system must generate timely and accurate records. For example, when a
company sells merchandise to a customer, a transaction processing system records the
sale, updates the customers balance, and makes a deduction from inventory. A related
business support system can highlight slow-or-fast moving items, customers with past due
balances, and inventory items that need reordering. Managers, buyers, and inventory
control specialists all use information to make better decisions. An important feature of a
business support system is decision support capability to conduct a what-if analysis.
Decision support helps users make decisions by creating a business model and applying a
set of variables. For example, a truck fleet dispatcher might run a series of what-if
scenarios to determine the impact of increased demand or bad weather on the fleets
capability of delivering goods on time. Alternatively, a retailer might use what-if analysis
to determine the price it must charge to increase profits by10 percent assuming that
volume and costs remain unchanged.
1.3.4.4
Knowledge Management Systems
Knowledge management systems are sometimes called expert systems because they
simulate human reasoning by combining a knowledgebase and inference rules that
determine how the knowledge is applied. A knowledge base consisting of a large database
allows users of find information by clicking menus, typing keywords, or entering text
questions in normal English phrases. In a knowledge management system, logical rules
named inference rules identify data patterns and relationships. For example, a data
inquiry using the phrase data screen would produce different results than the phrase
screen data because of the word order. After a user enters a symptom, problem, or
question, Novells knowledge management system searches for a solution.
Knowledge management systems do not make decisions based on common sense or
intuition ash humans do. Many knowledge management systems use an approach called
fuzzy logic that allows logical inferences to be drawn from imprecise relationships. Using
fuzzy logic, values need not be black and white, like binary logic, but can be many shades
of gray. For example, if you ask the Novell Knowledgebase to find information about user
password administration, it will search the knowledge base for articles with those terms.
Using fuzzy logic, the results will be displayed in priority order, with those that are
presumably more relevant at the top of the list.
1.3.4.5
User Productivity Systems
User productivity systems provide employees at all organization all levels with a wide
array of tools that can improve quality and job performance. Local and wide area
networking, e-mail, voicemail, fax, videoconferencing, word processing, automated
calendars, database management, spreadsheets, desktop publishing, presentation graphics,
company intranets, and Internet access throughout the company enhance user
productivity. When companies first installed word processing systems, managers
expected to reduce the number of employees as office efficiency increased. That did not
happen, primarily because the basic nature of clerical work changed. As the country
22
code modules. Although the models might appear to overlap, they actually work together
to describe the same environment from different points of view. Modeling involves
various techniques, such as data flow diagrams, entity-relationship diagrams, use cases,
and unified modeling language.
1.5.2Prototyping
Prototyping involves the creation of an early working version of the information system
or its components. Just as an aircraft manufacturer tests a new design in a wind tunnel,
systems analysts construct and review prototypes for a larger systems. Prototyping tests
system concepts and provides an opportunity to examine input, output, and user interfaces
before final decisions are made. The prototype can serve as an initial model that is used as
a benchmark to evaluate the completed system, or the prototype itself can develop into the
final version of the system. Either way, prototyping speeds up the development process
significantly. A possible disadvantage of prototyping is that important decisions might be
made too early, before business or IT issues are thoroughly understood. If a prototype is
based on careful fact-finding and modeling techniques, however, it can be an extremely
valuable tool.
1.5.3Computer-Aided Systems Engineering
Computer-aided system engineering (CASE) is a technique that uses powerful programs,
called CASE tools, to help systems analysts develop and maintain information systems.
CASE tools provided an overall framework for systems development and support a wide
variety of design methodologies, including structured analysis and object-oriented
analysis. Traditionally, systems developers differentiated between two CASE categories:
upper CASE tools and lower CASE tools.
Upper CASE tools support the modeling process and produce a logical design of the
information system.
Lower CASE tools speed the development process by generating source code based on
the logical model. Today, many popular CASE tools combine upper and lower CASE
features into a single product. CASE tools can boost IT productivity and improve the
quality of the finished product. For example, developers use CASE tools to maintain
design integrity, manage a complex project, and generate code modules that speedup
implementation.
1.6 Joint Application Development and Rapid Application Development
In the past, the IT department typically developed information systems and contacted
users only when their input was desired or needed. Unfortunately that approach often left
large communication gaps between system developers and users. Over time, many
companies discovered that systems development teams composed of IT staff, user, and
managers could complete their work more rapidly and produce better results. Two
methodologies became popular:
Joint application development (JAD)
Rapid application development (RAD).
25
Both approaches use teams composed of user, managers, and IT staff to complete
projects. JAD involves team-based fact-finding techniques, while RAD is more like a
condensed version of the entire development process.
Other Systems Development Tools
In addition to CASE tools, systems analyst use various productivity tools or organizes and
structure the task of developing an information system. In addition to word processing,
spreadsheets, graphics tools, and presentation software, analysts use special purpose
charting tools.
1.7 SYSTEMS DEVELOPMENT METHODS
A popular, traditional method is called structured analysis, but a newer strategy called
object-oriented analysis and design also is widely used. Each method offers many
variations. Some organizations develop their own approaches or adopt methods offered by
software vendors or consultants. Most IT experts agree that no single, best system
development strategy exists. Instead, a systems analysis should understand the alternative
methodologies and their strengths and weaknesses.
1.7.1Structure Analysis
Structured analysis is a traditional systems development technique that is time-tested and
easy to understand. Structured analysis evolves in a1960s environment, where most
systems were based on mainframe processing of individual data files. Because it describes
the processing that transforms data into useful information, structured analysis includes
data organization and structure, relational database design, and user interface issues.
Structured analysis uses a series of phase, called the systems development life cycle
(SDLC) to plan, analyze, design, implement, and support an information system.
Structured analysis relies on a set of process models that graphically describe a system.
Process modeling identifies the data flowing into a process, the business rules that
transform the data, and resulting output data flow. Structured analysis is developing into a
technique called information engineering. Information engineering, like enterprise
computing, envisions the overall business enterprise and how corporate data and
processes interact throughout the organization.
1.7.2Object-Oriented Analysis
Whereas structured analysis regards processes and data as separate components,
Object-oriented (O-O) analysis combines data and the processes that act on the data into
thing called objects. Systems analysts use O-O methods to model real-world business
processes and operations. The result is a set of software objects that represent actual
people, things, transactions, and events. Using an O-O programming language, a
programmer then transforms the object it into reusable code and components. An object is
member of a class, which is collection of similar objects. Objects posses characteristics
called properties, which it inherits from its class or possess on its own.
One object can send information to another object by using a message. A message can
request specific behaviour or information from the recipient. For example, if there if there
is no wind, a sailboat owner object might send a start the motor message to the sailboat
object. The owner object has the capability to send this message, and the sailboat object
26
knows what action to perform when it receives he message. O-O analysis uses object
models to represent data, behaviour, by what means objects affects other objects. By
describing an objects (data) and methods (processes) needed to support a business
operation, a system developer can design reusable components that allow faster system
implementation and decreased development cost. Many analysts believe that, compared
with structured analysis, O-O method are more flexible, efficient, and realistic in todays
dynamic business environment. Also O-O analysis provides an easy transition to popular
O-O programming languages, such as Java C++.
1.8
Structured analysis uses a technique called the system development life cycle (SDCL) to
plan and manage the system development process. Although it is primarily identified with
structured analysis, the SDCL describes activities and functions fit into a particular
methodology. The SDCL model includes the following steps:
System planning
System analysis
System design
S ys t e m i mp l e me n t a t i o n
S ys t e m o p e r a t i o n a n d s u p p o r t traditionally,
27
28
development is always a work in progress. Business processes change rapidly, and most
information systems need to be updated significantly or replaced after several years of
operation.
1.9 SYSTEMS DEVELOPMENT GUIDELINES
With experience as a systems analyst, you will develop your own style and techniques.
Although each project is different, you should consider some basic guidelines as you
build an information system.
Planning
Stick to an overall development plan. If you use the SDLC as a framework for systems
development, complete the phases in sequence. If you use an O-O methodology,
follow a logical series of steps as you define the components.
Involve the Users throughout the Development Process
Ensure that users are involved in the development process, especially when identifying
and modeling system requirements. Modeling and prototyping can help you user needs
and develop a better system.
Listening is very important
The best system is the one that meets user needs most effectively. When you interact with
users, you must put aside any preconceive notions and listen very closely to what they are
saying to you.
Create a Timetable with Major Milestones.
Identify major milestones for project review and assessment. At those milestones,
managers and systems developers must decide whether to proceed with the project,
redo certain tasks, return to an earlier phase, or terminate the project entirely. The
SDLC model requires formal assessment of end products and deliverables. O-O
analysis involves a continuous modeling process that also requires check points and
project review.
Identify Interim Checkpoints. Establish interim checkpoints between major milestones
to ensure that the project remains on schedule. Regardless of the development
methodology, the systems analyst must keep the project on track and avoid surprises.
Create a reasonable number of checkpoints too many can be burdensome, but too
few the completion of interviews conducted during a preliminary investigation.
Remain Flexible
Be flexible within the framework of your plan. Systems development is a dynamic
process, and overlap often exists between the phases of systems planning, analysis,
design, and implementation. For example, when you investigate a systems request, you
begin a fact-finding process that often carries over into the next phase. Similarly, you
often start building process models before fact-finding is complete. The ability to
overlap phases is especially important when you are working on a system that must be
developed rapidly.
Develop Accurate Cost and Benefit Information
30
Provide accurate and reliable cost and benefit information. Managers need to know the
cost of developing and operating a system. At the start of each phase, you must
provide specific estimates.
1.10 INFORMATION TECHNOLOGY DEPARTMENT
The information technology (IT) department develops and maintains a companys information
system. The structure of the IT department varies among companies, as does its name and
placement within the organization. In a small firm, one person might require many people
with specialized skills to provide information systems support.
The IT group provides technical support, which includes six main functions: application
development, systems support and security, user support, database administration,
network administration and Web support. These functions overlap considerably and often
have different companies.
Application Development
Traditionally, IT departments had an application development group composed of
systems analysts and programmers who handled information system design,
development, and implementation. Today, many companies use development teams
consisting of users, managers, and IT staff members for those same tasks. A popular
model for information systems development is a project-oriented team using RAD or
JAD, with IT professionals providing overall coordination, guidance, and technical
support.
Systems Support and Security
Systems support and security provides vital protection and maintenance services for
system hardware and software, including enterprise computing systems, networks,
transaction processing systems, corporate IT infrastructure. The systems support and
security group implements and monitors physical and electronic security hardware,
software and procedures. This group also installs and supports operating systems,
telecommunication software, and centralized database management systems. In
addition, systems support and security technicians provide technical assistance to other
groups in the IT department.
User Support
User support provides users with technical information, training, and productivity
support. The user support function usually is called a help desk or information center
(IC). A help desks staffs train users and managers on application software such as email, word processors, spreadsheet, and graphics packages. User support specialists
answer questions, troubleshoot problems, and serve as a clearing house for user
problems and solutions.
In many companies, the user support team also installs and configures software
applications that are used within the organization. Although user support specialists
coordinates with other technical support areas, their primary focus is user productivity
and support for business processes.
31
Database Administration
Database administration involves database design, management, security backup, and
user access. In small- and medium-sized companies, and IT support person performs
those roles in addition to other duties. Regardless of company size, mission-critical
database applications require continuous attention and technical support.
Network Administration
Business operations depend on telecommunication networks that enable companywide information systems. Network administration includes hardware and software
maintenance, support, and security. In addition to controlling user access, network
administrators install, configure, manage, monitor, and maintain network applications
Web Support
Web support is the newest technical support function. Web support specialists, often
called webmaster, support a companys Internet and intranet operations. Web support
involves design and construction of Web pages, monitoring traffic, managing
hardware and software, and linking Web-based applications to the companys existing
information systems. Reliable, high-quality Web support is especially critical for
companies engaged in e-commerce.
Review Questions
1.
2.
3.
4.
5.
6.
7.
32
TOPIC 2
2. ANALYZING THE BUSINESS CASE
_______________________________ _________________________________
LEARNING OUTCOMES
After studying this topic you should be able to:
When you finish this chapter, you will be able to:
Describe the strategic planning process, and why it is important IT managers
Explain the purpose of a mission statement
Explain the SDLC as a framework for systems development and business modeling
Explain the reason for information systems projects and the factors that affect such
projects
Describe the initial review of systems request and the role of the systems review
committee
Describe the internal and external factors that affect information systems projects
Define operational feasibility, technical feasibility, and economic feasibility
Describe the steps and end product of a preliminary investigation
INTRODUCTION
Systems planning is the first of five phases in the system development life cycle.
During the systems planning phase, a systems analyst reviews systems project and gains
an understanding of the companys objectives, information requirements, and business
operations.
2.1 STRATEGIC PLANNING
It is the process of identifying long-term organizational goals, strategic, strategies, and
resources. Strategic planning looks beyond day-to-day activities and focuses on a horizon
that is 3, 5, 10, or 20 years in the future.
During strategic planning, many companies ask a series of broadly worded question that
is called a SWOT analysis because it examines a companys strengths (S), weakness (W),
opportunity (O), and threats (T).Each question leads to an IT-related issue, which in turn
requires more review, analysis, and planning. For example:
What are our major strengths, and how can we utilize them in the future? What must
we do to strengthen our IT function, including our people and technology
infrastructure?
What are four major weaknesses, and how can we overcome them? How should we
address weaknesses in IT resources and capability?
What are our major opportunities, and how can we take full advantage of them? What
IT plans do we have to support business opportunities?
What major threats do we face, and what can we do about them? What can we do to
deal with potential threats to IT success?
33
When a company performs a SWOT analysis, a long-term strategic plan emerges. The
plan requires technical, financial, and human resources. Most important, the strategic plan
requires information resources and technology that area supplied by IT professionals,
including systems analysts.
34
37
In addition to costs, you need to assess tangible and intangible benefits to the company.
The systems review committee will use those figure, along with you cost estimates, to
decide whether to pursue the project beyond the preliminary investigation phase.
Tangible benefits are benefits that can be measured in dollar. Tangible benefits results
from a decrease in expenses, an increase in revenues, or both. Examples of tangible
benefits include the following:
A new scheduling system that reduces overtime
An online package tracking system that improves service and decreases the need for
clerical staff
A sophisticated inventory control system that cuts excess inventory and eliminates
production delays.
Intangible benefits are difficult to measure in dollar but also should be identified.
Examples of intangible benefits include the following:
A user-friendly system that improves employee job satisfaction
A sales tracking system that supplies better information for marketing decisions
A new Web site that enhances the companys image you also must consider the development
timetable, because some benefits might occur as soon as the system is operational, but
others might not take place until later. The Systems Analysts Toolkit contains tools to help
you assess economic feasibility
2.3.4 Schedule Feasibility
The first step in the evaluation of a systems request is to make an initial determination of
feasibility. Any request that is not feasible should be identified as soon as possible. For
example, a request might require hardware or software that the company already rejected
for other reasons. If so, the request will not fit the companys technical environment and should not
be pursued further. Even if the request is technically feasible, it might not be the best
solution. For example, a request for a new report that is needed only once could require
considerable design and computer-based software package and ask users to produce their
own reports. In that case, a better investment is to train users instead of producing the
reports for them. You should keep in mind that systems requests that are not currently
feasible can be resubmitted as new hardware, software, or expertise becomes available.
Development costs might decrease, or the value of benefits might increase enough that a
systems request eventually becomes feasible. Conversely, an initially feasible project can
39
be rejected later. As the project progresses, conditions often change. Acquisition costs
might increase, and the project might become more expensive than anticipated. In
addition, managers and users sometimes lose confidence in a project. For all those
reasons, feasibility analysis is an ongoing task that must be performed throughout the
system development process.
2.3.4.1
Criteria Used to Evaluate Systems Requests
After rejecting systems requests that are not feasible, the systems review committee must
establish priorities for the remaining items. Priority usually goes to projects that provide
the greatest benefit, at the lowest cost, in the shortest period of time. Many factors,
however, influence project evaluation. When assessing a project, a system analyst should
ask the following questions:
Will the proposed system reduce costs? Where? When? How much?
Will the system increase revenue for the company? Where? When? How? How much?
Will the systems project result in more information or produce better results? How?
Are the results measurable?
Will the system serve customers better?
Will the system serve the organization better?
Can the project be implemented in a reasonable time period? How long will the results
last?
Are the necessary financial, human, and technical resources available?
Very few projects will score high in all areas. Some proposed systems might not reduce
costs but will provide important new feature. Other systems might reduce operating cost
substantially but require the purchase or lease of additional hardware. Some systems
might be very desirable but require several years of development before producing
significant benefits. Whenever possible, the analyst should evaluate a proposed project
based on tangible factors. A tangible factor can be assigned an actual or approximate
dollar value. A reduction of $8,000 in network maintenance is an example of a tangible
factor. Often, the evaluation involves intangible factors. In contrast to a tangible factor, it
is difficult to assign a dollar value to an intangible factor. Enhancing the organizations
image and improving customer service are examples of intangible factors. Intangible
factors often weigh heavily in the decision for or against a systems project.
2.3.4.2
Discretionary and Non-discretionary Projects
Is the project absolutely necessary? Projects where management has a choice in
implementing them are called discretionary projects. Projects where no choice exists are
called nondiscretionary projects. Creating a new report for a user is an example of a
discretionary project; adding a report required by a new federal law is an example of a
nondiscretionary project. If a particular project is not discretionary, is it really necessary
for the system review committee to evaluate it? Some people believe that waiting for
committee approval delays critical nondiscretionary projects unnecessarily. Others
40
believe that by submitting all systems requests to the systems review committee, the
committee is kept aware of all projects that compete for the resources of the IT
department. As a result, the committee assesses the priority of discretionary projects and
can schedule them more realistically. Additionally, the committee might need to prioritize
on discretionary projects when funds or staffs are limited.
Many nondiscretionary projects are predictable. Examples include annual updates to
payroll, tax percentages, or quarterly changes in reporting requirements for an insurance
processing system. By planning a head for predictable projects, the IT department
manages in resources better and keeps the systems review committee fully informed
without needing prior approval in every case.
2.3.4.3
Preliminary Investigation
A system analyst conducts a preliminary investigation to study the systems request and
recommend specific action.
Steps in Preliminary Investigation
During a preliminary investigation, a system analyst typically follows a series of steps.
The exact procedure however depends on the nature of the request, the size of the project,
and the degree of urgency.
Step 1: Understand the Problem or Opportunity
If the systems request involves a new information system or a substantial change in an
existing system, system analyst might need to develop a business profile that describes
business processes and functions. Even where the request involves relatively minor
changes or enhancements, you need to understand how those modifications will affect business
operations and other information systems. Often a change in one system has an
unexpected effect on another system. When you analyze a systems request, you need to
determine which department users, and business processes are involved. In many cases,
the systems request does not reveal the underlying problem, but only a symptom. For
example, you might receive a request to investigate mainframe processing delays, and
find improper scheduling practices, rather than hardware problems. Similarly, a request
for analysis customer complaints might disclose a lack of sales rep training, rather than
problems with the product.
Step 2: Define the Project Scope and Constraints
Determining the project scope means to define the boundaries, or extent, of the project --being as specific as possible. For example, the statement, payroll is not being produced
accurately is very general, compare with the statement, overtime pay is not being
calculated correctly for production workers on the second shift at Yorktown plant.
Similarly, the statement, the project scope is to allow customers to inquire online about
account balances and recent transactions.
Projects sometimes expand gradually, without specific authorization, in a process called
project creep. To avoid this problem, you should define projects scope as clearly as
possible. You might want to use a graphical model that shows systems, people, and
business processes that will be affected. The scope of the project also establishes the
41
boundaries of the preliminary investigation itself. A systems analyst should also limit the
focus to the problem at hand and avoid unnecessary expenditure of time and money.
Along with defining the scope of the project, you need to identify any constraints on the
system. A constraint, or requirement, is a condition that the system must satisfy or an
outcome that the system must achieve. A constraint can involve hardware, software, time,
policy, law, or cost. System constraints also define project scope. For example, if the
system must operate with existing hardware, that is a constraint that affects potential
solutions. Other examples of constraints are: the order entry system must accept input
from 15 remote sites; the human resources information system must produce statistics on
hiring practices; and the new web site must be operational by March 1. When examining
constraints, you should identify their characteristics.
Present Versus Future Constraints
Is the constraint something that must be met as soon as the system is developed or
modified, or is the constraint necessary at some future time?
Internal versus External Constraints
Is the constraint due to a requirement within the organization or does the constraint or
does some external force, such as government regulations, impose it?
Mandatory versus Desirable Constraints
Is the constraint mandatory? Is it absolutely essential that the constraint is met, or is it
merely? If desirable, how important is the constraint. One common mistake is to list all
constrains as mandatory, which results in increased development time and costs. Present,
external, and mandatory constraints usually are fixed and must be met by the system
when it is developed or modified. Constraints that are future, internal, or desirable often
can be postponed. Regardless of the type, all constraints should be identified as possible
avoid future problems and surprises. A clear definition of projects scope and constraints
avoids misunderstandings that arise when mangers assume that the system will have a
certain feature or support for a project, but later find that the feature is not included.
Step 3: Perform Fact-Finding
Fact-Finding involves various techniques, which are described below. Depending on what
information is needed to investigate the systems request, fact-finding might consume
several hours, days, or weeks. For example, a change in a report format or data entry
screen might require a single telephone call or e-mail message to a user, whereas a new
inventory system would involve a series of interviews. During fact-finding, you might
analyze organization charts conduct interviews, review current documentation, observe
operations, and carry out a user survey.
Analyze Organization Charts
In many instances you will not know the organizational structure of departments involved
in the study. You should obtain organization charts to understand how the department
functions and identify individuals you might want to interview. Organization charts often
can be obtained the companys human resources department. If such charts are
unavailable, you should obtain the necessary information directly from department
personnel and then construct your own charts. You can use and organization chart tool
built into your word processor or a separate graphical tool, such as Microsoft Visio. When
42
organization charts are available, you should verify their accuracy, Keep in mind that
organization charts show formal reporting relationships but not the informal alignment of
a group, which also is important.
2.3.5 CONDUCT INTERVIEWS
The primary method of obtaining information during the preliminary investigation is the
interview. Your primary role in an interview is to ask effective questions and listen
carefully. If you plan to talk to several people about the same topic, you should prepare a
standard set of questions for all the interviews. When conducting interviews during the
preliminary investigation, you should interview managers and supervisors who have a
broad knowledge of the system and can give you an overview of the business process
involved. Depending on the situation, you might talk to learn how the system functions on
a day-to-day basis.
The interviewing process involves a series of steps:
Determine the people to interview
Establish objectives for the interview
Develop interview questions
Prepare for the interview
Conduct the interview
Document the interview
Evaluate the interview
2.3.5.1
Review Current Documentation
Although interviews are an extremely important method of obtaining information, you
also may want to investigate the current system documentation. The documentation might
not be up-to-date, so you should check with users to confirm that you are receiving
accurate and complete information.
2.3.5.2
Observe Operations
Another fact-finding method is to observe the current system in operation. You might see
how workers carry out typical tasks. You might choose to trace or follow the actual paths
taken by input source documents or output reports. In addition to observing operations,
you might want to sample the inputs or outputs of the system. Using simple statistical
techniques described in the Systems Analysts Toolkit, you can obtain valuable information about
the nature and frequency of the problem.
2.3.5.3
Carry out A User Survey
Interviews can be time-consuming. Sometimes you can obtain information from a larger group
by carrying out a user survey. In this case, you design a form that users complete and
return to you for tabulation. A survey is not as flexible as a series of interviews, but it is
less expensive, generally takes less time, and can involve a broad cross section of people.
Step 4: Determine Feasibility
At this point you have analyzed the problem or opportunity, defined project scope and
constraints, performed fact-finding to learn about factors that might affect the project, and
estimated the costs and benefits of the new system. Now you are ready to determine
operational, technical, and economic feasibility.
43
44
4. Recommendations
Recommendations for further action, with specific reasons and justification, are
explain in this section. Management will make the final decision, but the IT
departments input is an important factor.
5. T i m e a n d C o s t E s t i m a t e s .
This section describes the cost of acquiring and installing the system, and the total cost
of ownership during the systems useful life.
6. E x p e c t e d B e n e f i t s .
Anticipated tangible and intangible benefits and a timetable that shows when they are
to occur are included in this section.
7. A p p e n d i x .
An appendix is included in the report if you need to attach supporting information. For
example, you might list the interviews you conducted, the documentation you
reviewed, and other sources for the information you obtained. You do not need
detailed reports of the interviews or other lengthy documentation. It is critical that you
retain those documents to support you findings and for future reference.
Review Questions
1.
2.
3.
4.
5.
6.
7.
8.
9.
45
TOPIC 3
3. REQUIREMENT MODELING
_______________________________ _________________________________
LEARNING OUTCOMES
After studying this topic you should be able to:
Explain systems analysis phase activities and the end product of the systems
analysis phase
Describe joint application development (JAD) and rapid application development
(RAD)
Describe the Unified Modeling Language (UML) and explain use case diagrams and
sequence diagrams
Explain how functional decomposition diagrams (FDD) are used during systems
development
List and describe system requirements, including outputs, inputs, process,
performance, and controls
Explain the importance of scalability in systems design
Define total cost of ownership (TCO)
Describe how to conduct a successful interview
Explain when and how to use fact-finding techniques, including interviews,
documentation review, observation, questionnaires, sampling, and research.
Develop effective documentation methods to use during systems development
3.1 OVERVIEW OF SYSTEMS ANALYSIS PHASE
Fact-finding techniques
Interviewing
Documentation review
Observation
Surveys and Questionnaires
Sampling
Research
Methods used to record results
3.1.1Systems analysis phase tasks
Requirements Modeling
Data and Process Modeling
Object Modeling
Transition to Systems Design
46
professionals now recognize that successful systems must be user oriented, and user need
to be involved, formally or informally, at every stage of system development One popular
strategy for user involvement is a JAD team approach, which involves a task force of
users, managers, and IT professionals that work together to gather information, discuss
business need, and define the new system requirements.
A (JAD) team usually meets over a period of days or weeks in special conference room or
at an off-site location. JAD participants should be insulated from the distraction of day-today operations. Objective is to analyze the existing system, obtain user input and
expectations, and document user requirements for the new system.
The traditional model for systems development was an IT department the use structured
analysis and consulted users when their input or approval was needed. Although the IT
staffs still has a central role and structured analysis remains a common method of systems
development, many companies now use teams to develop information systems. For
example, joint application development (JAD), is a group-oriented technique for factfinding and requirements modeling. Because it is not linked to a specific development
methodology, systems developers use JAD when group input and interaction is desired.
Team-oriented methodologies that go beyond JAD and provide an overall framework for
systems development include rapid application development (RAD) and Microsoft
Solutions Framework (MSF), which are both described in the Systems Analysts Toolkit.
Joint Application Development Joint application development (JAD) is a popular systems
development technique. In a traditional structured analysis process, the IT staff collects
information from users and managers and develops the requirements for a new system.
The company creates a task force of users, managers, and IT professional that works
together to gather information, discuss business needs, and define the new system
requirements.
The JAD team usually meets over a period of days or weeks, in a special conference room
or at an off-site location. Either way, JAD participants should be insulated from the
distraction of day-to-day operations. The objective is to analyze the existing system, work
on potential solutions, and agree on requirements for the new system. The JAD group
usually has a project leader, who needs strong interpersonal and organizational skills, and
one or more members who document and record the results and decisions. IT staff
members often serve as JAD project leaders, but that is not always the case. Systems
analysts on the JAD team participate in discussions, ask question, take notes, and provide
support to the team. If CASE tools are available, analysts can develop models and enter
documentation from the JAD session directly into the CASE tool. The JAD process
involves intensive effort by all team members. Because of the wide range of input and
constant interaction among the participants, many companies believe that a JAD group
produces the best possible definition of the new system. JAD is more expensive and can
be cumbersome if the group is too large relative to the size of the project. Many
companies find, however, that JAD allows key users to participate effectively in the
requirements modeling process. When properly used, JAD can result in a more accurate
statement of system requirements, a better understanding of common goals, and stronger
commitment to the success of the new system. JAD participants and their roles are
48
Project leader-Project leader develop an agenda, acts as facilitators, and leads the JAD
session.
Top management-Provide enterprise level authorization and support for the project
Managers-Provide department level support for the project and understanding of how the
project must support business functions and requirements.
Users-Provide operational level input on current operations, desired changes, input and
output requirements, user interface issues, and how the project will support day-to-day
tasks.
Systems analysts and other IT staff members-Provide technical assistance and
resources for JAD team members on issues such as security, backup, hardware, software,
and network capability.
Recorder-Documents results of JAD sessions and work with system analysts to build
system models and develop CASE tool documentation
Preparing for the JAD Sessions
Time commitment day to several weeks
Strong management support is needed to release key participants from their usual
responsibilities
Careful planning is essential
Typical JAD session agenda
49
In order to complete the current version in as short amount of time as possible. There
elements contribute to the success of rapid development by improving both the quality of
the delivered system and the speed of delivery. Traditional lifecycles follow a rigid
sequence of steps focus a user to sign-off after the completion before development can
proceed to the next step. The requirements and design are then frozen and the system is
coded, tested, and implemented. With such conventional methods, there is a long delay
before the customer gets to see any results.
RAD is a methodology to for compressing the analysis, design, build, and test phases into
a series of short, iterative development cycles. This has a number of distinct advantages
over the traditional sequential development model. This lifecycle, through the following
four stages, includes all of the activities and tasks required to scope and define business
requirements and design, develop, and implement the application system that supports
those requirements.
The structure of the RAD lifecycle is thus designed ensure the developers build the
systems that the users really need. This lifecycle, though the following four stages,
includes all of the activities and tasks require to scope and define business requirements
and design, develop, and implement the application system that support those
requirement.
Requirements Planning
Also known as the Concept Definition Stage, this stage defines the functions and data
subject areas that the system will support and determines the systems scope.
User Design
Also known as the Function design Stage, this stage uses workshop to model the
systems data and processes and to build the prototype of the critical system
components.
Construction
Also known as the Development Stage, this stage completes the construction of the
physical application system and help designer creates code using code generator and
end user validates screens and other aspects of design.
Implementation
Also known as the Deployment Stage, this stage includes final user testing and
training, data conversion, and the implementation of the application system.
3.3.1 RAD advantage and disadvantage
Advantage of RAD
Dramatic time savings the system development effort.
Can save time, money and human effort.
Tighter fit between user requirements and system specifications.
System optimized for users involved in RAD process.
Ability to rapidly change system design as demanded by users.
Concentrates on essential system elements from user viewpoint.
51
Disadvantage
More speed and lower cost may lead to lower overall system quality.
Danger of misalignment of system developed via RAD with the business due to
missing information.
May have inconsistent internal designs within and across systems.
Lack of scalability designed into system.
Lack of attention to later systems administration built into system.
High cost of commitment on the part of key user personnel.
3.4
Models helps users, managers, systems develops to understand current r new system
designs. Modeling involves graphical method and nontechnical language that represent
the system at various stages of development. During requirements modeling, you can use
the Unified Modeling Language to describe user interaction with the system, and function
decomposition diagram to show the organization of business function and processes.
Modeling and fact-finding are closely related fact-finding results translate into
models that improve documentation and communication, and often lead to more factfinding and modeling.
3.4.1 Unified Modeling Language
The Unified Modeling Language (UML) is widely used methods of visualizing and
documenting software systems design. UML was created by Grady Booch, Ivar Jacobson,
and James Rumbaugh in early1990s and soon became an IT industry standard. UML uses
object-oriented design concepts, but it is independent any specific programming language
and is used to describe business processes and requirements generally.UML provides
various graphical tools and techniques, such as use case diagrams and sequence diagrams.
During requirements modeling, a systems analyst can utilize such tools to represent the
information system from a users viewpoint. A brief description of each is given below.
3.4.2 USE CASE Diagrams
During requirements modeling, system analyst and users work together to document
requirements and model system functions. A use case diagram visually represents the
interaction between users and the information system.
In a use case diagram, the user becomes an actor, with a specific role that describes how
he or she interacts with the system. Systems analysts can draw use case diagrams
freehand or use CASE tools that integrate the use cases into the overall system design.
3.4.3 Sequence Diagrams
Sequence diagrams show the timing of transaction between objects as they occur. A
systems analysts use a sequence diagram to show all possible outcomes, or focus on a
single scenario. The interaction proceeds from top to bottom, along a vertical timeline,
while the horizontal arrows represent messages from one object to another.
52
Data entry screens must be uniform, except for background colour, which can be
changed by the user.
A data entry person at the medical group must input patient service into the billing
system.
3.5.3 Processes
The student records system must allow record access by either the student name or the
student number.
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 IRS.
The warehouse distribution system must analyze daily orders and create a routing
pattern for delivery trucks that maximizes efficiency and reduces unnecessary mileage.
The human resources system must interface properly with the existing payroll
system.
The video rental system must not execute new rental transactions for customers who
overdue tapes.
The prescription system must automatically generate an insurance claim form.
3.5.4Performance
The system must support 25 users online simultaneously.
Response time must not exceed four seconds.
The system must be operational 7 days a week, 365 days a year.
The accounts receivable system must prepare customer statements by the third
business day of the following month.
The student records system must produce class lists within five hours after the end of
registration.
The online inventory control system must flag all low-stock items within one
hour after the quantity falls below a predetermined minimum.
3.5.5Controls
The system must provide log-on security at the operating system level.
An employee record must be added, changed, or deleted only by a member of the
human resources department.
The system must maintain separate levels of security for users and the system
administrator.
All transactions must have audit trails.
The manager of the sales department must approve orders that exceed a customers
credit limit.
The system must create an error log file that includes the error type, description, and
time.
54
them in TCO estimate. Even if accurate figures are unavailable, management should
consider indirect costs that might increase TCO.
3.7 FACT-FINDING
Now that you understand the categories of system requirements, scalability, and TCO, the
next step is to begin collecting information. Whether you are working on your own or as a
member of a JAD team, during requirements modeling you will use various fact-finding
techniques, including interviews, document review, observation, surveys and
questionnaires, sampling, and research.
3.7.1Overview
Although software can help you gather and analyze facts, no program actually performs
fact-finding for you. The first step is to identify the information you need.
Typically, you begin by asking a series of questions, such as these:
1. What business functions are supported by the current system?
2. What strategic objectives and business requirements must be supported by the new
system?
3. What are the benefits and TCO of the propose system?
4. What transactions will the system process?
5. What information do users and managers need from the system?
6. Must the new system interface with legacy systems?
7. What procedures could be eliminated by business process reengineering?
8. What security issues exist?
9. What risks are acceptable?
10.What budget and timetable constraints will affect system development?
To obtain answers those and similar questions, you must start with a fact-finding plan.
You will develop a strategy, carry out fact-finding techniques, document the results, and
prepare a system requirements document, which is presented to management.
3.7.2Who, What, When, Where, and How?
Fact-finding involves answers to five familiar questions: who, what, when, where
and how. For each of those questions you must also ask another very important question:
why . Some examples of these questions are:
1. W h o ?
Who performs each of the procedures within the system? Why are the correct people
performing the activity? Could other people perform the tasks more effectively?
2. W h a t ?
What is being done? What procedures within are being followed? Why is the process
necessary? (Often, procedures are followed for many years and no one knows why.
You should question why a procedure is being followed at all.)
3. W h e r e ?
56
Where are operations being performed? Why? Where could they be performed? Could
they be performed more efficiently elsewhere?
4. W h e n ?
When is a procedure performed? Why is it being performed at this time? Is it the best
time?
5. H o w ?
How is a procedure performed? Why is it performed in that manner? Could it be
performed better, more efficiently, or less expensively in some other manner?
There is a difference between asking what is being done and what could or should be
done. The sequence of the questions is very important, especially at this early stage of the
development process. The systems analyst first must know what current situation is. Only
then can he or she tackle the question of what should be done.
The system analysis phase can be especially challenging when a large system is
involved. Business systems are never static they change rapidly to meet the
organizations needs. If revision were made to a system, it might not resemble the original
systems design at all. In some cases, the systems analyst must perform reverse
engineering to find out how the original system functional before it was modifies.
It is possible that several layers of changes were made at various times because of
enhancements and maintenance.
3.7.3Fact-Finding Techniques
Interviews
Document review
Observation
Surveys and questionnaires
Sampling
Research
3.7.3.1
Interviews
Systems analysts spend a great deal of time talking with people, both inside and outside
the information technology department. Much of that conducting interviews, which are an
important fact-finding technique. An interview is a planned meeting during which you
obtain information from another person. You must have the skill needed to plan, conduct,
and document interviews successfully. The interviewing process consists of these seven
steps:
1. Determine the people to the interview.
2. Establish objectives for the interviews.
3. Develop interview questions.
4. Prepare for the interview.
5. Conduct the interview.
6. Document the interview.
7. Evaluate the interview.
57
3 .7 .3 .2 Do c u me n t r e v i ew
Review existing system documentation
Obtain copies of actual forms and documents
Review blank copies of forms
Review samples of completed forms
Review software documentation
3 .7 .3 .4 O b s e r v a t i o n
Ask questions about present system operation
Observe all steps in the processing cycle
Examine each form, record, and report
Consider each person working with the system
Talk to people who receive current reports
Consider the Hawthorne Effect
3.7.3.5 Questionnaires and surveys
Brief and user-friendly
Clear instructions
Questions in logical order
Simple wording to avoid misunderstanding
Avoid leading questions
Open-ending questions are difficult to tabulate
Limit questions raising concern/negative issues
Section for general comments
Test the questionnaire in advance
3.7.3.6 Sampling
Collect examples of actual documents
Sampling techniques
Systematic sample
Stratified sample
Random sample
Main objective is to ensure representation of the overall population accurately
Sampling should be considered for interviewing or questionnaires
3.7.3.7Research
Journals, periodicals, books
Internet sites
Hardware and software vendors
Independent firms that provide information
Newsgroups
Professional meetings, seminars, discussions
58
59
TOPIC 4
__________________________________________________________________
4. DATA AND PROCESS MODELING
__________________________________________________________________
LEARNING OUTCOMES
After studying this topic you should be able to:
Describe data and process modeling concepts and tools
Explain how structured analysis describes an information system
Describe the symbols used in data flow diagrams and explain the rules for their use
Explain the sequence of data flow diagrams, from general to specific
Explain how to level and balance a set of data flow diagrams
Draw a complete set of data flow diagrams for an information system
Describe how a data dictionary is used and what it contains
Use process description tools, including structured English, decision tables, and
decision trees
Explain the interaction among data flow diagrams, the data dictionary, and process
description
Describe the relationship between logical and physical models
INTRODUCTION
Systems analysis phase has three stages
Requirements determination
Requirements analysis
Evaluation of alternatives
4.1
Process
Data flow
Data store
External entity
61
The symbol for a data flow is a line with a single or double arrowhead. The data flow
name appears above, below, or alongside the line. A data flow name consists of a singular
noun and an adjective, if needed. Examples of data flow names are DEPOSIT, INVOICE
PAYMENT, STUDENT GRADE, ORDER and COMMISION. Exceptions to the singular
name rule are data flow names, such as GRADING PARAMETERS, where a singular
name could mislead you into thinking a singular parameter or singular item of data exists.
Because a process changes data from one form to another, at least one data flow must
enter and one data flow must exit each process symbol, as they do in the CREATE
INVOICE process. A process symbol can have more than one outgoing data flow, as
shown in the GRADE STUDENT WORK process, or more than one incoming data flow,
as shown in the CALCULATE GROSS PAY process. A process also can connect to any
other symbol, including another process symbol, as shown by the connection between
VERIFY ORDER and ASSEMBLE ORDER. Therefore, a data flow must have a process
symbol on at least one end.
62
The APPLY INSURANCE PREMIUM process, for instance, has no input data flow.
Because it has no input, the process is called a spontaneous generation process. The
CALCULATEGROSS PAY is a black hole process, which is a process that has no output.
A gray hole is a process that has at least one input and one output, but the input obviously
is insufficient to generate the output shown. For example, a date of birth input is not
sufficient to produce a final grade output in the CALCULATE GRADE process.
A data store must be connected to a process with a data flow. In each case, the data store
has at least one incoming and one outgoing data flow and is connected to a process
symbol with a data flow.
4.1.6 External Entity Symbol
An external entity is a person, department, outside organization, or other information that
provides data to the system or receives output from the system. The symbol for an entity
is a rectangle, which usually is shaded to make it look three-dimensional. The
name of the external entity appears inside the square. External entities show the
boundaries of the information system and how the information system interacts with the
outside world. For example, a customer submitting an order is an external entity because
the customer supplies data to the order system. Other examples of external entities
include a patient who supplies medical data, a homeowner who receives a property
tax bill, a warehouse that supplies a list of items in stock, and an accounts payable system
that receives data from the companys purchasing system. External entities also are
called terminators, because they are data origins or final destinations. Systems analysts
call an external entity that supplies data to the system a source, and an external entity that
receives data from the system a sink. An external entity name is the singular form of a
department, outside organization, other information system, or person. An external
entity must be connected to a process by data flow.
4.1.7Context Diagrams
Top-level view that shows the systems boundaries scope
Represent the results of fact-finding
One process symbol, numbered 0 (zero) is drawn in the center
Data flows connect the process to the entities
Conventions for data flow diagrams
1. Each context diagram must fit on one page
2. Process name in the context diagram should be the name of the information system
3. Use unique names within each set of symbols
4. Do not cross lines. Use abbreviated identifications (# <9)
5. Use a unique reference number for each process symbol
Diagram 0
Displays more detail than the context diagram
Shows entities, major processes, data
Other characteristics of dataflow diagrams
Lower-level diagrams
Usually necessary to show more detail
Design must consider
o Leveling
o Balancing
o Data stores
Leveling: Process of drawing increasingly detailed diagrams. Also called exploding,
partitioning, or decomposing.
Balancing: Maintains consistency among an entire set of DFDs. Parents input and output
data flows are preserved on the child.
Data stores: Might not appear on higher-level DFDs. These are shown on the highestlevel DFD that has two or more processes using that data store.
Strategies for developing DFDs
Main objective is to ensure that your model is
accurate and easy to understand
A diagram should have no more than nine process symbols
the objective is the same: to provide clear, comprehensive information about the data and
processes that make up the system.
4.2.2 Documenting the data flows
Must document every data flow
Standard form or CASE tool can be used
All major characteristics must be recorded and described
4.2.3 Documenting the data stores
Must document every data store
Standard form or CASE tool can be used
All major characteristics must be recorded and described
4.2.4 Documenting the processes
Must document every process
Standard form or CASE tool can be used
All major characteristics must be recorded and described
4.2.5 Documenting the external entities
Must document every external entity
Standard form or CASE tool can be used
All major characteristics must be recorded and described
4.2.6 Documenting the records
Must document every record
Standard form or CASE tool can be used
All major characteristics must be recorded and described
4.2.7 Data dictionary reports
Data dictionary serves as a central storehouse for documentation
Using this data, you can produce many valuable reports
4.3 MODULAR DESIGN
Modular design is based on combinations of three logical structures, sometimes called
control structures, which serve as building blocks for the process. Notice that each logical
structure has a single entry and exit point. The three structures are called sequence,
selection, and iteration. A rectangle represents a step or process, a diamond shape
represents a condition or decision, and the logic follows the lines in the direction
indicated by the arrows
66
1. Sequence-The completion of steps in sequential order, one after another. One or more
of the steps might represent a sub process that contains additional logical structures.
2. Selection-The completion of one of two or more process steps based on the results of a
test or condition
3. Iteration-The completion of a process step that is repeated until a specific condition
changes. Iteration also is called repetition or looping.
Sequence, selection, and iteration structures can be combined in various ways to describe
processing logic.
4.3.1 Structured English
Structured English is a subset of Standard English that describes logical process clearly
and accurately. When you use structured English, you must conform to the following
rules:
Use only the three building blocks of sequence, selection, and iteration.
Use indentation for readability.
Use a limited vocabulary; including standard terms used in the data dictionary
and specific words that describe the processing rules.
Although the techniques are similar, the primary purpose of structured English is to
describe the underlying business logic, while programmers, who are concerned with
coding, mainly use pseudo code as a short hand for the actual code. Notice that the
capitalized words are all terms from the data dictionary to ensure consistency between
process description and the data dictionary. The other terms, such as for, each, if, and
output, describe the processing logic. Following these structured English rules ensures
that your process descriptions are understandable to users who must confirm that the
process is correct, as well as to other analysis and programmers who must design the
information system from your descriptions.
4.3.2Decision tables
4.3.2Decision Trees
A decision trees is a graphical representation of the conditions, actions, and rules found in
a decision table. Decision trees show the logic structure in a horizontal form that
resembles a tree with the roots at the left and the branches to the right. Like flowcharts,
decision trees are effective ways to present the system to management. Decision trees and
decision tables are considered equivalent, but in different formsa graphic versus a
table. A decision tree is read from left to right, with the conditions along the various
branches and the actions at the far right. Because the example has two conditions with
67
four resulting sets of actions, the example has four terminating branches at the right side
of the tree.
Whether to use decision table or a decision tree of often is a matter of personal
preference. A decision table might be a better way to handle complex combinations of
conditions. On the other hand, a decision tree is an effective way to describe a
relatively simple process.
Decision trees
Graphical representation that shows a decision tables conditions, actions, and rules
Logic structure is shown horizontally
Easy to construct and understand
Decision table is better in complex situations
4.4
4.4.1Sequence of models
A physical model shows how the systems requirements are implemented
Create a physical model of the current system
Develop a logical model of the current system
After the current system is understood, create a logical model of the new system
4.4.2Four-model approach
Physical model of the current system
Logical model of the current system
Logical model of the new system
Physical model of the new system
Review Questions
1. Describe data and process modeling, and name the main data and process modeling
techniques.
2. Describe the Gane and Sarson symbols used for process, data flows, data stores, and
entities.
3. What is the relationship between the context diagram and diagram 0 and which symbol
is not used in a context diagram.
4. What is meant by a DFD?
5. Describe the steps in creating a decision table.
6. What is structured English?
68
TOPIC 5
__________________________________________________________________
5. OBJECT MODELING
__________________________________________________________________
LEARNING OUTCOMES
After studying this topic you should be able to:
Explain how object-oriented analysis can be used to describe an information system.
Define object modeling terms and concepts, including objects, attributes, methods,
messages, classes, and instances
Explain relationships among objects, including dependency, association, aggregation,
and inheritance
Draw an object relationship diagram
Describe Unified Modeling Language (UML) tools and techniques, including use
cases, use case diagrams, class diagrams, sequence diagrams, state transition diagrams,
and activity diagrams
Explain the advantages of using CASE tool in developing the object model
Explain how to organize the object model
INTRODUCTION
Object-oriented analysis is an approach that sees a system from the viewpoint of the
objects themselves. The end product is an object model, Use Unified Modeling Language
(UML) to develop object models. Objects include data and the processes which affect the
data. A class is a group of similar objects
5.1 OBJECT-ORIENTED TERMS AND CONCEPTS
Object-oriented analysis describes an information system by identifying things called
objects. An object represents a real person, place, event, or transaction. For example,
when a patient makes an appointment itself is an object. Object-oriented analysis is a
popular approach that sees a system from the viewpoint of the objects themselves as they
function and interact with the system. The end product of object-oriented analysis is an
object model, which represents the information system in terms of objects and object
object-oriented concepts. Later, during the implementation phase of the SDLC, systems
analysts and programmers transform the objects into program code modules. A modular
approach saves money and time; because the modules can be optimized, tested, and
reused.
5.1.1 Objects
An object can represent a real person, place, event, or transaction. The UML represents
an object as a rectangle with the object name on the top, followed by the objects
attributes and methods.
69
5.1.2 Attributes
Attributes are characteristics that describe the object
The number of attributes needed depends on the business requirements of the
information system and its users
Attributes are designed during the systems design process
Objects can inherit, or acquire, attributes from other objects
The state of an object is an adjective that describes the objects current status
5.1.3 Methods
A method defines specific tasks that an object can perform
Methods describe what and how an object does something
A constructor method creates a new instance of an object
An update method changes existing data
A query method provides information about an objects attributes
5.1.4 Messages
A message is a command that tells an object to perform a certain method
Polymorphism is the concept that the same message to two different objects can
produce different results
The black box concept is an example of encapsulation all data and methods are
5.1.5 Classes
An object belongs to a group or category called a class
Objects within a class can be grouped into subclasses
A class can belong to a more general category called a super class
5.2
RELATIONSHIPS AMONG OBJECTS AND CLASSES
Relationships enable objects to communicate and interact
Relationships describe what objects need to know about each other
5.2.1Types of relationships
Dependency- Occurs when one object must be informed about another
Association-Stronger than dependency and occurs when certain attributes of one object
are determined by its interaction with another object
Aggregation-Exists when an object forms part of another object
Inheritance-Enables an object to derive one of more of its attributes from another
object
5.2.3 Object relationship diagram
Provides an overview of the system
Used as a guide to develop additional diagrams and documentation
70
5.3
71
72
TOPIC 6
6. DEVELOPMENT STRATEGIES
_______________________________ _________________________________
LEARNING OUTCOMES
After studying this topic you should be able to:
Evaluate software alternatives and development strategies
Explain advantages and disadvantages of developing in-house software versus
purchasing and customizing a software package
Describe how companies use out-sourcing and user applications
List the steps in purchasing and evaluating a software package
Explain the differences between a request for proposal (RFP) and a request for
quotation (RFQ)
Describe the system requirements document and the presentation to management at the
end of the systems analysis phase
Explain the transition from systems analysis to systems design, and the difference
between logical and physical design
Explain the importance of prototyping and describe various prototyping methods,
tools, and techniques
Discuss the systems design process and provide guidelines for system design
Create and use appropriate codes during systems design and development
6.1
In the system analysis phase, you investigated the current system and developed a logical
model for the proposed system. Now, as you prepare for the transition to the system
design phase, you will examine software alternatives and select an overall strategy for the
proposed system. Companies can acquire software by developing an in-house system,
buying a commercial software package, or customizing a software package. Although
many factors influence this decision, the most important consideration is total cost of
ownership (TCO). The choice between developing in-house software and purchasing
software often is called a make or buy, or build or buy decision. The companys IT
department makes, builds, and develops in-house software, whereas a software package
is purchased or leased from another firm. The package might be a standard commercial
program to a customized package designed specifically for the purchaser. Companies that
develop software for sale are called software vendors.
A firm that enhances a commercial package by adding custom features and configuring it
for a particular industry is called a value-added reseller (VAR).
Software packages are available for every type of business activity. A software package
that can be used by many different types of organizations is called a horizontal
application.
An accounting package is a good example of a horizontal application because it can be
utilized by many different businesses.
73
74
75
79
and selection of alternatives is not a simple process. The objective is to obtain the product
with the lowest total cost of ownership, but actual cost and performance can be difficult to
measure. When selecting hardware and software, systems analysts often work as an
evaluation and selection team. A team approach ensures that critical factors are not
overlooked and that a sound choice is made. The evaluation and selection team also must
include users, who will participate in the selection process and feel a sense of ownership in the
new system. The primary objective of the evaluation and selection team is to eliminate
system alternatives that will not work, rank the system alternatives that will work, and
then present the visible alternatives to management for a final decision.
6.6 COMPLETION OF SYSTEMS ANALYSIS
To complete the systems analysis phase, you must prepare the system requirements
document and your presentation to management.
6.6.1 System Requirements Document
The system requirements document, or software requirements specification, contains the
requirements for the new system, describes the alternatives that were considered, and
makes a specific recommendation to management. This important document is the
starting point for measuring the performance, accuracy, and completeness of the finished
system before entering the systems design phase. The system requirements document is
like a contract that identifies what must be delivered, by the systems developers, to uses;
therefore you should write the system requirements document in language that users can
understand so they can offer input, suggest improvements, and approve the final version.
Because the system requirements document can be lengthy, you should format and
organize it so it is easy to read and use. The system requirements document should
include a cover page and a detailed table of contents. The system requirements document
should include a cover page and a detailed table of contents. You also can add index and a
glossary of terms to make the document easier to use. The content of the system
requirements document will depend on the company and the complexity of the system.
The Systems Analysts Toolkit provides guidance and offers suggestions to help you
create the system requirements document.
6.6.2Presentation to Management
The presentation to management at the end of the systems analysis phase is one of the most
critical milestones in the systems development process. At this point, managers make key
decisions that affect the future development of the system. Prior to the management
presentation, you might give two other presentations: one to the principal individuals in
the IT department to keep them posted, and another presentation to users to answer their
questions and seek their approval. The system requirements document is the basis for all
three presentations, and you should distribute the document, or a summary, in advance so
the recipients can review it. When preparing your presentation, you should review the
guidelines and suggestions in the Systems Analysts Toolkit, which will help you, design
and deliver a successful presentation. In addition to the techniques found in the Toolkit, also keep
the following suggestions in mind
82
Begin you presentation with a brief overview of the purpose and primary objectives of
the system project.
Summarize the primary visible alternatives. For each alternative, describe the costs,
advantages, and disadvantages.
Explain why the evaluation and selection team chose the recommended alternative.
Allow time for discussion and for questions and answers.
Obtain a final decision from management or agree on a timetable for the next step in
the process.
The object of the management presentation is to obtain approval for the development of
the system and to gain managements full support, including necessary financial
resources. Management will probably choose one of the five alternatives: develop an in
house system, modify the current system, purchase or customize a software package,
perform additional systems analysis work, or stop all further work. Depending on their
decision, you next task as a systems analyst will be one of the following:
1. D e v e l o p a n i n - h o u s e s ys t e m. Begin the systems design phase for the new
system.
2. M o d i f y t h e c u r r e n t s ys t e m. Begin the systems design phase for the modified
system.
3. P u r c h a s e o r c u s t o mi z e a s o f t w a r e p a c k a g e . Negotiate the purchase terms
with the software vendor for management approval. Then, if the package will be used
without modification, you can begin planning the systems implementation phase.
If you must make modifications to the package, your next step is to start planning the
testing and documentation of the modifications as part of the systems implementations
phase.
4. Performing additional systems analysis work.
Management might want you to investigate certain alternatives further, explore
alternatives not examined, reduce the project scope because of cost constraints, or
expand the project scope based on new developments. If necessary, you will perform the
additional work and schedule a follow-up presentation.
5. S t o p a l l f u r t h e r w o r k .
The decision might be based on your recommendation, a shift in priorities or costs, or
for other reasons. Whatever the reason, if that is managements decision, then you
have no additional tasks for the project other than to file all your research in a logical
location so that it can be retrieved if the project is reopened in the future.
After the presentation and management decision, you will begin a variety of tasks,
depending on the strategy chosen. If you are developing an in-house system or modifying
a package, you will build a model of the proposed system and start designing the systems
output, input, files, and data structures. The following sections describe several tools and
techniques that can assist you in the process, including prototyping, CASE tools, and
alternative graphical tools.
83
requirements change. You might return to requirements analysis if you reencounter unforeseen
design issues or problems. Such cases are the exception to the rule, however. If an analyst
develops a pattern of returning to prior phases, it could indicate that earlier work was
inaccurate or incomplete.
Other Modeling Tools
As you proceed from logical design to physical design, you continue to use DFDs, object
modeling tools, CASE tools, and the prototyping tools described in this chapter. You also
should know about systems flowcharts, which are another method of physical design of a
system.
6.10 OVERVIEW OF SYSTEMS DESIGN
An information system has five basic components: data, people, processes, hardware, and
software. Interaction among the components has a major impact on the design process, so
the systems analyst must understand the entire logical design of system before beginning
the physical design of any one component. The first step is to review the system
requirements document, which is especially important if you did not work on the previous
phase or if a substantial amount of time passed since the analysis phase was completed.
6.10.1 System Design Objectives
The goal of system design is to build the system that is effective, reliable, and
maintainable. To be effective, the system must satisfy the defined requirements and
constraints. The system also must be accepted by users who use it to support the
organizations business objectives. A system is reliable if it adequately handles error, such
as input errors, processing error, hardware errors, or human mistakes. Ideally, all errors
can be prevented. Unfortunately, no system is completely foolproof, whether it is a
payroll system, a telephone switching system, an internet access system, or a space shuttle
navigation system. A more realistic approach to building are liable system is to plan an
errors, detect them as early as possible, allow for them correction, and prevent them from
damaging the system itself. A system is maintainable if it is well designed, flexible, and
developed with future modifications in mind. No matter how well a system is design and
implemented, at some point it will need to be modified. Modifications will be necessary
to correct problems, to adapt to changing user requirements, to enhance the system, or to
take advantage of changing technology. Your systems design must be capable of handling
future modifications or the system soon will be outdated and fail to meet requirements.
6.10.2 Systems Design Considerations
Good design results in systems that are effective, reliable, and maintainable. Design
considerations involve users, data, and processing.
6.10.3 User Considerations
Of the many issues you must consider during systems design, your most important goal is
to make the system acceptable to users, or user-friendly. Throughout the design process,
the essential factor to consider is how decisions will affect users. Always remember that
you are designing the system for the user, and keep these basic points in mind.
85
Carefully consider any point where users receive output from, or provide input to, the
system.
Above all, the user interface must be easy to learn and use. Input process should be well
documented, easy to follow, intuitive, and forgiving of errors. Output should be attractive
and easy to understand, with an appropriate level of detail.
Anticipate future needs of the users, the system and the organization.
Suppose that an employee master file contains one-character field to indicate each
employees category. The field currently has two valid values: indicates a full time
employee, and P indicates a part-time employee. Depending on the field value, either
FULL TIME or PART-TIME will print as the value on various reports. While those two
values could be programmed, or hard coded, into the report programs, designing a
separate table with category Cades and captions is a better choice.
6.10.4 Data Considerations
Data entry storage considerations are important parts of the system design. Here are some
guidelines to follow: Data should be entered into the system where and when it occurs
because delays cause data errors.
For examples, employees receiving department should enter data about incoming
shipments when the shipments arrive, and sales clerks should enter the data about new
orders when they take the orders. Data should be verified when it is entered, to errors
immediately.
The input design should specify a data type, such as numeric, alphabetic, or character, and
range of acceptable values for each entry data item. If an incorrect data value is entered,
the system should recognize and flag it immediately. The systems should also allow
corrections at any time. Some errors, for examples, are corrected easiest right at entry
while the original source documents are at hand or the costumer is on the telephone. Other
errors may need further investigation, so users must be able to correct errors at a later
time. Automated methods of data entry should be used whenever possible. Receiving
department employees in many companies, for examples, are corrected easiest right at
entry while the original source documents are at hand or the customer is on the telephone.
Other errors may need further investigation, so users must be able to correct errors at a
later time.
Automated methods of data entry should be used whenever possible. Receiving
department employees in many companies, for example, use scanners to capture data
about merchandise received. Access for data entry should be controlled and all entries or
changes to critical data values should be reported.
Dollar fields and many volume fields are considered critical data fields. Examples of
critical volumes include the number of checks processed, the number of medical
prescription dispensed, or the number insurance premium payments received. Reports that
trace the entry and changes to critical data values are called audit trails and are essential in
every system. Every instance of entry and change to data should be logged.
Data duplication should be avoided.
86
87