Lecture Notes in:

Systems Analysis and Design I.

Business Information Systems Program

Prof. Amira M. Idrees

1
 ‫بسم هللا الرحمن الرحيم‬

‫س ْب َحانَ َك ََل ِع ْل َم لَنَا ِإ اَل‬ ‫( قَالُوا ُ‬

‫علا ْمتَنَا ۖ ِإنا َك أ َ ْنتَ ا ْلعَ ِلي ُم‬
‫َما َ‬
‫ا ْل َح ِكي ُم )‬

‫صدق هللا العظيم‬

‫سورة البقرة (أية رقم‪)32 :‬‬

‫‪2‬‬
 Table of Content

Section Page
No
Chapter 1: Foundations for System Development 6
1.1 System Analysis and Design 6
1.2 Systems Analysis and Design: Core Concepts 9
1.3 System Concepts 11
1.4 The Systems Analyst 17
1.5 Developing Information Systems and the Systems 21
Development Life Cycle
1.6 Planning and control for system success 26
1.7 Alternative Approaches to Development 28
Chapter 2: Project Selection and Management 33
2.1 Reasons for Systems Projects 34
2.2 Sources of Systems Projects 36
2.3 Projects’ Initiation 37
2.4 Problem Definition 41
2.5 Project Planning 42
2.6 Project Closedown 67
2.7 Using Project Management Software 68
Chapter 3: Determining System Requirements 69
3.1 Performing Requirements Determination 71
3.2 Traditional Methods for Determining Requirements 81
3.3 Modern Methods for Determining System 92
3.4 Radical Methods for Determining System 96
Requirements
3.5 Selecting the Appropriate Techniques 96
3.6 Requirements Analysis Strategies 99
Chapter 4: Structuring System Requirements: 105
Process Modeling
4.1 The Analysis Phase 105

3
4.2 Process Modeling 107
4.3 Deliverables and Outcomes 109
4.4 What Is Structured Analysis? 109
4.5 Pros and Cons of Each Tool 140
Chapter 5: Structuring System Requirements: 142
Conceptual Data Modeling
5.1 Conceptual Data Modeling 143
5.2 The Process of Conceptual Data Modeling 143
5.3 Deliverables and Outcomes 145
5.4 The Entity Relationship Diagram 145
5.5 Creating an Entity Relationship Diagram 145
5.6 Advanced Syntax 155
5.7 Validating an ERD 157
5.8 Normalization 160
Chapter 6: System Design 166
6.1 Architecture Design 167
6.2 Designing the Human Interface 174
Chapter 7: Systems Implementation and Operation 183
7.1 The Processes of Coding 185
7.2 System Testing 185
7.3 System Changeover 188
7.4 Systems Maintenance 190
7.5 System documents 191
7.6 System Training 193
References 196

4
Preface
Systems Analysis and Design (SAD) is an exciting, active field in
which analysts continually learn new techniques and approaches to
develop systems more effectively and efficiently. However, there is
a core set of skills that all analysts need to know no matter what
approach or methodology is used. All information systems projects
move through the four phases of planning, analysis, design, and
implementation; all projects require analysts to gather requirements,
model the business needs, and create blueprints for how the system
should be built; and all projects require an understanding of
organizational behavior concepts like change management and team
building.
In today’s information- and technology-driven business world,
students need to be aware of three key factors. First, it is more
crucial than ever to know how to organize and access information
strategically. Second, success often depends on the ability to work
as part of a team. Third, the Internet will play an important part in
their work lives. This book addresses these key factors.
We provide
A clear presentation of the concepts, skills, and techniques students
need to become effective systems analysts who work with others to
create information systems for businesses. We use the systems
development life cycle model as an organizing tool throughout the
book to provide a strong conceptual and systematic framework.

5
 Chapter 1
Foundations for System Development

Learning Objectives

− Define information systems analysis and design.

− Discuss the modern approach to systems analysis and

design that combines both process and data views of

systems.

− Describe the role of the systems analyst in information

systems development.

− Describe the information systems development life cycle

(SDLC).

− Describe the Alternative Approaches to System

Development

6
Chapter 1: Foundations for System Development

In business, System Analysis and Design refers to the process of

examining a business situation with the intent of improving it
through better procedures and methods. System analysis and design
relates to shaping organizations, improving performance and
achieving objectives for profitability and growth. The emphasis is
on systems in action, the relationships among subsystems and their
contribution to meeting a common goal.

Looking at a system and determining how adequately it functions,

the changes to be made and the quality of the output are parts of
system analysis. Organizations are complex systems that consist of
interrelated and interlocking subsystems. Changes in one part of the
system have both anticipated and unanticipated consequences in
other parts of the system. The systems approval is a way of thinking
about the analysis and design of computer-based applications. It
provides a framework for visualizing the organizational and
environmental factors that operate on a system. When a computer is
introduced into an organization, various functions operate on the
user as well as on the organization.

1.1 System Analysis and Design

Systems development can generally be thought of as having two

major components: Systems analysis and Systems design.

System design is the process of planning a new business system or

one to replace or complement an existing system. But before this

7
planning can be done, we must thoroughly understand the old
system and determine how computers can best be used to make its
operation more effective.

System analysis, then, is the process of gathering and interpreting

facts, diagnosing problems, and using the information to
recommend improvements to the system. This is the job of the
system analyst. Consider, for example, the stockroom operation of a
clothing store. To better control its inventory and gain access to
more up – to – date information about stock levels and reordering,
the store asks a system analyst, to “computerize” its stockroom
operations.

Systems analysts do more than solve current problems. They are

frequently called upon to help handle the planned expansion of a
business. In the case of the clothing store, the systems study is
future oriented since no system currently exists. Analysts assess as
carefully as possible what the future needs of the business will be
and what changes should be considered to meet these needs. In this
instance and in most others, analysts may recommend alternatives
for improving the situation. Usually more than one strategy is
possible.

Working with managers and employees in the organization, systems

analysts recommend which alternative to adopt, based on such
concerns as the suitability of the solution to the particular
organization and setting, as well as the employee support the
solution is likely to have. Sometimes the time required to develop
one alternative, compared with others, is the most critical issue.
Costs and benefits are also important determinants. In the end,

8
management, which will pay for and use the result, actually decides
which alternative to accept. Once this decision is made, a plan is
developed to implement the recommendation. The plan includes all
systems design features, such as new data capture needs, file
specifications, operating procedures, equipment and personnel
needs.

Analysis specifies what the system should do. Design states how to
accomplish the objective. Notice that each of the processes
mentioned involves people. Managers and employees have good
ideas about what works and what does not, about what flows
smoothly and what causes problems, about where change is needed
and where it is not, and especially about where change will be
accepted and where it will not. Despite technology, people are still
the keys that make the organizations work. Thus, communicating
and dealing with people are very important parts of the systems
analyst’s job.

1.2 Systems Analysis and Design: Core Concepts

The major goal of systems analysis and design is to improve

organizational systems. Often this process involves developing or
acquiring application software and training employees to use it.
Application software, also called a system, is designed to support a
specific organizational function or process, such as inventory
management, payroll, or market analysis. The goal of application
software is to turn data into information. For example, software
developed for the inventory department at a bookstore may keep
track of the number of books in stock of the latest best seller.
Software for the payroll department may keep track of the changing

9
pay rates of employees. In addition to application software, the
information system includes:

− The hardware and systems software on which the application

software runs. Note that the systems software helps the
computer function, whereas the application software helps the
user perform tasks such as writing a paper, preparing a
spreadsheet, and linking to the Internet.
− Documentation and training materials, which are materials
created by the systems analyst to help employees use the
software they’ve helped create.
− The specific job roles associated with the overall system, such
as the people who run the computers and keep the software
operating.
− Controls, which are parts of the software written to help
prevent fraud and theft.
− The people who use the software in order to do their jobs.

This course helps you understand and follow the software

engineering process that leads to the creation of information
systems. As shown in Figure 1.1, proven methodologies,
techniques, and tools are central to software engineering processes.
Methodologies are a sequence of step-by-step approaches that help
develop your final product, the information system. Most
methodologies incorporate several development techniques, such as
direct observations and interviews with users of the current system.
Techniques are processes that you, as an analyst, will follow to help
ensure that your work is well thought-out, complete, and
comprehensible to others on your project team.

10
 Software
Engineering
Process

~
Tools

Figure 1.1: The Software Engineering Process

1.3 System Concepts

System may be referred to any set of components, which function in

interrelated manner for a common cause or objective.

The term system refers to an organized relationship among

functioning units or components. A system exists because it is
designed to achieve one or more objectives. We come into daily
contact with the transportation system, the telephone system, the
accounting system, the production system, and, for over two
decades, the computer system. Similarly, we talk of the business
system and of the organization as a system consisting of interrelated
departments (subsystems) such as production, sales, personnel, and
an information system. None of these subsystems is of much use as
a single, independent unit. When they are properly coordinated,
however, the firm can function effectively and profitably.

There are more than a hundred definitions of the word system, but
most seem to have a common thread that suggests that a system is

11
an orderly grouping of interdependent components linked together
according to a plan to achieve a specific objective. The word
component may refer to physical parts (engines, wings of aircraft,
car), managerial steps (planning, organizing and controlling), or a
system in a multi-level structure. The component may be simple or
complex, basic or advanced. They may be single computer with a
keyboard, memory, and printer or a series of intelligent terminals
linked to a mainframe. The study of systems concepts, then, has
three basic implications:

1. A system must be designed to achieve a predetermined objective.

2. Interrelationships and interdependence must exist among the

components.

3. The objectives of the organization as a whole, have a higher

priority than the objectives of its subsystems. For example,
computerizing personnel applications must conform to the
organization’s policy on privacy, confidentiality, and security, as
well as making selected data (e.g. payroll) available to the
accounting division on request.

1.3.1 Elements of a System

In most cases, systems analysts operate in a dynamic environment

where change is a way of life. The environment may be a business
firm, a business application, or a computer system. To reconstruct a
system, the following key elements must be considered:

Outputs and Inputs: A major objective of a system is to produce

an output that has value to its user. Whatever the nature of the
output (goods, services, or information), it must be in line with the

12
expectations of the intended user. Inputs are the elements (material,
human resources, and information) that enter the system for
processing. Output is the outcome of processing. A system feeds on
input to produce output in much the same way that a business
brings in human, financial, and material resources to produce goods
and services. It is important to point out here that determining the
output is a first step in specifying the nature, amount, and regularity
of the input needed to operate a system.

Processor(s): The processor is the element of a system that

involves the actual transformation of input into output. It is the
operational component of a system. Processors may modify the
input totally or partially, depending on the specifications of the
output. This means that as the output specifications change so does
the processing. In some cases, input is also modified to enable the
processor to handle the transformation.

Control: The control element guides the system. It is the decision –

making subsystem that controls the pattern of activities governing
input, processing, and output. In an organizational context,
management as a decision – making body controls the inflow,
handling and outflow of activities that affect the welfare of the
business. In a computer system, the operating system and
accompanying software influence the behavior of the system.
Output specifications determine what and how much input is
needed to keep the system in balance. In systems analysis, knowing
the attitudes of the individual who controls the area for which a
computer is being considered can make a difference between the
success and failure of the installation.

13
Feedback: Control in a dynamic system is achieved by feedback.
Feedback measures output against a standard in some form of
cybernetic procedure that includes communication and control.
Output information is fed back to the input and / or to management
(Controller) for deliberation. After the output is compared against
performance standards, changes can result in the input or processing
and consequently, the output.

Environment: The environment is the “sup-system” within which

an organization operates. It is the source of external elements that
impinge on the system. In fact, it often determines how a system
must function. For example, the organization’s environment,
consisting of vendors, competitors, and others, may provide
constraints and, consequently, influence the actual performance of
the business.

Boundaries and interface: A system should be defined by its

boundaries – the limits that identify its components, processes and
interrelationship when it interfaces with another system. For
example, a teller system in a commercial bank is restricted to the
deposits, withdrawals and related activities of customers checking
and savings accounts. It may exclude mortgage foreclosures, trust
activities, and the like. Each system has boundaries that determine
its sphere of influence and control.

1.3.2 Systems Models

In no field are models used more widely and with greater variety
than in systems analysis. The analyst beings by creating a model of

14
the reality (facts, relationships, procedures, etc.) with which the
system is concerned. Every computer system deals with the real
world, a problem area, or a reality outside itself.

Schematic Models: A schematic model is a two – dimensional chart

depicting system elements and their linkages. Different arrows are
used to depict information flow, material flow and information
feedback. Various elements of the system are depicted in boxes.

Flow system Models: A flow system model shows the flow of the
material, energy and information that hold the system together.
There is an orderly flow of logic in such models. A widely known
example is PERT (Program Evaluation and Review Technique). It
is used to abstract a real-world system in model form, manipulate
specific values to determine the critical path, interpret the
relationships and relay them back as a control.

Static system models: This type of model exhibits one pair of

relationships such as activity – time or cost – quantity. The Gantt
chart, for example, gives a static picture of an activity- time
relationship. Planned activities (stamping, sanding etc.) are plotted
in relation to time. The date column has light lines that indicate the
amount of time it takes to complete a given activity. The heavy line
represents the cumulative time schedule for each activity. The
stamping department, for example, is scheduled to start working on
order number 25 Wednesday morning and complete the job by the
same evening. One day is also scheduled for order number 28, two
days for order number 28, two days for order number 22 and two
days (May 10-11) for order number 29. The heavy line opposite the
stamping department represents the total of six days. The broken

15
line indicates that the department is two days behind schedule. The
arrowhead indicates the date when the chart is to be in effect.

Dynamic System Models: Business organizations are dynamic

systems. A dynamic model approximates the type of organization or
application that analysts deal with. It depicts an ongoing, constantly
changing system. It consists of (1) inputs that enter the system, (2)
the processor through which transformation takes place, (3) the
program(s) required for processing and (4) the output(s) that result
from processing.

1.3.3 Categories of Information

There are three categories of information related to managerial

levels and the decision managers make.

The first level is strategic information, which relates to long range

planning policies that are of direct interest to upper management.
Information such as population growth, trends in financial
investment and human resources changes would be of interest to top
company officials who are responsible for developing policies and
determining long-range goals. This type of information is achieved
with the aid of Decision Support System (DSS).

The second level of information is managerial information. It is of

direct use to middle management and department heads for
implementation and control. Examples are sales analysis, cash flow
projection and annual financial statements. This information is of
use in short – and intermediate -range planning – that is months
rather than years. It is maintained with the aid of Management
information Systems (MIS).

16
The third information level is operational information, which is
short-term, daily information used to operate departments and
enforce the day-to-day rules and regulations of the business.
Examples are daily employee absent sheets, overdue purchase
orders and current stocks available. Operational information is
established by Data processing systems (DPS).

1.4 The Systems Analyst

The systems analyst plays a key role in information systems

development projects. The systems analyst works closely with all
project team members so that the team develops the right system in
an effective way. Systems analysts must understand how to apply
technology to solve business problems. In addition, systems
analysts may serve as change agents who identify the organizational
improvements needed, design systems to implement those changes,
and train and motivate others to use the systems.

A systems analyst investigates, analyzes, designs, develops, installs,

evaluates, and maintains a company’s information systems. To
perform those tasks, a systems analyst constantly interacts with
users and managers within and outside the company. On large
projects, the analyst works as a member of an IT department team;
on smaller assignments, he or she might work alone. Most
companies assign systems analysts to the IT department, but
analysts also can report to a specific user area such as marketing,
sales, or accounting. As a member of a functional team, an analyst
is better able to understand the needs of that group and how
information systems support the department’s mission. Smaller

17
companies often use consultants to perform systems analysis work
on an as-needed basis.

1.4.1 Systems Analyst Skills

New information systems introduce change to the organization and

its people. Leading a successful organizational change effort is one
of the most difficult jobs that someone can do. Understanding what
to change, knowing how to change it, and convincing others of the
need for change require a wide range of skills. These skills can be
broken down into six major categories: technical, business,
analytical, interpersonal, management, and ethical.

Analysts must have the technical skills to understand the

organization’s existing technical environment, the new system’s
technology foundation, and the way in which both can be fit into an
integrated technical solution. Business skills are required to
understand how IT can be applied to business situations and to
ensure that the IT delivers real business value. Analysts are
continuous problem solvers at both the project and the
organizational level, and they put their analytical skills to the test
regularly.

Often, analysts need to communicate effectively, one-on-one with

users and business managers (who often have little experience with
technology) and with programmers (who often have more technical
expertise than the analyst does). They must be able to give
presentations to large and small groups and to write reports. Not
only do they need to have strong interpersonal abilities, but they
also need to manage people with whom they work, and they must
manage the pressure and risks associated with unclear situations.

18
1.4.2 Systems Analyst Roles

As organizations and technology have become more complex, most

large organizations now build project teams that incorporate several
analysts with different, but complementary, roles. In smaller
organizations, one person may play several of these roles. Here we
briefly describe these roles and how they contribute to a systems
development project.

The systems analyst role focuses on the IS issues surrounding the

system. This person develops ideas and suggestions for ways that IT
can support and improve business processes, helps design new
business processes supported by IT, designs the new information
system, and ensures that all IS standards are maintained. The
systems analyst will have significant training and experience in
analysis and design and in programming.

The business analyst role focuses on the business issues

surrounding the system. This person helps to identify the business
value that the system will create, develops ideas for improving the
business processes, and helps design new business processes and
policies. The business analyst will have business training and
experience, plus knowledge of analysis and design.

The requirements analyst role focuses on eliciting the requirements

from the stakeholders associated with the new system. As more
organizations recognize the critical role that complete and accurate
requirements play in the ultimate success of the system, this
specialty has gradually evolved. Requirements’ analysts understand
the business well, are excellent communicators, and are highly
skilled in an array of requirements elicitation techniques.

19
The infrastructure analyst role focuses on technical issues
surrounding the ways the system will interact with the
organization’s technical infrastructure (hardware, software,
networks, and databases). This person ensures that the new
information system conforms to organizational standards and helps
to identify infrastructure changes that will be needed to support the
system. The infrastructure analyst will have significant training and
experience in networking, database administration, and various
hardware and software products.

The change management analyst role focuses on the people and

management issues surrounding the system installation. This person
ensures that adequate documentation and support are available to
users, provides user training on the new system, and develops
strategies to overcome resistance to change. The change
management analyst will have significant training and experience in
organizational behavior and specific expertise in change
management.

The project manager role ensures that the project is completed on

time and within budget and that the system delivers the expected
value to the organization. The project manager is often a seasoned
systems analyst who, through training and experience, has acquired
specialized project management knowledge and skills.

1.4.3 System Analyst Responsibilities

The systems analyst’s job overlaps business and technical issues.

Analysts help translate business requirements into IT projects.
When assigned to a systems development team, an analyst might
help document business profiles, review business processes, select

20
hardware and software packages, design information systems, train
users, and plan e-commerce Web sites.

A systems analyst plans projects, develops schedules, and estimates

costs. To keep managers and users informed, the analyst conducts
meetings, delivers presentations, and writes memos, reports, and
documentation.

1.5 Developing Information Systems and the Systems

Development Life Cycle

Organizations use a standard set of steps, called a systems

development methodology, to develop and support their
information systems. Like many processes, the development of
information systems often follows a life cycle. For example, a
commercial product, such as a Nike sneaker or a Honda car, follows
a life cycle: It is created, tested, and introduced to the market. Its
sales increase, peak, and decline. Finally, the product is removed
from the market and is replaced by something else.

The Systems Development Life Cycle (SDLC), as shown in

Figure 1.2, is a common methodology for systems development in
many organizations. It marks the phases or steps of information
systems development: Someone has an idea for an information
system and what it should do. The organization that will use the
system decides to devote the necessary resources to acquiring it.

A careful study is done of how the organization currently handles

the work the system will support. Professionals develop a strategy
for designing the new system, which is then either built or
purchased. Once complete, the system is installed in the

21
organization, and after proper training, the users begin to
incorporate the new system into their daily work. Every
organization uses a slightly different life-cycle model to model
these steps, with anywhere from three to almost twenty identifiable
phases. SDLC includes four main steps: (1) planning and selection,
(2) analysis, (3) design, and (4) implementation and operation (see
Figure 1.2).

Systems
Planning and
Selecllon

S DLC
Systems Systems
Implementation
Analysis
and Operabon

Systems
Design

Figure 1.2 SDLC Phases

Although any life cycle appears at first glance to be a sequentially

ordered set of phases, it actually is not. The specific steps and their
sequence are meant to be adapted as required for a project. For
example, in any given SDLC phase, the project can return to an
earlier phase, if necessary. Similarly, if a commercial product does
not perform well just after its introduction, it may be temporarily
removed from the market and improved before being reintroduced.
In the systems development life cycle, it is also possible to
complete some activities in one phase in parallel with some
activities of another phase. Sometimes the life cycle is iterative; that
is, phases are repeated as required until an acceptable system is

22
found. Some systems analysts consider the life cycle to be a spiral,
in which we constantly cycle through the phases at different levels
of detail, as illustrated in Figure 1.2. The circular nature of the life-
cycle diagram in Figure 1.2 illustrates how the end of the useful life
of one system leads to the beginning of another project that will
replace the existing system altogether.

Every medium-to-large corporation, such as Wal-Mart, and every

custom software producer, such as SAP, will have its own specific,
detailed life cycle or systems development methodology in place.
Even if a particular methodology does not look like a cycle, many
of the SDLC steps are performed, and SDLC techniques and tools
are used. This book follows a generic SDLC model, as illustrated in
Figure 1.2 we use this SDLC as an example of methodology and a
way to think about systems analysis and design. You can apply this
methodology to almost any life cycle.

Each phase has specific outcomes and deliverables that feed

important information to other phases. At the end of each phase
(and sometimes within phases for intermediate steps), a systems
development project reaches a milestone. Then, as deliverables are
produced, they are often reviewed by parties outside the project
team, including managers and executives.

Phase 1: Systems Planning and Selection

The first phase in the SDLC, systems planning and selection, has
two primary activities. First, someone identifies the need for a new
or enhanced system. Information needs of the organization are
examined, and projects to meet these needs are identified. The
organization’s information system needs may result from:

23
− Requests to deal with problems in current procedures
− The desire to perform additional tasks
− The realization that information technology could be used to
capitalize on an existing opportunity

The systems analyst prioritizes and translates the needs into a

written plan for the information systems (IS) department, including
a schedule for developing new major systems. Requests for new
systems spring from users who need new or enhanced systems.
During the systems planning and selection phase, an organization
determines whether resources should be devoted to the development
or enhancement of each information system under consideration. A
feasibility study is conducted before the second phase of the SDLC
to determine the economic and organizational impact of the system.

Phase 2: Systems Analysis

The second phase of the systems development life cycle is systems

analysis. During this phase, the analyst thoroughly studies the
organization’s current procedures and the information systems used
to perform tasks such as general ledger, shipping, order entry,
machine scheduling, and payroll. Analysis has several sub-phases.
The first sub-phase involves determining the requirements of the
system. In this sub-phase, you and other analysts work with users to
determine what the users want from a proposed system. This sub-
phase involves a careful study of any current systems, manual and
computerized, that might be replaced or enhanced as part of this
project. Next, you study the requirements and structure them
according to their interrelationships, eliminating any redundancies.
As part of structuring, you generate alternative initial designs to

24
match the requirements. Then you compare these alternatives to
determine which best meets the requirements within the cost, labor,
and technical levels the organization is willing to commit to the
development process. The output of the analysis phase is a
description of the alternative solution recommended by the analysis
team.

Phase 3: Systems Design

The third phase of the SDLC is called systems design. During

systems design, analysts convert the description of the
recommended alternative solution into logical and then physical
system specifications. You must design all aspects of the system
from input and output screens to reports, databases, and computer
processes. Logical design is not tied to any specific hardware and
systems software platform. Theoretically, the system you design
could be implemented on any hardware and systems software.
Logical design concentrates on the business aspects of the system;
that is, how the system will impact the functional units within the
organization. In information systems design, you turn the logical
design into physical, or technical, specifications. For example, you
must convert diagrams that map the origin, flow, and processing of
data in a system into a structured systems design that can then be
broken down into smaller and smaller units for conversion to
instructions written in a programming language. You design the
various parts of the system to perform the physical operations
necessary to facilitate data capture, processing, and information
output. During physical design, the analyst team decides which
programming languages the computer instructions will be written

25
in, which database systems and file structures will be used for the
data, and which hardware platform, operating system, and network
environment the system will run under. These decisions finalize the
hardware and software plans initiated at the end of the analysis
phase.

Phase 4: Systems Implementation and Operation

The final phase of the SDLC is a two-step process: systems

implementation and operation. During systems implementation
and operation, you turn system specifications into a working system
that is tested and then put into use. Implementation includes coding,
testing, and installation. During coding, programmers write the
programs that make up the system. During testing, programmers
and analysts test individual programs and the entire system in order
to find and correct errors. During installation, the new system
becomes a part of the daily activities of the organization.

The SDLC is a highly linked set of phases whose products feed the
activities in subsequent phases. Table 1.1 summarizes the outputs or
products of each phase based on the preceding descriptions.

1.6 Planning and control for system success

What can the analyst do to ensure the success of a system? First, a

plan must be devised, detailing the procedure, some methodology,
activities, resources, costs, and timetable for completing the system.
Second, in larger projects, a project team must be formed of
analysts, programmers, a system consultant, and user
representatives. Shared knowledge, interaction, and the
coordination realized through team effort can be extremely effective

26
in contrast with individual analysts doing the same work. Finally,
the project should be divided into manageable modules to reflect
the phases of system development – analysis, design, and
implementation.

rPhase Products. Outputs. or Deliverables

Syslems planning and selection Praities IOI systems and projects
Alchiledure IOI dala. networks. hardware, and IS management
Delailed WOik plan IOI selected project
Specification d sy,;1em scope
System justilication 01 business case
Syslems analysis Descriplion d. curreot sy,;lem
General recommeodation an how la lix, enhance, or replace current sy,;lem
Explanation d allemotive systems and just~icalion IOI choseo alternative
Acquisition plan IOI new technolcgy
Syslems des;g, Delailed specilk:otioos d. all system elemeots
Syslems implemenlation and Code
operation Documeolation
Training procedures and suppoit COfXlbilities
New 11e1sions 01 releases d. salt-More With associated updates la documeolatioo,
kainlng, and suppoit

Table 1.1 Products of the SDLC Phases

Most of this work falls under project management and control. The
main idea behind the system development life cycle is to formalize
a means structured at three major levels for effective control of the
project. At the lowest level, work assignments are broken down into
small manageable tasks.

The second level at which work units are structured involves

activities that have larger scope and are designed to produce
substantial results. An activity is a group of logically related tasks
that serve one phase of the system development life cycle. A phase,
a third level of control, is a set of activities that bring the project to
a critical milestone.

27
1.7 Alternative Approaches to Development

Prototyping, computer-aided software engineering (CASE) tools,

joint application design (JAD), rapid application development
(RAD), participatory design (PD), and the use of Agile
Methodologies represent different approaches that streamline and
improve the systems analysis and design process from different
perspectives.

1.7.1 Prototyping

Designing and building a scaled-down but working version of a

desired system is known as prototyping. A prototype can be
developed with a CASE tool, a software product that automates
steps in the systems development life cycle. CASE tools make
prototyping easier and more creative by supporting the design of
screens and reports and other parts of a system interface. CASE
tools also support many of the diagramming techniques you will
learn, such as data-flow diagrams and entity-relationship diagrams.

Figure 1.3 illustrates prototyping. The analyst works with users to

determine the initial or basic requirements for the system. The
analyst then quickly builds a prototype. When the prototype is
completed, the users work with it and tell the analyst what they like
and do not like about it. The analyst uses this feedback to improve
the prototype and takes the new version back to the users. This
iterative process continues until the users are relatively satisfied
with what they have seen. The key advantages of the prototyping
technique are: (1) it involves the user in analysis and design, and (2)
it captures requirements in concrete, rather than verbal or abstract,

28
form. In addition to being used as a stand-alone, prototyping may
also be used to augment the SDLC.

Initial
Identify Requirements Develop
Problem Prototype

Convert to
Operational
System

If Prototype
Accepted

Problems
Implement and Revise and
Use Prototype ◄-------"""" Enhance Prototype
Next Ve rsion

Figure 1.3: The Prototyping Method

1.7.2 Computer-Aided Software Engineering (CASE) Tools

Computer-aided software engineering (CASE) refers to

automated software tools used by systems analysts to develop
information systems. These tools can be used to automate or
support activities throughout the systems development process with
the objective of increasing productivity and improving the overall
quality of systems. CASE helps provide an engineering-type
discipline to software development and to the automation of the
entire software life-cycle process, sometimes with a single family of
integrated software tools. In general, CASE assists systems builders
in managing the complexities of information system projects and
helps ensure that high-quality systems are constructed on time and
within budget.

29
1.7.3 Joint Application Design

In the late 1970s, systems development personnel at IBM developed

a new process for collecting information system requirements and
reviewing system designs. The process is called joint application
design (JAD). The idea behind JAD is to structure the requirements
determination phase of analysis and the reviews that occur as part of
the design. Users, managers, and systems developers are brought
together for a series of intensive structured meetings run by a JAD
session leader. By gathering the people directly affected by an IS in
one room at the same time to work together to agree on system
requirements and design details, time and organizational resources
are better managed. Group members are more likely to develop a
shared understanding of what the IS is supposed to do. JAD has
become common in certain industries, such as insurance, and in
specific companies, such as CIGNA.

1.7.4 Rapid Application Development

Prototyping, CASE, and JAD are key tools that support Rapid
Application Development (RAD). The fundamental principle of
any RAD methodology is to delay producing detailed system design
documents until after user requirements are clear. The prototype
serves as the working description of needs. RAD involves gaining
user acceptance of the interface and developing key system
capabilities as quickly as possible. RAD is widely used by
consulting firms. It is also used as an in-house methodology by
firms such as the Boeing Company. RAD sacrifices computer
efficiency for gains in human efficiency in rapidly building and
rebuilding working systems. On the other hand, RAD

30
methodologies can overlook important systems development
principles, which may result in problems with systems developed
this way. As Figure 1.4 shows, the same phases followed in the
traditional SDLC are also followed in RAD, but the phases are
combined to produce a more streamlined development technique.
Planning and design phases in RAD are shortened by focusing work
on system functional and user interface requirements at the expense
of detailed business analysis and concern for system performance
issues.

SDLC

1111
Planning
I
11111111 ..
Design
I
11111111 ..
Development
I
Cutover
1111

Figure 1.4: RAD SDLC Compared to Standard SDLC

Also, usually RAD looks at the system being developed in isolation

from other systems, thus eliminating the time-consuming activities
of coordinating with existing standards and systems during design
and development. The emphasis in RAD is generally less on the
sequence and structure of processes in the life cycle and more on
doing different tasks in parallel with each other and on using
prototyping extensively.

31
1.7.5 Agile Methodologies

As you might imagine, many other approaches to systems analysis

and design have been developed over the years. These approaches
include Extreme Programming, the Crystal family of
methodologies, Adaptive Software Development, Scrum, and
Feature Driven Development. In February 2001, many of the
proponents of these alternative approaches met in Utah in the
United States and reached a consensus on many of the underlying
principles their various approaches contained. This consensus
turned into a document they called “The Agile Manifesto”. These
Agile Methodologies share three key principles:

(1) A focus on adaptive rather than predictive methodologies, (2) A

focus on people rather than roles, and (3) A self-adaptive process.
Adopting an adaptive rather than predictive methodology refers to
the observation that engineering-based methodologies work best
when the process and product are predictive.

32
 Chapter 2
Project Selection and Management

Learning Objectives

− Explain how projects are selected in some organizations.

− Describe the steps involved when identifying and

selecting projects and initiating and planning projects.

− Become familiar with project estimation.

− Be able to create a project work plan.

− Describe project staffing issues and concerns.

− Explain how to manage risk on the project.

− Explain the need for and the contents of a project scope

statement and baseline project plan.

− List and describe various methods for Preliminary

Investigation

− List and describe various methods for assessing project

feasibility.

− Describe the differences between tangible and intangible

benefits and costs, and the differences between one-time

and recurring costs.

33
Chapter 2: Projects Selection and Management
The system analyst gives a system development project meaning &
direction. A candidate system is approached after the analyst has
through understanding of user needs & problems. A viable solution
is worked out and then communicates the same. Candidate systems
often cut across the boundaries of users in the organization. For
example, a billing system may involve users in the sales order
department, the credit department, the warehouse, and the
accounting department. To make sure that all users’ needs are met,
a project from that represents each user works with the analysis to
carry out a system development project. The system development
life cycle method is classically thought of as the set of activities that
analysts, designers and users carry out to develop and implement an
information system.

Determining the size, scope, and resource requirements for a project

are just a few of the many skills that a project manager must
possess. A project manager is often referred to as a juggler keeping
aloft many balls, which reflect the various aspects of a project’s
development, as depicted in Figure 2.1.

2.1 Reasons for Systems Projects

Systems projects are initiated by many different sources for many

reasons. Some of the projects suggested will survive various stages
of evaluation to be worked on by you (or you and your team);
others will not and should not get that far. Business people suggest
systems projects for two broad reasons: (1) because they experience
problems that lend themselves to systems solutions, and (2) because
they recognize opportunities for improvement through upgrading,

34
altering, or installing new systems when they occur. In this section,
we discuss the main reasons for systems projects, which are
described below

~-
~ f~::. . .
Sysums
Development
urecycte

MethodolOQ.es
anaToots

conuac1ors
Ye-rl(lorS
30(1
{
~
Ma.~~:9
/
1(
Figure 2.1: Project Manager Activities

− Improved service: Systems requests are often aimed at

improving service to customers, suppliers, or users within the
company. A bank or a mutual fund company may want to allow
their account holders to check account balances from the
company Web sites, or a university may want to create an online
registration system.
− Better performance: The current system might not meet
performance requirements. For example, the systems might be
old and hence slow to respond data inquiries, have limited
flexibility, or be unable to support company growth. System

35
 performance can be increased by combining processes,
streamlining a process through the elimination of unnecessary or
duplicated steps, integration of systems and sub-systems, and so
on.
− More information: The system might produce information that
is insufficient, incomplete, or unable to provide company’s
changing information need. For example, a system that tracks
customer orders might not be capable of analyzing marketing
needs. The business might need to keep track of some key
information that cannot be obtained from the current system.
− Stronger controls: A system may not have all controls on
accurate data entry, leading to inaccurate data entry and storage,
loss of income, and even system failure. A system may not have
all security required by the company for different users.
− Reduced cost: The current system could be expensive to operate
and maintain as a result of technical problems, design
weaknesses, or the changing demands of the business.

2.2 Sources of Systems Projects

Initiation or request of systems projects may come from various

areas, both internal and external to an organization. Following are
some of the sources.

− User requests: Users of a company work usually with the

systems and interact with customers on a daily basis. They are
the most likely source for improved or new systems request.
Users may experience that the current system is not flexible
and it is difficult to learn. They might experience that the

36
 system does not produce information required by the company
business.
− Top-management directives: Directives from top managers
could generate a systems request. These can originate due to
new company objectives, a need for improved reports to make
strategic decisions.
− Existing systems: Errors or problems with existing systems
can trigger requests for systems projects.
− Information systems department: Systems project request
can come from the information systems department as
suggestions. This is possible if IS staff members such as CIO
(chief information officer) and managers are involved with
company operations and user needs.
− External factors: There are many external factors can cause
changes to an existing system or creation of a new system.
Examples are: Changes in government tax regulations and
reporting requirements.

2.3 Projects’ Initiation

Project initiation begins when someone in an organization identifies

that there is a need to improve an existing system or a new system
is needed to improve business operations. Most ideas come from
outside the IT department such as marketing, accounting, and etc.,
as a form of systems request.

As its name implies, two major activities occur during project

initiation. Project initiation focuses on activities that will help
organize a team to conduct project planning. During initiation, one

37
or more analysts are assigned to work with a customer to establish
work standards and communication procedures.

Many activities performed during initiation and planning could also

be completed during the next phase of the SDLC—systems
analysis. Proper and insightful project initiation and planning,
including determining project scope and identifying project
activities, can reduce the time needed to complete later project
phases, including systems analysis.

The objective of project initiation and planning is to transform a

vague system request document into a tangible project description.
Getting all parties to agree on the direction of a project may be
difficult for cross-department projects when different parties have
different business objectives. Projects at large, complex
organizations require systems analysts to take more time to analyze
both the current and proposed systems. The activities that are
performed during project initiation are as follows:

− Establishing the Project Initiation Team

− Establishing a Relationship with the Customer

− Establishing the Project Initiation Plan

− Establishing Management Procedures

− Establishing the Project Management Environment and Project

Workbook

2.3.1 Establishing the Project Initiation Team

This activity involves organizing an initial core of project team

members to assist in accomplishing the project initiation activities.

38
For example, during the Purchasing Fulfillment System project at
PVF, Chris Martin was assigned to support the purchasing
department. It is a PVF policy that all initiation teams consist of at
least one user representative, in this case Juanita Lopez, and one
member of the IS development group. Therefore, the project
initiation team consisted of Chris and Juanita; Chris was the project
manager.

2.3.2 Establishing a Relationship with the Customer

A thorough understanding of your customer builds stronger

partnerships and higher levels of trust. At PVF, management has
tried to foster strong working relationships between business units
(such as purchasing) and the IS development group by assigning a
specific individual to work as a liaison between both groups.
Because Chris had been assigned to the purchasing unit for some
time, he was already aware of some of the problems with the
existing purchasing systems. PVF’s policy of assigning specific
individuals to each business unit helped to ensure that both Chris
and Juanita were comfortable working together prior to the
initiation of the project. Many organizations use a similar
mechanism for establishing relationships with customers.

2.3.3 Establishing the Project Initiation Plan

This step defines the activities required to organize the initiation

team while it is working to define the scope of the project. Chris’s
role was to help Juanita translate her business requirements into a
written request for an improved information system. This task
required the collection, analysis, organization, and transformation
of a lot of information. Because Chris and Juanita were already

39
familiar with each other and their roles within a development
project, they next needed to define when and how they would
communicate, define deliverables and project steps, and set
deadlines. Their initiation plan included agendas for several
meetings. These steps eventually led to the creation of their System
Service Request (SSR) form.

2.3.4 Establishing Management Procedures

Successful projects require the development of effective

management procedures. Within PVF, many of these management
procedures had been established as standard operating procedures
by the Systems Priority Board and the IS development group. For
example, all project development work is charged to the functional
unit requesting the work. In other organizations, each project may
have unique procedures tailored to its needs. Yet, in general, when
establishing procedures, you are concerned with developing team
communication and reporting procedures, job assignments and
roles, project change procedures, and determining how project
funding and billing will be handled. It was fortunate for Chris and
Juanita that most of these procedures were already established at
PVF, allowing them to move quickly on to other project activities.

2.3.5 Establishing the Project Management Environment and

Project Workbook

The focus of this activity is to collect and organize the tools that
you will use while managing the project and to construct the
project workbook. For example, most diagrams, charts, and
system descriptions provide much of the project workbook contents.

40
Thus, the project workbook serves as a repository for all project
correspondence, inputs, outputs, deliverables, procedures, and
standards established by the project team. The project workbook
can be stored as an online electronic document, a Web site, or in a
large three-ring binder. The project workbook is used by all team
members and is useful for project audits, orientation of new team
members, communication with management and customers,
identification of future projects, and performance of post-project
reviews. The establishment and diligent recording of all project
information in the workbook are two of the most important
activities you will perform as project manager.

2.4 Problem Definition

Whether using the classical SDLC or an object-oriented approach,

the analyst first defines the problems and objectives of the system.
These form the foundation of determining what needs to be
accomplished by the system. Methods like Six Sigma) start with a
problem definition.

A problem definition usually contains some sort of problem

statement, summarized in a paragraph or two. This is followed by a
series of issues, or major, independent pieces of the problem. The
issues are followed by a series of objectives, or goals that match the
issues point by point. Issues are the current situation; objectives are
the desired situation. The objectives may be very specific or worded
using a general statement. Here are some examples of business
questions relating to business objectives:

− What are the purposes of the business?

41
 − Is the business profit or nonprofit?
− Does the company plan to grow or expand?
− What is the business’s attitude (culture) about technology?
− What is the business’s budget for IT?
− Does the business’s staff have the expertise?

As the systems analyst needs to understand how a business works,

then the last part of the problem definition contains requirements,
the things that must be accomplished, along with the possible
solutions and the constraints that limit the development of the
system. The requirements section may include security, usability,
government requirements, and so on. Constraints often include the
word not, indicating a limitation, and may contain budget
restrictions or time limitations. The problem definition is produced
after completing interviews, observations, and document analysis
with the users. The result of gathering this information is a wealth
of facts and important opinions in need of summary. The first step
in producing the problem definition is to find a number of points
that may be included in one issue.

2.5 Project Planning

The major outcomes and deliverables from project planning are the
baseline project plan and the project scope statement. The Baseline
Project Plan (BPP) contains all information collected and analyzed
during the project initiation and planning activity. The plan contains
the best estimate of the project’ scope, benefits, costs, risks, and
resource requirements given the current understanding of the
project. The BPP specifies detailed project activities for the next life
cycle phase—systems analysis—and provides less detail for

42
subsequent project phases (because these depend on the results of
the analysis phase). The activities that are performed during project
planning are as follows:

− Describing the project scope, alternatives, and feasibility

− Dividing the project into manageable tasks
− Estimating resources and creating a resource plan
− Developing a preliminary schedule
− Developing a communication plan
− Determining project standards and procedures
− Identifying and assessing risk
− Creating a preliminary budget
− Developing a project scope statement
− Setting a baseline project plan

2.5.1 Preliminary Investigation

Preliminary Investigation basically refers to the collection of

information that guides the management of an organization to
evaluate the merits and demerits of the project request and make an
informed judgment about the feasibility of the proposed system.
The data that the analysts collect during preliminary investigations
are gathered through two primary methods: reviewing documents
and interviewing selected company personnel.

− Reviewing organization documents

The analysts conducting the investigation first learn about the

organization involved in, or affected by, the project. For example,
to review an inventory systems proposal means knowing first how
the inventory department operates and who the managers and

43
supervisors are Analysts can usually learn these details by
examining organization charts and studying written operating
procedures. The procedures describe how the inventory process
should operate and identify the most important steps involved in
receiving, managing, and dispensing stock.

− Conducting interviews

Written documents tell the analysts how the systems should operate,
but they may not include enough detail to allow a decision to be
made about the merits of a systems proposal, nor do they present
user views about current operations. To learn these details, analysts
use interviews.

Interviews allow analysts to learn more about the nature of the

project request and the reason for submitting it. To accomplish the
purpose of the interviews, analysts must be sure to emphasize the
request and the problem it addresses. In other words, interviews
should provide details that further explain the project and show
whether assistance is merited economically, operationally, and
technically. Working out a solution to the situation comes later,
during the detailed investigation. Usually, preliminary investigation
interviews involve only management and supervisory personnel.

2.5.2 Assessing Project Feasibility

Depending on the results of the initial investigation, the survey is

expanded to a more detailed feasibility study. Once the need for the
system and its business requirements have been defined, the
approval committee may authorize the systems analyst to prepare a
more detailed business case to better understand the proposed

44
information system project. Feasibility analysis guides the
organization in determining whether to proceed with the project.

A feasibility study is a test of a system proposal according to its

workability. Impact on the organization, ability to meet user needs,
and effective use of resources. It focuses on three major questions:

1. What are the user’s demonstrable needs and how does a

candidate system meet them?

2. What resources are available for given candidate systems? Is the

problem worth solving?

3. What is the likely impact of the candidate system on the

organization? How well does it fit within the organization’s
master MIS plan?

The result of the feasibility study is a formal proposal. This is

simply a report- a formal document detailing the nature and scope
of the proposed solution. The proposal summarizes what is known
and what is going to be done. It consists of the following:

1. Statement of the problem – a carefully worded statement of the

problem that led to analysis.

2. Summary of findings and recommendations- a list of the major

findings and recommendations of the study. It is ideal for the
user who requires quick access to the results of the analysis of
the system under study. Conclusions are stated followed by a list
of the recommendations and a justification for them.

3. Details of findings- an outline of the methods and procedures

undertaken by the existing system followed by coverage of the

45
 objectives and procedures of the candidate system. Included are
also discussions of output reports, file structures, and costs and
benefits of the candidate system.

4. Recommendations and conclusions- specific recommendations

regarding the candidate system including personnel assignments,
costs, project schedules, and target dates.

Data for the feasibility study can be gathered through interviews.

The kind of interview required is directly related to the problem or
opportunity being suggested. The systems analyst typically
interviews those requesting help and those directly concerned with
the decision-making process, typically management. Although it is
important to address the correct problem, the systems analyst
should not spend too much time doing feasibility studies, because
many projects will be requested and only a few can or should be
executed. The feasibility study must be highly time compressed,
encompassing several activities in a short span of time.

After an analyst determines reasonable objectives for a project, the

analyst needs to determine if it is possible for the organization and
its members to see the project through to completion. Generally, the
process of feasibility assessment is effective in screening out
projects that are inconsistent with the business’s objectives,
technically impossible, or economically without merit. In order for
an analyst to recommend further development, a project must show
that it is feasible in all of the following ways as shown in table 2.1.

46
 The Three Key Elements of Feasibility
Operational Feasibility
▪ Whether the system will operate when installed
▪ Whether the system will be used
Technical Feasibility
▪ Add on to present system
▪ Technology available to meet users’ needs
Financial and Economic Feasibility
▪ Systems analysts’ time
▪ Cost of systems study
▪ Cost of employees’ time for study
▪ Estimated cost of hardware
▪ Cost of packaged software or software development

Table 2.1: Key Elements of Feasibility

2.5.2.1 Operational feasibility

Suppose for a moment that technical and economic resources are

both judged adequate. The systems analyst must still consider the
operational feasibility of the requested project. Operational
feasibility is dependent on the human resources available for the
project and involves projecting whether the system will operate and
be used once it is installed.

Operational Feasibility is the process of examining the likelihood

that the project will attain its desired objectives. The goal of this
study is to understand the degree to which the proposed system will
likely solve the business problems or take advantage of the
opportunities outlined in the system service request or project
identification study. In other words, assessing operational feasibility
requires that you gain a clear understanding of how an IS will fit
into the current day-to-day operations of the organization.

47
2.5.2.2 Technical feasibility

Technical Feasibility is to understand the development

organization’s ability to construct the proposed system. This
analysis should include an assessment of the development group’s
understanding of the possible target hardware, software, and
operating environments to be used, as well as, system size,
complexity, and the group’s experience with similar systems.

At the same time, the analyst can ask whether the organization has
the staff who are technically proficient enough to accomplish the
objectives. If not, the question becomes whether they can hire
additional programmers, testers, experts, or others who may have
different programming skills from theirs, or maybe outsource the
project completely.

Assessing technical feasibility includes evaluating the ability of

computer hardware and software to handle workloads adequately.
Figure 2.2 shows the steps the systems analyst takes in ascertaining
hardware and software needs. First, all current computer hardware
the organization owns must be inventoried to discover what is on
hand and what is usable. The systems analyst needs to work with
users to determine what hardware will be needed. Hardware
determinations can come only in conjunction with determining
human information requirements. Knowledge of the organizational
structure and how users interact with technologies in an
organizational setting can also be helpful in hardware decisions.
Only when systems analysts, users, and management have a good
grasp of what kinds of tasks must be accomplished can hardware
options be considered.

48
A) Ascertaining Hardware Needs

Begin by inventorying what computer hardware is already

available in the organization. As will become apparent, some of
the hardware options involve expanding or recycling current
hardware, so it is important to know what is on hand. If an updated
computer hardware inventory is unavailable, the systems analyst
needs to set up one quickly and carry through on it.

Figure 2.2: Steps in Choosing Hardware and Software

The three main options for acquisition of computer hardware are

buying, leasing, or renting it. There are advantages and
disadvantages that ought to be weighed for each of the decisions, as
shown in table 2.2 Some of the more influential factors to consider
in deciding which option is best for a particular installation include
initial versus long-term costs, whether the business can afford to tie
up capital in computer equipment, and whether the business desires
full control of and responsibility for the computer equipment.

49
 Advantages
− Cheaper than leasing or
− renting over the long run
− Ability to change system
Buying
− Provides tax advantages of
− accelerated depreciation
− Full control
− No capital is tied up
− No financing is required
− Leases are lower than rental
Leasing
payments
− No capital is tied up
− No financing is required
Renting − Easy to change systems
− Maintenance and insurance
are usually included
Disadvantages
− Initial cost is high
− Risk of obsolescence
− Risk of being stuck if choice
was wrong
− Full responsibility
− Company doesn’t own the
− system when lease expires
− Usually a heavy penalty for
− terminating the lease
− Leases are more expensive
− than buying
− Company doesn’t own the
computer
− Cost is very high because
vendor assumes the risk (most
expensive option)

Table 2.2: Advantages and Disadvantages for Acquisition of Hardware Options

B) Ascertaining Software Needs

Analysts and organizations are increasingly faced with a make, buy,

or outsource decision when assessing software for information
systems projects, particularly when contemplating upgrades to
existing or legacy systems. You have seen the decisions that
analysts make when deciding about renting, buying, or leasing
hardware. Table 2.3 summarizes the advantages and disadvantages
of each of these options.

− Familiarity with the application. When analysts are unfamiliar

with the business application area, they have a greater chance of
misunderstanding the users or missing opportunities for
improvement. The risks increase dramatically when the users
themselves are less familiar with an application. In general, the
development of new systems is riskier than extensions to an

50
 existing system, because existing systems tend to be better
understood.

Advantages Disadvantages
− Specific response to − May be significantly higher
specialized business initial cost compared to
needs COTS software or ASP
Creating
− Innovation may give firm − Necessity of hiring or
Custom
a competitive advantage working
Software
− In-house staff available − with a development team
to maintain software − Ongoing maintenance
− Pride of ownership
− Refined in the − Programming focused; not
commercial world business focused
− Increased reliability − Must live with the existing
− Increased functionality features
Purchasing
− Often lower initial cost − Limited customization
COTS
Packages − Already in use by other − Uncertain financial future
firms of vendor
− Help and training comes − Less ownership and
with software commitment

− Organizations that do not − Loss of control of data,

specialize in information systems, IT employees, and
systems can focus on schedules
what they do best (their − Concern over the financial
strategic mission) viability and long-run
Using an − There is no need to hire, stability of the ASP
ASP train, or retain a large IT − Security, confidentiality,
staff and privacy concerns
− There is no expenditure − Loss of potential strategic
of employee time on corporate advantage
nonessential IT tasks regarding innovativeness of
applications

Table 2.3: Advantages and Disadvantages of Creating Custom Software,

Purchasing COTS packages, and Outsourcing to an ASP

− Familiarity with the technology is another important source of

technical risk. When a system will use technology that has not
been used before within the organization, there is a greater
chance that problems and delays will occur because of the need
to learn how to use the technology. Risk increases dramatically

51
 when the technology itself is new (e.g., web development using
Ajax).

− Project size is an important consideration, whether measured as

the number of people on the development team, the length of
time it will take to complete the project, or the number of
distinct features in the system. Larger projects present more
risk, because they are more complicated to manage and because
there is a greater chance that some important system
requirements will be overlooked or misunderstood. The extent
to which the project is highly integrated with other systems
(which is typical of large systems) can cause problems, because
complexity is increased when many systems must work
together.
− Finally, project teams need to consider the compatibility of the
new system with the technology that already exists in the
organization. Systems rarely are built in a vacuum—they are
built in organizations that have numerous systems already in
place. New technology and applications need to be able to
integrate with the existing environment for many reasons. They
may rely on data from existing systems, they may produce data
that feed other applications, and they may have to use the
company’s existing communications infrastructure.

2.5.2.3 Financial and Economic Feasibility

Economic feasibility is the second part of resource determination. A

system that can be developed technically and that will be used must
still be a good investment for the organization. Financial benefits
must equal or exceed the costs. A study of economic feasibility is

52
required for the baseline project plan. The purpose for assessing
economic feasibility is to identify the financial benefits and costs
associated with the development project. Economic feasibility is
often referred to as cost-benefit analysis.

The basic resources to consider are your time and that of the
systems analysis team, the cost of doing a full systems study
(including the time of employees you will be working with), the
cost of the business employee time, the estimated cost of hardware,
and the estimated cost of software or software development.

2.5.2.4 Assessing other feasibility concerns

− Behavioral Feasibility: People are inherently resistant to

change, and computers have been known to facilitate
change. An estimate should be made of how strong a
reaction the user staff is likely to have toward the
development of a computerized system. It is common
knowledge that computer installations have something to do
with turnover, transfers, retraining and changes in employee
job status. Therefore, it is understandable that the
introduction of a candidate system requires special effort to
educate, sell and train the staff on new ways of conducting
business.
− Organizational Feasibility: The final technique used for
feasibility analysis is to assess the organizational feasibility
of the system: how well the system ultimately will be
accepted by its users and incorporated into the ongoing
operations of the organization. There are many
organizational factors that can have an impact on the

53
 project, and seasoned developers know that organizational
feasibility can be the most difficult feasibility dimension to
assess. In essence, an organizational feasibility analysis
attempts to answer the question “If we build it, will they
come?”
− Schedule Feasibility: Considers the likelihood that all
potential time frames and completion date schedules can be
met and that meeting these dates will be sufficient for
dealing with the needs of the organization. For example, a
system may have to be operational by a government-
imposed deadline by a particular point in the business cycle
(such as the beginning of the season when new products are
introduced), or at least by the time a competitor is expected
to introduce a similar system.
− Legal and Contractual Feasibility: Assessing legal and
contractual feasibility requires that you gain an
understanding of any potential legal and contractual
ramifications due to the construction of the system.
Considerations might include copyright or nondisclosure
infringements, labor laws, foreign trade regulations (e.g.,
some countries limit access to employee data by foreign
corporations), and financial reporting standards as well as
current or pending contractual obligations.
− Political Feasibility: Assessing political feasibility
involves understanding how key stakeholders within the
organization view the proposed system. Because an
information system may affect the distribution of
information within the organization, and thus the

54
 distribution of power, the construction of an IS can have
political ramifications.
2.5.3 Determining Project Benefits

An information system can provide many benefits to an

organization. For example, a new or renovated IS can automate
monotonous jobs, reduce errors, provide innovative services to
customers and suppliers, and improve organizational efficiency,
speed, flexibility, and morale. These benefits are both tangible and
intangible.

A tangible benefit is an item that can be measured in dollars and

with certainty. Examples of tangible benefits include reduced
personnel expenses, lower transaction costs, or higher profit
margins. It is important to note that not all tangible benefits can be
easily quantified. For example, a tangible benefit that allows a
company to perform a task 50 percent of the time may be difficult
to quantify in terms of hard dollar savings. Most tangible benefits
fit in one or more of the following categories:
− Cost reduction and avoidance
− Error reduction
− Increased flexibility
− Increased speed of activity
− Improvement of management planning and control
− Opening new markets and increasing sales opportunities

Intangible benefits refer to items that cannot be easily measured in

dollars or with certainty. Intangible benefits may have direct
organizational benefits, such as the improvement of employee
morale, or they may have broader societal implications, such as the

55
reduction of waste creation or resource consumption. Potential
tangible benefits may have to be considered intangible during
project initiation and planning because you may not be able to
quantify them in dollars or with certainty at this stage in the life
cycle. During later stages, such intangibles can become tangible
benefits as you better understand the ramifications of the system
you are designing. Intangible benefits include:
− Competitive necessity
− Increased organizational flexibility
− Increased employee morale
− Promotion of organizational learning and understanding
− More timely information

2.5.5 Comparing Costs and Benefits

There are many well-known techniques for comparing the costs and
benefits of the proposed system. They include break-even analysis,
payback, cash-flow analysis, and present value analysis. All these
techniques provide straightforward ways of yielding information to
decision makers about the worthiness of the proposed system.

− Break-Even Analysis: By comparing costs alone, the systems

analyst can use break-even analysis to determine the break-even
capacity of the proposed information system. The point at which
the total costs of the current system and the proposed system
intersect represents the break-even point, the point where it
becomes profitable for the business to get the new information
system.
− Cash-Flow Analysis: Cash-flow analysis examines the
direction, size, and pattern of cash flow that is associated with

56
 the proposed information system. If you are proposing the
replacement of an old information system with a new one and if
the new information system will not be generating any
additional cash for the business, only cash outlays are associated
with the project. If that is the case, the new system cannot be
justified on the basis of new revenues generated and must be
examined closely for other tangible benefits if it is to be pursued
further.
− Present Value Analysis: helps the systems analyst to present to
business decision makers the time value of the investment in the
information system as well as the cash flow. Present value is a
way to assess all the economic outlays and revenues of the
information system over its economic life, and to compare costs
today with future costs and today’s benefits with future benefits.
− Guidelines for Analysis: For general guidelines, however, it is
safe to say the following:
1. Use break-even analysis if the project needs to be justified
in terms of cost, not benefits, or if benefits do not
substantially improve with the proposed system.
2. Use payback when the improved tangible benefits form a
convincing argument for the proposed system.
3. Use cash-flow analysis when the project is expensive
relative to the size of the company or when the business
would be significantly affected by a large drain (even if
temporary) on funds.
4. Use present value analysis when the payback period is long
or when the cost of borrowing money is high. Whichever
method is chosen, it is important to remember that cost-

57
 benefit analysis should be approached systematically, in a
way that can be explained and justified to managers, who
will eventually decide whether to commit resources to the
systems project. Next, we turn to the importance of
comparing many systems alternatives.

2.5.6 Dividing the Project into Manageable Tasks

This activity is critical during the project planning process. Here,

you must divide the entire project into manageable tasks and then
logically order them to ensure a smooth evolution between tasks.
The definition of tasks and their sequence is referred to as the work
breakdown structure (WBS). Some tasks may be performed in
parallel, whereas others must follow one another sequentially. Task
sequence depends on which tasks produce deliverables needed in
other tasks, when critical resources are available, the constraints
placed on the project by the client, and the process outlined in the
SDLC. For example, suppose that you are working on a new
development project and need to collect system requirements by
interviewing users of the new system and reviewing reports they
currently use to do their job.

2.5.6.1 Constructing a Gantt chart

A work breakdown for these activities is represented in a Gantt

chart in figure 2.3. A Gantt chart is a graphical representation of a
project that shows each task as a horizontal bar whose length is
proportional to its time for completion. Different colors, shades, or
shapes can be used to highlight each kind of task. For example,
those activities on the critical path may be in red, and a summary
task could have a special bar. Note that the black horizontal bars

58
(rows) 1, 2, and 6 in Figure 2.3 represent summary tasks. Planned
versus actual times or progress for an activity can be compared by
parallel bars of different colors, shades, or shapes. Gantt charts do
not show how tasks must be ordered (precedence) but simply show
when an activity should begin and end. In Figure 2.6, the task
duration is shown in the second column, in days, and necessary
prior tasks are noted in the third column as predecessors. Most
project management software tools support a broad range of task
durations, including minutes, hours, days, weeks, and months.

Figure 2.3: Project Tasks duration Using Gantt Chart

2.5.7 Estimating Resources and Creating a Resource Plan

The goal of this activity is to estimate resource requirements for

each project activity and use this information to create a project
resource plan. The resource plan helps assemble and deploy
resources in the most effective manner. For example, you would not
want to bring additional programmers onto the project at a rate
faster than you could prepare work for them. Project managers use a
variety of tools to assist in making estimates of project size and

59
costs. The most widely used method is called COCOMO
(COnstructive COst MOdel), which uses parameters that were
derived from prior projects of differing complexity. COCOMO uses
these different parameters to predict human resource requirements
for basic, intermediate, and complex systems (see Figure 2.4).

Figure 2.4: Project Resources Estimation Using COCOMO

People are the most important and expensive part of project

resource planning. Project time estimates for task completion and
overall system quality are significantly influenced by the
assignment of people to tasks. It is important to give people tasks
that allow them to learn new skills. It is equally important to make
sure that project members are not in “over their heads” or working
on a task that is not well suited to their skills. Resource estimates
may need to be revised based upon the skills of the actual person (or
people) assigned to a particular activity.

60
2.5.8 Developing a Preliminary Schedule

During this activity, you use the information on tasks and resource
availability to assign time estimates to each activity in the work
breakdown structure. These time estimates will allow you to create
target starting and ending dates for the project. Target dates can be
revisited and modified until a schedule produced is acceptable to
the customer. Determining an acceptable schedule may require that
you find additional or different resources or that the scope of the
project be changed. The schedule may be represented as a Gantt
chart, as illustrated in Figure 2.3, or as a Network diagram, as
illustrated in Figure 2.5.

2.5.9 Developing the Work Plan

Once a project manager has a general idea of the size and

approximate schedule for the project, he or she creates a work plan,
which is a dynamic schedule that records and keeps track of all of
the tasks that need to be accomplished over the course of the
project.

Figure 2.5: Project Tasks Representation using Network Diagram

61
The project manager first must assemble important details about
each task to be completed. Figure 2.5 shows the type of task
information needed, including when it needs to be completed, the
person assigned to do the work, and any deliverables that will
result. The level of detail and the amount of information captured
by the work plan depend on the needs of the project (and the detail
usually increases as the project progresses). Usually, the work plan
is the main component of the project management software. To
create a work plan, the project manager identifies the tasks that
need to be accomplished and determines how long each one will
take. Then the tasks are organized within a work breakdown
structure.

Identify Tasks

The project manager’s job is to identify all the tasks that will be
needed to accomplish those objectives. This is a daunting task,
certainly. The methodology that was selected by the project
manager should be a valuable resource, however. The methodology
that seems most appropriate for the project provides a list of steps
and deliverables. A project manager can take the methodology,
select the steps and deliverables that apply to the current project,
and add them to the work plan.

The work breakdown structure can be organized in one of two

ways: by SDLC phase or by product. For example, if a firm decided
that it needed to develop a Web site, the firm could create a work
breakdown structure based on the SDLC phases: planning, analysis,
design, and implementation. In this case, a typical task that would
take place during planning would be feasibility analysis. This task

62
would be broken down into the different types of feasibility
analysis: technical, economic, and organizational. Each of these
would be further broken down into a series of subtasks.
Alternatively, the firm could organize the work plan along the lines
of the different products to be developed.

2.5.10 Determining Project Standards and Procedures

During this activity, you specify how various deliverables are

produced and tested by you and your project team. For example, the
team must decide on which tools to use, how the standard SDLC
might be modified, which SDLC methods will be used,
documentation styles (e.g., type fonts and margins for user
manuals), how team members will report the status of their assigned
activities, and terminology. Setting project standards and
procedures for work acceptance is a way to ensure the development
of a high-quality system. Also, it is much easier to train new team
members when clear standards are in place.

2.5.11 Selecting the Appropriate Development Methodology

As there are many methodologies. The first challenge faced by

project managers is to select which methodology to use. Choosing a
methodology is not simple, because no one methodology is always
best. (If it were, we’d simply use it everywhere!) Many
organizations have standards and policies to guide the choice of
methodology. You will find that organizations range from having
one “approved” methodology to having several methodology
options to having no formal policies at all.

63
− Clarity of User Requirements When the user requirements for
what the system should do are unclear, it is difficult to
understand them by talking about them and explaining them
with written reports. Users normally need to interact with
technology to really understand what the new system can do
and how to best apply it to their needs. System prototyping and
throwaway prototyping are usually more appropriate when user
requirements are unclear, because they provide prototypes for
users to interact with early in the SDLC.
− Familiarity with Technology When the system will use new
technology with which the analysts and programmers are not
familiar (e.g., the first Web development project with Ajax),
applying the new technology early in the methodology will
improve the chance of success. If the system is designed
without some familiarity with the base technology, risks
increase because the tools may not be capable of doing what is
needed.
− System Complexity Complex systems require careful and
detailed analysis and design. Throwaway prototyping is
particularly well suited to such detailed analysis and design, but
system prototyping is not. The waterfall methodologies can
handle complex systems, but without the ability to get the
system or prototypes into users’ hands early on, some key
issues may be overlooked.
− System Reliability System reliability is usually an important
factor in system development. After all, who wants an
unreliable system? However, reliability is just one factor
among several. For some applications, reliability is truly

64
 critical (e.g., medical equipment, missile control systems),
while for other applications it is merely important (e.g., games,
Internet video). The V-model is useful when reliability is
important, due to its emphasis on testing.
− Schedule Visibility One of the greatest challenges in systems
development is knowing whether a project is on schedule. This
is particularly true of the waterfall-based methodologies
because design and implementation occur at the end of the
project. The RAD methodologies move many of the critical
design decisions to a position earlier in the project to help
project managers recognize and address risk factors and keep
expectations in check.

2.5.12 Calculating Expected Time Durations Using PERT Chart

One of the most difficult and most error-prone activities when

constructing a project schedule is the determination of the time
duration for each task within a work breakdown structure. It is
particularly problematic to make these estimates when a high
degree of complexity and uncertainty characterize a task. PERT
(Program Evaluation Review technique) is a technique that uses
optimistic, pessimistic, and realistic time estimates to calculate the
expected time for a particular task. This technique helps you obtain
a better time estimate when you are uncertain as to how much time
a task will require to be completed.

2.5.13 Identifying and Assessing Risk

The goal of this activity is to identify sources of project risk and to

estimate the consequences of those risks. Risks might arise from the
use of new technology, prospective users’ resistance to change,

65
availability of critical resources, competitive reactions or changes in
regulatory actions due to the construction of a system, or team
member inexperience with technology or the business area. You
should continually try to identify and assess project risk. The
identification of project risks is required to develop PVF’s new
Purchasing Fulfillment System.

2.5.14 Creating a Preliminary Budget

During this phase, you need to create a preliminary budget that

outlines the planned expenses and revenues associated with your
project. The project justification will demonstrate that the benefits
are worth these costs. Figure 2.5 shows a cost-benefit analysis for a
new development project. This analysis shows net present value
calculations of the project’s benefits and costs, as well as a return
on investment and cash flow analysis.

Figure 2.5: A Financial Cost-Benefits Analysis for a Systems Development

Project

66
2.5.15 Developing a Project Scope Statement

An important activity that occurs near the end of the project

planning phase is the development of the project scope statement.
Developed primarily for the customer, this document outlines work
that will be done and clearly describes what the project will deliver.
The project scope statement is useful to make sure that you, the
customer, and other project team members have a clear
understanding of the intended project size, duration, and outcomes.

2.5.16 Setting a Baseline Project Plan

Once all of the prior project planning activities have been

completed, you will be able to develop a baseline project plan. This
baseline plan provides an estimate of the project’s tasks and
resource requirements and is used to guide the next project phase—
execution. As new information is acquired during project execution,
the baseline plan will continue to be updated.

2.6 Project Closedown

The focus of project closedown is to bring the project to an end.

Projects can conclude with a natural or unnatural termination. A
natural termination occurs when the requirements of the project
have been met—the project has been completed and is a success.
An unnatural termination occurs when the project is stopped before
completion. Several events can cause an unnatural termination of a
project. For example, it may be learned that the assumption used to
guide the project proved to be false, or that the performance of the
system or development group was somehow inadequate, or that the
requirements are no longer relevant or valid in the customer’s

67
business environment. The most likely reasons for the unnatural
termination of a project relate to running out of time or money, or
both. Regardless of the project termination outcome, several
activities must be performed: closing down the project, conducting
post-project reviews, and closing the customer contract. Within the
context of the SDLC, project closedown occurs after the
implementation phase. The system maintenance phase typically
represents an ongoing series of projects, each needing to be
individually managed. The project closedown activities can be
summarized to closing down the Project, conducting Post-project
Reviews, and closing the Customer Contract

2.7 Using Project Management Software

A wide variety of automated project management tools are available

to help you manage a development project. New versions of these
tools are continuously being developed and released by software
vendors. Most of the available tools have a common set of features
that include the ability to define and order tasks, assign resources to
tasks, and easily modify tasks and resources. Project management
tools are available to run on Windows-compatible personal
computers, the Macintosh, and larger mainframe and workstation-
based systems. For example, numerous shareware project
management programs (e.g., OpenProj or EasyProjectPlan) can be
downloaded from the World Wide Web (e.g., at
www.download.com). Because these systems are continuously
changing, you should comparison shop before choosing a particular
package.

68
2.7.1 Establishing a Project Starting Date

Defining the general project information includes obtaining the

name of the project and project manager and the starting or ending
date of the project. Starting and ending dates are used to schedule
future activities or backdate based upon their duration and
relationships to other activities.

2.7.2 Entering tasks and assigning task relationships

The next step in defining a project is to define project tasks and

their relationships. For the Purchasing Fulfillment System project,
Chris defined 11 tasks to be completed when he performed the
initial system analysis activities of the project (Task 1—Start
Analysis Phase—is a summary task that is used to group related
tasks).

69
 Chapter 3
Determining System Requirements

Learning Objectives

− Describe the content and purpose of the requirements

definition statement.
− Classify requirements correctly as business, user, functional,
or nonfunctional requirements.
− Employ the requirement elicitation techniques of interviews,
JAD sessions, questionnaires, document analysis, and
observation.
− Define the role that each requirement elicitation technique
plays in determining requirements.
− Describe several analysis strategies that can help the analyst
discover requirements.
− Describe options for designing and conducting interviews
and develop a plan for conducting an interview to determine
system requirements.
− Use prototyping during requirements determination.
− Select the appropriate methods to elicit system
requirements.

70
Chapter 3 - Determining System Requirements
Requirements' determination is performed to transform the system
request’s high-level statement of business requirements into a more
detailed, precise list of what the new system must do to provide the
needed value to the business. This detailed list of requirements is
supported, confirmed, and clarified by the other activities of the
analysis phase: creating use cases, building process models, and
building a data model. We first explain what a requirement is and
discuss the process of creating a requirements definition statement.

3.1 Performing Requirements Determination

The two parts to systems analysis are determining requirements and

structuring requirements. We address these as two separate steps,
but you should consider these steps as somewhat parallel and
repetitive. For example, as you determine some aspects of the
current and desired system(s), you begin to structure these
requirements or to build prototypes to show users how a system
might behave. Inconsistencies and deficiencies discovered through
structuring and prototyping lead you to explore further the operation
of the current system(s) and the future needs of the organization.
Eventually your ideas and discoveries meet on a thorough and
accurate depiction of current operations and the requirements for
the new system.

3.1.1 What is a Requirement?

A requirement is simply a statement of what the system must do or

what characteristics it needs to have. During a systems development
project, requirements will be created that describe what the business

71
needs (business requirements); what the users need to do (user
requirements); what the software should do (functional
requirements); characteristics the system should have
(nonfunctional requirements); and how the system should be built
(system requirements). Although this list of requirement categories
may seem intimidating at first, the categories merely reflect the
purpose of the requirements and the stage in the SDLC in which
they are defined.

− Business Requirements:

In the system request, there are statements that describe the reasons
for proposing the systems development project. These statements
reflect the business requirements that this system, if built, will
fulfill. These business requirements help define the overall goals of
the system and help clarify the contributions it will make to the
organization’s success. Examples of business requirements include:
“Increase market share”; “Shorten order processing time”; “Reduce
customer service costs”; “Lower inventory spoilage”; “Improve
responsiveness to customer service requests”; and “Provide account
access to mobile customers.” When the systems development
project is complete, success will be measured by evaluating whether
the stated business requirements have actually been achieved;
therefore, they provide the overall direction for the project.

− User Requirements

During the analysis phase, requirements are written from the

perspective of the business, and they focus on what the system
needs to do in order to satisfy business user needs. A good starting

72
place is to concentrate on what the user actually needs to
accomplish with the system in order to fulfill a needed job or task.
These user requirements describe tasks that the users perform as an
integral part of the business’ operations, such as: “Schedule a client
appointment”; “Place a new customer order”; “Re-order inventory”;
“Determine available credit”; and “Look up account balances.” Use
cases are tools used to clarify the steps involved in performing these
user tasks. By understanding what the user needs to do in terms of
tasks to perform, the analyst can then determine ways in which the
new system can support the users’ needs.

− Functional requirements

Determining ways in which the new system can support user needs
leads to statements of the system’s functional requirements. A
functional requirement relates directly to a process the system has
to perform as a part of supporting a user task and/or information it
needs to provide as the user is performing a task. The International
Institute of Business Analysis (IIBA) defines functional
requirements as “the product capabilities, or things that a product
must do for its users.”3 Functional requirements begin to define
how the system will support the user in completing a task. For
example, assume the user requirement is “Schedule a client
appointment.” The functional requirements associated with that task
include: “Determine client availability,” “Find available openings
matching client availability,” “Select desired appointment,”
“Record appointment,” and “Confirm appointment.” Notice how
these functional requirements expand upon the user’s task to

73
describe capabilities and functions that the system will need to
include, allowing the user to complete the task.

− Non-functional Requirements

Although the term “nonfunctional” is not very descriptive, this

requirement category includes important behavioral properties that
the system must have, such as performance and usability. The
ability to access the system through a mobile device would be
considered a nonfunctional requirement. Nonfunctional
requirements are primarily used in the design phase when decisions
are made about the user interface, the hardware and software, and
the system’s underlying architecture. Many of these requirements
will be discovered during conversations with users in the analysis
phase, however, and should be recorded as they are discovered.
Table 3.1 lists different kinds of nonfunctional requirements and
examples of each kind. Notice that the nonfunctional requirements
describe a variety of system characteristics: operational,
performance, security, and cultural and political. These
characteristics do not describe business processes or information,
but they are very important in understanding what the final system
should be like.

Nonfunctional Requirement Examples

Description
▪ The system can run on handheld
The physical and devices.
Operational technical
environments in ▪ The system should be able to integrate
which the system with the existing inventory system.
will operate
▪ The system should be able to work on
any Web browser.

74
Nonfunctional Requirement Examples
Description
▪ Any interaction between the user and
the system should not exceed 2
seconds.
▪ The system downloads new status
Performance The speed, capacity, parameters within 5 minutes of a
and reliability of the change.
system
▪ The system should be available for use
24 hours per day, 365 days per year.
▪ The system supports 300 simultaneous
users from 9–11 A.M.; 150
simultaneous users at all other times.
▪ Only direct managers can see
personnel records of staff.
Who has authorized
access to the system ▪ Customers can see their order history
Security
under what only during business hours.
circumstances
▪ The system includes all available
safeguards from viruses, worms,
Trojan horses, etc.
▪ The system should be able to
distinguish between U.S. requirements
that affect the system currency and
currency from other nations.
Cultural and ▪ Company policy is to buy computers
Political Cultural and political only from Dell.
factors and legal
▪ Country managers are permitted to
authorize custom user interfaces within
their units.
▪ Personal information is protected in
compliance with the
▪ Data Protection Act.
Table 3.1: Nonfunctional Requirements (Source: The Atlantic Systems
Guild, http://www.systemsguild.com)

− System Requirements

User requirements and functional requirements defined in the

analysis phase will flow into the design phase, where they evolve to
become more technical, describing how the system will be

75
implemented. Requirements in the design phase reflect the
developer’s perspective, and they usually are called system
requirements. These requirements focus on describing how to create
the software product that will be produced from the project. Before
we continue, we want to stress that it can be difficult to draw a
black-and-white dividing line between these categories of
requirement—and, confusingly, some companies use the terms
interchangeably. The important thing to remember is that a
requirement is a statement of what the system must do, and the
focus of requirements will change over time as the project moves
from planning to analysis to design to implementation.

3.1.2 Basic Requirements

Analysts structure their investigation by seeking answers to these

four major questions:

1. What is the basic business process?

2. What data are used or produced during that process?
3. What are the limits imposed by time and the volume of
work?
4. What performance controls are used?

3.1.2.1 Understand the process

Begin with the basics. Analysts must raise questions that, when
answered, will provide a background of fundamental details about
the system and describe it. Asking the following questions will help
acquire the necessary understanding.

1. What is the purpose of this business activity?

2. What steps are performed?

76
 3. Where are they performed?
4. Who performs them?
5. How long does this take?
6. How often is it done?
7. Who uses the resulting information?

3.1.2.2 Identify data used and information produced

Analysts next need to find out what data are used to perform each
activity for example, to reorder inventory, the buyer might require
data describing the quantity of an item of hand, expected demand
for the item, supplier name, and item cost. To know when to place
an order, the buyer would also consider the necessary lead-time
(how in advance the item should be ordered to be on hand when
needed).

3.1.2.3 Determine process timing and volume

The frequency of business activities varies greatly. For example,

some activities, such as paying taxes, occur only a few times a year,
whereas paying employees is a weekly activity. Therefore, analysts
should learn how often the activity is repeated. Knowing whether an
activity occurs frequently may lead the analyst to raise many
additional and important questions to determine the reason for the
frequency and its effect on business activities.

3.1.2.4 Identity controls

In business situations that are well controlled either by management

or process monitoring, determining whether an activity has been
performed properly may be no problem. But during the analysis
stage, the analysts must examine control methods:

77
 − Are there specific performance standards?
− Who compares performance against standards?
− How are mistakes caught?
− How are error handled?
− Are the errors excessive?

3.1.2.5 User transaction requirements

Transaction – level systems captures, process, and store data for a

reason. In an order system, for example, sale order form customers
are processed so that specified item can be shipped. This simple
procedure applies to every order that is received. Analysts who are
assigned to work on an order entry system would want to know
more about how these transactions are processed.

3.1.2.6 User decision requirements

Decision, unlike transaction activities, may not follow a specific

procedure. Routines are not as clear – cut, and controls may be very
vague. Decisions are made by integrating information in such a way
that managers can know what actions to take. Decision systems may
focus on the past, the present, or the future. Some may support
recurring decisions (such as merchandise pricing, while other are
unique and do not recur (such as the merger example used earlier).
They may use data that originate inside the firm, such as through
transaction processing, or outside, for example form trade
associations or commercial sources (such as marketing research
firms who sell information to organizations). In some cases,
transaction data are processed to provide new information for

78
decision making. For instance, summarized sales transaction data
tell managers which products sell, and which do not.

3.1.3 The Process of Determining Requirements

Both business and IT perspectives are needed to determine

requirements during the analysis phase. Systems analysts may not
understand the true business needs of the users. A recent study by
the Standish Group found that the lack of user involvement is the
top reason for IT project failure. On the other hand, the business
users may not be aware of the opportunities that a new technology
may offer. It is important that the team carefully considers the
underlying business process and how best to support that business
process with information system technology. A good analogy is
building a house or an apartment. We have all lived in a house or
apartment, and most of us have some understanding of what we
would like in our homes. If we were asked to design a dwelling
from scratch, however, it would be a challenge because we lack
appropriate design skills and technical engineering skills. Likewise,
an architect acting alone would probably miss some of our unique
requirements.

3.1.4 The Requirements Definition Statement

The requirements definition statement—usually just called the

requirements definition—is a straightforward text report that simply
lists the functional and nonfunctional requirements in an outline
format. Figure 3.1 shows a sample requirements definition for
Holiday Travel Vehicles, a fictitious recreational vehicle dealership.
As shown in Figure 3.1, it is common to number the requirements
in a legal or outline format so that each requirement is clearly

79
identified. It is important that the requirements be identified with
unique numbers so that each requirement can be easily tracked
through the entire development process. For clarity, the
requirements are typically grouped into functional and
nonfunctional groupings. Then, within each of those groups, they
are classified further by the type of requirement or by business area.

Figure 3.1: Sample Requirements Definition

3.1.5 Deliverables and Outcomes

The primary deliverables from requirements determination are the

types of information gathered during the determination process. The

80
information can take many forms: transcripts of interviews; notes
from observation and analysis of documents; sets of forms, reports,
job descriptions, and other documents; and computer-generated
output such as system prototypes. In short, anything that the
analysis team collects as part of determining system requirements is
included in these deliverables. Table 3.3 lists examples of some
specific information that might be gathered at this time.

3.1.6 Requirements Structuring

The amount of information gathered during requirements

determination could be huge, especially if the scope of the system
under development is broad. The time required to collect and
structure a great deal of information can be extensive and, because
it involves so much human effort, quite expensive. Because of the
dangers of excessive analysis, today’s systems analysts focus more
on the system to be developed than on the current system. Later in
the chapter, you learn about Joint Application Design (JAD) and
prototyping, techniques developed to keep the analysis effort at a
minimum yet still be effective. Other processes have been
developed to limit the analysis effort even more, providing an
alternative to the SDLC. Many of these are included under the name
of Agile Methodologies. Before you can fully appreciate alternative
approaches, you need to learn traditional fact-gathering techniques.

3.2 Traditional Methods for Determining Requirements

Collection of information is at the core of systems analysis. At the

outset, you must collect information about the information systems
that are currently in use. You need to find out how users would like

81
to improve the current systems and organizational operations with
new or replacement information systems.

One of the best ways to get this information is to talk to those

directly or indirectly involved in the different parts of the
organization affected by the possible system changes. Another way
is to gather copies of documentation relevant to current systems and
business processes. In this chapter, you learn about traditional ways
to get information directly from those who have the information
you need: interviews and direct observation. You learn about
collecting documentation on the current system and organizational
operation in the form of written procedures, forms, reports, and
other hard copy. These traditional methods of collecting system
requirements are listed in Table 3.2.

Traditional Method Activities Involved

Interviews with Individuals
Observations of workers
Business documents
Interview individuals informed about the operation
and issues of the current system and needs for
systems in future organizational activities.
Observe workers at selected times to see how data
are handled and what information people need to
do their jobs.
Study business documents to discover reported
issues, policies, rules, and directions, as well as,
concrete examples of the use of data and
information in the organization.

Table 3.2 Traditional Methods of Collecting System Requirements

3.2.1 Interviewing and Listening

Interviewing is one of the primary ways’ analysts gather

information about an information systems project. Early in a
project, an analyst may spend a large amount of time interviewing
people about their work, the information they use to do it, and the
types of information processing that might supplement their work.

82
Others are interviewed to understand organizational direction,
policies, and expectations that managers have of the units they
supervise. During interviewing, you gather facts, opinions, and
speculation and observe body language, emotions, and other signs
of what people want and how they assess current systems.

3.2.1.1 Selecting Interviewees

An interview schedule should be created, listing who will be

interviewed, the purpose of the interview, and where and when it
will take place. (See Figure 3.3) The schedule can be an informal
list that is used to help set up meeting times or a formal list that is
incorporated into the work plan. The people who appear on the
interview schedule are selected on the basis of the analyst’s
information needs. The project sponsor, key business users, and
other members of the project team can help the analyst determine
who in the organization can best provide important information
about requirements. These people are listed on the interview
schedule in the order in which they should be interviewed.

3.2.1.2 Designing Interview Questions

There are three types of interview questions:

Closed-Ended questions, open-ended questions, and probing

questions. Closed-ended questions require a specific answer. You
can think of them as being similar to multiple choice or arithmetic
questions on an exam. Closed-ended questions are used when the
analyst is looking for specific, precise information (e.g., how many
credit card requests are received per day).

83
 Figure 3.3: A Typical Interview Guide

− Open-Ended questions are those that leave room for elaboration

on the part of the interviewee. They are similar in many ways to
essay questions that you might find on an exam. Open-ended
questions are designed to gather rich information and give the
interviewee more
− The third type of question is the probing question. Probing
questions follow up on what has just been discussed in order for
the interviewer to learn more, and they often are used when the
interviewer is unclear about an interviewee’s answer. They
encourage the interviewee to expand on or to confirm
information from a previous response, and they are a signal that
the interviewer is listening and interested in the topic under
discussion.

84
There are two fundamental approaches to organizing the interview
questions: top-down or bottom-up; see Figure 3.4. With the top-
down interview, the interviewer starts with broad, general issues and
gradually works towards more specific ones. With the bottom-up
interview, the interviewer starts with very specific questions and
moves to broad questions. In practice, analysts mix the two
approaches, starting with broad general issues, moving to specific
questions, and then back to general issues.

Figure 3.4: Top-Down and Bottom-Up Questioning Strategies

The top-down approach is an appropriate strategy for most

interviews. (It is certainly the most common approach.) The top-
down approach enables the interviewee to become accustomed to
the topic before he or she needs to provide specifics. It also enables
the interviewer to understand the issues before moving to the
details, because the interviewer may not have sufficient information
at the start of the interview to ask very specific questions. Perhaps
most importantly, the top-down approach enables the interviewee to
raise a set of big-picture issues before becoming enmeshed in
details, so the interviewer is less likely to miss important issues.

85
3.2.1.3 Choosing Interview Questions

You need to decide on the mix and sequence of open-ended and

closed-ended questions to use. Open-ended questions are usually
used to probe for information when you cannot anticipate all
possible responses or when you do not know the precise question to
ask. The person being interviewed is encouraged to talk about
whatever interests him or her within the general bounds of the
question.

Closed-ended questions provide a range of answers from which

the interviewee may choose. Here is an example: Which of the
following would you say is the one best thing about the information
system you currently use to do your job (pick only one)?

a) Having easy access to all of the data you need

b) The system’s response time
c) The ability to run the system concurrently with other
applications

3.2.1.4 Preparing for the Interview

It is important to prepare for the interview in the same way that you
would prepare to give a presentation. You should have a general
interview plan which lists the questions that you will ask in the
appropriate order; anticipates possible answers and provides how
you will follow up with them; and identifies segues between related
topics. Confirm the areas in which the interviewee has knowledge
so you do not ask questions that he or she cannot answer. Review
the topic areas, the questions, and the interview plan, and clearly

86
decide which ones have the greatest priority in case you run out of
time.

3.2.1.5 Interview Guidelines

First, with either open- or closed-ended questions, do not phrase a

question in a way that implies a right or wrong answer.
Respondents must feel free to state their true opinions and
perspectives and trust that their ideas will be considered. Avoid
questions such as “Should the system continue to provide the ability
to override the default value, even though most users now do not
like the feature?” because such wording predefines a socially
acceptable answer.

Second, listen carefully to what is being said. Take careful notes or,
if possible, record the interview on a tape recorder (be sure to ask
permission first!). The answers may contain extremely important
information for the project. Also, this may be your only chance to
get information from this particular person. If you run out of time
and still need more information from the person you are talking to,
ask to schedule a follow-up interview.

Third, once the interview is over, go back to your office and key in
your notes within forty-eight hours with a word processing program
such as Microsoft Word. For numerical data, you can use a
spreadsheet program such as Microsoft Excel. If you recorded the
interview, use the recording to verify your notes. After forty-eight
hours, your memory of the interview will fade quickly. As you type
and organize your notes, write down any additional questions that
might arise from lapses in your notes or ambiguous information.

87
Fourth, be careful during the interview not to set expectations about
the new or replacement system unless you are sure these features
will be part of the delivered system. Let the interviewee know that
there are many steps to the project. Many people will have to be
interviewed.

Fifth, seek a variety of perspectives from the interviews. Talk to

several different people: potential users of the system, users of other
systems that might be affected by this new system, managers and
superiors, information systems staff, and others. Encourage people
to think about current problems and opportunities and what new
information services might better serve the organization. You want
to understand all possible perspectives so that later you will have
information on which to base a recommendation or design decision
that everyone can accept.

3.2.1.6 Conducting the Interview

When you start the interview, the first goal is to build rapport with
the interviewee so that he or she trusts you and is willing to tell you
the whole truth, not just give the answers that he or she thinks you
want. You should appear to be professional and an unbiased,
independent seeker of information. The interview should start with
an explanation of why you are there and why you have chosen to
interview the person, and then move into your planned interview
questions.

3.2.1.7 Post-interview Follow-up

After the interview is over, the analyst needs to prepare an interview

report that describes the information from the interview. The report

88
contains interview notes, information that was collected over the
course of the interview and is summarized in a useful format. In
general, the interview report should be written within 48 hours of
the interview, because the longer you wait, the more likely you are
to forget information. Often, the interview report is sent to the
interviewee with a request to read it and inform the analyst of
clarifications or updates.

3.2.2 Record Review

Many kinds of records and reports can provide analysts with

valuable information about organizations and operations. In record
reviews, analysts examine information that has been recorded about
the system and user. Record inspection can be performed at the
beginning of the study, as an introduction, or later in the study, as a
basis for comparing, actual operations with the records indicate
should be happening.

3.2.3 Questionnaires

A questionnaire is a set of written questions for obtaining

information from individuals. Questionnaires often are used when
there is a large number of people from whom information and
opinions are needed. In our experience, questionnaires are
commonly used for systems intended for use outside of the
organization (e.g., by customers or vendors) or for systems with
business users spread across many geographic locations. Most
people automatically think of paper when they think of
questionnaires, but today more questionnaires are being distributed
in electronic form, either via e-mail or on the Web. Electronic

89
distribution can save a significant amount of money, compared with
distributing paper questionnaires.

3.2.3.1 Selecting Participants

As with interviews and JAD sessions, the first step is to select the
individuals to whom the questionnaire will be sent. However, it is
not usual to select every person who could provide useful
information. The standard approach is to select a sample, or subset,
of people who are representative of the entire group. The important
point in selecting a sample, however, is to realize that not everyone
who receives a questionnaire will actually complete it. On average,
only 30%–50% of paper and e-mail questionnaires are returned.

3.2.3.2 Designing the Questionnaire

Developing good questions is critical for questionnaires because the

information on a questionnaire cannot be immediately clarified for a
confused respondent. Questions must be very clearly written and
must leave little room for misunderstanding; therefore, closed-
ended questions tend to be most commonly used. Questions must
enable the analyst to clearly separate facts from opinions. Opinion
questions often ask the respondent the extent to which they agree or
disagree (e.g., “Are network problems common?”), while factual
questions seek more precise values (e.g., “How often does a
network problem occur?”).

3.2.3.3 Administering the Questionnaire

The key issue in administering the questionnaire is getting

participants to complete the questionnaire and send it back. Dozens
of marketing research books have been written about ways to

90
improve response rates. Commonly used techniques include clearly
explaining why the questionnaire is being conducted and why the
respondent has been selected; stating a date by which the
questionnaire is to be returned; offering an inducement to complete
the questionnaire (e.g., a free pen); and offering to supply a
summary of the questionnaire responses.

3.2.3.4 Questionnaire Follow-up

It is helpful to process the returned questionnaires and develop a

questionnaire report soon after the questionnaire deadline. This
ensures that the analysis process proceeds in a timely fashion and
that respondent who requested copies of the results receive them
promptly.

3.2.4 Directly Observing Users

Observation, the act of watching processes being performed, is a

powerful tool to gain insight into the as-is system. Observation
enables the analyst to see the reality of a situation, rather than
listening to others describe it in interviews or JAD sessions.

Several research studies have shown that many managers really do

not remember how they work and how they allocate their time.
(Quick, how many hours did you spend last week on each of your
courses?) Observation is a good way to check the validity of
information gathered from other sources such as interviews and
questionnaires.

Observation is often used to supplement interview information. The

location of a person’s office and its furnishings gives clues as to
their power and influence in the organization, and such clues can be

91
used to support or refute information given in an interview. For
example, an analyst might become skeptical of someone who
claims to use the existing computer system extensively if the
computer is never turned on while the analyst visits. In most cases,
observation will support the information that users provide in
interviews. When it does not, it is an important signal that extra care
must be taken in analyzing the business system.

3.3 Modern Methods for Determining System

Even though we called interviews, questionnaires, observation, and

document analysis traditional methods for determining a system’s
requirements, all of these methods are still used by analysts to
collect important information. Today, however, additional
techniques are available to collect information about the current
system, the organizational area requesting the new system, and what
the new system should be like. In this section, you learn about two
modern information-gathering techniques for analysis: joint
application design (JAD) and prototyping. These techniques can
support effective information collection and structuring while
reducing the amount of time required for analysis.

3.3.1 Joint Application Design

No matter how adept you become as an interviewer, you will

inevitably experience situations in which one-on-one interviews do
not seem to be as useful as you would like. Personal interviews are
time consuming and subject to error, and their data are prone to
misinterpretation. An alternative approach to interviewing users one
by one, called Joint Application Design (JAD), was developed by
IBM. The motivation for using JAD is to cut the time (and hence

92
the cost) required by personal interviews, to improve the quality of
the results of information requirements assessment, and to create
more user identification with new information systems as a result of
the participative processes.

3.3.1.1 Where to Hold JAD Meetings

The JAD group meets for several hours, several days, or several
weeks until all of the issues have been discussed and the needed
information is collected. Most JAD sessions take place in a
specially prepared meeting room, away from the participants’
offices, so that they are not interrupted. The meeting room is
usually arranged in a U shape so that all participants can easily see
each other. (See Figure 3.5) At the front of the room (the open part
of the “U”), there is a whiteboard, flip chart and/or overhead
projector for use by the facilitator, who leads the discussion. One
problem with JAD is that it suffers from the traditional problems
associated with groups: Sometimes people are reluctant to challenge
the opinions of others (particularly their boss), a few people often
dominate the discussion, and not everyone participates.

Electronic JAD, or e-JAD, attempts to overcome these problems by

the use of groupware. In an e-JAD meeting room, each participant
uses special software on a networked computer to anonymously
submit ideas, view all ideas generated by the group, and rate and
rank ideas through voting. The facilitator uses the electronic tools of
the e-JAD system to guide the group process, maintaining
anonymity and enabling the group to focus on each idea’s merits
and not the power or rank of the person who contributed the idea. In

93
this way, all participants can contribute at the same time, without
fear of reprisal from people with differing opinions.

Figure 3.5: Joint Application Development Meeting Room

3.3.1.2 Potential Benefits of Using JAD in Place of Traditional

Interviewing

There are four major potential benefits that you, the users, and your
systems analysis team should consider when you weigh the
possibilities of using joint application design.

The first potential benefit is time savings over traditional one-on-

one interviews. Some organizations have estimated that JAD
sessions have provided a 15 percent time savings over the
traditional approach. Hand-in-hand with time savings is the rapid
development possible via JAD. Because user interviews are not
accomplished serially over a period of weeks or months, the
development can proceed much more quickly. A third benefit to
weigh is the possibility of improved ownership of the information
system. A final benefit of participating in JAD sessions is the
creative development of designs. The interactive character of JAD
has a great deal in common with brainstorming techniques that

94
generate new ideas and new combinations of ideas because of the
dynamic and stimulating environment.

3.3.2 Using Prototyping during Requirements Determination

Prototyping is a repetitive process in which analysts and users build

a rudimentary version of an information system based on user
feedback. Prototyping could replace the systems development life
cycle or augment it. To establish requirements for prototyping, you
still have to interview users and collect documentation. Prototyping,
however, allows you to quickly convert basic requirements into a
working, though limited, version of the desired information system.
The user then views and tests the prototype. Typically, seeing
verbal descriptions of requirements converted into a physical
system prompts the user to modify existing requirements and
generate new ones.

Prototyping is most useful for requirements determination when:

− User requirements are not clear or well understood, this is often

the case for totally new systems or systems that support decision
making.
− One or a few users and other stakeholders are involved with the
system.
− Possible designs are complex and require concrete form to
evaluate fully.
− Communication problems have existed in the past between
users and analysts, and both parties want to be sure that system
requirements are as specific as possible.

95
− Tools (such as form and report generators) and data are readily
available to rapidly build working systems.

3.4 Radical Methods for Determining System Requirements

Whether traditional or modern, the methods for determining system

requirements apply to any requirements determination effort,
regardless of its motivation. Yet, most of what you have learned has
traditionally been applied to systems development projects that
involve automating existing processes. Analysts use system
requirements determination to understand current problems and
opportunities, as well as what is needed and desired in future
systems. Typically, the current way of doing things has a large
impact on the new system. In some organizations, though,
management is looking for new ways to perform current tasks.

3.4.1 Disruptive Technologies

Once key business processes and activities have been identified,

information technologies must be applied to improve business
processes radically. Hammer and Champy suggest that
organizations think “inductively” about information technology.
Induction is the process of reasoning from the specific to the
general, which means that managers must learn about the power of
new technologies and think of innovative ways to alter the way
work is done. This approach is contrary to deductive thinking, in
which problems are first identified and solutions then formulated.

3.5 Selecting the Appropriate Techniques

Each of the requirements elicitation techniques just discussed has

strengths and weaknesses. No one technique is always better than

96
the others, and in practice most projects benefit from a combination
of techniques. Thus, it is important to understand the strengths and
weaknesses of each technique and when to use each. (See Table
3.3) One issue not discussed is that of the analysts’ experience. In
general, document analysis and observation require the least amount
of training, while JAD sessions are the most challenging.

3.5.1 Type of Information

The first characteristic is type of information. Some techniques are

more suited for use at different stages of the analysis process,
whether understanding the as-is system, identifying system.
Interviews and JAD are commonly used in all three stages. In
contrast, document analysis and observation usually are most
helpful for understanding the as-is system, although they
occasionally provide information about improvements.
Questionnaires are often used to gather information about the as-is
system, as well as general information about improvements.

Joint Document
Interviews Application Questionnaires Observations
Analysis
Design
As-is, As-is,
Type of As-is,
improvements, improvements, As-is As-is
information improvements
to-be to-be
Depth of
high high Medium Low Low
information
Breadth of
Low Medium High High Low
information
Integration
of Low High Low Low Low
information
User
involvemen Medium High Low Low Low
t
Cost Medium Low- Medium Low Low Low- Medium

Table 3.3: Comparison of Requirements Elicitation Techniques

97
3.5.2 Depth of Information

The depth of information refers to how rich and detailed the

information is that the technique usually produces and the extent to
which the technique is useful at obtaining not only facts and
opinions, but also an understanding of why those facts and opinions
exist. Interviews and JAD sessions are very useful at providing a
good depth of rich and detailed information and helping the analyst
to understand the reasons behind them. At the other extreme,
document analysis and observation are useful for obtaining facts,
but little beyond that.

3.5.3 Breadth of Information

Breadth of information refers to the range of information and

information sources that can be easily collected by that technique.
Questionnaires and document analysis both are easily capable of
soliciting a wide range of information from a large number of
information sources. In contrast, interviews and observation require
the analyst to visit each information source individually and,
therefore, take more time. JAD sessions are in the middle because
many information sources are brought together at the same time.

3.5.4 Integration of Information

One of the most challenging aspects of requirements gathering is

the integration of information from different sources. Simply put,
different people can provide conflicting information. Combining
this information and attempting to resolve differences in opinions or
facts is usually very time consuming because it means contacting
each information source in turn, explaining the discrepancy, and

98
attempting to refine the information. In many cases, the individual
wrongly perceives that the analyst is challenging his or her
information, when in fact the source of conflict is another user in
the organization. This can make the user defensive and make it hard
to resolve the differences.

3.5.5 User Involvement

User involvement refers to the amount of time and energy the

intended users of the new system must devote to the analysis
process. It is generally agreed that, as users become more involved
in the analysis process, the chance of success increases. However,
user involvement can have a significant cost, and not all users are
willing to contribute valuable time and energy. Questionnaires,
document analysis, and observation place the least burden on users,
while JAD sessions require the greatest effort.

3.6 Requirements Analysis Strategies

The analyst often must encourage the stakeholders to think critically

about the needs for the new system and discover the true underlying
requirements. In this section, we present several strategies that the
analyst can employ with the stakeholders to accomplish this goal.

3.6.1 Problem Analysis

The most straightforward (and probably the most commonly used)

requirements analysis strategy is problem analysis. Problem
analysis means asking the users and managers to identify problems
with the as-is system and to describe how to solve them in the to-be
system. Most users have a very good idea of the changes they
would like to see, and most will be quite vocal about suggesting

99
them. Most changes tend to solve problems rather than capitalize on
opportunities, but this is possible, too. Improvements from problem
analysis tend to be small and incremental (e.g., add a field to store
the customer’s cell phone number; provide a new report that
currently does not exist). This type of improvement often is very
effective at improving a system’s efficiency or ease of use.

3.6.2 Root Cause Analysis

The ideas produced by problem analysis tend to be solutions to

problems. All solutions make assumptions about the nature of the
problem, assumptions that may or may not be valid. In our
experience, users (and most people in general) tend to jump quickly
to solutions without fully considering the nature of the problem.
Sometimes the solutions are appropriate, but many times they
address a symptom of the problem, not the true problem or root
cause itself.

Root cause analysis focuses on problems first rather than solutions.

The analyst starts by having the users generate a list of problems
with the current system, then prioritizes the problems in order of
importance. Starting with the most important, the users and/or
analysts generate all possible root causes for the problem. The
problem of “too frequent stock-outs” has several potential root
causes (inaccurate on-hand counts; incorrect reorder points; lag in
placing supplier orders). Each possible root cause is investigated,
and additional root causes are identified. As Figure 3.6 shows, it is
sometimes useful to display the potential root causes in a tree-like
hierarchy. Ultimately, the investigation process reveals the true root

100
cause or causes of the problem, enabling the team to design the
system to correct the problem with the right solution.

Figure 3.6: root cause analysis for Inventory Stock Outs

3.6.3 Duration Analysis

Duration analysis requires a detailed examination of the amount of

time it takes to perform each process in the current as-is system.
The analysts begin by determining the total amount of time it takes,
on average, to perform a set of business processes for a typical
input. They then time each of the individual steps (or sub-processes)
in the business process. The time to complete the basic steps are
then totaled and compared with the total for the overall process. A

101
significant difference between the two—and, in our experiences, the
total time often can be 10 or even 100 times longer than the sum of
the parts—indicates that this part of the process is badly in need of a
major overhaul.

3.6.4 Activity-Based Costing

Activity-based costing is a similar analysis that examines the cost of

each major process or step in a business process rather than the time
taken. The analysts identify the costs associated with each of the
basic functional steps or processes, identify the most costly
processes, and focus their improvement efforts on them.

Assigning costs is conceptually simple. You just examine the direct

cost of labor and materials for each input. Materials costs are easily
assigned in a manufacturing process, while labor costs are usually
calculated on the basis of the amount of time spent on the input and
the hourly cost of the staff. However, as you may recall from a
managerial accounting course, there are indirect costs such as rent,
depreciation, and so on that also can be included in activity costs.

3.6.5 Informal Benchmarking

Benchmarking refers to studying how other organizations perform a

business process in order to learn how your organization can do
something better. Benchmarking helps the organization by
introducing ideas that employees may never have considered, but
that have the potential to add value.

Informal benchmarking is fairly common for “customer-facing”

business processes (i.e., those processes that interact with the
customer). With informal benchmarking, the managers and analysts

102
think about other organizations, or visit them as customers to watch
how the business process is performed. In many cases, the business
studied may be a known leader in the industry or simply a related
firm.

3.6.6 Outcome Analysis

Outcome analysis focuses on understanding the fundamental

outcomes that provide value to customers. While these outcomes
sound as though they should be obvious, they often aren’t. For
example, suppose that you are an insurance company and one of
your customers has just had a car accident. What is the fundamental
outcome from the customer’s perspective? Traditionally, insurance
companies have answered this question by assuming that the
customer wants to receive the insurance payment quickly. To the
customer, however, the payment is only a means to the real
outcome: a repaired car.

3.6.7 Technology Analysis

Many major changes in business over the past decade have been
enabled by new technologies. Technology analysis therefore starts
by having the analysts and managers develop a list of important and
interesting technologies. Then the group systematically identifies
how each and every technology could be applied to the business
process and identifies how the business would benefit.

3.6.8 Activity Elimination

Activity elimination is exactly what it sounds like. The analysts and

managers work together to identify how the organization could
eliminate each and every activity in the business process, how the

103
function could operate without it, and what effects are likely to
occur. Initially, managers are reluctant to conclude that processes
can be eliminated, but this is a “force-fit” exercise in that they must
eliminate each activity. In some cases, the results are silly;
nonetheless, participants must address each and every activity in the
business process.

3.6.9 Comparing Analysis Strategies

Each of the requirements analysis strategies discussed here has its

own purpose. No one technique is inherently better than the others.
Remember that an organization will likely have a wide range of
projects in its portfolio; the requirements analysis strategy should be
chosen to fit the nature of the project. Problem analysis and root
cause analysis tend to be most useful in situations with a narrow
focus where efficiency gains are sought. Duration analysis and
activity-based costing strategies help the team find the most
“broken” business processes so that those processes can be
redesigned and improved. Outcome analysis, technology analysis,
and informal benchmarking help the team think “outside the box”
and are very useful when the team is trying to create completely
new ways of accomplishing the business processes.

104
 Chapter 4
Structuring System Requirements
Process Modeling

Learning Objectives

− Understand the logical modeling of processes through

studying examples of data-flow diagrams.

− Draw data-flow diagrams following specific rules and

guidelines that lead to accurate and well-structured process

models.

− Decompose data-flow diagrams into lower level diagrams.

− Balance higher-level and lower-level data-flow diagrams.

− Use data-flow diagrams as a tool to support the analysis of

information systems.

− Use decision tables to represent process logic.

105
Chapter 4: Structuring System Requirements:
Process Modeling
4.1 The Analysis Phase

Analysis is the heart of the process. It is the key component of the

first two phases of the cycle. In analyzing the present system, the
analyst collects a great deal of relatively unstructured data through
interviews, questionnaires, on–site observations, procedures
manuals, and the like. The traditional approach is to organize and
convert the data though system flowcharts, which support future
developments of the system and simplify communication with the
user. But the system flowchart represents a physical rather than a
logical system. It makes it difficult to distinguish between what
happens and how it happens in the system.

There are other problems with the traditional approach.

1. The system life cycle provides very little quality control to

ensure accurate communication from user to analyst. They
have no language in common.

2. The analyst is quickly overwhelmed with the business and

technical details of the system. Much of the time is spent
gathering information. The details are needed and must be
available, but the analyst does not have the tools to structure
and control the details.

3. Present analytical tools have limitations.

− English narrative descriptions of a system are often too

vague and make it difficult for the user to grasp how the

106
 parts fit together. Furthermore, English is inherently
difficult to use where precision is needed.

− System and program flowcharts commit to a physical

implementation of the system before on has complete
understanding of its logical requirements.

4. Problems also relate to system specifications:

− System specifications are difficult to maintain or

modify. A simple change in the user’s requirements
necessitates changes in several parts of the document.
− They describe user requirements in terms of physical
hardware that will implement the system rather than
what the user wants the system to do.
− They are monolithic and redundant; that is, to find out
information about a particular part of the system, the
user has to search the entire document.

There are other tools as well. The use of several tools in structured
analysis, including the following:

1. Data flow diagram (DFD).

2. Data dictionary.
3. Structured English.
4. Decision trees.
5. Decision tables.

4.2 Process Modeling

Process model describes business processes—the activities that

people do. Process models are developed for the as-is system and/or

107
the to-be system. There are many different process modeling
techniques in use today.

Process models are used to explain the relationship of functions/

processes to the system users, how the functions/processes relate to
each other, how data is entered and produced by
functions/processes, and how functions/processes create and use
stored data. Process models help clarify the software components
that will be needed to accomplish the functional requirements. In
addition, the functional requirements begin to define the data that
must be kept track of in order to accomplish the user tasks.

Process modeling involves graphically representing the processes,

or actions, that capture, manipulate, store, and distribute data
between a system and its environment and among components
within a system. A common form of a process model is a data-flow
diagram (DFD). A data-flow diagram is a graphic that illustrates
the movement of data between external entities and the processes
and data stores within a system. Data-flow diagramming is one of
several structured analysis techniques used to increase software
development productivity. Although not all organizations use each
structured analysis technique, collectively, these techniques, like
dataflow diagrams, have had a significant impact on the quality of
the systems development process. Although the name data flow
diagram (DFD) implies a focus on data, this is not the case. The
focus is mainly on the processes or activities that are performed.
Process modeling, and creating DFDs in particular, is one of the
most important skills needed by systems analysts.

108
4.3 Deliverables and Outcomes

In structured analysis, the primary deliverables from process

modeling are a set of coherent, interrelated data-flow diagrams.
Table 4.1 lists the progression of deliverables that result from
studying and documenting a system’s process. First, a context data-
flow diagram shows the scope of the system, indicating which
elements are inside and outside the system. Second, data-flow
diagrams of the current system specify which people and
technologies are used in which processes to move and transform
data, accepting inputs and producing outputs. The detail of these
diagrams allows analysts to understand the current system and
eventually to determine how to convert the current system into its
replacement. Third, technology-independent, or logical, data-flow
diagrams show the dataflow, structure, and functional requirements
of the new system. Finally, entries for all of the objects in all
diagrams are included in the project dictionary or CASE repository.

Table 4.1: Deliverables of Process Modeling

4.4 What is Structured Analysis?

Structured analysis is a set of techniques and graphical tools that

allow the analyst to develop a new kind of system specifications
that are easily understandable to the user. Analysts work primarily
with their wits, pencil, and paper. Most of them have no tools. The

109
traditional approach focuses on cost/benefit and feasibility analysis,
project management, hardware and software selection and
personnel considerations. In contrast, structured analysis considers
new goals and structured tools for analysis. The new goals specify
the following:

1. Use graphics wherever possible to help communicate better

with the user.
2. Differentiate between logical and physical systems.
3. Build a logical system model to familiarize the user with
system characteristics and interrelationships before
implementation.

The structured specification consists of the DFDs that show the

major decomposition of system functions and their interfaces, the
data dictionary documenting all interface flows and data stores on
the DFDs and documentation of the intervals of DFDs in a rigorous
manner through structured English, decision trees, and decision
tables.

4.4.1 Data Flow Diagram (DFD)

The first step is to draw a data flow diagram (DFD). The DFD was
first developed by Larry Constantine as a way of expressing system
requirements in a graphical from; this led to a modular design.
Data-flow diagrams are versatile diagramming tools. A DFD also
known as a “bubble chart,” has the purpose of clarifying system
requirements and identifying major transformations that will
become programs in system design. So, it is the starting point of the
design phase that functionally decompose the requirements
specifications down to the lowest level of detail. A DFD consists of

110
a series of bubbles joined by lines. The bubbles represent data
transformations, and the lines represent data flows in the system.
For example: The system takes orders from the customer
(bookstore, library, etc.), checks them against an index (file) listing
the books available, verifies customer credit through a credit
information file, and authorizes, shipment with an invoice.

Note that a DFD describes what data flow (logical) rather than how
they are processed so it does not depend on hardware, software,
data structure, or the organization. The key question that we are
trying to answer is: What major transformations must occur for
input to be correctly transformed into output?

Advantages of the Data Flow Approach

The data flow approach has four chief advantages over narrative
explanations of the way data move through the system:

1. Freedom from committing to the technical implementation

of the system too early.
2. Further understanding of the interrelatedness of systems and
subsystems.
3. Communicating current system knowledge to users through
data flow diagrams.
4. Analysis of a proposed system to determine if the necessary
data and processes have been defined.

4.4.1.1 DFD Symbols

With only four symbols, data-flow diagrams can represent both

physical and logical information systems. The four symbols used in
DFDs represent data flows, data stores, processes, and sources/sinks

111
(or external entities). The set of four symbols we use was developed
by Gane and Sarson (1979) and is illustrated in Figure 4.1. A data
flow is data that are in motion and moving as a unit from one place
in a system to another. A data flow could represent data on a
customer order form or a payroll check. It could also represent the
results of a query to a database, the contents of a printed report, or
data on a data-entry computer display form. A data flow can be
composed of many individual pieces of data that are generated at
the same time and that flow together to common destinations.

There are four symbols in the DFD language (processes, data flows,
data stores, and external entities), each of which is represented by a
different graphic symbol.

1. A square defines a source (originator) or destination of

system data.
2. An arrow identifies data flow- data in motion. It is a pipeline
through which information flows.
3. A round square (some people use an oval bubble or circle
bubble) represents a process that transforms incoming data
flow(s) into outgoing data flow(s).
4. An open rectangle is a data store- data at rest, or a temporary
repository of data.

Process:

A process is an activity or a function that is performed for some

specific business reason. Processes can be manual or
computerized. A process is the work or actions performed on data
so that they are transformed, stored, or distributed. When modeling

112
the data processing of a system, it doesn’t matter whether a process
is performed manually or by a computer. Every process should be
named starting with a verb and ending with a noun (e.g.,
“Determine request quantity”). Names should be short yet contain
enough information so that the reader can easily understand
exactly what they do.

Figure 4.1: Dataflow Diagram Symbols

Data Flow:

A data flow is a single piece of data (e.g., quantity available)

(sometimes called a data element), or a logical collection of several
pieces of information (e.g., new chemical request). Every data flow
should be named with a noun. The description of a data flow lists
exactly what data elements the flow contains (Figure 4.2). For
example, the pick-up notice data flow can list the LCA name,
chemical, and quantity requested as its data elements. Data flows
are the glue that holds the processes together. One end of every data

113
flow will always come from or go to a process, with the arrow
showing the direction into or out of the process. Data flows show
what inputs go into each process and what outputs each process
produces. Every process must create at least one output data flow,
because if there is no output, the process does not do anything.
Likewise, each process has at least one input data flow, because it is
difficult, if not impossible, to produce an output with no input.

Table 4.2: Data Flow Diagram Elements

114
Data Store:

A data store is a collection of data that is stored in some way

(which is determined later when creating the physical model).
Every data store is named with a noun and is assigned an
identification number and a description. Data stores form the
starting point for the data model and are the principal link between
the process model and the data model.

External Entity (also called source/sink):

An external entity is a person, organization, organization unit, or

system that is external to the system, but interacts with it (e.g.,
customer, clearinghouse, government organization, accounting
system). The external entity typically corresponds to the primary
actor identified in the use case. External entities provide data to the
system or receive data from the system, and serve to establish the
system boundaries. Every external entity has a name and a
description.

Figure 4.2A illustrates an incorrectly drawn DFD showing a

process, 3.0 Update Customer Master, as a source/sink, Accounting
Department. The reference numbers “1.0” and “2.0” uniquely
identify each process. D1 identifies the first data store in the
diagram. However, we are not concerned with where the data are
physically located

However, if the processing that occurs in the other office takes

place outside the system you are working on, then it should be a
source/sink on your DFD. Figure 4.2B is a DFD showing proper
use of a process.

115
 Figure 4.2: (A) An incorrectly drawn DFD showing a process as a source/sink,
(B) A DFD showing proper use of a process.

4.4.1.2 Using Data Flow Diagrams to Define Business Processes

Most business processes are too complex to be explained in one

DFD. Most process models are therefore composed of a set of
DFDs. The first DFD provides a summary of the overall system,
with additional DFDs providing more and more detail about each
part of the overall business process. Thus, one important principle

116
in process modeling with DFDs is the decomposition of the
business process into a hierarchy of DFDs, with each level down
the hierarchy representing less scope but more detail. Figure 4.4
shows how one business process can be decomposed into several
levels of DFDs.

Context Diagram The first DFD in every business process model,

whether a manual system or a computerized system, is the context
diagram (see Figure 4.3). As the name suggests, the context
diagram shows the entire system in context with its environment.
All process models have one context diagram.

The context diagram shows the overall business process as just one
process (i.e., the system itself) and shows the data flows to and from
external entities. Data stores usually are not included on the context
diagram, unless they are “owned” by systems or processes other
than the one being documented. For example, an information
system used by the university library that records who has borrowed
books would likely check the registrar’s student information
database to see whether a student is currently registered at the
university. In this context diagram, the registrar’s student
information data store could be shown on the context diagram
because it is external to the library system but used by it. Many
organizations, however, would show this as an external entity called
“Registrar’s Student Information System,” not as a data store.

Level 0 Diagram The next DFD is called the level 0 diagram or

level 0 DFD. (See Figure 4.3) The level 0 diagram shows all the
processes at the first level of numbering (i.e., processes numbered 1
through 3), the data stores, external entities, and data flows among

117
them. The purpose of the level 0 DFD is to show all the major high-
level processes of the system and how they are interrelated. All
process models have one and only one level 0 DFD.

Figure 4.3: Relationship among Levels of Data Flow Diagrams (DFDs)

Level 1 Diagrams In the same way that the context diagram

deliberately hides some of the system’s complexity, so, too, does
the level 0 DFD. The level 0 DFD shows only how the major high-
level processes in the system interact. Each process on the level 0

118
DFD can be decomposed into a more explicit DFD, called a level 1
diagram, or level 1 DFD, which shows how it operates in greater
detail.

In general, all process models have as many level 1 diagrams as

there are processes on the level 0 diagram; every process in the
level 0 DFD would be decomposed into its own level 1 DFD, so the
level 0 DFD in Figure 4.3 would have three level 1 DFDs (one for
process 1, one for process 2, one for process 3). For simplicity, we
have chosen to show only one level 1 DFD in this figure, the DFD
for process 2. The processes in level 1 DFDs are numbered on the
basis of the process being decomposed.

The level 1 DFD shows more precisely which process uses the input
data flow B (process 2.1) and which produces the output data flows
A and Y (process 2.3). Note, however, that the level 1 DFD does
not show where these data flows come from or go to. To find the
source of data flow B, for example, we have to move up to the level
0 DFD, which shows data flow B coming from external entity B.
Likewise, if we follow the data flow from A up to the level 0 DFD,
we see that it goes to process 3, but we still do not know exactly
which process within process 3 uses it (e.g., process 3.1, 3.2). To
determine the exact source, we would have to examine the level 1
DFD for process 3.

Level 2 Diagrams The bottom of Figure 4.3 shows the next level of
decomposition: a level 2 diagram, or level 2 DFD, for process 2.2.
This DFD shows that process 2.2 is decomposed into three
processes (2.2.1, 2.2.2, and 2.2.3). The level 1 diagram for process
2.2 shows interactions with data store D1, which we see in the level

119
2 DFD as occurring in process 2.2.3. Likewise, the level 2 DFD for
2.2 shows two input data flows (H, K) and two output data flows
(C, G), which we also see on the level 2 diagram, along with several
new data flows (Q, R, S). The two DFDs are therefore balanced.

Alternative Data Flows Suppose that a process produces two

different data flows under different circumstances. For example, a
quality-control process could produce a quality-approved widget or
a defective widget, or our search for a chemical could find it is
approved or not approved for use. How do we show these
alternative paths in the DFD? The answer is that we show both data
flows and use the process description to explain that they are
alternatives. Nothing on the DFD itself shows that the data flows
are mutually exclusive. For example, process 2.1 on the level 1
DFD produces three output data flows (H, J, K). Without reading
the text description of process 2.1, we do not know whether these
are produced simultaneously or whether they are mutually
exclusive.

4.4.1.3 Data-Flow Diagramming Rules

You must follow a set of rules when drawing data-flow diagrams.

These rules, listed in table 4.3, allow you to evaluate DFDs for
correctness. Figure 4.4 illustrates incorrect ways to draw DFDs and
the corresponding correct application of the rules. The rules that
prescribe naming conventions (rules C, G, I, and P in Table 4.3) and
those that explain how to interpret data flows in and out of data
stores (rules N and O in Table 4.3) are not illustrated in Figure 4.4.

Besides the rules in Table 4.3, two DFD guidelines apply most of
the time:

120
Process
A. No process can have only outputs.
It is making data from nothing (a
miracle). If an object has only outputs,
then it must be a source.
B. No process can have only inputs (a
black hole).
If an object has only inputs, then it
must be a sink.
C. A process has a verb-phrase label.
Data Store
D. Data cannot move directly from one
data store to another data store. Data
must be moved by a process.
E. Data cannot move directly from an
outside source to a data store. Data
must be moved by a process that
receives data from the source and
places the data into the data store.
F. Data cannot move directly to an
outside sink from a data store. Data
must be moved by a process.
G. A data store has a noun-phrase
label.
Source/Sink
H. Data cannot move directly from a
source to a sink.
They must be moved by a process if
the data are of any concern to our
system. Otherwise, the data flow is not
shown on the DFD.
I. A source/sink has a noun-phrase
label.
Table 4.3: Rules Governing Data-Flow Diagramming (Source: Celko,, 1987)
− The inputs to a process are different from the outputs of that
process: The reason is that processes, to have a purpose,
typically transform inputs into outputs, rather than simply
121
Data Flow
J. A data flow has only one direction of
flow between symbols.
It may flow in both directions between
a process and a data store to show a
read before an update. The latter is
usually indicated, however, by two
separate arrows because the read and
update usually happen at different
times.
K. A fork in a data flow means that
exactly the same data go from a
common location to two or more
different processes, data stores, or
sources/sinks (it usually indicates
different copies of the same data going
to different locations).
L. A join in a data flow means that
exactly the same data come from any
of two or more different processes, data
stores, or sources/sinks to a common
location.
M. A data flow cannot go directly back
to the same process it leaves. At least
one other process must handle the data
flow, produce some other data flow,
and return the original data flow to the
beginning process.
N. A data flow to a data store means
update (delete or change).
O. A data flow from a data store means
retrieve or use.
P. A data flow has a noun-phrase label.
More than one dataflow noun phrase
can appear on a single arrow as long as
all of the flows on the same arrow
move together as one package.
 passing the data through without some manipulation. The same
input may go in and out of a process, but the process also
produces other new data flows that are the result of
manipulating the inputs.
− Objects on a DFD have unique names: Every process has a
unique name. There is no reason to have two processes with the
same name. To keep a DFD uncluttered, however, you may
repeat data stores and sources/sinks. When two arrows have the
same data-flow name, you must be careful that these flows are
exactly the same. It is a mistake to reuse the same data-flow
name when two packets of data are almost the same but not
identical. Because a data-flow name represents a specific set of
data, another data flow that has even one more or one less piece
of data must be given a different, unique name.

Figure 4.4: Incorrect and correct ways to draw data-flow diagrams

122
Figure 4.4 (Continue): Incorrect and correct ways to draw data-flow diagrams

Figure 4.4 (Continue): Incorrect and correct ways to draw data-flow diagrams

123
 Figure 4.4 (Continue): Incorrect and correct ways to draw data-flow diagrams

4.4.1.4 Developing DFDs: An Example

Let’s work through an example to see how DFDs are used to model
the logic of data flows in information systems. Consider Hoosier
Burger, a fictional fast-food restaurant in Bloomington, Indiana.
Hoosier Burger is owned by Bob and Thelma Mellankamp and is a
favorite of students at nearby Indiana University.

Hoosier Burger uses an automated food-ordering system. The

boundary or scope of this system, and the system’s relationship to
its environment, is represented by the context diagram. A context
diagram is shown in Figure 4.5. Notice that this context diagram
contains only one process, no data stores, four data flows, and three
sources/sinks. The single process, labeled “0,” represents the entire
system; all context diagrams have only one process labeled “0.” The
sources/sinks represent its environmental boundaries. Because the
data stores of the system are conceptually inside the one process, no
data stores appear on a context diagram.

124
After drawing the context diagram, the next step for the analyst is to
think about which processes are represented by the single process.
As you can see in Figure 4.6, we have identified four separate
processes, providing more detail of the Hoosier Burger food-
ordering system.

The main processes in the DFD represent the major functions of the
system, and these major functions correspond to such actions as the
following:

1. Capturing data from different sources (Process 1.0)

2. Maintaining data stores (Processes 2.0 and 3.0)
3. Producing and distributing data to different sinks (Process 4.0)
4. High-level descriptions of data transformation operations
(Process 1.0)

We see that the system in Figure 4.6 begins with an order from a
customer, as was the case with the context diagram. In the first
process, labeled “1.0,” we see that the customer order is processed.

The results are four streams or flows of data:

(1) The food order is transmitted to the kitchen

(2) The customer order is transformed into a list of goods sold
(3) The customer order is transformed into inventory data
(4) The process generates a receipt for the customer.

Notice that the sources/sinks are the same in the context diagram
(Figure 4.5) and in this diagram: the customer, the kitchen, and the
restaurant’s manager. A context diagram is a DFD that provides a
general overview of a system. Other DFDs can be used to focus on

125
the details of a context diagram. A level-0 diagram, illustrated in
Figure 4.5, is an example of such a DFD. Compare the level of
detail in Figure 4.6 with that of Figure 4.5. A level-0 diagram
represents the primary individual processes in the system at the
highest possible level of detail. Each process has a number that ends
in .0 (corresponding to the level number of the DFD).

Two of the data flows generated by the first process, Receive and
Transform Customer Food Order, go to external entities (Customer
and Kitchen), so we no longer have to worry about them. We are
not concerned about what happens outside of our system. Let’s
trace the flow of the data represented in the other two data flows.
First, the data labeled Goods Sold go to Process 2.0, Update Goods
Sold File. The output for this process is labeled Formatted Goods
Sold Data. This output updates a data store labeled Goods Sold File.
If the customer order were for two cheeseburgers, one order of fries,
and a large soft drink, each of these categories of goods sold in the
data store would be incremented appropriately.

Figure 4.5: A context diagram of Hoosier Burger’s food-ordering system.

126
The Daily Goods Sold Amounts are then used as input to Process
4.0, Produce Management Reports. Similarly, the remaining data
flow generated by Process 1.0, called Inventory Data, serves as
input for Process 3.0, Update Inventory File. This process updates
the Inventory File data store, based on the inventory that would
have been used to create the customer order. For example, an order
of two cheeseburgers would mean that Hoosier Burger now has two
fewer hamburger patties, two fewer burger buns, and four fewer
slices of American cheese. The Daily Inventory Depletion Amounts
are then used as input to Process 4.0. The data flow leaving Process
4.0, Management Reports, goes to the sink Restaurant Manager.

Figure 4.7 illustrates several important concepts about information

movement. Consider the data flow Inventory Data moving from
Process 1.0 to Process 3.0. We know from this diagram that Process
1.0 produces this data flow and that Process 3.0 receives it.
However, we do not know the timing of when this data flow is
produced, how frequently it is produced, or what volume of data is
sent. Thus, this DFD hides many physical characteristics of the
system it describes. We do know, however, that this data flow is
needed by Process 3.0 and that Process 1.0 provides this needed
data.

4.4.1.5 Decomposition of DFDs

In the Hoosier Burger’s food-ordering system, we started with a

high-level context diagram (see Figure 4.5). After drawing the
diagram, we saw that the larger system consisted of four processes.
The act of going from a single system to four component processes
is called (functional) decomposition.

127
Figure 4.6: Four separate processes of the Hoosier Burger food-ordering system.

Functional decomposition is a repetitive process of breaking the

description or perspective of a system down into finer and finer
detail. This process creates a set of hierarchically related charts in
which one process on a given chart is explained in greater detail on
another chart. For the Hoosier Burger system, we broke down or
decomposed the larger system into four processes. Each of those
processes (or subsystems) is also a candidate for decomposition.
Each process may consist of several sub-processes. Each sub-
process may also be broken down into smaller units. Decomposition

128
continues until no sub-process can logically be broken down any
further. The lowest level of DFDs is called a primitive DFD.

Let’s continue with Hoosier Burger’s food-ordering system to see

how a level-0 DFD can be further decomposed. The first process in
Figure 4.6, called Receive and Transform Customer Food Order,
transforms a customer’s verbal food order (e.g., “Give me two
cheeseburgers, one small order of fries, and one large orange soda”)
into four different outputs. Process 1.0 is a good candidate process
for decomposition. Think about all of the different tasks that
Process 1.0 has to perform:

1. Receive a customer order

2. Transform the entered order into a printed receipt for the
customer
3. Transform the order into a form meaningful for the kitchen’s
system,
4. Transform the order into goods sold data
5. Transform the order into inventory data. At least these five
logically separate functions occur in Process 1.0. We can
represent the decomposition of Process 1.0 as another DFD, as
shown in Figure 4.7.

Note that each of the five processes in Figure 4.7 are labeled as sub-
processes of Process 1.0: Process 1.1, Process 1.2, and so on. Also
note that, just as with the other data-flow diagrams we have looked
at, each of the processes and data flows are named. No sources or
sinks are represented. The context and level-0 diagrams show the
sources and sinks. The data-flow diagram in Figure 4.7 is called a
level-1 diagram. If we should decide to decompose Processes 2.0,

129
3.0, or 4.0 in a similar manner, the DFDs we create would also be
called level-1 diagrams. In general, a level-n diagram is a DFD that
is generated from n nested decompositions from a level-0 diagram.

Figure 4.7: Level-1 for Hoosier Burger’s Food-Ordering System.

Processes 2.0 and 3.0 perform similar functions in that they both
use data input to update data stores. Because updating a data store is
a singular logical function, neither of these processes needs to be
decomposed further. We can, on the other hand, decompose Process
4.0, Produce Management Reports, into at least three sub-processes:
Access Goods Sold and Inventory Data, Aggregate Goods Sold and
Inventory Data, and Prepare Management Reports. The
decomposition of Process 4.0 is shown in the level-1 diagram of
Figure 4.9.

Each level-1, -2, or -n DFD represents one process on a level-(n-1)

DFD; each DFD should be on a separate page. As a rule of thumb,

130
no DFD should have more than about seven processes in it, because
the diagram would be too crowded and difficult to understand. To
continue with the decomposition of Hoosier Burger’s food-ordering
system, we examine each of the sub-processes identified in the two
level-1 diagrams, one for Process 1.0 and one for Process 4.0. To
further decompose any of these sub-processes, we would create a
level-2 diagram showing that decomposition. For example, if we
decided to further decompose Process 4.3 in figure 4.8, we would
create a diagram that looks something like Figure 4.9. Again, notice
how the sub-processes are labeled. Just as the labels for processes
must follow numbering rules for clear communication, process
names should also be clear, yet concise.

Figure 4.8: Level-1 Diagram for Hoosier Burger’s Food-Ordering System.

Examples include merge, sort, read, write, and print. Process names
should capture the essential action of the process in just a few
words yet be descriptive enough of the action of the process so that

131
anyone reading the name gets a good idea of what the process does.
Many times, students just learning DFDs will use the names of
people who perform the process or the department in which the
process is performed as the process name. This practice is not
especially useful, because we are more interested in the action the
process represents than the person performing it or the place where
it occurs.

Figure 4.9: Level-2 Diagram for Hoosier Burger’s Food-Ordering System.

4.4.2 Data Dictionary

In our data flow diagrams, we give names to data flows, processes

and data stores.

Although the names are descriptive of the data, they do not give
details. So following the DFD our interest is to build some
structured pace to keep details of the contents of data flows,
processes and data store. A data dictionary is a structured repository
of data. It is a set of rigorous definitions of all DFD data elements
and data structure. A data dictionary has many advantages. The
most obvious is documentation: it is a valuable reference in any
organization. Another advantage is improving analyst/ user

132
communication by establishing consistent definitions of various
elements, terms and procedures.

4.4.2.1 Modeling Logic with Decision Tables

Sometimes the logic of a process can become quite complex.

Research has shown, for example, that people become confused in
trying to interpret more than three nested IF statements. A decision
table is a diagram of process logic where the logic is reasonably
complicated. All of the possible choices and the conditions the
choices depend on are represented in tabular form, as illustrated in
the decision table in Figure 4.10.

The decision table in Figure 4.10 models the logic of a generic

payroll system. The three parts to the table include the condition
stubs, the action stubs, and the rules. The condition stubs contain
the various conditions that apply in the situation the table is
modeling. In Figure 4.10, two condition stubs correspond to
employee type and hours worked. Employee type has two values:
“S,” which stands for salaried, and “H,” which stands for hourly.
Hours worked has three values: less than 40, exactly 40, and more
than 40. The action stubs contain all the possible courses of action
that result from combining values of the condition stubs. Four
possible courses of action are indicated in this table: pay base
salary, calculate hourly wage, calculate overtime, and produce
Absence Report. You can see that not all actions are triggered by all
combinations of conditions. Instead, specific combinations trigger
specific actions. The part of the table that links conditions to actions
is the section that contains the rules.

133
To read the rules, start by reading the values of the conditions as
specified in the first column: Employee type is “S,” or salaried, and
hours worked are less than 40. When both of these conditions occur,
the payroll system is to pay the base salary. In the next column, the
values are “H” and “_40,” meaning an hourly worker who worked
fewer than 40 hours. In such a situation, the payroll system
calculates the hourly wage and makes an entry in the Absence
Report. Rule 3 addresses the situation when a salaried employee
works exactly 40 hours. The system pays the base salary, as was the
case for rule 1. For an hourly worker who has worked exactly 40
hours, rule 4 calculates the hourly wage. Rule 5 pays the base salary
for salaried employees who work more than 40 hours. Rule 5 has
the same action as rules 1 and 3 and governs behavior with regard
to salaried employees.

The number of hours worked does not affect the outcome for rules
1, 3, or 5. For these rules, hours worked is an indifferent
condition, in that its value does not affect the action taken. Rule 6
calculates hourly pay and overtime for an hourly worker who has
worked more than 40 hours.

Figure 4.10: Complete Decision Table for Payroll System Example.

134
Because of the indifferent condition for rules 1, 3, and 5, we can
reduce the number of rules by condensing rules 1, 3, and 5 into one
rule, as shown in Figure 4.11. The indifferent condition is
represented with a dash. Whereas we started with a decision table
with six rules, we now have a simpler table that conveys the same
information with only four rules.

In constructing these decision tables, we have actually followed a

set of basic procedures, as follows:

Figure 4.11: Reduced decision table for payroll system example.

1. Name the conditions and the values each condition can assume.
Determine all of the conditions that are relevant to your
problem, and then determine all of the values each condition can
take. For some conditions, the values will be simply “yes” or
“no” (called a limited entry). For others, such as the conditions
in Figures 4.10 and 4.11, the conditions may have more values
(called an extended entry).
2. Name all possible actions that can occur. The purpose of
creating decision tables is to determine the proper course of
action given a particular set of conditions.

135
3. List all possible rules. When you first create a decision table,
you have to create an exhaustive set of rules. Every possible
combination of conditions must be represented. It may turn out
that some of the resulting rules are redundant or make no sense,
but these determinations should be made only after you have
listed every rule so that no possibility is overlooked. To
determine the number of rules, multiply the number of values
for each condition by the number of values for every other
condition. In Figure 4.10, we have two conditions, one with two
values and one with three, so we need 2 _ 3, or 6, rules. If we
added a third condition with three values, we would need 2 _ 3
_ 3, or 18, rules.

When creating the table, alternate the values for the first
condition, as we did in Figure 4.10 for type of employee. For
the second condition, alternate the values but repeat the first
value for all values of the first condition, then repeat the second
value for all values of the first condition, and so on. You
essentially follow this procedure for all subsequent conditions.
Notice how we alternated the values of hours worked in Figure
4.10. We repeated “40” for both values of type of employee,
“S” and “H.” Then we repeated “40,” and then “40.”

Define the actions for each rule. Now that all possible rules
have been identified, provide an action for each rule. In our
example, we were able to figure out what each action should be
and whether all of the actions made sense. If an action doesn’t
make sense, you may want to create an “impossible” row in the
action stubs in the table to keep track of impossible actions.

136
4. Simplify the decision table. Make the decision table as simple as
possible by removing any rules with impossible actions. Consult
users on the rules where system actions aren’t clear, and either
decide on an action or remove the rule. Look for patterns in the
rules, especially for indifferent conditions. We were able to
reduce the number of rules in the payroll example from six to
four, but often greater reductions are possible.

Three things are distinctive about Figure 4.12. First, the values for
the third condition repeat, providing a distinctive pattern for relating
the values for all three conditions to one another. Every possible
rule is clearly provided in this table. Second, there are 12 rules. Two
values for the first condition (type of item) times two values for the
second condition (time of week) times three values for the third
condition (season of year) equals 12 possible rules. Third, the action
for nonperishable items is the same, regardless of the day of the
week or the time of year. For nonperishable goods, both time-
related conditions are indifferent. Collapsing the decision table
accordingly gives us the decision table in Figure 4.13. Now it
contains only 7 rules instead of 12.

4.4.2.2 Decision Trees

Decision trees are used when complex branching occurs in a

structured decision process. Trees are also useful when it is
essential to keep a string of decisions in a particular sequence.
Although the decision tree derives its name from natural trees,
decision trees are most often drawn on their side, with the root of
the tree on the left side of the paper; from there, the tree branches
out to the right.

137
This orientation allows the analyst to write on the branches to
describe conditions and actions. Unlike the decision tree used in
management science, the analyst’s tree does not contain
probabilities and outcomes. In systems analysis, trees are used
mainly for identifying and organizing conditions and actions in a
completely structured decision process.

Figure 4.12: Complete decision table for Hoosier Burger’s inventory reordering
system.

Figure 4.13: Reduced decision table for Hoosier Burger’s inventory reordering system

138
Drawing Decision Trees

It is useful to distinguish between conditions and actions when

drawing decision trees. This distinction is especially relevant when
conditions and actions take place over a period of time and their
sequence is important. For this purpose, use a square node to
indicate an action and a circle to represent a condition. Using
notation makes the decision tree more readable, as does numbering
the circles and squares sequentially. Think of a circle as signifying
IF, whereas the square means THEN.

When decision tables were discussed in an earlier section, a point-

of-sale example was used to determine the purchase approval
actions for a department store. Conditions included the amount of
the sale (under $50) and whether the customer paid by check or
credit card. The four actions possible were to: complete the sale
after verifying the signature; complete the sale with no signature
needed; call the supervisor for approval; or communicate
electronically with the bank for credit card authorization. Figure
4.14 illustrates how this example can be drawn as a decision tree.

Figure 4.14: Drawing a Decision Tree for a Department Store

139
The decision tree has three main advantages over a decision table.
First, it takes advantage of the sequential structure of decision tree
branches so that the order of checking conditions and executing
actions is immediately noticeable. Second, conditions and actions of
decision trees are found on some branches but not on others, which
contrasts with decision tables, in which they are all part of the same
table. Those conditions and actions that are critical are connected
directly to other conditions and actions, whereas those conditions
that do not matter are absent. In other words, the tree does not have
to be symmetrical. Third, compared with decision tables, decision
trees are more readily understood by others in the organization.
Consequently, they are more appropriate as a communication tool.

Avoiding problems with Decision Trees

Decision trees may not always be the best tolls for decision
analysis. A decision tree for a complex system with many
sequences of steps and combinations of conditions will be
unwieldy. A large number of branches with many paths through
them will could rather than aid analysis. The analyst may not be
able to determine which business policies or practices guide the
formulation of specific decisions. Where these problems arise,
decision tables should be considered.

4.5 Pros and Cons of Each Tool

Which tool is the best depends on a number of factors: the nature

and complexity of the problem the number of actions resulting from
the decision, and the ease of use. In reviewing the benefits and
limitations of each tool, we come to the following conclusion:

140
1. The primary strength of the DFD is its ability to represent data
flows. It may be used at high or low level of analysis and
provides good system documentation. However, the tool only
weakly shows input and output detail. The user often finds it
confusing initially.
2. The data dictionary helps the analyst simplify the structure for
meeting the data requirements of the system. It may be used at
high or low levels of analysis, but it does not provide
functional details, and it is not acceptable to many nontechnical
users.
3. Structured English is best used when the problem requires
sequences of actions with decisions.
4. Decision trees are sued to verify logic and in problems that
involve a few complex decisions resulting in limited number of
actions.
5. Decision trees and decision tables are best suited for dealing
with complex branching routines such as calculating discounts
or sales commissions or inventory control procedures.

The major contribution of structured analysis to the system

development life cycle is producing a definable and measurable
document – the structured specification. Other benefits include
increased user involvement, improved communication between user
and designer, reduction of total personnel time, and fewer “kinks”
during detailed design and implementation. The only drawback is
increased analyst and user time in the process. Overall, the benefits
outweigh the drawbacks, which make-structured analysis tools
viable alternatives in system development.

141
 Chapter 5
Structuring System Requirements
Conceptual Data Modeling

Learning Objectives

− Concisely define each of the following key data-modeling

terms: conceptual data model, entity-relationship
diagram, entity type, entity instance, attribute, candidate
key, multivalued attribute, relationship, degree,
cardinality, and associative entity.
− Ask the right kinds of questions to determine data
requirements for an information system.
− Draw an entity-relationship (E-R) diagram to represent
common business situations.
− Explain the role of conceptual data modeling in the
overall analysis and design of an information system.
− Select the best design strategy using both qualitative and
quantitative methods.
− Describe the use of a data dictionary and metadata.
− Explain how to balance entity relationship diagrams and
data flow diagrams.
− Describe the process of normalization.

142
Chapter 5: Structuring System Requirements:
Conceptual Data Modeling
5.1 Conceptual Data Modeling
A conceptual data model is a representation of organizational data.
The purpose of a conceptual data model is to show as many rules
about the meaning and interrelationships among data as possible,
independent of any database management system or other
implementation considerations. Entity-relationship data models are
commonly used diagrams that show how data are organized in an
information system. The main goal of conceptual data modeling is
to create accurate E-R diagrams. As a systems analyst, you typically
do conceptual data modeling at the same time as other requirements
analysis and structuring steps during systems analysis. You can use
methods such as interviewing, questionnaires, and JAD sessions to
collect information for conceptual data modeling. On larger systems
development teams, a subset of the project team concentrates on
data modeling while other team members focus attention on process
or logic modeling.

5.2 The Process of Conceptual Data Modeling

You typically begin conceptual data modeling by developing a data

model for the system being replaced, if a system exists. This phase
is essential for planning the conversion of the current files or
database into the database of the new system. Further, it is a good,
but not a perfect, starting point for your understanding of the new
system’s data requirements. Then, you build a new conceptual data
model that includes all of the data requirements for the new system.

143
Conceptual data modeling is only one kind of data modeling and
database design activity done throughout the systems development
process. Figure 5.1 shows the different kinds of data modeling and
database design that occur during the systems development life
cycle. The conceptual data-modeling methods are suitable for
various tasks in the planning and analysis phases. These phases of
the SDLC address issues of system scope, general requirements,
and content. An E-R data model evolves from project identification
and selection through analysis as it becomes more specific and is
validated by more detailed analysis of system needs.

In the design phase, the final E-R model developed in analysis is

matched with designs for systems inputs and outputs and is
translated into a format that enables physical data storage decisions.
During physical design, specific data storage architectures are
selected, and then, in implementation, files and databases are
defined as the system is coded.

Figure 5.1: Relationship between data modeling and SDLC

144
5.3 Deliverables and Outcomes

Most organizations today do conceptual data modeling using entity-

relationship modeling, which uses a special notation of rectangles,
diamonds, and lines to represent as much meaning about data as
possible. Thus, the primary deliverable from the conceptual data-
modeling step within the analysis phase is an entity-relationship (E-
R) diagram. A sample E-R diagram appears in Figure 5.2A.

This figure shows the major categories of data (rectangles in the

diagram) and the business relationships between them (lines
connecting rectangles). For example, Figure 5.2 describes that, for
the business represented, a SUPPLIER sometimes supplies ITEMs
to the company, and an ITEM is always supplied by one to four
SUPPLIERS. This diagram includes two names on each line, giving
you explicit language to read a relationship in each direction.

It is common that E-R diagrams are developed using CASE tools or

other smart drawing packages. These tools provide functions to
facilitate consistency of data models across different systems
development phases, reverse engineering an existing database
definition into an E-R diagram, and provide documentation of
objects on a diagram, one popular tool is Microsoft Visio.

5.4 The Entity Relationship Diagram

An entity relationship diagram (ERD) is a picture which shows the

information that is created, stored, and used by a business system.
An analyst can read an ERD to discover the individual pieces of
information in a system and how they are organized and related to
each other. On an ERD, similar kinds of information are listed

145
together and placed inside boxes called entities. Lines are drawn
between entities to represent relationships among the data, and
special symbols are added to the diagram to communicate high-
level business rules that need to be supported by the system.

Figure 5.2: Sample conceptual data model diagrams: Standard E-R notation

5.4.1 Reading an Entity Relationship Diagram

The analyst can answer these questions and more by using an entity
relationship diagram. We have included a partial ERD for the
chemical request scenario in Figure 5.3. First, we have organized
the data into three main categories: Lawn Chemical Applicator,
Chemical Request, and Chemical. The Lawn Chemical Applicator
data describe the employees who apply the lawn chemicals. The
Chemical Request data capture information about every chemical
request event, and the chemical data describe the chemicals used for
lawn care.

146
The lines connecting the three categories of information
communicate the relationships that the categories share. By reading
the relationship lines, the analyst understands that an LCA makes
chemicals requests and chemical requests involve chemicals.

The ERD also communicates high-level business rules. Business

rules are constraints or guidelines that are followed during the
operation of the system; they are rules such as “A payment can be
cash, check, debit card, credit card, coupon(s), or food stamps,” “A
sale is paid for by one or more payments,” or “A customer may
place many orders.” Over the course of a workday, people are
constantly applying business rules to do their jobs, and they know
the rules through training or knowing where to look them up. If a
situation arises where the rules are not known, workers may have to
refer to a policy guide or written procedure to determine the proper
business rules.

Figure 5.3: Chemical Request ERD

5.4.2 Elements of an Entity Relationship Diagram

There are three basic elements in the data modeling language

(entities, attributes, and relationships), each of which is represented
by a different graphic symbol. There are many different sets of
symbols that can be used on an ERD. No one set of symbols

147
dominates industry use, and none is necessarily better than another.
Table 5.1 summarizes the three basic elements of ERDs and the
symbols we will use.

Table 5.1: Data Modeling Symbol Set

Entity The entity is the basic building block for a data model. It is a
person, place, event, or thing about which data is collected—for
example, an employee, an order, or a product. An entity is depicted
by a rectangle, and it is described by a singular noun spelled in
capital letters. All entities have a name, a short description that
explains what they are, and an identifier that is the way to locate

148
information in the entity. In Figure 5.3, the entities are Lawn
Chemical Applicator, Chemical Request, and Chemical.

Entities represent something for which there exist multiple

instances, or occurrences. For example, John Smith and Susan
Jones could be instances of the customer entity (Figure 5.4). We
would expect the customer entity to stand for all of the people with
whom we have done business, and each of them would be an
instance in the customer entity. If there is just one instance, or
occurrence, of a person, place, event, or thing, then it should not be
included as an entity in the data model. For example, think a little
more broadly about the lawn care business’s information system.
Figure 5.3 focuses on just a small part of that information system.

Attribute An attribute is some type of information that is captured

about an entity. For example, last name, home address, and e-mail
address are all attributes of a customer. It is easy to come up with
hundreds of attributes for an entity (e.g., a customer has an eye
color, a favorite hobby, a religious affiliation), but only those that
actually will be used by a business process should be included in
the model. Attributes are nouns that are listed within an entity.
Usually, some form of the entity name is appended to the beginning
of each attribute to make it clear as to what entity it belongs (e.g.,
CUS_lastname, CUS_address). Without doing this, you can get
confused by multiple entities that have the same attributes—for
example, a customer and an employee both can have an attribute
called “lastname.” CUS_lastname and EMP_lastname are much
clearer ways to name attributes on the data model.

149
Relationship Relationships are associations between entities, and
they are shown by lines that connect the entities together. Every
relationship has a parent entity and a child entity, the parent being
the first entity in the relationship, and the child being the second.

Figure 5.4: Entities and Instances

In Figure 5.3, we have included words for both directions of the

relationship line; the top words are read from parent to child, and
the bottom words are read from child to parent. Notice that the LCA
entity is the parent entity in the LCA-Chemical Request relationship.
In addition, some CASE tools require that every relationship name
be unique on the ERD, so we select unique descriptive verbs for
each relationship.

Cardinality Relationships have two properties. First, a relationship

has cardinality, which is the ratio of parent instances to child
instances. To determine the cardinality for a relationship, we ask
ourselves: “How many instances of one entity are associated with
an instance of the other?” (Remember that an instance is one
occurrence of an entity, such as LCA John Brown or Chemical
Orthene™.) For example, an LCA makes how many chemical

150
requests? The cardinality for binary relationships (i.e., relationships
between two entities) is 1:1, 1:N, or M:N.

The 1:1 (read as “one to one”) relationship means that one instance
of the parent entity is associated with one instance of the child
entity. There are no examples of 1:1 relationships in Figure 5.3. So,
imagine for a moment that, as a reward, a company assigns a
specific reserved parking place to every employee who is honored
as an “employee of the month.” One reserved parking place is
assigned to each honored employee, and each honored employee is
assigned one reserved parking place. If we were to draw these two
entities, we would place a bar next to the Employee entity and a bar
next to the Reserved Parking Place entity. The cardinality is clearly
1:1 in this case, because each honored employee is assigned exactly
one reserved parking place, and a reserved parking place is assigned
to exactly one employee.

A third kind of relationship is the M:N (read as “many to many”)

relationship. In this case, many instances of a parent entity can
relate to many instances of a child entity. There are no M:N
relationships shown in Figure 5.3, but take a look at Figure 5.5.
This figure shows an early draft version of the Chemical Request
ERD. In this version, an M:N relationship does exist between LCA
and Chemical. As we can see, one LCA (parent entity) can request
many Chemicals (e.g., Orthene™, Roundup™, and 2, 4-D.), and a
Chemical (child entity) can be requested by many LCAs. M:N
relationships are depicted on an ERD by having crow’s feet at both
ends of the relationship line.

151
Modality Second, relationships have a modality of null or not null,
which refers to whether or not an instance of a child entity can exist
without a related instance in the parent entity. Basically, the
modality of a relationship indicates whether the child-entity
instance is required to participate in the relationship. It forces you to
ask questions like, Can you have a Chemical Request without a
Chemical? and Can you have a Chemical without a Chemical
Request? Modality is depicted by placing a zero on the relationship
line next to the parent entity if nulls are allowed. A bar is placed on
the relationship line next to the parent entity if nulls are not
allowed. In the two questions we just asked, the first answer is no:
you need a chemical to have a chemical request. You can, however,
have a chemical without having a chemical request for that
chemical. The modality is “not null,” or “required,” for the first
relationship in Figure 5.3. Notice, however, that a zero has been
placed on the relationship line between Chemical and Chemical
Request next to the Chemical Request entity. This means that
chemicals can exist in our system without requiring that a chemical
request exists. Said another way, instances of chemical requests are
optional for a chemical. The modality is “null.”

Figure 5.5: M:N Relationship

152
5.4.3 The Data Dictionary and Metadata

A CASE tool is used to help build ERDs. Every CASE tool has
something called a data dictionary, which quite literally is where
the analyst goes to define or look up information about the entities,
attributes, and relationships on the ERD. Even Visio 2010,
primarily known as a drawing tool, has some elementary data
dictionary capabilities. Figures 5.6, 5.7, and 5.8 illustrate common
data dictionary entries for an entity, an attribute, and a relationship;
notice the kinds of information the data dictionary captures about
each element. The information you see in the data dictionary is
called metadata, which, quite simply, is data about data. Metadata
is anything that describes an entity, attribute, or relationship, such
as entity names, attribute descriptions, and relationship cardinality,
and it is captured to help designers better understand the system that
they are building and to help users better understand the system that
they will use.

Figure 5.6: Data Dictionary Entity for Chemical Entity (in Visio 2010)

Metadata are stored in the data dictionary so that they can be shared
and accessed by developers and users throughout the SDLC. The

153
data dictionary allows you to record the standard pieces of
information about your elements in one place, and it makes that
information accessible to many parts of a project. For example, the
data attributes in a data model also appear on the process models as
elements of data stores and data flows, and on the user interface as
fields on an input screen. When you make a change in the data
dictionary, the change ripples to the relevant parts of the project that
are affected.

Figure 5.7: Data Dictionary Entry for Chemical Attributes (in Visio 2010)

Figure 5.8: Data Dictionary Entry for a Relationship (in Visio 2010)

154
5.5 Creating an Entity Relationship Diagram

Drawing an ERD is an iterative process of trial and revision. It

usually takes considerable practice. ERDs can become quite
complex, there are systems that have ERDs containing hundreds or
thousands of entities. The basic steps in building an ERD are these:
(1) Identify the entities, (2) add the appropriate attributes to each
entity, and then (3) draw relationships among entities to show how
they are associated with one another. First, we will describe the
three steps in creating ERDs, using the data model example from
Figure 5.3.

Step 1: Identify the Entities As we explained, the most popular

way to start an ERD is to first identify the entities for the model,
and their attributes. The entities should represent the major
categories of information that you need to store in your system. If
you begin your data model by using a use case, look at the major
inputs to the use case, the major outputs, and the information used
for the use case steps.

If the process models (e.g., DFDs) have been prepared, the easiest
way to start is with them: The data stores on the DFDs, the external
entities, and the data flows indicate the kinds of information that are
captured and flow through the system.

Step 2: Add Attributes and Assign Identifiers The information

that describes each entity becomes its attributes. It is likely that you
identified a few attributes if you read the chemical request system
use cases and paid attention to the information flows on their DFDs.
For example, an LCA has a name, and a chemical has a name and
description. Unfortunately, much of the information from the

155
process models and use cases does not include enough detail to
identify the exact attributes that should exist in each of our entities.

On a real project, there are a number of places you can go to figure

out what attributes belong in your entity. For one, you can check in
the CASE tool—often, an analyst will describe a process model
data flow in detail when he or she enters the data flow into the
CASE repository. For example, an analyst may create an entry for
the chemical request information data flow like the one shown in
Figure 5.9, which lists four data elements that make up the chemical
request information. The elements of the data flow should be added
to the ERD as attributes in your entities. A second approach is to
check the requirements definition. Often, there is a section under
functional requirements called data requirements. This section
describes the data needs for the system that were identified while
requirements were gathered. A final approach to identifying
attributes is to use requirements elicitatior techniques.

Figure 5.9: Elements of the New Chemical Request Data Flow

Step 3: Identify Relationships The last step in creating ERDs is to

determine how the entities are related to each other. Lines are
drawn between entities that have relationships, each relationship is
labeled, and cardinality and modality is assigned. The easiest
approach is to begin with one entity and determine all the entities
with which it shares relationships. In our example in Figure 5.5, we

156
can see that an LCA makes chemical requests, and a chemical is
included in a chemical request.

When you find a relationship to include on the model, you need to

determine its cardinality and modality. For cardinality, ask how
many instances of each entity participate in the relationship. You
know that an LCA can make many chemical requests, but a specific
chemical request is made by only one LCA. Therefore, we place a
crow’s foot next to the chemical request entity and a single bar
closest to the LCA entity. This suggests that there is a 1:N
relationship in which the LCA is the parent entity (the “1”) and the
chemical request is the child entity (the “many”).

5.6 Advanced Syntax

Now that we have created a data model according to the basic

syntax, we can move to several advanced concepts. We will explain
three special types of entities and show how they can be used in our
Chemical Request system.

Independent Entity An independent entity is an entity that can

exist without the help of another entity, such as Lawn Chemical
Applicator and Chemical. These entities all have identifiers that
were created from their own attributes. Attributes from other
entities were not needed to uniquely identify instances of these
entities. Independent entities are drawn as rectangles with a single
border line. When a relationship includes an independent child
entity, it is called a nonidentifying relationship. This name is
derived from the fact that parent entity attributes are not needed as
part of the child entity’s identifier.

157
Dependent Entity There are situations when a child entity does
require attributes from the parent entity to uniquely identify an
instance. In these cases, the child entity is called a dependent entity,
and its identifier consists of at least one attribute from the parent
entity. When relationships have a dependent child entity, they are
called identifying relationships. This name is derived from the fact
that parent entity attributes are needed as part of the child entity’s
identifier.

Intersection Entity A third kind of entity is the intersection entity.

It exists in order to capture some information about the relationship
between two other entities. Typically, intersection entities are added
to a data model to store information about two entities sharing an
M:N relationship. These entities are also called Associative Entities.
Think back to the M:N relationship between LCA and Chemical
shown in Figure 5.5. In that figure, one instance of an LCA could
request many Chemicals, and a Chemical can be requested by many
LCAs. A difficulty arises if we want to capture the date on which a
particular chemical was requested by a specific LCA. We cannot
put the date in the Chemical entity, because the Chemical is
requested by many LCAs. We also cannot put the date in the LCA
entity, because there are many Chemicals requested by the LCA.
Therefore, we need another entity that enables us to associate a
specific chemical with a specific LCA on a specific date.

The process of adding an intersection entity is called “resolving an

M:N relationship” because it eliminates the M:N relationship and its
associated problems from the data model. There are three steps
involved in adding an intersection entity.

158
Step 1: Remove the M:N relationship line and insert a new entity in
between the two existing ones. Step 2: Add two 1:N relationships to
the model. The two original entities should serve as the parent
entities for each 1:N, and the new intersection entity becomes the
child entity in both relationships. Step 3: Name the intersection
entity. Intersection entities are often named by a concatenation of
the two entities that created it (e.g., Chemical Request), making its
meaning clear. Alternatively, the entity can be given another
appropriate name. Figure 5.10 shows the M:N LCA-Chemical
relationship and how it was resolved with the use of an intersection
entity.

Figure 5.10: Resolving an M:N Relationship

Are intersection entities dependent or independent? Actually, it

depends. Sometimes an intersection entity has a logical identifier
that can uniquely identify its instances. For example, an intersection
entity between a student and a course (a student may take many
courses and a course is taken by many students) may be called a

159
transcript. If transcripts have unique transcript numbers, then the
entity would be considered independent. In contrast, the Chemical
Request intersection entity in Figure 5.10 requires the identifiers
from both LCA and Chemical for an instance to be uniquely
identified. Thus, Chemical Request is a dependent entity.

5.7 Validating an ERD

Creating ERDs is pretty tough. It takes a lot of experience to draw

ERDs well, and there are not many black-and-white rules to help
guide you. Luckily, there are some general design guidelines that
you can keep in mind as you build ERDs, and once the ERDs are
drawn, you can use a technique called normalization to validate that
your models are well formed.

Another technique is to check your ERD against your process

models to make sure that both models balance each other.

5.8 Normalization

Once you have created your ERD, there is a technique called

normalization that can help analysts validate the models that they
have drawn. It is a process whereby a series of rules are applied to a
logical data model or a file to determine how well formed it is.
Normalization rules help analysts identify entities that are not
represented correctly in a logical data model, or entities that can be
broken out from a file. The result of the normalization process is
that the data attributes are arranged to form stable, yet flexible,
relations for the data model. In the next section, we describe three
normalization rules that are applied regularly in practice.

160
5.8.1 Normalizing the Data Model

In this section, we describe the rules of normalization that help

analysts improve the quality of the data model. These rules help
identify entities that are not represented correctly in the logical data
model and entities that can be broken out from a file. The result of
the normalization process is that the data attributes are arranged to
form stable yet flexible relations for the data model. Typically,
three rules of normalization are applied regularly in practice. (See
Figure 5.11) We describe these rules and illustrate them with an
example here.

First Normal Form A logical data model is in first normal form

(1NF) if it does not contain attributes that have repeating values for
a single instance of an entity. Often, this problem is called repeating
attributes, or repeating groups. Every attribute in an entity should
have only one value per instance for the model to “pass”

1NF. Let’s pretend that the Tune Source project team was given the
layout for the CD purchase file that is used by the existing CD sales
system. The team members are anxious to incorporate the data from
this file into their own system, and they decide to put the file into
third normal form to make the information easier to understand and,
ultimately, easier for them to add to the data model for the new
Digital Music Download system.

The second violation of 1NF may not be as readily noticed. The

music preferences attribute includes the kinds of music the
customer prefers (e.g., classical, rock, jazz). The fact that the
attribute name is plural is a clue that many different preferences
may be captured for each instance of a sale and that music

161
preferences is a repeating attribute. This can be resolved by creating
a new entity that contains preference information, and a relationship
is added between CD purchase and preference. The new
relationship is M:N, because a CD purchase can be associated with
many music preferences and a music preference can be found on
many CD purchases. See Figure 5.12 for the current data model in
1NF.

Figure 5.11: Normalization Steps

Second Normal Form Second normal form (2NF) requires first

that the data model is in 1NF and second that the data model
leads to entities containing attributes that are dependent on the
whole identifier. This means that the value of all attributes that
serve as identifier can determine the value for all of the other

162
attributes for an instance in an entity. Sometimes, nonidentifier
attributes are dependent on only part of the identifier (i.e.,
partial dependency), and these attributes belong in another
entity. Figure 5.13 shows the CD purchase data model placed in
2NF. Notice that originally, the CD purchase entity had three
attributes that were used as identifiers: purchase date, customer
last name, and customer first name. The problem was that some
of the attributes were dependent on the customer last name and
first name, but had no dependency on purchase date. These
attributes were those that describe a customer: phone, address,
e-mail, and birth date. To resolve this problem, a new entity
called customer was created, and the customer attributes were
moved into the new entity. A 1:N relationship exists between
customer and CD purchase because a customer can purchase
many CDs, but a CD purchase is associated with only one
customer.

Figure 5.12: First Normal Form

163
 Figure 5.13: First Normal Form with M:N Relationships Resolved

Third Normal Form Third normal form (3NF) occurs when a

model is in both 1NF and 2NF and when, in the resulting
entities, none of the attributes is dependent on a nonidentifier
attribute (i.e., transitive dependency). A violation of 3NF can be
found in the CD Purchase entity in Figure 5.14.

Figure 5.14: Second Normal Form

164
The 1:1 relationship assumes that there is one payment for every
CD purchase, and every CD purchase has one payment. Also, a
payment is required for very CD purchase, and every CD
purchase requires a payment. Third normal form also addresses
issues of derived, or calculated, attributes. By definition,
derived attributes can be calculated from other attributes and do
not need to be stored in the data model. As an example, a
person’s age would not be stored as an attribute if birthdate
were stored, because, by knowing the birthdate and current date,
we can always calculate the age. In order to verify that no
purchased CDs are omitted from the entire purchase, the total
due is stored as an attribute of CD purchase, and the sum of the
individual CD prices is also computed to ensure that they match.
We will leave the total due in the data model and show the final
ERD in 3NF in Figure 5.15.

Figure 5.15: Third Normal Form

165
 Chapter 6
System Design

Learning Objectives
− Describe the design objectives and constraints.
− Explain how operational, performance, security,
cultural, and political requirements affect the
architecture design.
− Create an architectural design.
− Create a hardware and software specification.
− Describe several fundamental user interface design
principles.
− Explain the process of user interface design.
− Explain how to design the user interface standards.
− Be able to design a user interface.
− Apply the general guidelines for formatting input and
output
− Describe and apply the general guidelines for interface
design, including guidelines for layout design,
structuring data-entry fields, providing feedback, and
system help.

166
Chapter 6: System Design
The design phase decides how the new system will operate. Many
activities will be involved as the development team develops the
system requirements. The purpose of the design phase is to decide
how to build it. System design is the determination of the overall
system architecture—consisting of a set of physical processing
components, hardware, software, people, and the communication
among them—that will satisfy the system’s essential requirements.

6.1 Architecture Design

An important step of the design phase is the creation of the
architecture design, the plan for how the information system
components will be distributed across multiple computers and what
hardware, operating system software, and application software will
be used on each computer (e.g., Windows or Linux operating
system software).
Every information system involves three main functions: data
storage and access methods, application programs to handle the
processing logic, and an interface that allows users to interact with
the system. Depending on the architecture, the three functions are
performed on a server, on a client, or are divided between the server
and the client. As you plan the system design, you must determine
where the functions will be carried out and the advantages and
disadvantages of each design approach. This section discusses
server and client characteristics and how each design alternative
handles system functions.
The major architectural components of any system are the software
and the hardware. The major software components of the system

167
being developed have to be identified and then allocated to the
various hardware components on which the system will operate.
Each of these components can be combined in a variety of different
ways.

6.1.1 Client/Server Architecture

Many business applications are characterized by three distinct
layers of processing: presentation and display, application logic,
and data management. Without distribution of processing, all the
programming logic resides in one computer, which is typical of
traditional mainframe and midrange systems as well as standalone
microcomputers and workstations. By connecting machines
together, cooperative processing is made possible. Client/server
computing is a form of cooperative processing.
− Technical Developments
Client/server technology is possible because of many advances in
technology including the increasingly powerful processors available
at ever-decreasing cost, the different graphical user interface (GUI)
which have been developed, each layered on top of a base operating
system. moreover, the inexpensive disk storage in parallel with the
decrease in magnetic disk storage cost are significant improvements
in disk access speeds and throughput rates, local area networks
(LANs), primarily Ethernet and Token Ring are becoming
widespread because of standardization of differing wiring schemes
(in addition to the original coaxial standard), the availability of less
expensive and more powerful network interface boards, and the
development of Network Operating System. The wide area
networks (WANs) that provide high-bandwidth digital transmission

168
at affordable costs. T1 lines, together with intelligent bridges and
routers, allow the linking of multiple LANs into true, enterprise
wide networks. Relational data bases with improved performance
and capability. And finally the structured query language (SQL) has
become established as a standard language for data base access.
− Benefits of Client/Server Computing
Client/server computing meets the challenges of the business
environment by providing a middle ground between the centrally
controlled mainframe computing environment and the completely
distributed environment. In the client/server architecture, the key
assets—corporate data and associated business rules—can be
controlled and managed centrally and users can have access to,
manipulate, and present the data locally. Additional benefits are
associated with client/server computing. Optimization By dividing
and distributing functions, systems resources can also be selected
and tuned for specific processing requirements.

6.1.2 Creating an Architecture Design

Creating an architecture design includes considering the
nonfunctional requirements. Then the nonfunctional requirements
and the architecture design are used to develop the hardware and
software specification.
In many cases, the technical environment requirements as driven by
the business requirements may simply define the application
architecture. In this case, the choice is simple: Business
requirements dominate other considerations. For example, the
business requirements may specify that the system needs to work
over the Web, using the customer’s Web browser. In this case, the

169
application architecture must be thin client–server. Such business
requirements most likely occur in systems designed to support
external customers. Internal systems may also impose business
requirements, but usually they are not as restrictive.

6.1.2.1 Non-Functional Requirements

Operational requirements describe how the system will run and
communicate with operations personnel. Preferences from
requirements should be distinguished. Requirements are based on
business needs. Preferences are not. If, for example, the user
expresses a desire for sub-second response but does not have a
business-related reason for needing it, that desire is a preference.
− Security
Security refers to the need to control access to the data. This
includes controlling who may view and alter application data.
various types of users need different levels of access - Internal
users, contractors, outsiders, partners, etc. Resources also have
different classification levels- confidential, internal use only,
private, public, etc. moreover, diverse identity data must be kept on
different types of users - credentials, personal data, contact
information, work-related data, digital certificates, cognitive
passwords, etc.
− Reliability
Reliability is the probability that the system will be able to process
all work correctly and completely without being aborted. More
specific, reliability is the probability that a product or part will
operate properly for a specified period of time (design life) under
the design operating conditions (such as temperature, volt, etc.)

170
without failure. In other words, reliability may be used as a measure
of the system’s success in providing its function properly.
Reliability is one of the quality characteristics that consumers
require from the manufacturer of products.
− Recoverability
Recoverability refers to the ability to restore your deployment to the
point at which a failure occurred. The ability to recover quickly
from a system failure or disaster depends not only on having current
backups of your data, but also on having a predefined plan for
recovering that data on new hardware.
− Availability
System availability is the time when the application must be
available for use. Availability is the ratio of time a system or
component is functional to the total time it is required or expected
to function. This can be expressed as a direct proportion (for
example, 9/10 or 0.9) or as a percentage (for example, 90%). It can
also be expressed in terms of average downtime per week, month or
year or as total downtime for a given week, month or year.
Sometimes availability is expressed in qualitative terms, indicating
the extent to which a system can continue to work when a
significant component or set of components goes down. Required
system availability is used in determining when maintenance may
be performed.
− Fault Tolerance
Fault tolerance is the ability to remain partially operational during a
failure. Fault-tolerant technology is a capability of a computer
system, electronic system or network to deliver uninterrupted
service, despite one or more of its components failing. Fault

171
tolerance also resolves potential service interruptions related to
software or logic errors. The purpose is to prevent catastrophic
failure that could result from a single point of failure. For most
applications, there are no fault tolerance requirements. When a
portion of the application is unavailable, there is no need to be able
to use the remainder of the application.
− General Performance
Other requirements could be considered such as response time for
queries and updates, Throughput, and Expected rate of user activity
(for example, number of transactions per hour, day, or month).
Specific performance requirements related to a specific functional
requirement should be listed with that functional requirement.
− Capacity
List of the required capacities and expected volumes of data in
business terms should be highlighted. For example, the number of
cases about which the application will have to store data. For
example, “The system shall be able to process a projected volume
of 600 applications for naturalization per month.”
− Data Retention

The length of time the data must be retained could also be

determined. For example, “Information about an application for
naturalization shall be retained in immediately accessible form for 3
years after receipt of the application.”

6.1.2.2 Hardware and Software Specification

The design phase is also the time to begin selecting and acquiring
the hardware and software that will be needed for the future system.
In many cases, the new system will simply run on the existing

172
equipment in the organization. Other times, however, new hardware
and software (usually, for servers) must be purchased. The
hardware and software specification is a document that describes
what hardware and software are needed to support the application.
There are several steps involved in creating the document. Table 6.1
shows a sample hardware and software specification.
Standard Standard
Standard Standard
Component Application Database
Client Web Server
Server Server
Operating − Windows − Linux − Linux − Linux
System − Mozilla

− Real Audio − Apache − Java − Oracle

Special
− Adobe
Software Acrobat
Reader
− 250-GB − 500-GB − 160-GB disk − 1-TB disk
disk drive disk drive drive drive
− Intel®- − Dual-core − Quad-core − RAID
CoreTM i3- Xeon Xeon
Hardware 2100 dual
core
processor
− 19-inch
LCD
Monito
− Always-on − Dual 100 − Dual 100 − Dual 100
Broadband, Mbps Mbps Mbps
preferred Ethernet Ethernet Ethernet
− Dial-up at
Network 56 Kbps,
possible
with some
performance
loss

Table 6.1: Sample Hardware and Software Specification

First, you will need to define the software that will run on each
component. This usually starts with the operating system (e.g.,
Windows, Linux) and includes any special purpose software on the

173
client and servers (e.g., Oracle database). Here, you should consider
any additional costs such as technical training, maintenance,
extended warranties, and licensing agreements (e.g., a site license
for a software package). Again, the needs that you list are
influenced by decisions that are made in the other design phase
activities.
Next, you must create a list of the hardware needed to support the
future system. In general, the list can include such things as
database servers, network servers, peripheral devices (e.g., printers,
scanners), backup devices, storage components, and any other
hardware component needed to support an application. At this time,
you also should note the quantity of each item that will be needed.

6.2 Designing the Human Interface

Designing a user interface may seem a simple and side aspect of the
development of an entire application. In fact it is, perhaps, the most
important part of the development of an application. When
designing a user interface you always have to be aware that you
create a product that is used by other people. Often, designers are
too busy to create an award-winning, cool product without being
aware that the product may be a complete mystery and unusable for
the end users

6.2.1 General User Interface Design Principles

− Strive for consistency
Inconsistencies force people to spend extra time trying to figure out
how to find the answers to questions they have. This rule is the
most frequently violated one. Consistent sequences of actions
should be required in similar situations; identical terminology

174
should be used in prompts, menus, and help screens; and consistent
color, layout capitalization, fonts.
− Cater to universal usability
Recognize the needs of diverse users and design for plasticity,
facilitating transformation of content. Novice-expert differences,
age ranges, disabilities, and technology diversity each enrich the
spectrum of requirements that guides design. Adding features for
novices, such as explanations, and features for experts, such as
shortcuts and faster pacing, can enrich the interface design and
improve perceived system quality.
− Offer informative feedback
For every user action, there should be system feedback. For
frequent and minor actions, the response can be modest, whereas
for infrequent and major actions, the response should be more
substantial. Visual presentation of the objects of interest provides a
convenient environment for showing changes explicitly. Sequences
of actions should be organized into groups with a beginning,
middle, and end.
− Prevent errors
As much as possible, design the system such that users cannot make
serious errors; for example, gray out menu items that are not
appropriate and do not allow alphabetic characters in numeric entry
fields. If a user makes an error, the interface should detect the error
and offer simple, constructive, and specific instructions for
recovery. For example, users should not have to retype an entire
name-address form if they enter an invalid zip code, but rather
should be guided to repair only the faulty part. Erroneous actions

175
should leave the system state unchanged, or the interface should
give instructions about restoring the state.
− Permit easy reversal of actions
As much as possible, actions should be reversible. This feature
relieves anxiety, since the user knows that errors can be undone,
thus encouraging exploration of unfamiliar options. The units of
reversibility may be a single action, a data-entry task, or a complete
group of actions, such as entry of a name and address block.
− Support internal locus of control
Experienced operators strongly desire the sense that they are in
charge of the interface and that the interface responds to their
actions. Surprising interface actions, tedious sequences of data
entries, inability to obtain or difficulty in obtaining necessary
information, and inability to produce the action desired all build
anxiety and dissatisfaction.
− Reduce short-term memory load
The limitation of human information processing in short-term
memory (the rule of thumb is that humans can remember "seven
plus or minus two chunks" of information) requires that displays be
kept simple, multiple-page displays be consolidated, window-
motion frequency be reduced, and sufficient training time be
allotted for codes, and sequences of actions. Where appropriate,
online access to command-syntax forms, abbreviations, codes, and
other information should be provided.
− Recoverability
The system should provide some resilience to user errors and allow
the user to recover from errors. This might include an UNDO
facility, confirmation of destructive actions, 'soft' deletes, etc.

176
Additionally, there is one basic principle which counts for all User
Interface designers: Keep your message as simple as possible. Use
only the amount of text and graphics as is absolutely necessary to
get your point across.

6.2.2 User Interface Design Process

User interface design is a five-step process that is iterative—
analysts often move back and forth between steps rather than
proceed sequentially from step 1 to step 5 (Figure 6.2).

Figure 6.2: User Interface Design Process

First, the analysts examine the DFDs and use cases developed in
the analysis phase and interview users to develop use scenarios that
describe users’ commonly employed patterns of actions so that the
interface can enable users to quickly and smoothly perform these
scenarios.
Second, the analysts develop the interface structure diagram (ISD)
that defines the basic structure of the interface. This diagram (or set
of diagrams) shows all the interfaces (e.g., screens, forms, and
reports) in the system and how they are connected. Third, the

177
analysts design interface standards, which are the basic design
elements on which interfaces in the system are based. Fourth, the
analysts create an interface design prototype for each of the
individual interfaces in the system, such as navigation controls,
input screens, output screens, forms (including preprinted paper
forms), and reports. Finally, the individual interfaces are subjected
to interface evaluation to determine whether they are satisfactory
and how they can be improved.

6.2.3 Navigation Design

Two problems must be addressed in interactive systems design,
how information from the user should be provided to the computer
system, and how information from the computer system should be
presented to the user. Different Interaction styles are introduced as
illustrated in table 6.2.
Manipulation Main Main Disadvantages Application
Type Advantages Examples
Direct − Fast and − May be hard to − Video games
intuitive implement − CAD systems
interaction − Only suitable where
− Easy to learn there is a visual
metaphor for tasks
and objects
Menu − Avoids user − Slow for − Most general
error experienced users purpose systems
− Little typing − Can become
required complex if many
options
Form Fill-in − Simple data − Takes up a lot of − Stock control,
entry screen space personal loan
− Easy to learn processing
Command − Powerful and − Hard to learn − Operating
Language flexible − Poor error systems, Library
management information
retrieval systems

178
Manipulation Main Main Disadvantages Application
Type Advantages Examples
Natural − Accessible to − Requires more − Timetable
Language casual users typing systems
− Easily − Natural language − WWW
extended understanding information
systems are retrieval systems
unreliable
Table 6.2: Interaction styles

6.2.5 Designing Input and output

System inputs and outputs—forms and reports—are produced at the
end of the systems analysis phase of the SDLC. A form is a
business document containing some predefined data and often
includes some areas where additional data are to be filled in. Most
forms have a stylized format and are usually not in simple rows and
columns. Examples of business forms are product order forms,
employment applications, and class registration sheets.
Traditionally, forms have been displayed on a paper medium, but
today, video display technology allows us to duplicate the layout of
almost any printed form, including an organizational logo or any
graphic, on a video display terminal. Forms on a video display may
be used for data display or data entry.
A report is a business document containing only predefined data; it
is a passive document used solely for reading or viewing. Examples
of reports are invoices, weekly sales summaries by region and
salesperson, and a pie chart of population by age categories. We
usually think of a report as printed on paper, but it may be printed to
a computer file, a visual display screen, or some other medium such
as microfilm. Often a report has rows and columns of data, but a
report may consist of any format—for example, mailing labels.

179
Frequently, the differences between a form and a report are subtle.
A report is only for reading and often contains data about multiple
unrelated records in a computer file. On the other hand, a form
typically contains data from only one record or is, at least, based on
one record, such as data about one customer, one order, or one
student. The guidelines for the design of forms and reports are
similar.
A wide variety of information can be provided to users of
information systems, ranging from text to video to audio. As
technology continues to evolve, a greater variety of data types will
be used. A definitive set of rules for delivering every type of
information to users has yet to be defined because these rules are
continuously evolving along with the rapid changes in technology.
Research conducted by computer scientists on human-computer
interaction has provided numerous general guidelines for formatting
information. Many of these guidelines undoubtedly will apply to the
formatting of all evolving information types on yet-to-be-
determined devices. Keep in mind that designing usable forms and
reports requires your active interaction with users. If this single and
fundamental activity occurs, you will likely create effective designs.
There are six basic principles of good input/output design, which
can be summarized as U2H2C2:

− User Involvement

The users interact with a system through the interfaces

(input/output). To increase the satisfaction of the user, the analyst
should consult the user throughout the design of the user interfaces.

180
The primary goal of input/output design is to assist the user in their
tasks. If the design is good, the users perform their task easily and
make few mistakes. If the design is bad, the users grumble and
make mistakes. Good design enhances user productivity.

− User First, Computers Last

The design choices must be made to create the best design for the
users rather than the easiest design for the programmers to code.
The interfaces must be formulated to assist the user, but if the
system performance will be severely degraded, compromises may
be necessary.

− Minimize Human Efforts

Whenever possible, the interaction of the human with the computer

should be minimized. The number of keystrokes by the user should
be minimal. Avoid manual data entry to minimize data error. Do not
key in data that can be retrieved from the file or database. Do not
ask for a value that can be computed by the system. For example,
using the zip code to identify a client’s city and state is more
appropriate than having the user enter the city and state values.

− Remember Human Limitations

Humans are prone to errors, and hence checks should be placed in

the system to prevent the entry of erroneous data. Screens should
not be cluttered with too much information that can overwhelm the
user. Information carried over to more than three screens should be
avoided. This is to reduce human empowerment of short-term
memory and pattern recognition. The system menu and the screens

181
should be linked such that screens can be called up without going
through multiple screens.

− Convention Standardization

If other systems of an organization have some standard that the

users are used to, implement the same to the new system.
Standardization assists the user by eliminating the need to
remember many operating procedures. For example, if function F1
is used to display help features of other information systems, adopt
the same for the new system.

− Cultural Bias

Design of input and output should be consistent with the natural

human expectation. Screens, forms, and reports should follow data
representation from left to right and then from top to bottom.
Computer messages such as error messages should be use common
terms used in the work area rather than expressions preferred by a
particular user or programmer.

182
 Chapter 7
Systems Implementation and Operation

Learning Objectives

− Be familiar with the system construction process.

− Explain different types of tests and when to use them.
− Describe how to develop user documentation.
− Describe the process of coding, testing, and changeover an
organizational information system.
− Understand the changeover strategies
− Explain why systems implementation sometimes fails.
− Explain and contrast the types of maintenance.

183
Chapter 7: Systems Implementation and
Operation
As the implementation phase begins, foremost on people’s minds is
construction of the new system. A major component of building the
system is writing programs. In fact, some people mistakenly believe
that programming is the focal point of systems development.
However, doing a good, thorough job on the analysis and design
phases is essential to a smooth and successful implementation
phase. Developing the system’s software (writing programs) can be
the largest single component of any systems development project in
terms of both time and cost. It is generally also the best understood
component and may offer the fewest problems of all the aspects of
the SDLC
The implementation phase consists of developing and testing the
system’s software, documentation, and new operating procedures.
Additional issues that are essential to a successful system
implementation is also discussed, including installation of the new
system, selection of the most suitable conversion approach,
preparing the organization and the users to adapt to the new system,
and ensuring that the system is supported after it is put into
production.
Systems implementation and operation is made up of seven major
activities:
− Coding
− Testing
− Change over
− Maintenance
− Documentation
− Training

184
The purpose of these steps is to convert the final physical system
specifications into working and reliable software and hardware,
document the work that has been done, and provide help for current
and future users and caretakers of the system. Usage of the system
leads to changes, so during maintenance, users and others submit
maintenance requests; requests are transformed into specific
changes to the system; the system is redesigned to accept the
changes; and the changes are implemented.

7.1 The Processes of Coding

Coding is the process through which the physical design
specifications created by the design team are turned into working
computer code by the programming team. Depending on the size
and complexity of the system, coding can be an involved, intensive
activity.
Once coding has begun, the testing process can begin and proceed
in parallel. As each program module is produced, it can be tested
individually, then as part of a larger program, and then as part of a
larger system. We should emphasize that although testing is done
during implementation, you must begin planning for testing earlier
in the project. Planning involves determining what needs to be
tested and collecting test data. These activities are often done during
the analysis phase, because testing requirements are related to
system requirements.

7.2 System Testing

Testing is involved in every stage of software life cycle, but the
testing done at each level of software development is different in
nature and has different objectives. Unit Testing is done at the

185
lowest level. It tests the basic unit of software, which is the smallest
testable piece of software, and is often called “unit”, “module”, or
“component” interchangeably. Integration Testing is performed
when two or more tested units are combined into a larger structure.
The test is often done on both the interfaces between the
components and the larger structure being constructed, if its quality
property cannot be assessed from its components. System Testing
tends to affirm the end-to-end quality of the entire system. System
test is often based on the functional/requirement specification of the
system. Non-functional quality attributes, such as reliability,
security, and maintainability, are also checked. Acceptance Testing
is done when the completed system is handed over from the
developers to the customers or users. The purpose of acceptance
testing is rather to give confidence that the system is working than
to find errors.

7.2.1 Static Analysis and Dynamic Analysis

Based on whether the actual execution of software under evaluation
is needed or not, there are two major categories of quality assurance
activities: Static Analysis focuses on the range of methods that are
used to determine or estimate software quality without reference to
actual executions. Techniques in this area include code inspection,
program analysis, symbolic analysis, and model checking. Dynamic
Analysis deals with specific methods for ascertaining and/or
approximating software quality through actual executions, i.e., with
real data and under real (or simulated) circumstances. Techniques in
this area include synthesis of inputs, the use of structurally dictated
testing procedures, and the automation of testing environment
generation. Generally the static and dynamic methods are

186
sometimes inseparable, but can almost always discussed separately.
In this paper, we mean dynamic analysis when we say testing, since
most of the testing activities (thus all the techniques studied in this
paper) require the execution of the software.

7.2.2 Functional Technique and Structural Technique

Testing involves the configuration of proper inputs, execution of the
software over the input, and the analysis of the output. The
“Software Configuration” includes requirements specification,
design specification, source code, and so on. The “Test
Configuration” includes test cases, test plan and procedures, and
testing tools. Based on the testing information flow, a testing
technique specifies the strategy used in testing to select input test
cases and analyze test results. Different techniques reveal different
quality aspects of a software system, and there are two major
categories of testing techniques, functional and structural.
Functional Testing: the software program or system under test is
viewed as a “black box”. The selection of test cases for functional
testing is based on the requirement or design specification of the
software entity under test. Examples of expected results, sometimes
are called test oracles, include 3 requirement/design specifications,
hand calculated values, and simulated results. Functional testing
emphasizes on the external behavior of the software entity.
Structural Testing: the software entity is viewed as a “white box”.
The selection of test cases is based on the implementation of the
software entity. The goal of selecting such test cases is to cause the
execution of specific spots in the software entity, such as specific
statements, program branches or paths. The expected results are
evaluated on a set of coverage criteria. Examples of coverage

187
criteria include path coverage, branch coverage, and data-flow
coverage. Structural testing emphasizes on the internal structure of
the software entity.

7.3 System Changeover

As name suggest it is the process of changing the old information
system. System changeover is the process of putting the new
information system online and retiring the old system. The four
system changeover approaches description, advantages,
disadvantages and the implications of using each of these
approaches are as follows:
− Direct Cutover
In simple words direct cutover approach is a direct approach where
old system is cut and over write by new system. The direct cutover
approach causes the changeover from the old system to the new
system to occur immediately when the new system becomes
operational. This is a least expensive method among all four but
involves high risk of data loss. With the direct cutover method,
company cannot revert to the old system as a backup option. Direct
cutover involves more risks of total system failure and if there is a
system failure then it will be difficult to store information and this
will result in improper storage of data.
But if there is lack of funds, this approach will be a possible option
because of its low cost application among all four approaches.
− Parallel Operation
Parallel word is used when two things run simultaneously, so here
two operations run simultaneously. The parallel operation
changeover method requires that both the old and the new
information systems operate fully for a specified period. When

188
users, management, and the IT group are satisfied that the new
system operates correctly, the old system is terminate. Parallel
operation is having very low amount of risk as if the new system
does not work correctly, the company can use the old system as a
backup. But it is the most costly changeover method. Data have to
be input in both systems. Users must work in both system and result
in increased workload and processing delays. Because of its high
cost it would not be a suitable approach even though it’s the safest
approach as it is having back up.
− Pilot Operation
The pilot operation changeover method involves implementing the
complete new system at a selected location of the company. The
group that uses the new system first is called the pilot site. The old
system continues to operate for the entire organization including the
pilot site. After the system proves successful at the pilot site, it is
implemented in the rest of the organization, usually using direct
cutover method. Pilot operation is combination of parallel operation
and direct cutover methods. Pilot site assure the working of new
system and reduces the risk of system failure. This is also less
expensive than the parallel operation as only at one section both
system works for limited period.
− Phased Operation
Phased operation works in different phases or stages.
Implementation of new system in modules or stages is phased
operation. This is also a combination of direct cutover and parallel
similar to pilot operation. But in this approach the entire system is
provided to some users instead a part of system to all users. In
phase operation the risk of errors or failures is limited to the

189
implemented module only and also phased operation is less
expensive than the full parallel operation. But in some cases, phased
operation can cost more than a pilot approach where the system
involves a large number of separate phases. In case of the
involvement of so many phases it would be difficult and costly to
apply phased operation approach.

7.4 Systems Maintenance

Once a system is delivered, the analyst’s role changes from
development to support. Maintenance is the correction of errors and
omissions that were not caught during the testing and delivery
phases. Improvements are the additions of new capabilities to the
system. They may arise due to the reasons such as:
− Additional features
Request for additional features such as new reports and interfaces,
improved screen or report layouts, and so on.
− Change of business over time
Software must be modified to encompass changes as new
government rules need to be implemented.
− Hardware and software change
A system that uses older technology may be modified to use the
capabilities of newer technology. The phases and steps defined in
the SDLC will be discussed in detail throughout the semester.
The last part of the system development life cycle is system
maintenance which is actually the implementation of the post-
implementation plan. When systems are installed, they are generally
used for long periods. This period of use brings with it the need to
continually maintain the system. Maintenance accounts for 50-80%

190
if the total system development. Maintenance is not as rewarding
and exciting as developing systems.
Maintenance can be classified as:
− Corrective
It means repairing, processing or performance failures or making
changes because of previously uncorrected problems.
− Adaptive
It means changing the program functions.
− Perfective
It means enhancing the performance or modifying the programs to
respond to the users’ additional or changing needs. The greatest
amount of time is spent on perfective. Maintenance covers a wide
range of activities including correcting coding and design errors,
updating documentation and test data.
− Preventive
Its mission is to maintain a level of certain service on equipment,
programming the interventions of their vulnerabilities in the most
opportune time. It is used to be a systematic character, that is, the
equipment is inspected even if it has not given any symptoms of
having a problem.

7.5 System documents

There are five types of documentation:
− Program
Before a program is developed, the systems analyst should provide
the programmer with the required documentation. The logic in
some programs is best described by a flowchart. Sometimes
decision tables are also useful. The main responsibility in

191
documentation is to provide enough information to enable future
programmers to understand and make necessary changes. Since
programmers do not retain their jobs for a very long time, it
becomes necessary that there be some kind of documentation that
will be useful for the new programmers who are assigned the same
system.
− Operations
For smooth running of the system, the data entry operator must
have complete knowledge about the job. The instructions must be in
a form that is easily accessible to the console operator and written
in simple and understandable style.
− User
System users should have a manual that describes everything the
users must know to do their job correctly. Users require two general
type of information: complete details to handle everything the
system processes, and an overall picture of the system.
− Management
The documentation required by management differs a lot from that
required by users. The manual should enable management to
perform three functions: (a) Evaluate progress on the development
of system. (b) Monitor the existing systems. (c) Understand the
objectives and methods of the new and existing system.
− Systems
This manual document the complete life cycle of the system. If
documents the results of the feasibility study, the team assigned,
etc. It also documents the file specification, transaction
specification and output specification.

192
7.6 System Training
Training has been defined as "The systematic development of the
knowledge, skills and attitudes required by an individual to perform
adequately a given task or job". There are numerous methods and
materials with the most effective training techniques available to
help you prepare and equip employees to better do their jobs.
Indeed, with so many choices out there, it can be daunting to
determine which methods to use and when to use them. Using
several methods for each training session may actually be the most
effective way to help employees learn and retain information. In
this article, we take a close look at each of the myriad techniques
and examine their advantages and disadvantages. We also explain
how you can combine the various methods into an effective blended
learning approach.
7.6.1 Overall Considerations
The following are some of the main considerations that should be
considered during training.
− Training Strategies
Training strategies are determined by who is being trained and who
will train them. The analyst will want to ensure that anyone whose
work is affected by the new information system is properly trained
by the appropriate trainer.
− Whom to Train
All people who will have primary or secondary use of the system
must be trained. The amount of training a system requires depends
on how much someone’s job will change because of the new
interactions required by the revised system.

193
 − People Who Train Users
For a large project, many different trainers may be used depending
on how many users must be trained and who they are. Possible
training sources include Vendors, Systems analysts, External paid
trainers, In-house trainers, other system users.

7.6.2 Guidelines for Training

The analyst has four major guidelines for setting up training. They
are (1) establishing measurable objectives, (2) using appropriate
training methods, (3) selecting suitable training sites, and (4)
employing understandable training materials.
− Training Objectives
Training objectives for each group must be spelled out clearly.
Well-defined objectives are of enormous help in letting trainees
know what is expected of them. In addition, objectives allow
evaluation of training when it is complete. For example, operators
must know such basics as turning on the machine, what to do when
common errors occur, basic troubleshooting, and how to end an
entry.
− Training Methods
Each user and operator will need slightly different training. To
some extent, their jobs determine what they need to know, and their
personalities, experience, and backgrounds determine how they
learn best. Some users learn best by seeing, others by hearing, and
still others by doing. Because it is often not possible to customize
training for an individual, a combination of methods is often the
best way to proceed. That way, most users are reached through one
method or another.

194
 − Training Sites
Training takes place in many different locations, some of which are
more conducive to learning than others. Large computer vendors
provide special off-site locations at which operable equipment is
maintained free of charge. Their trainers offer hands-on experience
as well as seminars in settings that allow users to concentrate on
learning the new system. One of the disadvantages of off-site
training is that users are away from the organizational context in
which they must eventually perform.
− Training Materials
In planning for the training of users, systems analysts must realize
the importance of well-prepared training materials. These materials
include training manuals; training cases, in which users are assigned
to work through a case that incorporates most of the commonly
encountered interactions with the system; and prototypes and mock-
ups of output. Because the user’s understanding of the system
depends on them, training materials must be clearly written for the
correct audience with a minimum of jargon. A summary of
considerations for training objectives, methods, sites, and materials
is provided in table 7.1.
Elements Relevant Factors
Training Objectives Depend on requirements of user’s job
Depend on user’s job, personality, background, and
Training Methods experience; use combination of lecture, demonstration,
hands-on, and study.
Depend on training objectives, cost, availability, free
Training Sites vendor sites with operable equipment; in-house
installation; rented facilities.
Depend on user’s needs; operate manuals, cases,
Training Materials
prototypes of equipment and output; online tutorials.

Table 7.1: Considerations for Training Objectives, Methods, Sites, and

Materials

195
References
1. Alan Dennis, Barbara Haley Wixom, and Roberta M. Roth,
System Analysis and Design. John Wiley & Sons, 2012
2. Applegate, L. M
3. R. D. Austin, and F. W. McFarlan. Corporate Information
Strategy and Management. 7th ed. Boston: Irwin/McGraw-Hill,
2007.
4. Fuller, M. A, J. S. Valacich, and J. F. George. Information
Systems Project Management. Upper Saddle River, NJ: Prentice
Hall, 2008
5. Fuller, M. A, J. S. Valacich, and J. F. George. Information
Systems Project Management. Upper Saddle River, NJ: Prentice
Hall, 2008.
6. Joseph S. Valacich, Joey F. George, Jeffrey A. Hoffer,
“Essentials of Systems Analysis and Design”, PEARSON, 2012
7. Kenneth E. Kendall and Julie E. Kendall, Systems Analysis and
Design, Eighth Edition ed.: Prentice Hall, 2011
8. Kulak, D., and E. Guiney. Use Cases: Requirement in Context,
2d ed. Boston: Pearson Education, 2004.
9. Kendall, J. E., K. E. Kendall, and S. Kong. “Improving Quality
Through the Use of Agile Methods in Systems Development:
People and Values in the Quest for Quality.” In Measuring
Information Systems Delivery Quality. Edited by E. W. Duggan
and H. Reichgelt, pp. 201–222. Hershey, PA: Idea Group
Publishing, 2006.
10. Kendall, J. E., K. E. Kendall, and S. Kong. “Improving Quality
Through the Use of Agile Methods in Systems Development:

196
 People and Values in the Quest for Quality.” In Measuring
Information Systems Delivery Quality. Edited by E. W. Duggan
and H. Reichgelt, pp. 201–222. Hershey, PA: Idea Group
Publishing, 2006.
11. Luftman, J. N. Managing the Information Technology Resource.
With C.V. Bullen, D. Liao, E. Nash, and C. Neumann. Upper
Saddle River, NJ: Prentice Hall, 2004.
12. Loveday, L. and S. Niehaus. Web Design for ROI: Turning
Browsers into Buyers and Prospects into Leads. Indianapolis,
IN: New Riders, 2007.
13. Laudon, K. C., and J. P. Laudon. Management Information
Systems, 11th ed. Upper Saddle River, NJ: Pearson Prentice
Hall, 2010.
14. Shneiderman, B., C. Plaisant, M. Cohen, and S. Jacobs.
Designing the User Interface. 5th ed. Reading, MA: Addison-
Wesley, 2009.
15. Wansink, B., S. Sudman, and N. M. Bradburn. Asking
Questions: The Definitive Guide to Questionnaire Design—For
Market Research, Political Polls, and Social and Health
Questionnaires. New York: Wiley, 2004.
16. Zhang, P., J. Carey, D. Te’eni, and M. Tremaine. “Integrating
Human–Computer Interaction Development into the Systems
Development Life Cycle: A Methodology.” Communications of
the Association for Information Systems, Vol. 15, 2005, pp.
512–543.
17. Strauss, J., and R. Frost. E-Marketing, 5th ed. Upper Saddle
River, NJ: Pearson Prentice Hall, 2008.

197
 Chapter 1
Part 1: Choose the correct answer

1) The particular processes that an analyst will follow to help ensure that
his work is complete, well-done, and understood by project team
members, best defines:
A) Techniques B) Tools
C) Methodologies D) Data flows

2) The person in an organization who has the primary responsibility for

systems analysis and design is the:
A) Systems analyst B) End user
C) Internal auditor D) Business manager

3) The traditional methodology used to develop, maintain, and replace

information systems best defines:
A) SDLC B) RAD
C) OOAD D) Prototyping

4) The three key principles shared by the Agile Methodologies include:

A) A focus on predictive methodologies
B) A focus on roles
C) A focus on self-adaptive processes
D) All of the above

Part 2: True/ False

5) The analysis and design of information systems is driven from a
technical perspective.
6) Information systems analysis and design is an organizational
improvement process.
7) An important result of systems analysis and design is application
software.
8) Implementation is the fourth phase of the SDLC in which the
information system is coded, tested, installed, and supported in the
organization.

198
Part 3: Complete the following statements
9) ________ is the second phase of the SDLC in which system
requirements are studied and structured.
10) ________ is an approach to develop information systems that
promises better and cheaper systems as well as rapid deployment. 11)
________ refers to systems development methodologies and techniques
based on objects rather than data or processes.

Part 4: Answer the following questions

12) List and define the five major SDLC phases. Draw an
illustrative figure that represent the SDLC
13) Discuss the three categories of information that are related to
managerial levels and the decision managers make.

199
 Chapter 2
Part 1: Choose the correct answer
1) Defining the necessary activities required to organize the initiation
team while they are working to define the scope of the project is the focus
of which of the following activities?
A) Establishing the project initiation team
B) Establishing management procedures
C) Establishing the project initiation plan
D) Establishing the project management environment and
project workbook

2) A graphical representation of a project that shows each task as a

horizontal bar whose length is proportional to its time for completion
defines: A) Network diagram
B) Data diagram
C) Project chart
D) Gantt chart

3) Activities designed to assist in organizing a team to conduct project

planning is the focus of:
A) Project planning
B) Project identification and selection
C) Project initiation
D) Analysis

4) Tangible benefits would include:

A) Improved organizational planning
B) Ability to investigate more alternatives
C) Improved asset control utilization
D) Lower transaction costs

Part 2: True/False
5) Establishing a relationship with the customer is a project initiation
activity.

200
5) Systems requirements planning is an orderly means of assessing
the information needs of an organization and defining the systems,
databases, and technologies that will best satisfy those needs.

6) The systems identification and selection process for an

Internetbased electronic commerce application is no different than the
process followed for other applications.

7) Project initiation focuses on activities that will help organize a

team to conduct project planning.

8) Project planning focuses on defining clear, discrete activities and

the work needed to complete each task.

Part 3: Complete the following statements

9) ________ is a technique that uses optimistic, pessimistic, and
realistic time estimates to calculate the expected time for a particular task.

10) Working closely with customers to assure project deliverables

meet expectations describes the ________ project manager activity.

11) An ________ is a benefit derived from the creation of an

information system that cannot be easily measured in dollars or with
certainty.

12) ________ is the ratio of the net cash receipts of the project
divided by the cash outlays of the project.

Part 4: Answer the following questions

13) Briefly define and compare Gantt charts and network diagrams.

14) Briefly identify and define the six major categories of feasibility.

201
 Chapter 3
Part 1: Choose the correct answer
1) Traditional methods of collecting systems requirements include:
A) Individual interviews
B) Observing workers
C) Group interviews
D) All of the above

2) Questions in interviews asking those responding to choose from among

a set of specified responses are:
A) Specific questions
B) closed-ended questions
C) Open-ended questions
D) Structured questions

3) The analysis of documents can help you identify:

A) Problems with existing systems
B) Special information processing circumstances that occur
irregularly and may not be identified by any other requirements
C) The reason why current systems are designed the way they are
D) All of the above

4) When comparing observations and document analysis:

A) The time required to conduct observations compared to document
analysis is low
B) The observee is not known to the interviewer
C) The potential audience of the observation method is limited
D) With document analysis, a clear commitment is discernible

Part 2: True/ False

5) Requirements determination and requirements structuring are the
two sub-phases to systems analysis.

6) During requirements determination, information can be gathered

from users of the current system, forms, reports, and procedures.

202
7) Challenging yourself to look at the organization in new ways
describes the impertinence characteristic that a systems analyst should
exhibit during the requirements determination phase.

8) Joint Application Design and prototyping can help keep the

analysis effort at a minimum yet still effective.

9) Unstructured questions are questions in interviews that have no

pre-specified answers.

Part 3: Complete the following statements

10) ________ are questions in interviews that ask those responding to
choose from among a set of specified responses.

11) A ________ is the official way a system works as described in

organizational documentation.

12) ________ is a repetitive process in which analysts and users build

a rudimentary version of an information system based on user feedback.

13) A ________ is the trained individual who plans and leads Joint
Application Design sessions.

Part 4: Answer the following questions

14) Discuss different sources from which the initiation or request of
systems projects may come from, (internal and external resources to an
organization).

203
 Chapter 4
Part 1: Choose the correct answer
1) The diagram that shows the scope of the system, indicating what
elements are inside and which are outside the system, is called a:
A) Context diagram
B) Level-2 diagram
C) Referencing diagram
D) Representative diagram

2) Data in motion, moving from one place in a system to another, defines:

A) Data store
B) Process
C) Source
D) Data flow

3) The act of going from a single system to several component processes

refers to: A) Structuring
B) Balancing
C) Functional decomposition
D) Formatting

Part 2: True/ False

4) A data flow diagram is a graphical tool that allows analysts to
illustrate the flow of data in an information system.

5) A primitive level data flow diagram is the first deliverable

produced during requirements structuring.

6) A level-0 diagram is a data flow diagram that represents a

system's major processes, data flows, and data stores at a high level of
detail.

7) Because data flow names represent a specific set of data, another

data flow that has even one more or one less piece of data must be given a
different unique name.

8) Functional decomposition is an iterative process of breaking the

description of a system down into finer and finer detail.

204
Part 3: Complete the following statements
9) A ________ is a matrix representation of the logic of a decision,
which specifies the possible conditions for the decision and the resulting
actions.

10) ________ are the part of a decision table that specifies which
actions are to be followed for a given set of conditions.

11) The __ to a process are different from the outputs of that process.

12) ________ is the extent to which information contained on one

level of a set of nested data flow diagrams is also included on other levels.

Part 4: Answer the following questions

13) Briefly describe the data flow diagramming symbols. Provide one
example of each.

14) For the following situation, draw a context-level diagram and a

level-0 data flow diagram.
Kellogg State Bank provides car and home loans to its banking customers.
Initially, a potential loan customer meets with a Kellogg loan officer,
requests a loan for a certain amount and time frame, and completes a loan
application. Next, the loan officer determines the customer's credit
standing, the type of loan required, and available interest rates. While the
loan officer can authorize car loans for credit worthy customers, a loan
committee must approve all home loans.

205
 Chapter 5
Part 1: Choose the correct answer
1) Which of the following is NOT an implementation method?
A) A purchased application software package
B) A system or utility program
C) An existing application program from a program library
D) A program to be written
E) All of these are implementation methods

2) A multi-user computer that hosts all the components of an information

system is used in: A) Distributed systems
B) Communication systems
C) Enterprise resource systems
D) Centralized systems
E) None of these

3) An application system can be mapped into how many different layers?

A) Two
B) Three
C) Four
D) Five
E) None of these

Part 2: True/ False

4) A physical process is either a processor, such as a computer or
person, or the technical implementation of specific work to be performed,
such as a computer program or manual process.

5) A logical process is either a processor, such as a computer or

person, or the technical implementation of specific work to be performed,
such as a computer program or manual process.

6) A reason that a logical process might be split into multiple

physical processes is because part of the process is performed by people,
and part is to be performed by the computer.

7) A reason that a physical process might be split into multiple

logical processes is to add additional data requirements.

206
Part 3: Complete the following statements
8) A(n) _________________________ system is a solution in which
the presentation, presentation logic, application logic, data manipulation
and data layers are distributed between client PCs and one or more
servers.

9) A(n) _________________________ server hosts one or more

shared databases (like a file server) but also executes all database
commands and services for information systems (unlike a file server).

10) A(n) _______________________ server hosts application logic

and services for an information system. It must communicate on the front
end with the clients (for presentation) and on the back end with database
servers for data access and update.

11) _____________________________________ duplicates some or

all tables (rows and columns) on more than one database server.

Part 4: Answer the following questions

12) There are three basic elements in the data modeling language,
Discuss the three basic elements of ERDs and the symbols

13) Discuss the different kinds of data modeling and database design and
explain the Relationship between data modeling and SDLC.

207
 Chapter 6
Part 1: Choose the correct answer
1) Which design identifies the software as a system with many
components interacting with each other?
A) Architectural design
B) High-level design
C) Detailed design
D) Both B & C

2) Mention any two indirect measures of product.

A) Quality
B) Efficiency
C) Accuracy
D) Both A and B
E) Both B and C

3) Which design deals with the implementation part in which it shows a

system and its sub-systems in the previous two designs?
A) Architectural design
B) High-level design
C) Detailed design
D) Both A & B

4) A human-computer interaction method where explicit statements are

entered into a system to invoke operations refers to:
A) Command language interaction
B) Natural language interaction
C) Machine language interaction
D) Object-based interaction

Part 2: True/ False

5) The ERD communicates high-level business rules.

6) Interface design focuses on how information is provided to and

captured from users.

7) The major deliverable from system interface and dialogue design is

user acceptance testing results.

208
8) Display sequence refers to the way a user can move from one display
to another.

Part 3: Complete the following statements

9) There are three basic elements in the data modeling language, they
are: _________________, _________________,
______________

10) An __________ is some type of information that is captured about an

entity.

11) ______________ are associations between entities

12) ________ refers to graphical pictures that represent specific functions

within a system.

13) When designing the navigation procedures within your system,

________ and ________ are primary concerns.

14) A ________ validation test checks for the existence of data items in
all fields of a record.

15) A ________ validation test assures that data conform to a standard

format.

Part 4: Answer the following questions

16) Discuss different examples of the operational requirements that
specify the operating environment(s) in which the system must
perform and how those may change over time.

17) Discuss the key operational requirement areas and provides some
examples of each.

18) Discuss the main principles of a good input and output design.

209
 Chapter 7
Part 1: Choose the correct answer
1) The process in which the current system is replaced by the new system
best describes:
A) The systems development life cycle
B) Changeover
C) Physical design
D) Set-up

2) A strategy for training users so they can quickly learn the new system
is a(n): A) Training plan
B) Installation plan
C) User guide
D) Training curriculum

3) Training on the use of the system begins during the early stages of the:
A) Analysis phase
B) Logical design phase
C) Implementation phase
D) Project initiation and planning phase

Part 2: True/ False

4) After maintenance, the implementation phase of the systems
development life cycle is the most expensive and time-consuming phase
of the entire life cycle.

5) Documentation is one of the six major activities associated with

systems implementation.

6) The development of a new version of the software and new

versions of all design documents are the major deliverables associated
with the coding, testing, and changeover stage.

7) The systems administration plan answers such questions as when

and where the new system will be installed, what people and resources are
required, which data will be converted and cleansed, and how long the
installation process will take.

210
Part 3: Complete the following statements
8) ________ are a testing technique in which participants examine
program code for predictable language-specific errors.

9) ________ is a testing technique in which the program code is

sequentially executed manually by the reviewer.

10) ________ refers to user testing of a completed information

system using simulated data.

11) ________ is written or other visual information about an

application system, how it works, and how to use it.

Part 4: Answer the following questions

12) Briefly identify the types of changeover.

211
Exercises

212
 Chapter 1
Foundations for System Development

Question 1:
Define: System, System Analysis, System Design, feasibility study,
Methodologies, Techniques, Computer-aided software
engineering (CASE), JAD
Answer:
System may be referred to any set of components, which function in
interrelated manner for a common cause or objective. The term system
refers to an organized relationship among functioning units or
components.

System analysis, the process of gathering and interpreting facts,

diagnosing problems, and using the information to recommend
improvements to the system. Analysis specifies what the system should
do.

System design, the process of planning a new business system or one to

replace or complement an existing system. Design states how to
accomplish the objective.

Feasibility study is conducted before the second phase of the SDLC to

determine the economic and organizational impact of the system.

Methodologies are a sequence of step-by-step approaches that help

develop your final product, the information system.

Techniques are processes that you, as an analyst, will follow to help

ensure that your work is well thought-out, complete, and
comprehensible to others on your project team.

213
 Computer-aided software engineering (CASE) refers to automated
software tools used by systems analysts to develop information
systems.

Joint Application Design (JAD) Gathering the people directly affected

by an IS in one room at the same time to work together to agree on
system requirements and design details

Question 2:
Discuss the different skills that the Systems Analyst should posses
Answer
Technical skills to understand the organization’s existing technical
environment, the new system’s technology foundation

Business skills are required to understand how IT can be applied to

business situations

Communication skills give presentations to large and small groups and

to write reports.
Interpersonal abilities, able to manage people with whom they work,
manage the pressure and risks associated with unclear situations.

Question 3:
Discuss the different Roles of the Systems Analyst
Answer
The systems analyst role: focus on IS issues and develop improvement
ideas with maintaining the required standards.

The business analyst role focuses on the business issues surrounding the
system.
The requirements analyst role focuses on eliciting the requirements
from the stakeholders associated with the new system.

214
 The infrastructure analyst role focuses on technical issues surrounding
the ways the system will interact with the organization’s technical
infrastructure (hardware, software, networks, and databases).

The change management analyst role focuses on the people and

management issues surrounding the system installation. ensures that
adequate and user training on the new system

The project manager role ensures that the project is completed on time
and within budget and that the system delivers the expected value to the
organization.

Question 4:
Compare between Logical design and physical design
Answer
Logical design concentrates on how the system will impact the
functional units within the organization

You design the various parts of the system to perform the physical
operations necessary to facilitate data capture, processing, and
information output.

Question 5:
Discuss briefly the phases of The Systems Development Life Cycle
(SDLC)
Answer
SDLC includes four main steps: (1) planning and selection, (2) analysis,
(3) design, and (4) implementation and operation (see figure 1.2).

215
Phase 1: Systems Planning and Selection
• Identifies the need for a new or enhanced system.
• Prioritizes and translates the needs into a written plan

Phase 2: Systems Analysis

• Studies the organization’s current procedures and the information
systems used to perform tasks
• Determining the requirements of the system.
• A careful study of any current systems, manual and computerized,
• Determine the requirements interrelationships, eliminating any
redundancies.
• Generate alternative initial designs to match the requirements.
• Compare these alternatives to determine the best alternative

Phase 3: Systems Design

• Convert the description of the recommended alternative solution
into logical and then physical system specifications.

Phase 4: Systems Implementation and Operation

• Turn system specifications into a working system that is tested
and then put into use. Implementation includes coding, testing,
and installation.

216
Question 6:
Discuss: Prototyping, RAD, and Agile methodologies
Answer:
Prototyping
A method that performs the analysis, design and implementation
phases concurrently and it is smaller version of the system with a
minimal amount of features. All three phases are performed
repeatedly in a cycle until the system is completed.
Advantage: Provides a system for the users to interact with, even if it
is not initially ready for use.
Disadvantage: significant changes that many initial design decisions
prove to be poor ones.

Rapid Application Development

The fundamental principle of any RAD methodology is to delay
producing detailed system design documents until after user
requirements are clear with gaining user acceptance of the interface
and developing key system capabilities as quickly as possible.
RAD methodologies can overlook important systems development
principles, which may result in problems with systems developed this
way. The problem with RAD-based methodologies is managing user
expectations.

217
 Agile Methodologies
some of the most well-known Agile Methodologies
Extreme Programming, the Crystal family of methodologies, Adaptive
Software Development, Scrum, and Feature Driven Development.
key principles:
(1) A focus on adaptive rather than predictive methodologies, (2) A
focus on people rather than roles, and (3) A self-adaptive process
which refers to the observation that engineering-based methodologies
work best when the process and product are predictive.

Question 7:
Compare between the different system development methodologies
based on the previously mentioned criteria in question 4.
Answer:

218
 Chapter 2
Project Selection and Management
Question 1:
List the different Project Management Activities
Answer:

Question 2: List the following

A) The main reasons for systems projects, which are described
below
Improved service, Better performance, more information,
Stronger controls, Reduced cost

B) Sources of Systems Projects

User requests, Top-management directives, Existing systems,
Information systems department, External factors

C) The activities that are performed during project initiation:

Establishing the Project Initiation Team, Establishing a Relationship
with the Customer, Establishing the Project Initiation Plan,

219
 Establishing Management Procedures, Establishing the Project
Management Environment and Project Workbook

D) The activities that are performed during project planning:

− Describing the project scope, alternatives, and feasibility
− Dividing the project into manageable tasks
− Estimating resources and creating a resource plan
− Developing a preliminary schedule
− Developing a communication plan
− Determining project standards and procedures
− Identifying and assessing risk
− Creating a preliminary budget
− Developing a project scope statement
− Setting a baseline project plan

E) Methods of preliminary investigation

Interviewing selected company personnel, Reviewing organization
documents

F) The content of the feasibility study report

Statement of the problem, Summary of findings and
recommendations, Details of findings, Recommendations and
conclusions

G) The Three Key Elements of Feasibility

The Three Key Elements of Feasibility

Operational Feasibility
▪ Whether the system will operate when installed
▪ Whether the system will be used
Technical Feasibility
▪ Add on to present system
▪ Technology available to meet users’ needs
Financial and Economic Feasibility
▪ Systems analysts’ time
▪ Cost of systems study
▪ Cost of employees’ time for study
▪ Estimated cost of hardware
▪ Cost of packaged software or software development

220
h) Advantages and disadvantages of the acquisition methods of
computer hardware
Advantages Disadvantages
− Cheaper than − Initial cost is high
leasing or − Risk of obsolescence
− renting over the − Risk of being stuck if choice was wrong
long run − Full responsibility
− Ability to change
Buying system
− Provides tax
advantages of
− accelerated
depreciation
− Full control
− No capital is tied − Company doesn’t own the
up − system when lease expires
− No financing is − Usually a heavy penalty for
Leasing required − terminating the lease
− Leases are lower − Leases are more expensive than buying
than rental
payments
− No capital is tied − Company doesn’t own the computer
up − Cost is very high because vendor assumes
− No financing is the risk (most expensive option)
required
Renting − Easy to change
systems
− Maintenance and
insurance are
usually included

i) Advantages and disadvantages of methods for obtaining a

software

Advantages Disadvantages
− Specific response to − May be significantly
specialized business needs higher initial cost
Creating − Innovation may give firm a compared to COTS
Custom competitive advantage software or ASP
Software − In-house staff available to − Necessity of hiring or
maintain software working
− Pride of ownership − with a development

221
 Advantages Disadvantages
team
− Ongoing maintenance
− Refined in the commercial − Programming focused;
world not business focused
− Increased reliability − Must live with the
− Increased functionality existing features
Purchasing
− Often lower initial cost − Limited customization
COTS
− Already in use by other − Uncertain financial
Packages
firms future of vendor
− Help and training comes − Less ownership and
with software commitment

− Organizations that do not − Loss of control of data,

specialize in information systems, IT employees,
systems can focus on what and schedules
they do best (their strategic − Concern over the
mission) financial viability and
− There is no need to hire, long-run stability of the
train, or retain a large IT ASP
Using an
staff − Security,
ASP
− There is no expenditure of confidentiality, and
employee time on privacy concerns
nonessential IT tasks − Loss of potential
strategic corporate
advantage regarding
innovativeness of
applications

j) The criteria that should be considered to select one of the

methods to obtain a software
Familiarity with the application, Familiarity with the technology,
Project size, compatibility of the new system with the technology that
already exists in the organization

k) Examples for tangible benefits:

− Cost reduction and avoidance
− Error reduction
− Increased flexibility
− Increased speed of activity
− Improvement of management planning and control

222
 − Opening new markets and increasing sales opportunities

l) Examples for Intangible benefits include:

− Competitive necessity
− Increased organizational flexibility
− Increased employee morale
− Promotion of organizational learning and understanding
− More timely information

m) Standards and policies to guide the choice of SDLC

methodology.
− Clarity of User Requirements
− Familiarity with Technology
− System Complexity
− System Reliability
− Schedule Visibility

Question 3:
Define: Preliminary Investigation, feasibility study, Economic
feasibility, Gantt chart, PERT
Answer:
Preliminary Investigation refers to the collection of information that
guides the management of an organization to evaluate the merits and
demerits of the project request.

A feasibility study is a test of a system proposal according to its

workability.

The three main options for acquisition of computer hardware are buying,
leasing, or renting it. There are advantages and disadvantages that ought
to be weighed for each of the decisions, as shown in table 2.2 Some of the
more influential factors to consider in deciding which option is best for a
particular installation include initial versus long-term costs, whether the
business can afford to tie up capital in computer equipment, and whether
the business desires full control of and responsibility for the computer
equipment.

Economic feasibility is to identify the financial benefits and costs

associated with the development project. Economic feasibility is often
referred to as cost-benefit analysis.

223
Gantt chart is a graphical representation of a project that shows each task
as a horizontal bar whose length is proportional to its time for completion.

PERT (program evaluation review technique) is a technique that uses

optimistic, pessimistic, and realistic time estimates to calculate the
expected time for a particular task..

Question 4:
Discuss the different feasibility perspectives that should be
considered in the Feasibility Analysis phase
Answer:

Technical Feasibility: Can We Build It?

− a process of assessing the development organization’s ability

to construct a proposed system.

− Users’ and analysts’ familiarity with the business

application area
− Familiarity with technology
o Have we used it before? How new is it?
− Project size
o Number of people, time, and features
− Compatibility with existing systems
The potential consequences of not assessing and managing risks
can include:
• Failure to attain expected benefits from the project
• Inaccurate project cost estimates.
• Inaccurate project duration estimates.
• Failure to achieve adequate system performance levels.
• Failure to adequately integrate the new system with
existing hardware, software, or organizational procedures.

Economic Feasibility: Should We Build It?

− a process of identifying the financial benefits and costs associated
with a development project
✓ Often referred to as a cost-benefit analysis
✓ Project is reviewed after each SDLC phase in order to
decide whether to continue, redirect, or kill a project

224
 − Identify costs and benefits
− Assign values to costs and benefits
− Determine cash flow
− Assess financial viability
o Net present value (NPV)
o Return on investment (ROI)
o Breakeven point (BEP)
Assign Cost and Benefit Values
− Difficult, but essential to estimate
− Work with people who are most familiar with the area to
develop estimates
− Intangibles should also be quantified
− If intangibles cannot be quantified, list and include as part
of supporting material
Organizational Feasibility: If we build it, will they come?
− Strategic alignment
o How well do the project goals align with business
objectives?
− Stakeholder analysis
o Project champion(s)
o Organizational management
o System users

- Assessing Other Feasibility Concerns

- Operational
• Does the proposed system solve problems or take advantage
of opportunities?
- Scheduling
• Can the project time frame and completion dates meet
organizational deadlines?
- Legal and Contractual
• What are the legal and contractual ramifications of the
proposed system development project?
- Political
• How do key stakeholders view the proposed system?

225
Question 5:
Compare between Tangible and Intangible Costs
Answer
− Tangible Costs: Includes revenue that the system enables
the organization to collect, such as increased sales.
− Intangible Costs: Are based on intuition and belief rather
than “hard numbers”

Question 6:
List the main tasks that should be accomplished in the Project Planning
phase
Answer:
− Describe project scope, alternatives, feasibility.
− Divide project into tasks.
− Estimate resource requirements and create resource plan.
− Develop preliminary schedule.
− Develop communication plan.
− Determine standards and procedures.
− Identify and assess risk.
− Create preliminary budget.
− Develop a statement of work.
− Set baseline project plan.

226
 Chapter 3
Determining System Requirements
Question 1:
Define the term “Requirement”
Answer:
− A statement of what the system must do
− A statement of characteristics the system must have
− Focus is on business user needs during analysis phase
− Requirements will change over time as project moves from
analysis to design to implementation

Question 2:
Why Documenting Requirements is so important?
Answer:
− Requirements definition report
− Text document listing requirements in outline form
− Priorities may be included
− Key purpose is to define the project scope: what is and is not to be
included.
− Participation by business users is essential

Question 3:
Discuss the different methods for requirements-gathering
techniques
Answer:
1- Interviews
− Most commonly used technique
− Basic steps:
− Selecting Interviewees
− Designing Interview Questions
− Preparing for the Interview
− Conducting the Interview
− Post-Interview Follow-up

- Selecting Interviewees
− Based on information needs
− Best to get different perspectives
− Managers

227
 − Users
− Ideally, all key stakeholders

-Designing Interview Questions

− Unstructured interview useful early in information gathering
− Goal is broad, roughly defined information
− Structured interview useful later in process
− Goal is very specific information

- Top-Down and Bottom-up Questioning Strategies

- Preparing for the Interview

− Prepare general interview plan : List of question,
Anticipated answers and follow-ups
− Confirm areas of knowledge
− Set priorities in case of time shortage
− Prepare the interviewee: Schedule, Inform of reason for
interview, Inform of areas of discussion

- Conducting the Interview

o Appear professional and unbiased
o Record all information
o Check on organizational policy regarding tape
recording
o Be sure you understand all issues and terms
o Separate facts from opinions
o Give interviewee time to ask questions
o Be sure to thank the interviewee
o End on time

228
 - Post-Interview Follow-Up
o Prepare interview notes and reports
o Have interviewee review and confirm interview
report
o Look for gaps and new questions

2- Joint Application Development (JAD)

o A structured group process focused on determining
requirements
o Involves project team, users, and management working
together
o Very useful technique, May reduce scope creep by 50%

3- Questionnaires
o A set of written questions, often sent to a large number of
people
o May be paper-based or electronic
o Select participants using samples of the population
o Design the questions for clarity and ease of analysis
o Administer the questionnaire and take steps to get a good
response rate
o Questionnaire follow-up report

- Document Analysis
o Study of existing material describing the current system
o Forms, reports, policy manuals, organization charts
describe the formal system
o Look for the informal system in user additions to
forms/report and unused form/report elements
o User changes to existing forms/reports or non-use of
existing forms/reports suggest the system needs
modification

4- Observation
o Watch processes being performed
o Users/managers often don’t accurately recall everything
they do
o Checks validity of information gathered other ways
o Be aware that behaviors change when people are watched

229
 o Be unobtrusive
o Identify peak and lull periods

Question 4:
Give examples for the different Three Types of Questions that are
conducted during an interview
Answer:

Question 5:
Compare between the different Requirements-Gathering
Techniques according to the type, depth, breadth, and integration
of information, as well as the cost and user involvement.
Answer:

Joint Document
Interviews Application Questionnaires Observations
Analysis
Design
As-is, As-is,
Type of As-is,
improvements, improvements, As-is As-is
information improvements
to-be to-be
Depth of
high high Medium Low Low
information
Breadth of
Low Medium High High Low
information
Integration
of Low High Low Low Low
information
User
Medium High Low Low Low
involvement
Low-
Cost Medium Low- Medium Low Low
Medium

230
 Chapter 4
Structuring System Requirements: Process Modelling

Question No 1:
Define: Process modelling, data-flow diagram (DFD), Structured
Analysis, Process, Functional decomposition, Data Dictionary,
decision table
Answer:
Process modelling: involves graphically representing the processes, or
actions, that capture, manipulate, store, and distribute data between a
system and its environment and among components within a system.

Data-flow diagram (DFD): a graphic that illustrates the movement of data

between external entities and the processes and data stores within a
system.

Structured Analysis: a set of techniques and graphical tools that allow the
analyst to develop a new kind of system specifications that are easily
understandable to the user. .

Process: an activity or a function that is performed for some specific

business reason. Processes can be manual or computerized. A process is
the work or actions performed on data so that they are transformed,
stored, or distributed.

Functional decomposition is a repetitive process of breaking the

description or perspective of a system down into finer and finer detail.

Data Dictionary: a structured repository of data. It is a set of rigorous

definitions of all DFD data elements and data structure.

Decision table: a diagram of process logic where the logic is reasonably

complicated. All of the possible choices and the conditions the choices
depend on are represented in tabular form

Question No 2:
Discuss the advantages and disadvantages of data dictionary and data
flow approach
Answer:
Data Flow Approach:
Advantages
5. Freedom from committing to the technical implementation of
the system too early.

231
 6. Further understanding of the interrelatedness of systems and
subsystems.
7. Communicating current system knowledge to users through
data flow diagrams.
Disadvantages
The tool only weakly shows input and output detail. The user often
finds it confusing initially.
Data dictionary
Advantages:
The data dictionary: Documentation is a valuable reference in any
organization, improving analyst/ user communication by
establishing consistent definitions of various elements, terms and
procedures. it helps the analyst simplify the structure for meeting
the data requirements of the system. It may be used at high or low
levels of analysis
Disadvantages
It does not provide functional details, and it is not acceptable to
many nontechnical users.

232
 Chapter 5
Structuring System Requirements
Conceptual Data Modeling
Question No 1:
Define: entity relationship diagram, Entity, Attribute,
Relationship, Cardinality, Modality, metadata
Answer:
Entity relationship diagram (ERD) is a picture which shows the
information that is created, stored, and used by a business system. An
analyst can read an ERD to discover the individual pieces of information
in a system and how they are organized and related to each other.

Entity is the basic building block for a data model. It is a person, place,
event, or thing about which data is collected—for example, an employee,
an order, or a product.

Attribute is some type of information that is captured about an entity. For

example, last name, home address, and e-mail address are all attributes of
a customer.

Relationships are associations between entities, and they are shown by

lines that connect the entities together. Every relationship has a parent
entity and a child entity, the parent being the first entity in the
relationship, and the child being the second.

Cardinality Relationships have two properties. First, a relationship has

cardinality, which is the ratio of parent instances to child instances.

Modality relationships have a modality of null or not null, which refers to

whether or not an instance of a child entity can exist without a related
instance in the parent entity.

Metadata: The information you see in the data dictionary, quite simply, is
data about data. Metadata is anything that describes an entity, attribute, or
relationship, such as entity names, attribute descriptions, and relationship
cardinality

233
 Chapter 6
System Design
Question No 1:
Discuss the different Non-Functional Requirements that should
be considered in the system design
Answer:
Security: Security refers to the need to control access to the data. This
includes controlling who may view and alter application data.
Reliability: Reliability is the probability that the system will be able to
process all work correctly and completely without being aborted.
Recoverability: Recoverability refers to the ability to restore your
deployment to the point at which a failure occurred.
Availability: System availability is the time when the application must be
available for use.
Fault Tolerance: Fault tolerance is the ability to remain partially
operational during a failure. Fault-tolerant technology is a capability of a
computer system, electronic system or network to deliver uninterrupted
service, despite one or more of its components failing.
General Performance: Other requirements could be considered such as
response time for queries and updates, Throughput, and Expected rate of
user activity (for example, number of transactions per hour, day, or
month).
Capacity: List of the required capacities and expected volumes of data in
business terms should be highlighted. For example, the number of cases
about which the application will have to store data.
Data Retention: The length of time the data must be retained could also
be determined. For example, “Information about an application for
naturalization shall be retained in immediately accessible form for 3 years
after receipt of the application.”
Question No 2:
Discuss the general Principles of the User Interface Design
Answer:
− Strive for consistency
− Cater to universal usability
− Offer informative feedback
− Prevent errors
− Permit easy reversal of actions
− Support internal locus of control

234
 − Reduce short-term memory load
− Recoverability

Question No 3:
Draw an illustrative graph representing the User Interface Design
Process
Answer:

Question No 4:
Discuss the main advantages, disadvantages for the Different
Interaction styles between a user and a system with providing an
example of each style

Answer:
Manipulation Main Main Application
Type Advantages Disadvantages Examples
Direct − Fast and − May be hard − Video games
intuitive to implement − CAD
interaction − Only suitable systems
− Easy to where there
learn is a visual
metaphor for
tasks and
objects

235
 Manipulation Main Main Application
Type Advantages Disadvantages Examples
Menu − Avoids − Slow for − Most general
user error experienced purpose
− Little users systems
typing − Can become
required complex if
many
options
Form Fill-in − Simple − Takes up a − Stock
data entry lot of screen control,
− Easy to space personal
learn loan
processing
Command − Powerful − Hard to learn − Operating
Language and − Poor error systems,
flexible management Library
information
retrieval
systems
Natural − Accessible − Requires − Timetable
Language to casual more typing systems
users − Natural − WWW
− Easily language information
extended understandin retrieval
g systems systems
are
unreliable

Question No 5:
Compare between a form and a report
Answer:
A form is a business document containing some predefined data and often
includes some areas where additional data are to be filled in.
A report is a business document containing only predefined data; it is a
passive document used solely for reading or viewing.

Question No 6:
Discuss the basic principles of good input/output design
Answer:
− User Involvement, User First, Computers Last, Minimize
Human Efforts, Remember Human Limitations, Convention
Standardization, Cultural Bias

236
 Chapter 7
Systems Implementation and Operation
Question No 1:
Define: Coding, System Changeover, Maintenance
Answer:
Coding: Coding is the process through which the physical design
specifications created by the design team are turned into working
computer code by the programming team.

System Changeover: the process of changing the old information

system. System changeover is the process of putting the new
information system online and retiring the old system.

Maintenance is the correction of errors and omissions that were not

caught during the testing and delivery phases.

Question No 2:
Discuss the main activities that are accomplished in the Systems
implementation and operation phase
Answer:
− Coding, Testing, Change over, Maintenance, Documentation,
Training

Question No 3:
What is the purpose of the system implementation and operation
stage?
Answer:
Convert the final physical system specifications into working and
reliable software and hardware, document the work that has been
done, and provide help for current and future users and caretakers of
the system.

Question No 4:
Compare between:
A) unit testing, integration testing, System Testing, and Acceptance
Testing
Answer:
Unit Testing is done at the lowest level. It tests the basic unit of
software, which is the smallest testable piece of software,

237
 Integration Testing is performed when two or more tested units are
combined into a larger structure.
System Testing is based on the functional/requirement specification
of the system. Non-functional quality attributes, such as reliability,
security, and maintainability, are also checked.
Acceptance Testing is done when the completed system is handed
over from the developers to the customers or users. The purpose of
acceptance testing is rather to give confidence that the system is
working than to find errors.

B) Static Analysis and Dynamic Analysis

Answer:
Static Analysis focuses on the range of methods that are used to
determine or estimate software quality without reference to actual
executions. Techniques in this area include code inspection, program
analysis, symbolic analysis, and model checking.
Dynamic Analysis deals with specific methods for ascertaining
and/or approximating software quality through actual executions,
i.e., with real data and under real (or simulated) circumstances.
Techniques in this area include synthesis of inputs, the use of
structurally dictated testing procedures, and the automation of testing
environment generation.

C) Functional Technique and Structural Technique

Answer:
Functional Testing: the software program or system under test is
viewed as a “black box”. Functional testing emphasizes on the
external behavior of the software entity.
Structural Testing: the software entity is viewed as a “white box”.
Structural testing emphasizes on the internal structure of the
software entity.

Question No 5:
Discuss the different approaches of system changeover including
their methodology, advantages and disadvantages
Answer:
− Direct Cutover
Old system is cut and over write by new system.
Advantages: a least expensive method

238
 Disadvantages. High risk of data loss, more risks of total system
failure

− Parallel Operation
Both the old and the new information systems operate fully for a
specified period. When users, management, and the IT group are
satisfied that the new system operates correctly, the old system is
terminate.
Advantages very low amount of risk
Disadvantages the most costly changeover method.

− Pilot Operation
Implementing the complete new system at a selected location of
the company. The group that uses the new system first is called
the pilot site. The old system continues to operate for the entire
organization including the pilot site. After the system proves
successful at the pilot site, it is implemented in the rest of the
organization, usually using direct cutover method.
Advantages Reduces the risk of system failure. Less expensive
than the parallel operation

− Phased Operation
Implementation of new system in modules or stages is phased
operation. This is also a combination of direct cutover and
parallel similar to pilot operation.
Advantages the risk of errors or failures is limited, less expensive
than the full parallel operation.
Disadvantages in some cases, phased operation can cost more
than a pilot approach where the system involves a large number
of separate phases.

Question No 6:
What are the reasons that may require system improvement?
Answer:
− Additional features, Change of business over time, Hardware and
software change

Question No 7:
Discuss the different types of maintenance
Answer:

239
 − Corrective
It means repairing, processing or performance failures or making
changes because of previously uncorrected problems.

− Adaptive
It means changing the program functions.

− Perfective
It means enhancing the performance or modifying the programs to
respond to the users’ additional or changing needs. The greatest
amount of time is spent on perfective. Maintenance covers a wide
range of activities including correcting coding and design errors,
updating documentation and test data.

− Preventive
Its mission is to maintain a level of certain service on equipment,
programming the interventions of their vulnerabilities in the most
opportune time. It is used to be a systematic character, that is, the
equipment is inspected even if it has not given any symptoms of
having a problem.

Question No 8:
Discuss the different types of System documents
Answer:
− Program
Before a program is developed, the systems analyst should provide
the programmer with the required documentation

− Operations
For smooth running of the system, the data entry operator must have
complete knowledge about the job.

− User
System users should have a manual that describes everything the
users must know to do their job correctly.

− Management
The manual should enable management to perform three functions:
(a) Evaluate progress on the development of system. (b) Monitor the
existing systems. (c) Understand the objectives and methods of the
new and existing system.

240
 − Systems
This manual document the complete life cycle of the system. If
documents the results of the feasibility study, the team assigned, etc.
It also documents the file specification, transaction specification and
output specification.

Question No 9:
Discuss the main considerations that should be highlighted in the
training phase
Answer
(1) Establishing measurable objectives, (2) using appropriate training
methods, (3) selecting suitable training sites, and (4) employing
understandable training materials.

Elements Relevant Factors

Training Depend on requirements of user’s job
Objectives
Depend on user’s job, personality, background, and
Training
experience; use combination of lecture, demonstration,
Methods
hands-on, and study.
Depend on training objectives, cost, availability, free vendor
Training Sites sites with operable equipment; in-house installation; rented
facilities.
Training Depend on user’s needs; operate manuals, cases, prototypes
Materials of equipment and output; online tutorials.

241