CHAPTER ONE

SYSTEM: AN OVERVIEW
1. Introduction
 Information systems analysis and design is a complex, challenging, and stimulating
organizational process that a team of business and systems professionals uses to develop and
maintain computer-based information systems.
 Information systems analysis and design is an organizational improvement process.
 Systems analysis and design is a established methodology that helps both large and small
business gain the rewards of utilizing information to its full capacity.
 The systems development life cycle (SDLC) is central to the development of and efficient
information system.
 Systems Development Life Cycle (SDLC ): The process of determining how an information
system can support business needs, designing the system, building it, and then delivering it to
users.
 Systems analyst is key person in the SDLC
 This person analyzes the business situation, identifies opportunities for improvements, and
designs an information system to implement the improvements
 Primary goal of a systems analyst is to create value for the company, which usually means
increasing profits
 In short, systems analysts do things and challenge the current way the organization works
We will highlight four key SDLC steps.
 Planning and selection
 Project identification and selection
 Initiating and planning
 Analysis
 Requirement determination
 Requirement structuring
 Design, and
 Implementation and operation.
Be aware that these steps may vary in each organization depending on its goals

 Planning and selection

1
 Planning:- Understanding “why” an IS should be built and determining how the project
team will go about building it
 Project identification and selection:- A project is identified when someone in the
organization identifies a business need to build a system.
 New marketing campaign, reaching out to a new type of customer, interactions with
suppliers
 Initiating and planning
I. Technical feasibility (can we build it?)
ii. Economic feasibility (will it provide business value?)
iii. Organizational Feasibility (if we build it, will it be used?)
 Analysis
 Requirement determination
 Requirement structuring
 Analysis:- Who will use the system? What will the system do? When will it be used?
1. Analysis Strategy
i. Study of the current system (called the “as-is system”), its problems, and ways to
design a new system (“to-be system”)
2. Requirements Gathering
i. Discovering the requirements via interviews, group workshops, or questionnaires
which leads to a concept for a new system
ii. System concept then used as a basis to develop a set of business analysis models that
describe how the business will operate if the new system were developed
3. System Proposal
i. Presenting the system concept and models to the project sponsor and other key decision
makers who will decide whether the project should continue to move forward
 Design
 Decides how the system will operate in terms of the hardware, software, and network
infrastructure that will be in place
1. Design Strategy

2
 i. Clarifies whether the system will be developed by the company’s own programmers,
outsourced to another firm, or whether the company will buy an existing software
package
2. Architecture Design
i. What hardware, software, and network infrastructure will be used
ii. Interface Design- how will users move through the system?
3. Database and File Specifications
i. Defines exactly what data will be stored and where they will be stored
4. Program Design
i. Defines the programs that need to be written and exactly what each program will do
 Implementation and operation.
 Implementation
 System is actually built (or purchased)
1. Construction
i. System is built and tested to ensure that it performs as designed
2. Installation
i. Old system off, new system on
3. Support
i. Formal or informal post-implementation review

1.1. System Analysis and Design

Information Systems Analysis and Design are complex organizational process, used to develop
and maintain computer-based information systems and used by a team of business and systems
professionals. Application Software is computer software designed to support organizational
functions or processes. Systems Analyst is organizational role most responsible for analysis and
design of information systems.

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.
3
The major goal of systems analysis and design is to improve organizational systems. Often this
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. The goal of application software is to turn
data into information.

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. Among the positive consequences are improved performance and a feeling
of achievement with quality information.

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 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 systems 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. Before one can
design a system to capture data, update files, and produce reports, one needs to know more about
the store operations: what forms are being used to store information manually, such as
requisitions, purchase orders, and invoices and what reports are being produced and how they are
being used.
The systems design is like the blueprint for a building: it specifies all the features that are to be
in the finished product.
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

4
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. System and its Components

Systems are created to solve problems. One can think of the systems approach as an organized
way of dealing with a problem. In this dynamic world, the subject System Analysis and Design
(SAD), mainly deals with the software development activities.
A collection of components that work together to realize some objectives forms a system.

In a system the different components are connected with each other and they are interdependent.
For example, human body represents a complete natural system. We are also bound by many
national systems such as political system, economic system, educational system and so forth. The
objective of the system demands that some output is produced as a result of processing the
suitable inputs. A well-designed system also includes an additional element referred to as
‘control’ that provides a feedback to achieve desired objectives of the system.

System is an interrelated set of business procedures (or components) used within one business
unit, working together for some purpose. For example, a system in the payroll department keeps
track of checks, whereas an inventory system keeps track of supplies.

A system has nine characteristic.

1. Components
2. Interrelated components
3. A boundary
4. A purpose
5. An environment
6. Interface
7. Constraints
8. Output
9. Input

5
1. A system is made up of components. A component is either a complex part or an aggregate
of parts, also called a subsystem. The simple concept of a component is very powerful. Just as
with an automobile, we can repair or upgrade the system by changing individual components
without having to make changes throughout the entire system.
2. The components are interrelated; that is, the function of one is somehow tied to the
functions of the others.
3. A system has a boundary, which in which all of its components is contained and which
establish the limits of a system, separating the system from other systems.
A system should be defined by its boundaries – the limits that identify its components,
processes and interrelationship when it interfaces with another system.
Each system has boundaries that determine its sphere of influence and control. Recently,
system design has been successful in allowing the automatic transfer of funds form a bank
account to pay bills and other obligations to creditors, regardless of distance or location. This
means that in systems analysis, knowledge of the boundaries of a given system is crucial in
determining the nature of its interface with other systems for successful design.
4. All of the components work together to achieve some overall purpose for the larger system:
the system's reason for existing.
5. A system exist with in an environment- everything outside the system’s boundary. The
environment is the “suprasystem” within which an organization operates. It is the source of
external elements that enforce on the system. For example, the organization’s environment,
consisting of vendors, competitors, and others, may provide constraints and, consequently,
influence the actual performance of the business. Usually the system interacts with its
environment, exchanging, in the case of an information system, data and information.
6. The points at which the system meets its environment are called interfaces, and there are also
interfaces between subsystems.
Because, an interface exists at the point where its environment, the interface has several
special, important function.
An interface provides:
 Security, protecting the system from undesirable elements that may want to penetrate it.
 Filtering unwanted data, both for elements leaving the system and entering it
 Coding and decoding incoming and outgoing messages
 Detecting and correcting errors in its interaction with the environment
6
 Safeguarding, providing a layer of slack between the system and its environment, so that the
system and its environment can work on different cycles and at different speeds.

 Because interface functions are critical in communication between system components or a

system and its environment, interfaces receive much attention in the design of information
system.
 You will spend a considerable portion of time in systems development dealing with
interfaces, especially interfaces between an automated system and its users (manual systems)
and interfaces between different information systems.
 It is the design of good interfaces that permits different systems to work together without
being too dependent on each other.

7. Constraints: - A system must face constraints in its functioning because there are limits to
what it can do and how it can achieve its purpose within its environment. Some of these
constraints are imposed inside the system (a limited number of staff available) and others are
imposed by the environment (due dates or regulation)

8. 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 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.

1.3. System Concepts

What is a System?
The word system is widely used. It has become fashionable to attach the word system to add a
contemporary flair when referring to things or processes. People speak of exercise system,
investment system, delivery system, information system, education system, computer system etc.

7
System may be referred to any set of components, which function in interrelated manner for a
common cause or objective.
The word System is derived from Greek word Systema, which means an organized relationship
between any set of components to achieve some common cause or objective.
A system is “an orderly grouping of interdependent components linked together according to a
plan to achieve a specific goal.”
The key term used most frequently. Understanding systems and how they work is critical to
understanding systems analysis and design.
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.

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.4. Fundamentals of Information Systems

Meaning: An information system can be any organized combination of people, hardware,
software, communication software and data resource that collects transformation or screening the
information in an organization.
Definition: An information system can be defined as a set of interrelated components that collect
(or retrieve), process, store and distribute information to support decision making, coordination
and control in an organization.
They are three vital roles that information systems can perform for a business enterprise:

8
  Support of business processes and operations.
 Support of decision making by employees and managers.
 Support of strategies for competitive advantage.
Let‘s look at a typical retail store as a good example of how these roles of IS in business can be
implemented.
Support of Business Processes and Operations: - As a consumer, you regularly encounter
information systems that support the business processes and operations at the many retail stores
where you shop. For example, most retail stores now use computer-based information systems
to help their employees record customer purchases, keep track of inventory, pay employees, buy
new merchandise, and evaluate sales trends. Store operations would grind to a halt without the
support of such information systems.
Support of Business Decision Making: - Information systems also help store managers and
other business professionals make better decisions. For example, decisions about what lines of
merchandise need to be added or discontinued and what kind of investments they require are
typically made after an analysis provided by computer-based information systems.
Support of Strategies for Competitive Advantage: - Gaining a strategic advantage over
competitors requires the innovative application of information technologies. For example, store
management might make a decision to install touch-screen kiosks in all stores, with links to the
e-commerce Web site for online shopping. This offering might attract new customers and build
customer loyalty because of the ease of shopping and buying merchandise provided by such
information systems. Thus, strategic information systems can help provide products and services
that give a business a comparative advantage over its competitors.

1.5. Types of Information System Overviews (DSS, MIS, ES TPS)

The natures and scopes of information required by managers and different levels in an
organization vary considerably. Organization required different types of information system to
meet their needs. The fields of information system have come a long way in last few decades.
Managers at different levels in an organization make different kind of decision (Operational,
tactical and strategic). So, that the types of information necessary to support their decision are
also different. Accordingly different types of information systems are designed to meet various
information needs of managers.

9
There are four types of information systems exist:
1. Transaction processing system (TPS) - are used primarily for structured operational, and to a
lesser degree, management control applications.
2. Management information system (MIS) - are used for semi--structured, management control
applications. It also overlaps into the operational and strategic planning realms as well.
3. Decisions support systems (DSS)- are used primarily for unstructured decision-making
whether that occurs at the operational, management and strategic planning levels.
4. Expert systems (ES) also known as knowledge based system is a software designed to
capture the knowledge and problem solving skills of human expert.

A typical organization is divided into operational, middle, and upper level. The information
requirements for users at each level differ. Towards that end, there are number of information
systems that support each level in an organization.
Pyramid Diagram of Organizational levels and information requirements Understanding the
various levels of an organization is essential to understand the information required by the users
who operate at their respective levels.
The following diagram illustrates the various levels of a typical organization.

Operational Management Level

The operational level is concerned with performing day to day business transactions of the
organization.

10
 Examples of users at this level of management include cashiers at a point of sale, bank
tellers, nurses in a hospital, customer care staff, etc.
Users at this level use make structured decisions. This means that they have defined rules that
guide them while making decisions.
For example, if a store sells items on credit and they have a credit policy that has some set
limit on the borrowing. All the sales person needs to decide whether to give credit to a
customer or not are based on the current credit information from the system.
Tactical Management Level
This organization level is dominated by middle-level managers, heads of departments,
supervisors, etc. The users at this level usually oversee the activities of the users at the
operational management level.
Tactical users make semi-structured decisions. The decisions are partly based on set
guidelines and judgmental calls.
As an example, a tactical manager can check the credit limit and payments history of a
customer and decide to make an exception to raise the credit limit for a particular customer.
The decision is partly structured in the sense that the tactical manager has to use existing
information to identify a payments history that benefits the organization and an allowed
increase percentage.
Strategic Management Level
This is the most senior level in an organization. The users at this level make unstructured
decisions. Senior level managers are concerned with the long-term planning of the
organization.
They use information from tactical managers and external data to guide them when making
unstructured decisions.

11
 1. Transaction Processing System (TPS)
Transaction processing systems are used to record day to day business transactions of the
organization. They are used by users at the operational management level. The main objective of
a transaction processing system is to answer routine questions such as;
 How printers were sold today?
 How much inventory do we have at hand?
 What is the outstanding due for John Doe?
By recording the day to day business transactions, TPS system provides answers to the above
questions in a timely manner.
 The decisions made by operational managers are routine and highly structured.
 The information produced from the transaction processing system is very detailed.
Examples of transaction processing systems include
 Point of Sale Systems – records daily sales
 Payroll systems – processing employees salary, loans management, etc.
 Stock Control systems – keeping track of inventory levels
 Airline booking systems – flights booking management

2. Management Information System (MIS)

Management Information Systems (MIS) are used by tactical managers to monitor the
organization's current performance status. The output from a transaction processing system is
used as input to a management information system.
The MIS system analyzes the input with routine algorithms i.e. aggregate, compare and
summarizes the results to produced reports that tactical managers use to monitor, control and
predict future performance.

12
For example, input from a point of sale system can be used to analyze trends of products that are
performing well and those that are not performing well. This information can be used to make
future inventory orders i.e. increasing orders for well-performing products and reduce the orders
of products that are not performing well.
Examples of management information systems include
 Sales management systems – they get input from the point of sale system
 Budgeting systems – gives an overview of how much money is spent within the
organization for the short and long terms.
 Human resource management system – overall welfare of the employees, staff turnover,
etc.
Tactical managers are responsible for the semi-structured decision. MIS systems provide the
information needed to make the structured decision and based on the experience of the tactical
managers, they make judgement calls i.e. predict how much of goods or inventory should be
ordered for the second quarter based on the sales of the first quarter.

3. Decision Support System (DSS)

Decision support systems are used by senior management to make non-routine decisions.
Decision support systems use input from internal systems (transaction processing systems and
management information systems) and external systems.
The main objective of decision support systems is to provide solutions to problems that are
unique and change frequently. Decision support systems answer questions such as;
 What would be the impact of employees' performance if we double the production lot at the
factory?
 What would happen to our sales if a new competitor entered the market?
Decision support systems use sophisticated mathematical models, and statistical techniques
(probability, predictive modeling, etc.) to provide solutions, and they are very interactive.
Examples of decision support systems include
 Financial planning systems – it enables managers to evaluate alternative ways of achieving
goals. The objective is to find the optimal way of achieving the goal. For example, the net
profit for a business is calculated using the formula Total Sales less (Cost of Goods +
Expenses).

13
 Bank loan management systems – it is used to verify the credit of the loan applicant and
predict the likelihood of the loan being recovered.

4. Expert systems (ES)

Expert systems (ES) also known as knowledge based system is a software designed to capture
the knowledge and problem solving skills of human expert.
Main characteristics of expert systems are:
 An expert system is a program designed to capture the knowledge and problem solving of
human expert. Expert system is a branch of artificial intelligence.
 Expert systems handle problem that require knowledge, intuition, and judgment.
 It has three main components: the knowledge base which stores the knowledge, the inference
engine, which stores the reasoning principles used by the expert, and the user interface,
which allows the user to interact with the system.
Expert systems are not designed for any one level of management; their primary function is to
disseminate expertise throughout the organization.

1.6. System and System Analyst

 Systems analyst is key person in the Systems Development Life Cycle (SDLC)
 This person analyzes the business situation, identifies opportunities for improvements, and
designs an information system to implement the improvements
 Primary goal of a systems analyst is to create value for the company, which usually means
increasing profits
 In short, systems analysts do things and challenge the current way the organization works

The Systems Analyst

 Works closely with all project team members so that the team develops the right system in an
effective way
 SA’s must understand how to apply technology to solve business problems
 They must additionally 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

Systems Analyst Skills

14
 Leadership
 Understanding what needs to change
 Lobbying others to agree that these current methods need to be changed
 Business skills help the Systems Analyst understand the organization’s existing technical
environment
 Work ethically and honestly

A systems analyst is an information technology (IT) professional who specializes in analyzing,

designing and implementing information systems.
Systems analysts assess the suitability of information systems in terms of their intended
outcomes and liaise with end users, software vendors and programmers in order to achieve these
outcomes.
A systems analyst is a person who uses analysis and design techniques to solve business
problems using information technology. 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 will often evaluate and modify code as well as review scripting.
A system analyst is responsible for analyzing, designing and implementing systems to fulfil
organizational needs. He/she plays a vital role in making operational the management
information system.
Systems analysts need to be able to understand humans' needs in interacting with technology,
and they need enough computer experience to program, to understand the capabilities of
computers, to glean information requirements from users, and to communicate what is needed to
programmers.
System analysist is important because it provides an avenue for solutions in the system through
the various tasks involved in doing the analysis. Through these various tasks, the overall quality
of a system can be easily modified or improved and occurrences of errors can ultimately be
reduced.

Roles of System Analyst:

Systems Analyst
 Focuses on the IS issues surrounding the system

15
 Develop ideas and suggestions for ways that IT can support and improve business processes
 Design the new IS and ensure that all IS standards are maintained
 Has significant training & experience in analysis design and programming
Business Analyst
 Focuses on the business issues surrounding the system
 Helps identify the value the system will create, develops ideas for improving the business
processes, and helps design these new policies
Requirements Analyst
 Focuses on evoking the requirements from stakeholders associated with the new system
 Understand the business well, are excellent communicators, and are highly skilled in an
array of requirements and evocation techniques
Infrastructure Analyst
 Focuses on technical issues surrounding the ways the system will interact with the
organization’s technical infrastructure (hardware, software, networks, and databases)
 Ensures that the new IS conforms to organizational standards
 Significant training in networking, database admin, various hardware & software products
 May eventually assume the role of software architect
Change Management Analyst
 Focuses on the people and management issues surrounding the system installation
 Ensures that adequate documentation and support are available to users, provides user
training on the new system, develops strategies to overcome resistance to change
 Significant training in org. behavior
Project Manager
 Ensures that the project is completed on time and within budget, and that the system delivers
expected value to the organization
 Often a seasoned analyst who has acquired specialized project management knowledge and
skills

CHAPTER TWO

16
 INFORMATION SYSTEMS DEVELOPMENT PROJECT
2.0. Introduction
Project:-is a series of related jobs usually directed toward some major output and requiring a
specified period of time to perform.
A project is a planned undertaking of a series of related activities to reach an objective that has a
beginning and end.

A project is characterized by: -

 Having an identifiable beginning and an end
 Having identifiable clients
 Having objectives
 Having constraints
 Requiring individual, continual management

 Project Management: It is the process of leading the work of a team to achieve goals and
meets success criteria at specified time.
 Project management is the most important aspect of the systems development.
 Need to know Project management skills more detail about resources management,
Project management, change management, risk management.
 The focus of project management is to assure that system development projects meet
customer expectations and are delivered within budget and time constraints.
 The primary challenge of project management is to achieve all of the project goals within
the given constraints.

2.1. Managing Information System Project

 Project manager refers to systems analyst role in managing information systems project
 Project manager work in an environment of change.
 He identifies and solves problems
 He responsible for all aspects of a systems development project (time, cost, progress,
etc.)
 He responsible either as a part or the whole project
 Systems analyst has specific task ( identify requirements, allocate budget and keep timing
constraints)

17
 In some organizations the project manager is a senior systems analyst who "has been
around the block" a time or two.
 Creating and implementing successful projects require managing resources, activities, and
tasks needed to complete the information systems project.
 The first question you might ask yourself is
 "Where do projects come from?"
 There is no standard and answer varies from organization to organization
 Several projects may be submitted and need selection by filling a ‘Systems Service
Requests’
 During project identification and selection the need for a new or enhanced system is
recognized.
 Project identification and selection is a pre-project step in the life cycle.
 Organizations vary in as to how they identify potential projects.

 Project manager is an individual with a diverse set of skills who is responsible for
managing the project process when the project is accepted
 Many of the skills are related to personnel or general management, not simply technical
skills.
 The project manager is a systems analyst with a diverse set of skills.
 Skills of project manager: They include:-
 Leadership
 Management (resources, materials, funding)
 Customer relationship
 Technical problem solving
 Conflict management
 Team management and risk & change management.
 Skills needed by a project manager go beyond just building a systems

In summary, development projects are undertaken for three primary reasons;

 To solve business problems (Develop a MIS)
 To take advantage of business opportunities (Develop BIS)

18
  Other non-rational reason: spend existing available resources, training and enhancing
skills of employees.

2.2. Information Systems Project Phase

 Determining the size, scope, resource requirements for a project are just a few of the many
activities that a project manager must involve.
 A project manager is a person who is responsible for initiating, studying, planning,
executing, and closing down a project.
 The project management process involves four phases:
1. Initiating the project
2. Planning the project
3. Executing the project & Performance Monitoring
4. Closing down the project
 Several activities must be performed during each of these four phases.

Project management

 Project management is the controlled process of initiating, planning, executing and closing-
down a project.

Phase-1 Project Initiation

1. Project Initiation: the project manager performs several activities that assess the size, scope,
and complexity of the project & establish procedures to support latter project activities.

19
The Activities are:
1. Establishing the project initiation team.
 Size: identify project team members who will work with in the project
2. Establishing a relationship with the customer.
 Develop good work relationship & trust between customers or users of the project & the
IS development group ( project team) before the project
 Helps customers to understand their problems they might face & propose improvement
3. Establishing the project initiation plan.
 Defines the scope (objective) of the project (even objectives are unsure)
 Assign objective to project team members
 Defines role of each members in the project
 The two core team members of the project needed to define when and how they would
communicate, define deliverables and project steps, and set deadlines.
 These steps eventually led to the creation of their System Service Request (SSR) form.
4. Establishing management procedures
 Successful projects require the development of effective management procedures.
 In some organizations, many of the mgt procedure would be established as standard
operating procedure.
 In establishing procedures, you are concerned with developing.
 Team communication and reporting procedure,
 Job assignments and roles, project change procedures, and
 Determining how project funding and billing will be handled.
 Regulators procedures
 Procedures exist or need to be created
5. Establishing the project management environment and project workbook.
 The focus to this activity is to collect and organize the tools that you will use while managing
the project and to construct the project workbook.
 Establishing an environment that includes data related project called workbook
 Performing the workbook is one important task of project manager
 Workbook can be on line ( a web site as SIMNET) or a hard copy repository that contain
 All project correspondence: minutes, deliverables, inputs, outputs
 Deliverables and reports
20
  Standard to performing audits
 Management procedures
 Post project review meeting (future)
 Workbook are on line in order to allows different partner to access the content through
different location

Phase-2 : Project planning

 Project planning involves defining clear, discrete activities and the work needed to
complete each activity within a single project (identify time, input and output)
 Project planning is different than Information System Planning (ISP)
 ISP focuses on assessing the Information System needed of entire organization
 There is positive relationship between effective project planning and better project
outcomes.
 In actual fact, you often have to construct longer-term plans that are more general in
scope and nearer term plans that are more detailed.
 Varied and numerous activities will be performed during project planning.
a. Describing project scope, alternatives, and feasibility
 The purpose of this activity is to understand the content and complexity of the project.
 The scope answer the following question
 What problem or opportunity does the project address?
 What are the quantifiable results to be achieved?
 How will success be measured?
 How will we know when we are finished?
 What criteria to be used in order to ensure the project are completed?
 After defining the scope of the project, identify and document general alternative solution
for the current business problem or opportunity.
 You must then assess the feasibility of each alternative solution and choose which to
consider during subsequent SDLC phases
 Make decision about the planed solution

 In some instances, standard software can be found.

21
  It is also important that any unique problems, constraints, and assumptions about the
project be clearly stated.

b. Dividing the project into manageable tasks and logical order

 Is called “Work breakdown” structure.
 Require to decompose SDLC phases into activities and activities into tasks
 SDLC include 6 phases. Each phase involves many activities;
Each activities involves many tasks. E.g. during phase 3 of SDLS,
 Activities = develop data and process flow
 Tasks = interviewing manager, identifying process and data inflow, outflow and
transformation, etc.
 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.
 Some tasks may be performed in parallel where as others must follow one another
sequentially.
 Defining tasks in too much detail will make the management of the project unnecessarily
complex.
 For example, it may be very difficult to list tasks that require less than one hour of time to
complete in a final work breakdown structure.

c. Estimating resources and creating a resource plan.

 Estimate resource requirements: how-many manpower, money, software tools, are
required to complete the project?
 Resource planning is the estimation of the resource, with in each activity needed to
complete the project
 Time allocated to tasks depend on people assignment to tasks.
 Project time estimates for task completion and overall system quality are significantly
influenced by the assignment of people to tasks.
 One approach to assigning tasks is to assign a single task type to each worker for the
duration of the project.

 Remark: a person could be assigning to more than one tasks his own area of expertise

22
d. Developing preliminary schedule.
 Preliminary schedule = tasks + time + people within each activity of work breakdown
structure
 Using the information on tasks and resource availability assign time estimates by to
creating target starting and ending dates for the project.
 Target dates can be revised and modified until a schedule produced is acceptable to the
customer.
 The schedule may be represented as a Gantt chart or as a Network diagram (PERT) chart.
 This schedule may be using the Grant and the PERT chart
e. Developing a communication plan.
 Outline the communication procedures among management, project team members, and
the customer.
 The communication plan includes when and who written and oral reports will be
provided by the team,
 When & how different role will communication
 When & how written and oral presentation will be provided by the team
 How many deliverable (official reports) and when should be written (set deadline)
 Define agenda for meeting and set deadlines ( small & big meeting)

f. Determining project standards and procedures.

 You will specify how various deliverables are produced and tested by you and your
project team.
 For example, the team must decide:
 which tools to use
 how the standard SDLC might be modified,
 What approaches will be used (JAD, Prototyping, etc.)
 How different team will report (horizontal or vertical)?
 which SDLC methods will be used
 Documentation styles (e.g., type fonts and margins for user manuals).
 Setting project standards and procedures for work acceptance is a way to assure the
development of a high-quality system.

23
g. Identifying and assessing risks
 It identifies sources of project risk and to estimate the consequences of those risks.
 It identifies sources of project risk and their expected impact.
 Source of Risk might arise:
 From the use of new technology,
 Users' resistance to change,
 Availability of insufficient resources,
 Team member inexperience

h. Create a preliminary budget/ Creating a cost benefit analysis.

 Estimate project cost of the and sometimes the revenues of the project (show revenues is
greater than cost)
 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.
 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.

i. Developing a Statement of Work (for customer)

 It is a short description of work to be done & expected deliverables
 Give clear idea to all project team and customer about the project size
 It is developed primarily for the customer.
 This document outlines work that will be done and clearly describes what the project will
deliver.
 The statement of Work is useful to make sure that you, the customer, and other project
team members have a clear understanding of the intended project outcomes.

j. Setting a Baseline Project Plan

 Contain resource, time and manpower (resource requirements)
 Is used to guide the executing phase or to update it when change happen
 Once all of the projects planning activities have been completed, you will be able to
develop a baseline project plan.

24
  This baseline plan provides an estimate of the project's tasks and resource, time and
manpower (resource requirements) and is used to guide in next project phase - execution.
 Is used to guide the executing phase or to update it when change happen
 As new information is acquired during project executions, the baseline plan will continue
to update.

K. Milestone with a review meeting

 Propose modification and update if needed –→ back to previous activities

Phase-3 : Executing the Project

 Project Execution: it consists to puts the baseline Project Plan into action.
 Project execution occurs primarily during the analysis, design, and implementation phase.
 The project manager is responsible for five key activities during project execution.
Five key Activities during executing phase
a. Executing the Baseline Project Plan
 Keep the project on schedule, and
 Assure the quality of project deliverables
 Motivate people and increase the work team; think as one members
 You initiate the execution of project activities, acquire and assign resources; orient and
train new team members, keep the project on schedule, and assure the quality of project
deliverables.
 You are responsible for initiating new team members by providing them with the
resources they need and helping them assimilate into the team.
 Regular team project status meeting, team-level reviews of project deliverables, and other
group events to mold the group into an effective team.
b. Monitoring Project Progress against the Baseline Project Plan.
 While you execute the Baseline Project Plan, you should monitor your progress.
 Enable modification to current Plans when needed
 If the project gets ahead of (or behind) schedule, you may have to adjust resources,
activities, and budgets.
 Evaluate efficiency of project team member

25
  Measuring the time and effort expended on each activity will help you improve the
accuracy of estimations for future projects.
 E.g. if one dependency activity is changed, you have o undertake the impact on the other
related activities
 PERT and Gantt will help you to fast undertaking changes
c. Managing changes to the Baseline Project Plan.
 Manage the change if it has to occur
 Managing change requires three steps
 Request a change
 Accept change
 Apply change order
 PERT and Gantt charts can be used to undertaking changes
 You will encounter pressure to make changes to the baseline plan.
 You include only approved changes to the project specification, all changes must be
reflected in the baseline plan and project workbook.
 A formal change request must be submitted and approved by the steering committee.
 The request should explain why changes are desired and describe all possible impacts on
prior and subsequent activities, project resources, and the overall project schedule.
 In addition to changes occurring through formal request, changes may also occur from
events outside your control.

d. Maintaining project workbook

 Maintain complete records of all project events.
 Update the workbook as the project progress
 The workbook provides the documentation new team members require to integrate
project tasks quickly.
 It explains why design decisions were made and is a primary source of information for
producing all project reports.

e. Communicating the project status.

 Keep involved roles informed about the latest development of the project
 There are three types of communication (communication is useful for)

26
  Solving issues through oral presentation
 Informing others through e-mails
 Keeping permanent storage of records (of written documents)
 The project manager is responsible for keeping all team abreast of the project status.
 Clear communication is required to create a shared understanding of the activities and
goals of the project; such an understanding assures better coordination of activities.
 Procedures for communication project activities vary from formal meeting to
informal hallway discussions.
 The ease with which the project can be managed is significantly influenced by the quality
of prior phases.
 If you develop a high-quality project plan, it is much more likely that the project will be
successfully executed.

Phase-4 : Closing down the project

Project closedown: is to bring the project to an end.
 When does a project end?
 If requirements have been all met (normal end)
 If all objectives have been successfully achieved
 Customers’ need are not any more valid in the customer business environment; state-of-
the-art technology is available on the market)
 Running out of money
 Project can conclude with a natural or unnatural termination.
 Several events can cause an unnatural termination to a project. For example,
o it may be learned that the assumption used to guide the project proved to be false
or
 the performance of the system or development group was somehow inadequate.
 the requirements are no longer relevant or valid in the customer’s business environment.
 The most likely reasons for the unnatural termination of a project relate to running out of
time or money, or both
 The performance of the system or development group was somehow inadequate.
 Regardless of the project termination outcome, several activities must be performed.

27
  Within the context of the SDLC, project closedown occurs after the implementation
phase.

a. Closing down the project.

 Inform all members about the project end during a review meeting
 Project completion may signify job and assignment changes for some members.
 Assess each team member and provide an appraisal for personnel files and salary
determination.
 Write letters to superiors, praising special accomplishments of team members, and send
thank-you letters to those who helped but were not team members.
 Notify all interested parties that the project has been completed.
 Finalize all project documentation and financial records so that a final review of the
project can be conducted.
 You should also celebrate the accomplishments of the.

b. Conducting post-project review

 Final review of the project would be conducted with management and customers to
assess project’ strengths and weakness.
 Develop new idea for new projects
 The objective of these reviews is:
o To determine the strengths and weaknesses of project deliverables,
o To evaluate the processes used to create the deliverables, and the project
management process.
 It is important that everyone understands what went right and what went wrong in order
to improve the process for the next project.

c. Closing the customer contract.

 Stop funding and further new projects
 The focus of this final activity is to ensure that all contractual terms of the project have
been met.
 You must gain agreement from your customer that all contractual obligations have been
met.

28
  You must also must agree that further work is either their responsibility or covered under
another System Service Request or contract.
 A project is not complete until it is closed, and it is at closedown that projects are deemed
a success or failure.

2.3. Representing and Scheduling Project plans

 A project manager has a wide variety of techniques available for showing and document
project plans.
 The most commonly used methods are Gantt and or Network diagram PERT (Program
Evaluation Review Technique) Charts.
 Gantt Charts
 Useful for depicting simple projects or parts of large projects
 Show start and completion dates for individual tasks
 Gantt chart is a graphical representation of a project that shows each task activity
as a horizontal bar who is proportional to its time for completion.
 Network Diagrams
 Show order of activities
 PERT chart is a diagram that represents project activities & their dependencies

Figure 2.1a Graphical Diagrams That Depict Project Plans – A Gantt chart.

Figure 2.2b Graphical Diagrams That Depict Project Plans – A Network Diagrams

29
Comparison of Gantt Charts and Network Diagrams
Gantt Charts Network Diagrams
Visually show duration of tasks Visually show dependencies between
tasks
Visually show time overlap between task Visually show which tasks can be
done in parallel
Visually show slacks time Show slack time by date in rectangles

Representing Project Plans

 Project scheduling and management require that time, costs; piece of equipment, or material
used in accomplishing an activity.
 Network diagram (PERT) is a critical path scheduling technique used for controlling
resources and timing
 PERT = Program Evaluation Review Technique
 It allows to determines critical path scheduling and Slack Time
 Critical path scheduling is a scheduling plan where the order and duration of the
sequence of activities directly affect the completion date of a project
 Critical path is represented by the sequence of connected activities that produces the
longest overall time period
 It represents the shortest time to complete a project

30
  Slack time refers to the amount of time that an activity can be delayed without delaying
the project duration
 Network diagram is best-known scheduling methods.

Calculating Expected Time Duration using PERT

ET =

 Where
 ET= expected time for the completion for an activity
 o=optimistic completion time for an activity
 r= realistic completion time for an activity
 p= pessimistic completion time for an activity
 Calculate an expected time for the completion of an upcoming programming assignment.
For this assignment, you estimate an optimistic time of 2 hours, a pessimistic time of 8
hours, and a most likely time of (r) 6 hours. Using PERT, how much is the expected time
for completing this assignment.

Constructing a Gantt Chart and Network Diagram

 Steps
 Identify each activity
 Requirements Collection
 Screen Design
 Report Design
 Database Design
 User documentation
 Software programming
 Installation and testing

Gantt Chart and Network Diagram for GM Furniture

1. Determine time estimates and expected completion times for each activity.

31
Figure 2.2 Expected Time Calculations for the SPSTS Project

Gantt Chart and Network Diagram for GM Furniture

3. Determine sequence of activities

Figure 2.3 Sequence of activities within the SPSTS Project

Gantt Chart and Network Diagram for GM Furniture

Figure 2.3 A Network Diagram That Illustrates the Activities (Circles) and the Sequence of
(Arrows) of Those Activities.

32
Gantt Chart and Network Diagram for GM Furniture

4. Determine critical path

 Sequence of events that will affect the final project delivery date

2.4. Commercial Project Management Software

 Many systems are available
 Three activities required to use:
 Establish project start or end date
 Enter tasks and assign task relationships
 Select scheduling method to review project reports

33
Summary
 Skills of an effective project manager
 Activities of project manager
 Initiation
 Planning
 Execution
 Closedown
 Gantt Charts and Network Diagrams
 Commercial PM Software

34
 CHAPTER THREE
THE SYSTEM DEVELOPMENT LIFE CYCLE
Introduction
 Organizations use a standard set of steps, called a systems development methodology to
develop and support their information systems.
 The common methodology for systems development is the systems development life cycle
(SDLC).
 It is series of steps used to mark the phases of development for an information system.

The project lifecycle and the various approaches to system development which can be used on IS
projects. These approaches are sometimes more formally termed ‘lifecycle models’. Various
models exist, many of which are developments or refinements of earlier ones.
 It is important to define the terms ‘system development lifecycle’ and ‘project lifecycle’.
 Generally speaking, the system development lifecycle covers the whole life of a system.
This will cover not only feasibility study, analysis, specification, design and development but
also the operation, maintenance and enhancement aspects which take place after the system
has been accepted by the end-users.
 A project can be defined as ‘a management environment set up to ensure the delivery of a
specified business product to meet a defined business case’.
 In terms of systems development, this can generally be taken to mean the delivery of the
specified IS within given constraints of time, cost, resource and quality, but a project may
not cover all stages of the system lifecycle.
 In other words, the project lifecycle covers the delivery of whatever has been defined as
constituting the end-product of the project.
 There is another important difference. The system development lifecycle often covers only
the technical deliverables whereas the project is concerned with all aspects leading to the
delivery of the project’s objectives.

3.1. The Traditional SDLC

Approaches to systems development
6.3.1 The traditional approach to systems development

35
By ‘traditional’ here, we mean unstructured and somewhat non-specific and most traditional
approaches are based on variations of the waterfall model. Although the overall picture will
probably be familiar, the actual methods of developing the systems are almost as numerous as
the projects themselves.
The approach is – or perhaps we should now write ‘was’? – characterized by a general lack
of user involvement, the use of text-based, as opposed to diagrammatic, documentation and an
emphasis on how things are going to be achieved rather than what is going to be achieved.
Although there is a stage-by-stage approach, it is difficult to see how the stages link together or
to follow an audit trail of individual requirements. Typically, in project management terms, there
is no business case or defined acceptance criteria for the system, which makes it difficult to
gauge success or failure. The lack of user involvement is demonstrated in many ways. The users
would be involved at the initial analysis stage but the only point where they would be formally
required to review anything would be when the requirements specification has been completed.
Following this, their next contact with the computer system would probably be when the system
is delivered.
On the other hand, this method of working suited many analysts and users. It allowed the analyst
to use ‘intuitive’ methods of working and made limited demands on the users’ time. The
documentation was relatively easy to understand, being mostly in English, and there were no
special techniques to be learned in order to understand it. Unfortunately, text tends to be
ambiguous and interpreted differently by different people and misunderstandings were common.
This lack of user involvement and ‘ownership’ of the system often resulted in a poor quality
system and an abdication of responsibility by the users and blame for the developers.
1. Traditional software development models: - is regarded as the proper, structured and
disciplined approach to the analysis and design of software applications.
 Generally the standard process followed in an organization consists of:
 Analysis
 Design
 Implementation
 Maintenance
 Such models included the code and fix, waterfall, staged and phased development,
transformational, and spiral models.

36
i. Waterfall Model
 In the waterfall model, system development is broken down into a number of sequential
sections or stages represented by boxes, with each stage being completed before work starts
on the following one. The outputs from one stage are used as inputs to the next.
 Waterfall Development The original structured design methodology (still used today) is
waterfall development.
 With waterfall development–based methodologies, the analysts and users proceed in
sequence from one phase to the next.
 The key deliverables for each phase are typically very long (often hundreds of pages in
length) and are presented to the project sponsor for approval as the project moves from phase
to phase.
 Once the sponsor approves the work that was conducted for a phase, the phase ends and the
next one begins. This methodology is referred to as waterfall development because it moves
forward from phase to phase in the same manner as a waterfall.
 Although it is possible to go backward in the SDLC (e.g., from design back to analysis), it is
extremely difficult (imagine yourself as a salmon trying to swim upstream against a
waterfall, as shown in Figure below.
 The two key advantages of the structured design waterfall approach are:-
 An identifies system requirement long before programming begins and
 It minimizes changes to the requirements as the project proceeds.
 The two key disadvantages are:-
 The design must be completely specified before programming begins and
 That a long time elapses between the completion of the system proposal in the
analysis phase and the delivery of the system (usually many months or years).
 In addition, the deliverables are often a poor communication mechanism, so important
requirements may be overlooked in the volumes of documentation.
 If the project team misses an important requirement, expensive post-implementation
programming may be needed.
 Users may forget the original purpose of the system, since so much time has elapsed between
the original idea and actual implementation.

Very structured, organized approach, suitable for planning, including phases:

37
  Planning and Feasibility study
 Analysis
 Design (overall design & detailed design)
 Implementation and Operation
 With waterfall development- based methodologies, the analysts and users proceed
sequentially from one phase to the next.
 The two key advantages of waterfall development-based methodologies are:
 The system requirements are identified long before programming begins.
 Changes to the requirements are minimized as the project proceeds.

Problem of Waterfall model

 Documentation: each phase requires developing fully elaborated documentation, which
takes too much time
 Frozen User requirements: hard to change user requirements once set during early
phase of projects
 The design must be completely specified before programming begins
 Product not visible until the end of project, where it will be hard to correct mistakes if
uncovered

Figure 3.1 Waterfall model of system Development life cycle

38
ii. Code and Fixing
 Iterative, programmers' approach, involves only two phases:
 Coding: writing the program code
 Fixing the code: running the program and fix errors if they appear while testing the
program with random test data
 Problems:
 Very poor structure,
 Does not match user requirements,
 Difficult to maintain
iii. Parallel Development
 This methodology attempts to address the long time interval between the analysis phase
and the delivery of the system.
 A general design for the entire system is performed and then the project is divided into a
series of distinct subprojects.
 The parallel development methodologies evolved to address the lengthy time frame of
waterfall development.
 As shown in Figure 3.2, instead of doing the design and implementation in sequence, a
general design for the whole system is performed. Then the project is divided into a series
of subprojects that can be designed and implemented in parallel.
 Once all subprojects are complete, there is a final integration of the separate pieces, and
the system is delivered.
 Parallel development reduces the time required to deliver a system, so changes in the
business environment are less likely to produce the need for rework.
 The approach still suffers from problems caused by voluminous deliverables. It also adds
a new problem: If the subprojects are not completely independent, design decisions in
one subproject may affect another, and at the project end, integrating the subprojects may
be quite challenging.

39
iv. Stage and Phased Development
 This methodology breaks the overall system into a series of versions that are developed
sequentially.
 The team categorizes the requirements into a series of versions, then the most important
and fundamental requirements are bundled into the first version of the system.
 The analysis phase then leads into design and implementation; however, only with the set
of requirements identified for version 1.
 As each version is completed, the team begins work on a new version.
Phased Development
 A phased development–based methodology breaks an overall system into a series of
versions, which are developed sequentially.
 The analysis phase identifies the overall system concept, and the project team, users, and
system sponsor then categorize the requirements into a series of versions.

40
 The most important and fundamental requirements are bundled into the first version of the
system.
 The analysis phase then leads into design and implementation but only with the set of
requirements identified for version 1.
 Once version 1 is implemented, work begins on version 2. Additional analysis is per- formed
based on the previously identified requirements and combined with new ideas and issues that
arose from the users’ experience with version 1. Version 2 then is designed and
implemented, and work immediately begins on the next version. This process continues until
the system is complete or is no longer in use.

v. Spiral Model
The spiral model differs from the waterfall model in that it introduces an evolutionary or iterative
approach to systems development.

41
The waterfall model concentrates on a stage-by-stage process with the end-products from one
stage being finalized before the next stage is begun.
The original spiral model was developed by Barry Boehm and it is shown in Figure 3.3. The
project starts at the centre of the spiral and progresses outwards.
At the centre, the requirements will be poorly understood and will be successively refined with
each rotation of the spiral. The total cost of the project will increase as the length of the spiral
increases. The model is divided into four quadrants:
 The top left quadrant is where the objectives are determined and the alternatives and
constraints identified.
 The top right quadrant is where the alternatives are evaluated and the various risks are
identified and resolved.
 The bottom right quadrant is where the development takes place. This ineffect covers the
same area as the more conventional waterfall model.
 The bottom left quadrant is where the next phase or iteration is planned.
The Boehm spiral introduces the important concepts of objective setting, risk management and
planning into the overall cycle. These are all very desirable from a project management point of
view as they apply explicitly to factors which may affect the timely delivery of the system within
its defined constraints.

 Develop system incrementally in several cycles including risk assessment at each cycle.
 Determine objectives, alternatives for development, and constraints for the portion or the
whole system to be developed in the current cycle
 Evaluate alternatives, considering objectives and constraints; identify and resolve risks
 Develop the current cycle's part of the system, using evolutionary or conventional
development methods (depending on remaining risks); perform validation at the end
 Prepare plans for subsequent phases

42
3.2. The Generic System Development Model
 We use generic SDLC as an example methodology in this course.
 The life cycle consists of four phases:
 Planning and Selection
 Analysis
 Design
 Implementation and Operation
 Phases are not necessarily sequential
 Each phase has a specific outcome and deliverable
 Individual companies use customized life cycle.

43
3.2. The Generic System Development Model
System
3.3. Approaches Planning
Systemto System Analysis and Design
Planning
and
and Selection
Selection
3.4. Approach to System Development
3.5. Software Engineering Process

Analysis
Analysis

Design
Design

Implementation
Implementation and
and
operation
operation

Figure 3.2 Generic model of system Development life cycle

Phases of the Systems Development Life Cycle

1. Systems Planning and Selection
 Two Main Activities
a. Identification and selection
 First, someone or group of individuals identifies the need for a new or enhanced system.
 The IS dep’t or the system priority board selects one of the systems based on the priority
set by the analyst.
 The group of systems analyst prioritizes and translates the needs into a written plan for
the IS department or system priority board.
b. Initiation and planning
 The second task systems initiation and planning phase is to investigate the system and
determine the proposed system’s scope.
 The team of systems analysts then produces a specific plan for the proposed project for
the team to follow.

44
  A feasibility study is conducted.

2. Analysis
 In this phase, the analyst thoroughly studies the organization's current procedures and the
information systems used to perform organizational tasks.
 Analysis has several sub phases.
 The first is requirements determination.
 In this sub phase, the analyst work with users to determine what the users want from a
proposed system.
 This baseline project plan customizes the standardized SDLC and specifies the
time and resources needed for its execution.
 This sub phase usually involves a careful study of any current systems, manual and
computerized, that might be replaced or enhanced as a part of this project.
 The second sub phase is, studying the requirements and structure them according to their
interrelationships and eliminate any redundancies.
 Third sub phase, you generate alternative initial designs to match the requirements.
 The final sub phase, 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 (but not a detailed design for) the
alternative solution recommended by the analysis team.

3. Designing the new or enhanced system.

 During design, the description of the recommended alternative solution will be converted
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.
 You must then provide the physical specifics of the system you have designed, either as a
model or as detailed documentation, to guide those who will build the new system.
 That part of the design process that is independent any specific hardware of software
platform is referred to as logical design.
 Turning the logical specifications into physical ones is referred to as physical design.

45
  During physical design, the analyst team must determine many of the physical details
necessary to build the final system.
 The final product of the design phase is the physical system specifications in a form
ready to be turned over to programmers and other system builders for construction.

4. System Implementation and operation.

 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 second part of the fourth phase of the SDLC is operation.
 During operation, programmers make the changes that users ask for and modify the
system to reflect changing business conditions (maintenance).

3.3. Approaches to System analysis & Design

 In actual project implementation, it is difficult to follow the waterfall principle.
 In any given SDLC phase, the project can return to an earlier phase if necessary.
 Sometimes the life cycle is iterative; that is phases are repeated as required until an
acceptable system is found.
 Four approaches that streamline and improve the systems analysis and design process.
 Prototyping
 Rapid application Development (RAD)
 Joint application Designs (JAD)
 Participatory Design (PD)
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 computer-aided software engineering (CASE) tool.
 CASE tool, a software product that automates the systems development life cycle steps.
 CASE tools make prototyping easier and more creative.

46
Figure 3.3 The prototyping methodology
2. Rapid application Development (RAD)
 RAD methodologies emphasize gaining user acceptance of the human-system interface
and developing core capabilities as quickly as possible.
 The fundamental principle of any RAD methodology is to delay producing detailed
system design documents until after user requirements are clear
 Prototyping is a form of rapid application development, or RAD.
3. Joint Application Design
 Users, mangers, and system developers are brought together for a series of intensive
structured meetings.
 The aim of JAD is to collect information system requirements and reviewing system
designs.
 The basic idea behind JAD is to bring structure to the requirements determination phase
of analysis and to the reviews that occur as part of design.
4. Participatory Design
 Participatory Design (PD) represents a viable alternative approach to the SDLC.

47
  PD emphasizes the role of the user much more than traditional structured analysis and
structured design do.
 Each user has an equal voice in determining system requirements and in approving
system design.
 an elected group of users controls the process.
3.4. Approach to System Development
 The analysis and design of computer-based information systems begins in the 1950’s.
 In the 1950’s, the focus of the development effort was on the processes the software
performed. Since computer power was a critical resource, efficiency of processing
become the main goal.
 In the beginning of 1960’s the first procedural or third-generation computer
programming language become available.
 In this years important breakthroughs in technology that enabled the development of
smaller, faster, less-expensive computer were introduced.
 During this time System development was more of an art than a science.
 In 1970’s system development came to be more disciplined as many people worked to
make it more like engineering.
 The development of database management systems helped shift the focus of system
development from processes first to data first

 In 1980’s were also marked by major breakthroughs in computing an organizations, as

microcomputers became key organizational tools.
 Developers began to write more and more application in fourth generation languages,
which unlike procedural languages, instructed a computer on what to do instead of how
to do it.
 Computer-aided software engineering (CASE) tools were developed to make systems
developers’ work easier and more consistent.
 The systems development environment in the late 1990’s focused on systems
integration.
 Today in this new century, there is lot of focus on developing systems for the Internets
and for firms’ Intranets and Extranets.

48
  Although the systems development has changed dramatically since its beginnings in the
1950’s, some basic principles that govern the approach to systems development have
been applicable through all the different areas of computing in organization.
 One principle is the distinction between data, data flows, and processing logic,
 This distinction will be considered in the next sections.
Separating data and processes
 Every information system consists of three key components that must be clearly
understood by anyone who analyzes and designs systems: data, data flows, and
processing logic.
 Data are raw facts that describe people, objects and events in an organization.
 Every information system depends on data in order to produce information, which
is processed data presented in a form suitable for human interpretation.
 Data flows: - are groups of data that move and flow through a system and
include a description of the sources and destinations for each data flow.
 Processing logic: Describe steps that transform data and events that trigger the
steps.

Figure 3.4 Difference among data, data flow and process logic
1. Processes Oriented approach

49
  Traditionally, an information system’s design was based upon what the system was
supposed to do, which billing and inventory control: the focus was on output and
processing logic.
 The focus was on outputs and processing logic
 The data used as inputs were seen as important also, but secondary to the application
 problems with this approach are, first the existence of several files of data each locked
with different applications and programs.
 Each system would contain its own files and data storage areas
 Each systems was considered ( looked at) separately
 The data in each system would match the specifications for that system only
 The construction on the flow, use and transformation of data in an information system
typified the process-oriented approach to systems-development.
 The natural structure of the data is not specified within the traditional process-oriented
approach.

 Data processing managers soon realized that there were problems with analyzing and
designing systems using only a process-oriented approach.
 One result was the existence of several specialized files of data, each locked within
different applications and programs.
 Many of the files in these different application contained the same data elements. When a
single data element changed, it had to be changed in each of these file which normally
difficult.
2. Data Oriented Approach
 Over time the approach changed to being a more data-oriented.

50
 Application independence is the separation of data and the definition of data from the
application that use these data.
 A data model is produced, which describes the data and relationships between the data
 Databases are designed around the subjects such as customers, suppliers, parts
 This approach tends to focus on how the data should be represented independently of
where and how data are used in the system
 It becomes important to standardize how data elements were represented, data processing
managers gradually came to separate the application programs and the data these
programs used.
 The focus on data typified the data-oriented approach to information systems
development.
 The data-oriented approach depicts
 The ideal organization of data, independent of where and how data are used
within a system.
 Result in a data model that describes the kinds of data needed in systems and the
business relationships among the data.
 A data model describe the rules and policies of a business.
 It is believed a data model to be more permanent than a process model since a
data model reflects the inherent nature of a business instead of the way a business
operates which constantly changing.
 Due to advancement in data storage mgt. technology, it has become possible to represent
data not in separate files for each application but in coherent and shared databases.
 A database is a shared collection of logically related data organized in ways that facilitate
capture, storage, and retrieval for multiple users in an organization.
 Under the data-oriented approach to system development, databases are designed around
subjects, such as customers, suppliers, and parts.
 Designing data bases around subjects enables you to use and revise databases for many
different independent applications.

51
3. Object-Oriented Analysis and Design
 OAD is often called the third approach to system development, after the process-oriented
and data-oriented approaches.
 The object-oriented approach combines data and processes (called methods) into single
entities called objects.

52
  Objects usually correspond to such as customers, suppliers, contracts and rental
agreements.
 Putting data and processes together in one place
 Another key idea behind object-orientation is that of inheritance.
 Objects are organized into object classes, which are groups of objects sharing structural
and behavioral characteristics.
 Inheritance allows the creation of new classes that share some of the characteristics of
existing classes.
3.5. Software Engineering Process
 In the early years of computing, analysis and design was considered to be an art.
 The techniques employed by each developer could vary substantially.
 This brings lack of consistency in technique and methodology often made it difficult to
integrate system and data.
 To address these problems, information system professionals concluded that software
development needs an engineering discipline.
 The goal was to concentrate on developing common
 technique,
 standard methodology, and
 automated tools
 Methodologies are comprehensive multiple-step approaches to systems development that
will guide your work.
 Techniques are particular processes that are followed to ensure that work is well thought-
out, complete and comprehensible to others on the project team.
 Tools Computer programs to assist in application of techniques to the analysis and design
process.
CASE tools and its components
 The purpose of CASE is to make it much easier to enact a single design philosophy
within an organization.
 Case can support most of the system development activities; Planning and selection,
Analysis, Design, and Implementation and operation.
 In general, CASE assists systems builders in managing the complexities of information
system projects.
53
 Groups of case tools are
 Upper CASE tools designed to support the system planning and selection (project
identification and selection, project initiation and planning), analysis, and design phases
of the SDLC.
 Lower CASE tools designed to support the implementation and maintenance phases of
the systems development life cycle.
 Cross life-cycle CASE tools designed to support activities that occur across multiple
phases of the SLDC.
 Most CASE tools utilize a repository to store all diagrams, forms, models and report
definitions.
 Types of CASE tools
 Diagramming tools
 Computer display and report generators
 Analysis tools used to check for incomplete, inconsistent or incorrect
specifications
 A central repository
 Documentation generators
 Code generators
 Security Features
 Secure your system specifications so that project teams may not access your
system requirements, design, and code.
 Version Control
 Allows one repository to contain the description of several versions the same
application system.
 Import/Export
 Automatically move data between the CASE repository and other software
development tools.
 Backup and Recovery
 Backup and disaster recovery facility are available as shared development
database

54
 CHAPTER FOUR
SYSTEM SELECTION AND PLANNING
Chapter outline
4.1. Identifying and Selecting Projects
4.2. Initiating and Planning System Development Project
4.3. Assessing Project Feasibility
4.4. Building the Baseline Project Plan
4.5. Electronic Commerce Application

Introduction
 The first phase of the systems development life cycle is systems planning and selection
that deals with:
 Identifying, selecting, initiating, and planning projects.
 There are two primary activities in this phase:
 General method for identifying and selecting projects and
 Project initiation (beginning) and planning, and present several techniques for
assessing project feasibility.

4.1. Identifying and Selecting Projects

 The first step is to identify the need for a system, which can be the result of:
 Problems in existing system or process
 New feature required in an existing system
 A new idea for which in Information System is required
 A requirement to improve efficiency in the organization
 Compulsory standards or bench marks by an external organization Ex. Government
 The need to keep up with competitors

The first activity of the systems planning and selection phase of the SDLC is project
identification and selection.
 During this activity, a senior manager, a business group, an IS manager, or a steering
committee identifies and assesses all possible systems development projects that a business
unit could undertake.

55
 Next, those projects deemed most likely to yield significant organizational benefits, given
available resources, are selected.
 Organizations vary in their approach to identifying and selecting projects. In some
organizations, project identification and selection is a formal process in which projects are
outcomes of a larger overall planning process.
 For example, a large organization may follow a formal project identification process that
involves rigorously comparing all competing projects.
 Alternatively, a small organization may use informal project selection processes that allow
the highest-ranking IS manager to select projects independently or allow individual business
units to decide on projects after agreeing on funding.

Requests for information systems development can come from three key sources:-
1. Managers and business units who want to replace or extend an existing system in order to
gain needed information or to provide a new service to customers
2. Information systems managers who want to make a system more efficient, less costly to
operate, or want to move a system to a new operating environment
3. Formal planning groups that want to improve an existing system in order to help the
organization meet its corporate objectives, such as providing better customer service.

Figure 4-1: Three key sources for information systems projects.

56
Regardless of how an organization executes the project identification and selection process, a
common sequence of activities occurs. In the following sections, we describe a general process
for identifying and selecting projects, and producing the deliverables and outcomes of this
process.

The Process of Identifying and Selecting Information Systems Development Projects

Project identification and selection consists of three primary activities:
 Identifying potential development projects,
 Classifying and ranking projects, and
 Selecting projects for development.

1. Identifying potential development projects. Organizations vary as to how they identify

projects. This process can be performed by:
 A key member of top management, either the CEO of a small or medium-size
organization or a senior executive in a larger organization
 A steering committee, composed of a cross section of managers with an interest in
systems
 User departments, in which either the head of the requesting unit or a committee from
the requesting department decides which projects to submit (as a systems analyst, you
will help users prepare such requests)
 The development group or a senior IS manager

Project sources identified by top management and steering committees are:-

 Most often reflect the broader needs of the organization.
 Have a better understanding of overall business objectives and constraints.
 Focus is on global/strategic needs of organization
 Referred to as coming from a top-down source.
Projects identified by a functional manager, a business unit, or the information systems
development group are:-
 often designed for a particular business need within a given business unit and
 Don’t reflect overall goals of the organization.
 Referred to as coming from a bottom-up source.
Projects identified by individual departments or business units

57
  Have a narrow, tactical focus.

These descriptions are evaluated in selecting which projects will be approved to move into the
project initiation and planning activities.
In sum, projects are identified by both top-down and bottom-up initiatives. The formality of
identifying and selecting projects can vary substantially across organizations. Because limited
resources preclude the development of all proposed systems, most organizations have some
process of classifying and ranking each project’s merit.

2. Classifying and ranking IS development projects.

 Assessing the merit of potential projects is the second major activity in the project
identification and selection phase.
 As with project identification, classifying and ranking projects can be performed by top
managers, a steering committee, business units, or the IS development group.
 The criteria used to assign the merit of a given project can vary based on the size of the
organization. As with project identification, the criteria used to evaluate projects will vary by
organization.
 If, for example, an organization uses a steering committee, it may choose to meet monthly or
quarterly to review projects and use a wide variety of evaluation criteria. At these meetings,
new project requests are reviewed relative to projects already identified, and ongoing projects
are monitored. The relative ratings of projects are used to guide the final activity of this
identification process—project selection.

Table 4-1 summarizes the criteria commonly used to evaluate projects.

Evaluation Criteria Description
Value chain analysis Extent to which activities add value and costs when developing products
and/or services; information systems projects providing the greatest overall
benefits will be given priority over those with fewer benefits
Strategic alignment Extent to which the project is viewed as helping the organization achieve its
strategic objectives and long-term goals
Potential benefits Extent to which the project is viewed as improving profits, customer service,
etc., and the duration of these benefits
Resource availability Amount and type of resources the project requires and their availability
Project size/duration Number of individuals and the length of time needed to complete the project

58
Technical Level of technical difficulty to complete the project successfully within given
difficulty/risks time and resource constraints
Table 4-1: Possible Evaluation Criteria When Classifying and Ranking Projects

3. Selecting IS development projects

The selection of projects is the final activity in the project identification and selection phase.
The short- and long-term projects most likely to achieve business objectives are considered. As
business conditions change over time, the relative importance of any single project may
substantially change. Thus, the identification and selection of projects is an important and
ongoing activity.

Numerous factors must be considered when selecting a project, as illustrated in Figure 4-3.
These factors include:
 Perceived needs of the organization
 Existing systems and ongoing projects
 Resource availability
 Evaluation criteria
 Current business conditions
 Perspectives of the decision makers

This decision-making process can lead to numerous outcomes. Of course, projects can be
accepted or rejected.
 Acceptance of a project usually means that funding to conduct the next SDLC activity has
been approved.
 Rejection means that the project will no longer be considered for development.
 However, projects may also be conditionally accepted; projects may be accepted pending
the approval or availability of needed resources or the demonstration that a particularly
difficult aspect of the system can be developed.
 Projects may also be returned to the original requesters who are told to develop or purchase
the requested system themselves.
 Finally, the requesters of a project may be asked to modify and resubmit their request after
making suggested changes or clarifications.

59
Figure 4-2:- Numerous factors must be considered when selecting a project. Decisions can result
in one of seven outcomes.

Deliverables and Outcomes

The primary deliverable, or end product, from the project identification and selection phase is a
schedule of specific IS development projects.
 These projects come from both top-down and bottom-up sources, and once selected they
move into the second activity within this SDLC phase—project initiation and planning. This
sequence of events is illustrated in Figure 4-3.
 An outcome of this activity is the assurance that people in the organization gave careful
consideration to project selection and clearly understood how each project could help the
organization reach its objectives.
 Because of the principle of incremental commitment, a selected project does not
necessarily result in a working system.
 Incremental commitment means that after each subsequent SDLC activity, you, other
members of the project team, and organization officials will reassess your project. This
reassessment will determine whether the business conditions have changed or whether a
more detailed understanding of a system’s costs, benefits, and risks would suggest that the
project is not as worthy as previously thought.

60
Figure 4-3- Information systems development projects come from both top-down and
bottom-up initiatives.

4.2. Initiating and Planning Systems Development Projects

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, and including systems
analysis.
 For example, a careful feasibility analysis conducted during initiation and planning could
lead to rejecting a project and saving a considerable expenditure of resources. The actual
amount of time expended will be affected by the size and complexity of the project as well as
by the experience of your organization in building similar systems.
 A rule of thumb is that between 10 and 20 percent of the entire development effort should
be expended on initiation and planning. In other words, you should not be reluctant to spend
considerable time and energy early in the project’s life in order to fully understand the
motivation for the requested system.

61
 Most organizations assign an experienced systems analyst, or team of analysts for large
projects, to perform project initiation and planning.
 The analyst will work with the proposed customers—managers and users in a business
unit—of the system and other technical development staff in preparing the final plan.
 Experienced analysts working with customers who well understand their information services
needs should be able to perform a detailed analysis with relatively little effort.
 Less experienced analysts with customers who only vaguely understand their needs will
likely expend more effort in order to be certain that the project scope and work plan are
feasible.
 The objective of project initiation and planning is to transform a vague system request
document into a tangible project description, as illustrated in Figure 4-5.
 Effective communication among the systems analysts, users, and management is crucial to
the creation of a meaningful project plan. 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.

62
Figure 4-4:- The systems analyst transforms a vague systems request into a tangible project
description during project initiation and planning.

The Process of Initiating and Planning Systems Development Projects

 As its name implies, two major activities occur during project initiation and project
planning.
 Project initiation focuses on activities that will help organize a team to conduct project
planning. During initiation, one or more analysts are assigned to work with a customer to
establish work standards and communication procedures. Table 4-2 summarizes six activities
performed during project initiation.
 The second activity, project planning, focuses on defining clear, discrete tasks and the work
needed to complete each task.
 The objective of the project planning process is to produce two documents:
 A baseline project plan (BPP) and
 The project scope statement (PSS)

63
  The BPP becomes the foundation for the remainder of the development project. It is an
internal document used by the development team but not shared with customers.
 Baseline project plan (BPP):- One of the major outcomes and deliverables from the
project initiation and planning phase. It contains the best estimate of the project’s scope,
benefits, costs, risks, and resource requirements.
 The PSS, produced by the project team, clearly outlines the objectives of the project
for the customer. As with the project initiation process, the size, scope, and complexity
of a project dictate the comprehensiveness of the project planning process and the
resulting documents.
 Further, numerous assumptions about resource availability and potential problems will
have to be made. Analysis of these assumptions and system costs and benefits forms a
business case. Table 4-3 lists the activities performed during project planning.

Deliverables and Outcomes

The major outcomes and deliverables from project initiation and 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’s
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 subsequent project phases (because these depend on the
results of the analysis phase). Similarly, benefits, costs, risks, and resource requirements will
become more specific and quantifiable as the project progresses. The project selection
committee uses the BPP to help decide whether to continue, redirect, or cancel a project. If
selected, the BPP becomes the foundation document for all subsequent SDLC activities;
however, it is updated as new information is learned during subsequent SDLC activities.

TABLE 4-2: Types of Activities Performed during Project Initiation

 Establishing the project initiation team
 Establishing a relationship with the customer
 Establishing the project initiation plan
 Establishing management procedures

64
 Establishing the project management environment and project workbook
 Developing the project charter

TABLE 4-3: Activities 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

4.3. Assessing Project Feasibility

Most information systems projects have budgets and deadlines. Assessing project feasibility is a
required task that can be a large undertaking because it requires you, as a systems analyst, to
evaluate a wide range of factors. Although the specifics of a given project will dictate which
factors are most important, most feasibility factors fall into the following six categories:
 Economic
 Operational
 Technical
 Schedule
 Legal and contractual
 Political
The analysis of these six factors forms the business case that justifies the expenditure of
resources on the project. In the remainder of this section, we examine various feasibility studies,
beginning with economic feasibility.

To help you better understand the feasibility assessment process, we examine a project at Pine
Valley Furniture. Jackie Judson, Pine Valley Furniture’s (PVF) vice president of marketing,

65
prepares a system service request (SSR), illustrated in Figure 4-5, to develop a customer
tracking system. Jackie feels that this system would allow PVF’s marketing group to better
track customer purchase activity and sales trends. She also feels that, if implemented, the
Customer Tracking System (CTS) would help improve revenue, a tangible benefit, and improve
employee morale, an intangible benefit. PVF’s Systems Priority Board selected this project for
an initiation and planning study. The board assigned senior systems analyst Jim Woo to work
with Jackie to initiate and plan the project. At this point in the project, all project initiation
activities have been completed: Jackie prepared an SSR, the selection board reviewed the SSR,
and Jim Woo was assigned to work on the project. Jackie and Jim can now focus on project
planning activities, which will lead to the baseline project plan.

66
FIGURE 4-5 System service request (SSR) for the Customer Tracking System at Pine Valley
Furniture. The SSR includes contact information, a problem statement, service request statement,
and liaison contact information.

67
1. Assessing Economic Feasibility
A study of economic feasibility is 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. During project initiation
and planning, it will be impossible for you to define precisely all benefits and costs related to
a particular project. Yet, it is important that you identify and quantify benefits and costs, or it
will be impossible for you to conduct a sound economic analysis and determine whether one
project is more feasible than another.
 Next, we review worksheets you can use to record costs and benefits, and techniques for
making cost-benefit calculations. These worksheets and techniques are used after each
SDLC phase to decide whether to continue, redirect, or kill a project.

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

68
Jim and Jackie identified several tangible benefits of the Customer Tracking System at PVF and
summarized them in a worksheet, shown in Figure 4-6. Jackie and Jim collected information
from users of the current customer tracking system in order to create the worksheet. They first
interviewed the person responsible for collecting, entering, and analyzing the correctness of the
current customer tracking data. This person estimated that he spent 10 percent of his time
correcting data-entry errors. This person’s salary is $25,000, so Jackie and Jim estimated an
error reduction benefit of $2,500 (10 percent of $25,000). Jackie and Jim also interviewed
managers who used the current customer tracking reports to estimate other tangible benefits.
They learned that cost reduction or avoidance benefits could be gained with better inventory
management.

FIGURE 4-6 Tangible benefits worksheet for the Customer Tracking System at Pine Valley
Furniture.

Also, increased flexibility would likely occur from a reduction in the time normally taken to
reorganize data manually for different purposes. Further, improvements in management planning
or control should result from a broader range of analyses in the new system. This analysis
forecasts that benefits from the system would be approximately $50,000 per year. Jim and Jackie
also identified several intangible benefits of the system. Although they could not quantify these
benefits, they will still be described in the final BPP. 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

69
societal implications, such as the 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
After determining project benefits, project costs must be identified.

Determining Project Costs An information system can have both tangible and intangible costs.
 A tangible cost refers to an item that you can easily measure in dollars and with certainty.
From a systems development perspective, tangible costs include items such as hardware
costs, labor costs, and operational costs from employee training and building renovations.
 Alternatively, an intangible cost refers to an item that you cannot easily measure in terms of
dollars or with certainty. Intangible costs can include loss of customer goodwill, employee
morale, or operational inefficiency.
Besides tangible and intangible costs, you can distinguish system-related development costs as
either one-time or recurring. A one-time cost refers to a cost associated with project initiation
and development and the start-up of the system. These costs typically encompass the following
activities:
 System development
 New hardware and software purchases
 User training
 Site preparation
 Data or system conversion

When conducting an economic cost-benefit analysis, you should create a worksheet for
capturing these expenses. This worksheet can be a two-column document or a multicolumn
spreadsheet. For large projects, one-time costs may be staged over one or more years. In these

70
cases, a separate one-time cost worksheet should be created for each year. This separation would
make it easier to perform present-value calculations (see the following section “Time Value of
Money”).

A recurring cost refers to a cost resulting from the ongoing evolution and use of the system.
Examples of these costs typically include:
 Application software maintenance
 Incremental data storage expense
 Incremental communications
 New software and hardware leases
 Consumable supplies and other expenses (e.g., paper, forms, datacenter personnel)

Both one-time and recurring costs can consist of items that are fixed or variable in nature.
 Fixed costs refer to costs that are billed or incurred at a regular interval and usually at a
fixed rate. A facility lease payment is an example of a fixed cost.
 Variable costs refer to items that vary in relation to usage. Long distance phone charges
are variable costs.
FIGURE 4-7 One-time costs worksheet for the Customer Tracking System at Pine Valley
Furniture.

FIGURE 4-8 Recurring costs worksheet for the Customer Tracking System at Pine Valley
Furniture.

71
2. Technical Feasibility

The goal of 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.

In addition to these considerations, project selection by an organization may be influenced by

issues beyond those discussed here.
 For example, projects may be selected for construction given high project costs and
high technical risk if the system is viewed as a strategic necessity, that is, the project is
viewed by the organization as being critical to its survival. Alternatively, projects may be
selected because they are deemed to require few resources and have little risk. Projects
may also be selected because of the power or persuasiveness of the manager proposing
the system. This means that project selection may be influenced by factors beyond those
discussed here and beyond items that can be analyzed. Your role as a systems analyst is
to provide a thorough examination of the items that can be assessed so that a project
review committee can make informed decisions.

3. Operational Feasibility
You may need to consider other feasibility studies when formulating the business case for a
system during project planning. Operational feasibility is the process of examining the

72
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.

4. Schedule Feasibility
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 o
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.

5. 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, antitrust
legislation (which might limit the creation of systems to share data with other organizations),
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. Typically, legal and contractual feasibility is a greater consideration if your
organization has historically used an outside organization for specific systems or services that
you now are considering handling yourself.

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 distribution of power, the construction of an IS can have political
ramifications.

73
Those stakeholders not supporting the project may take steps to block, disrupt, or change the
project’s intended focus.

4.4. Building the Baseline Project Plan

All the information collected during project initiation and planning is collected and organized
into a document called the baseline project plan. Once the BPP is completed, a formal review of
the project can be conducted with customers.

This presentation, a walkthrough, is discussed later in the chapter. The focus of the
walkthrough is to verify all information and assumptions in the baseline plan before moving
ahead with the project. An outline of a baseline project plan, shown in Figure 4-9, contains four
major sections:
1. Introduction
2. System description
3. Feasibility assessment
4. Management issues

The purpose of the introduction is to provide a brief overview of the entire document and outline
a recommended course of action for the project. The introduction is often limited to only a few
pages. Although it is sequenced as the first section of the BPP, it is often the final section to be
written. It is only after performing most of the project planning activities that a clear overview
and recommendation can be created. One initial activity that should be performed is the
definition of the project scope, its range, which is an important part of the BPP’s introduction
section.

When defining the scope for the Customer Tracking System within PVF, Jim Woo first needed
to gain a clear understanding of the project’s objectives. Jim interviewed Jackie Judson and
several of her colleagues to gain a good idea of their needs. He also reviewed the existing
system’s functionality, processes, and data-use requirements for performing customer tracking
activities. These activities provided him with the information needed to define the project scope
and to identify possible alternative solutions. Alternative system solutions can relate to different
system scopes, platforms for deployment, or approaches to acquiring the system. We elaborate
on the idea of alternative solutions, called design strategies. During project initiation and

74
planning, the most crucial element of the design strategy is the system’s scope. Scope depends
on the answers to these questions:
 Which organizational units (business functions and divisions) might be affected by or use the
proposed system or system change?
 With which current systems might the proposed system need to interact or be consistent, or
which current systems might be changed because of a replacement system?
 Who inside and outside the requesting organization (or the organization as a whole) might
care about the proposed system?
 What range of potential system capabilities is to be considered?

75
FIGURE 4-9 An outline of a baseline project plan contains four major sections: introduction,
system description, feasibility assessment, and management issues.

The statement of project scope for the Customer Tracking System project at PVF is shown in
Figure 4-10. A project scope statement is a short document prepared primarily for the customer
to clearly describe what the project will deliver and outline generally at a high level all the work
required for completing the project. It is therefore a useful communication tool. The project
scope statement ensures that both you and your customer gain a common understanding of the
project size, duration, and outcomes. The project scope statement is an easy document to create
because it typically consists of a high-level summary of the baseline project plan (BPP)
information.

76
FIGURE 4-10 Project scope statement for the Customer Tracking System at Pine Valley
Furniture.

Depending upon your relationship with your customer, the role of the project scope statement
may vary. At one extreme, the project scope statement can be used as the basis of a formal
contractual agreement outlining firm deadlines, costs, and specifications. At the other extreme,
the project scope statement can simply be used as a communication vehicle to outline the current
best estimates of what the project will deliver, when it will be completed, and the resources it
may consume. A contract programming or consulting firm, for example, may establish a formal
relationship with a customer and use a project charter that is more extensive and formal.
Alternatively, an internal development group may develop a project scope statement that is
shorter and less formal, as it will be intended to inform customers rather than to set contractual
obligations and deadlines.

The second section of the BPP is the system description, in which you outline possible
alternative solutions to the one deemed most appropriate for the given situation. Note that this
description is at a high level, mostly narrative in form. Alternatives may be stated as simply as
this:
1. Web-based online system
2. Mainframe with central database
3. Local area network with decentralized databases
4. Batch data input with online retrieval
5. Purchasing of a prewritten package

If the project is approved for construction or purchase, you will need to collect and structure
information in a more detailed and rigorous manner during the systems analysis phase and
evaluate in greater depth these and other alternatives for the system.

When Jim and Jackie were considering system alternatives for the CTS, they focused on two
primary issues.
First, they discussed how the system would be acquired and considered three options:
(1) purchase the system if one could be found that met PVF’s needs,
(2) outsource the development of the system to an outside organization, or

77
 (3) build the system within PVF.
Next, Jim and Jackie defined the comprehensiveness of the system’s functionality. To complete
this task, Jackie wrote a series of statements listing the types of tasks that she thought marketing
personnel would be able to accomplish when using the CTS.

This list became the basis of the system description and was instrumental in helping them make
the acquisition decision. After considering the unique needs of the marketing group, they decided
that the best decision was to build the system within PVF.

FIGURE 4-11 Context-level data-flow diagram showing project scope for the purchasing
fulfillment system at Pine Valley Furniture.

In the third section of the BPP, feasibility assessment, the systems analyst outlines project costs
and benefits and technical difficulties. This section is where high-level project schedules are
specified using Network diagrams and Gantt charts. Recall from Chapter 3 that this process is
referred to as a work breakdown structure. During project initiation and planning, task and
activity estimates are generally not detailed. An accurate work breakdown can be done only for
the next one or two life-cycle activities—systems analysis and systems design. After defining the
primary tasks for the project, an estimate of the resource requirements can be made. As with
defining tasks and activities, this activity involves obtaining estimates of the human resource
requirements, because people are typically the most expensive resource element of a project.

78
Once you define the major tasks and resource requirements, a preliminary schedule can be
developed. Defining an acceptable schedule may require that you find additional or different
resources or that the scope of the project be changed. The greatest amount of project planning
effort is typically expended on feasibility assessment activities.

The final section of the BPP, management issues, outlines the concerns that management has
about the project. It will be a short section if the proposed project is going to be conducted
exactly as prescribed by the organization’s standard systems development methodology. Most
projects, however, have some unique characteristics that require minor to major deviation from
the standard methodology.

In the team configuration and management portion, you identify the types of people to work on
the project, who will be responsible for which tasks, and how work will be supervised and
reviewed.

FIGURE 4-12 Task-responsibility matrix.

79
FIGURE 4-13 The Project Communication Matrix provides a high-level summary of the
communication plan.

In the communication plan portion, you explain how the user will be kept informed about project
progress, such as periodic review meetings or even a newsletter, and which mechanisms will be
used to foster sharing of ideas among team members, such as a computer-based conference
facility (see Figure 4-13). An example of the type of information contained in the project
standards and procedures portion would be procedures for submitting and approving project
change requests and any other issues deemed important for the project’s success.

You should now have a feel for how a BPP is constructed and the types of information it
contains. Its creation is not meant to be a project in and of itself but rather a step in the overall

80
systems development process. Developing the BPP has two primary objectives. First, it helps to
assure that the customer and development group share a common understanding of the project.
Second, it helps to provide the sponsoring organization with a clear idea of the scope, benefits,
and duration of the project. Meeting these objectives creates the foundation for a successful
project.

Reviewing the Baseline Project Plan

Before phase 2 of the SDLC analysis can begin, the users, management, and development group
must review and approve the baseline project plan. This review takes place before the BPP is
submitted or presented to some project approval body, such as an IS steering committee or the
person who must fund the project. The objective of this review is to ensure that the proposed
system conforms to organizational standards and to make sure that all relevant parties understand
and agree with the information contained in the baseline project plan. A common method for
performing this review (as well as reviews during subsequent life-cycle phases) is called a
walkthrough. Walkthroughs, also called structured walkthroughs, are peer group reviews of any
product created during the systems development process. They are widely used by professional
development organizations, such as IBM, Xerox, and the U.S. government, and have proven
effective in ensuring the quality of an information system. As a systems analyst, you will
frequently be involved in walkthroughs.

Although walkthroughs are not rigidly formal or exceedingly long in duration, they have a
specific agenda that highlights what is to be covered and the expected completion time.
Individuals attending the meeting have specific roles.
These roles can include the following:
 Coordinator: This person plans the meeting and facilitates discussions. This person may be
the project leader or a lead analyst responsible for the current life-cycle step.
 Presenter: This person describes the work product to the group. The presenter is usually an
analyst who has done all or some of the work being presented.
 User: This person (or group) makes sure that the work product meets the needs of the
project’s customers. This user would usually be someone not on the project team.
 Secretary: This person takes notes and records decisions or recommendations made by the
group. This may be a clerk assigned to the project team or one of the analysts on the team.

81
 Standards bearer: This person ensures that the work product adheres to organizational
technical standards. Many larger organizations have staff groups within the unit responsible
for establishing standard procedures, methods, and documentation formats. For example,
within Microsoft, user interface standards are developed and rigorously enforced on all
development projects. As a result, all systems have the same look and feel to users. These
standards bearer validate the work so that it can be used by others in the development
organization.
 Maintenance oracle: This person reviews the work product in terms of future maintenance
activities. The goal is to make the system and its documentation easy to maintain.

After Jim and Jackie completed their BPP for the Customer Tracking System, Jim approached
his boss and requested that a walkthrough meeting be scheduled and a walkthrough coordinator
be assigned to the project. PVF provides the coordinator with a Walkthrough Review Form,
shown in Figure 4-14. Using this form, the coordinator can easily make sure that a qualified
individual is assigned to each walkthrough role; that each member has been given a copy of the
review materials; and that each member knows the agenda, date, time, and location of the
meeting. At the meeting, Jim presented the BPP, and Jackie

82
83
FIGURE 4-14 Walkthrough Review Form for the Customer Tracking System at Pine Valley
Furniture.

added comments from a user perspective. Once the walkthrough presentation was completed, the
coordinator polled each representative for his or her recommendation concerning the work
product. The results of this voting may result in validation of the work product, validation
pending changes suggested during the meeting, or a suggestion that the work product requires
major revision before being presented for approval. In the last case, substantial changes to the
work product are usually requested, after which another walkthrough must be scheduled before
the project can be proposed to the Systems Priority Board (steering committee). In the case of the
Customer Tracking System, the BPP was supported by the walkthrough panel pending some
minor changes to the duration estimates of the schedule. These suggested changes were recorded
by the secretary on a Walkthrough Action List, shown in Figure 4-15, and given to Jim to
incorporate into the next version of the baseline plan presented to the steering committee.

FIGURE 4-15 Walkthrough Action List for Pine Valley Furniture.

Walkthrough meetings are a common occurrence in most systems development groups. In

addition to reviewing the BPP, these meetings can be used for the following activities:

84
  System specifications
 Logical and physical designs
 Code or program segments
 Test procedures and results
 Manuals and documentation

One of the key advantages to using a structured review process is to ensure that formal review
points occur during the project. At each subsequent phase of the project, a formal review should
be conducted (and shown on the project schedule) to make sure that all aspects of the project are
satisfactorily accomplished before assigning additional resources to the project. This
conservative approach of reviewing each major project activity with continuation contingent on
successful completion of the prior phase is called incremental commitment.
It is much easier to stop or redirect a project at any point when using this approach.
Walkthroughs are used throughout the duration of the project for briefing team members and
external stakeholders. These presentations can provide many benefits to the team but,
unfortunately, are often not well done. With the proliferation of computer technology and the
availability of powerful software to assist in designing and delivering presentations, making an
effective presentation has never been easier. Microsoft’s PowerPoint has emerged as the de
facto standard for creating computer-based presentations. Although this program is relatively
easy to use, it can also be misused such that the “bells and whistles” added to a computer-based
presentation actually detract from the presentation. Like any project, to make an effective
presentation it must be planned, designed, and delivered. Planning and designing your
presentation is equally important as delivering it. If your slides are poorly laid out, hard to read,
or inconsistent, it won’t matter how good your delivery is; your audience will think more about
the poor quality of the slides, than about what you are saying. Fortunately, with a little work it is
easy to design a high-quality presentation if you follow a few simple steps that are outlined in
Table 4-6.

Pine Valley Furniture WebStore: Systems Planning and Selection

Most businesses have discovered the power of Internet-based electronic commerce as a means to
communicate efficiently with customers and to extend their marketing reach. As a systems
analyst, you and a project team may be asked by your employer to help determine whether an

85
Internet-based electronic commerce application fits the goals of the company and, if so, how that
application should be implemented.

The systems planning and selection process for an Internet-based electronic commerce
application is no different than the process followed for other applications.
Nonetheless, you should take into account special issues when developing an Internet-based
application. In this section, we highlight those issues.

4.5. Electronic Commerce Application

Internet Basics
The term Internet is derived from the term internetworking. The Internet is a global network
comprised of thousands of interconnected individual networks that communicate with each other
through TCP/IP (transmission control protocol/Internet protocol).
 Using the Internet and other technologies to support day-to-day business activities, such as
communicating with customers and selling goods and services online, is referred to as
electronic commerce (EC), also called e-commerce.
 Note that EC can also refer to the use of non-Internet technologies such as telephone voice-
messaging systems that route and process customer requests and inquiries.
 Nonetheless, for our purposes, we will use EC to mean Internet-enabled business.
 Electronic Commerce (EC):- Internet-based communication designed to support business
activities
 System planning and selection process for Internet-based electronic commerce application
projects is no different than other projects
 Special issues need to be taken into account
 The three classes of Internet EC applications are Internet, intranet, and extranet, as
illustrated in Figure 4-19.

86
  Internet-based EC is transactions between individuals and businesses. Internet:-
Worldwide network of networks used for electronic commerce
 Intranet refers to the use of the Internet within the same business. And also,
Intranet:- Internet-based communication to support business activities within a
single organization
 Extranet refers to Internet-based communication to support business- to-business
activities.
FIGURE 4-16 Three possible modes of electronic commerce.

 Intranets and extranets are examples of two ways organizations communicate via
technology.
 Having an intranet is a lot like having a “global” local area network. A company may create
an intranet to house commonly used forms, up-to-date information on sales, and human
resource information so that employees can access them easily and at any time.
 Organizations that have intranets dictate:
(1) what applications will run over the intranet—such as electronic mail or an
inventory control system, and
(2) the speed and quality of the hardware connected to the intranet. Intranets are a
new way of using information systems to support business activities within a single
organization.
 Extranets are another new way of using an established computing model, electronic data
interchange (EDI). EDI refers to the use of telecommunication technologies to transfer
business documents directly between organizations.
 Electronic Data Interchange (EDI)
 The use of telecommunications technologies to transfer business documents
directly between organizations
 Using EDI, trading partners—suppliers, manufacturers, and customers— establish computer-
to-computer links that allow them to exchange data electronically.

87
 For example, a car manufacturer using EDI may send an electronic purchase order to a steel
or tire supplier instead of a paper request. The paper order may take several days to arrive at
the supplier, whereas an EDI purchase order will take only a few seconds. EDI is fast
becoming the standard by which organizations will communicate with each other in the
world of electronic commerce.
 Internet vs. Intranet/Extranet Applications
o Intranet/Extranet – Developer knows
 What application will be run and used.
 The speed of network connection.
 The type of communication device.
 When developing either an intranet or an extranet, developers know who the users are,
 What applications will be used,
 The speed of the network connection, and
 The type of communication devices (e.g., Web browsers such as Firefox, Chrome, or
Internet Explorer, smart phones such as an iPhone).
 On the other hand, when developing an Internet EC application, developers have to discern
countless unknowns in order to build a useful system.
 Table 4-7 lists several unknowns you and your project team may deal with when designing
and building an EC.
 Internet – Developer faces various unknowns.
 These unknowns may result in making trade-offs based on a careful analysis of:-
 Who the users are likely to be,
 Where is the user located? What is their expertise, education, or experience.
 How they are likely to be connected to the Internet.
 Even with all these difficulties to contend with, you will find no shortage of Internet
ECs springing up all across the world.
 One company that has decided to get onto the Web with its own EC site is Pine
Valley Furniture.
 Connection speed
 Access methods
 Web browser, personal digital assistant, web enable cellular phone.

88
Pine Valley Furniture WebStore
TABLE 4-5: Unknowns That Must Be Dealt with When Designing and Building Internet
Applications

The PVF board of directors has requested that a project team be created to explore the
opportunity to develop an EC system. Specifically, market research has found a good
opportunity for online furniture purchases, especially in the areas of:
 Corporate furniture buying
 Home-office furniture purchasing
 Student furniture purchasing
The board wants to incorporate all three target markets into its long-term EC plan but wants to
focus initially on the corporate furniture buying system. The board feels that this segment has the
greatest potential to provide an adequate return on investment and would be a good building
block for moving into the customer-based markets. Because the corporate furniture buying
system will be specifically targeted to the business furniture market, it will be easier to define the
system’s operational requirements. Additionally, this EC system should integrate nicely with
two currently existing systems, Purchasing Fulfillment and Customer Tracking. Together, these
attributes make it an ideal candidate for initiating PVF’s Web strategy.

Initiating and Planning PVF’s E-Commerce System Given the high priority of this project,
Jackie Judson, vice president of marketing, and senior systems analyst Jim Woo were assigned to
work on this project. As for the Customer Tracking System described earlier in the chapter, their
first activity was to begin the project’s initiation and planning activity. Over the next few days,
Jim and Jackie met several times to initiate and plan the proposed system.

89
At the first meeting, they agreed that “WebStore” would be the proposed system project name.
Next, they worked on identifying potential benefits, costs, and feasibility concerns. Jim
developed a list of potential costs the company would incur to develop Web-based systems that
he shared with Jackie and the other project team members (see Table 4-8).

WebStore Project Walkthrough After meeting with the project team, Jim and Jackie established
an initial list of benefits and costs (see Table 4-9) as well as several feasibility concerns (see
Table 4-10). Next, Jim worked with several of PVF’s technical specialists to develop an initial
project schedule. Figure 4-20 shows the Gantt chart for this 84-day schedule. Finally, Jim and
Jackie presented their initial project plans in a walkthrough to PVF’s board of directors and
senior management. All were excited about the project plan and approval was given to move the
WebStore project on to the analysis phase.

TABLE 4-6: Web-Based System Costs

TABLE 4-7: PVF WebStore Project Benefits and Costs

90
TABLE 4-8: PVF WebStore Feasibility Concerns

FIGURE 4-17 Gantt chart showing the schedule for the WebStore project.

91
92
 CHAPTER FIVE
CHAPTER 5: SYSTEM ANALYSIS
Introduction
Analysis is the heart of the process. It is the key component of the first two phases of the cycle.
In analysis 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.

 System analysis determine how the current information system functions and assess what
users would like to see in new system.
 There are three sub phases in analysis:
 Requirements determination
 Requirements structuring, and
 Alternative generation and choice.
 We will first study the more traditional requirements determination then
 Discuss modern methods for collecting system requirement (JAD).
 Structuring system requirement is modeling
 a system process,
 logic and
 conceptual data that provides a way for analysts to see how various process action
diagrams (data flow, entity relationship)
 Process modeling show the flow of data between manual or automated systems.
 Logic modeling show the decision logic of processing data finally
 Data modeling depicts the characteristics and natural structure of data independent of
how it is stored in side the computer.

THE ANALYSIS PHASE

The analysis phase is so named because the term analysis refers to breaking a whole into its
parts with the intent of understanding the parts’ nature, function, and interrelationships. These

93
planning phase deliverables are the key inputs into the analysis phase. In the analysis phase,
the systems analyst works extensively with the business users of the new system to understand
their needs from the new system.

The basic process of analysis involves three steps:

 Understand the existing situation (the as-is system).
 Identify improvements.
 Define requirements for the new system (the to-be system).

Sometimes the first step (i.e., understanding the as-is system) is skipped or done in a limited
manner. This happens when no current system exists, if the existing system and processes are
irrelevant to the future system, or if the project team is using a RAD or agile development
methodology in which the as-is system is not emphasized.
 Traditional methods such as waterfall and parallel development typically allot significant
time to understanding the as-is system and identifying improvements before moving to
capture requirements for the to-be system.
 Modern RAD and agile methodologies, such as iterative development, system prototyping,
throwaway prototyping, and extreme programming, focus almost exclusively on
improvements and the to-be system requirements, and they devote little time for
investigating the current as-is system. Experience shows that it is useful to study the current
situation whenever possible. The insights gained from reviewing the existing system can be
quite valuable to the project team.

To move the users “from here to there,” an analyst needs strong critical thinking skills. Critical
thinking is the ability to recognize strengths and weaknesses and recast an idea in an improved
form.

Determining System Requirement

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

94
process models, and building a data model. We first explain what a requirement is and discuss
the process of creating a requirements definition statement.

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 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.
We have already discussed the creation of the systems request in the planning phase of the
SDLC.
 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.”

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 place is to concentrate on what the user actually needs to accomplish with the
system in order to fulfill a needed job or task.

95
 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.”
 Determining ways in which the new system can support user needs leads to statements of
the system’s functional requirements.

Types of Requirements
 Requirements are partitioned into functional requirements and non-functional
requirements.
 Functional requirements are associated with specific functions, tasks or behaviors the
system must support.
 Non-functional requirements are constraints on various attributes of these functions or
tasks.
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.”
 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 describe
capabilities and functions that the system will need to include, allowing the user to complete
the task.

96
FIGURE 5-1 Functional Requirements
 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. The data component of the system is defined in the data
model.
 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 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.

 Typical functional requirements are:

 Business Rules

97
  Transaction corrections, adjustments, cancellations
 Administrative functions
 Authentication
 Authorization –functions user is delegated to perform
 Audit Tracking
 External Interfaces
 Certification Requirements
 Reporting Requirements
 Historical Data
 Legal or Regulatory Requirements

Nonfunctional requirements
 The final category of requirements is nonfunctional requirements.
 The International Institute of Business Analysis IIBA defines this group of requirements as
“the quality attributes, design, and implementation constraints, and external interfaces which
a product must have.”
 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.

Figure 3-2 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

98
  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.
 For example, the project team needs to know whether a system must be highly secure,
requires sub second response time, or has to reach a multilingual customer base.
 These requirements will affect design decisions that will be made in the design phase,
particularly architecture design.

FIGURE 5-2 Nonfunctional Requirements

 Typical non-functional requirements are:

 Performance - Response Time, Throughput, Utilization, Static Volumetric
 Scalability
 Capacity
 Availability
 Reliability
 Recoverability

99
  Maintainability
 Serviceability
 Security (log in, system audit, etc..)
 Regulatory
 Manageability
 Environmental
 Data Integrity
 Usability
 Interoperability

The Process of Determining Requirements

Both business and IT perspectives are needed to determine requirements during the analysis
phase. 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.
 Therefore, the most effective approach is to have both businesspeople and analysts working
together to determine requirements. In fact, the analysis phase involves significant
interactions with people who have an interest in the new system (often called stakeholders).
 One of the first tasks for the analyst is to identify the primary sources of requirements,
including the project sponsor, project champion(s), all users of the system (both direct and
indirect), and possibly others. It is important that all user perspectives are included.
 The analyst must also consider how best to elicit the requirements from the stakeholders.
 There are a variety of gathering techniques that can be used to acquire information, including
interviews, questionnaires, observation, joint application development (JAD), and document
analysis.
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

100
 Functional Requirements
1. New Vehicle Management
1.1 The system will allow managers to view the current new vehicle inventory.
1.2 Theformat.
outline systemFigure
will allow
3-3 the newavehicle
shows samplemanager to place
requirements orders for
definition for new vehicles.
Holiday Travel Vehicles,
1.3 The system will record the addition of new vehicles to inventory when they are received
afrom
fictitious recreational vehicle dealership.
the manufacturers.
2. Vehicle Sales Management
2.1 The system will enable salespersons to create a customer offer.
2.2 The system will allow salespeople to know whether an offer is pending on a specific
vehicle.
2.3 The system will enable managers to record approval of a customer offer.
2.4 The system will prepare a sales contract.
2.5 The system will prepare a shop work order based on customer requested dealer options.
2.6 The system will record a customer deposit.
2.7 The system will record a customer payment.
2.8 The system will create a record of the customer's vehicle purchase.
3. Used Vehicle Management
3.1 The system will record information on a customer trade-in vehicle ... etc.

Nonfunctional Requirements
1. Operational
1.1 The system should run on tablet PCs to be used by salespeople.
1.2 The system should interface with the shop management system.
1.3 The system should connect to printers wirelessly.
2. Performance
2.1 The system should support a sales staff of 15 salespeople.
2.2 The system should be updated with pending offers on vehicles every 15 minutes.
3. Security
3.1 No salesperson can access any other salesperson's customer contacts.
3.2 Only the owner and sales manager may approve customer offers.
3.3 Use of each tablet PC should be restricted to the salesperson to whom it is assigned.
4. Cultural and Political
4.1 Company policy says that all computer equipment is purchased from Dell.
4.2 Customer personal information is protected in compliance with the Data Protection Act.
4.3 The system will conform to the state's "lemon law."

FIGURE 5-3 Sample Requirements Definition

As shown in Figure 5-3, it is common to number the requirements in a legal or outline format so
that each requirement is clearly 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.

101
Sometimes, requirements are prioritized on the requirements definition statement. They can be
ranked as having “high,” “medium,” or “low” importance in the new system, or they can be
labeled with the version of the system that will address the requirement (e.g., release 1, release 2,
release3). This practice is particularly important with RAD methodologies that deliver
requirements in batches by developing incremental versions of the system.

Requirements Gathering in Practice

Before discussing the five requirements gathering techniques in detail, a few practical tips are
in order.
 First, the analyst should recognize that important side effects of the requirements definition
process include building political support for the project and establishing trust and rapport
between the project team and the ultimate users of the system.
 Second, the analyst should carefully determine who is included in the requirements
definition process. The choice to include (or exclude) someone is significant; involving
someone in the process implies that the analyst views that person as an important resource
and values his or her opinions. You must include all of the key stakeholders (the people who
can affect the system or who will be affected by the system). This might include managers,
employees, staff members, and even some customers and suppliers.
 Finally, do everything possible to respect the time commitment that you are asking the
participants to make. The best way to do this is to be fully prepared and to make good use of
all the types of requirements gathering techniques.

 Although, as we will see, interviewing is the most commonly used technique, other indirect
methods may help the analyst develop a basic understanding of the business domain so that
the direct techniques are more productive.
 In general, a useful strategy for the analyst to employ is to begin requirements gathering by
interviewing senior managers to gain an understanding of the project and get the “big
picture.”
 These preliminary interviews can then be followed by document analysis and, possibly,
observation of business processes to learn more about the business domain, the vocabulary,
and the as-is system.

102
 In our experience, identifying improvements is most commonly done through JAD sessions
because these sessions enable the users and key stakeholders to work together and create a
shared understanding of the possibilities for the to-be system.
 Occasionally, these JAD sessions are followed by questionnaires sent to a much larger
group of users or potential users to get a broad range of opinions. The concept for the to-be
system is frequently developed through interviews with senior managers, followed by JAD
sessions with users of all levels, to make sure that the key requirements of the new system
are well understood.

Requirements Gathering Techniques

The specific methods analysts use for collecting data about requirements are called fact –
finding techniques. These include the:-
 Interviews,
 Questionnaires,
 JAD sessions
 Document analysis, and
 Observation.
Analysts usually employ more than one of these techniques to help ensure an accurate and
comprehensive investigation.

A. Interviews
 The interview is the most commonly used requirements-gathering technique.
 After all, it is natural if you need to know something, you usually ask someone.
 In general, interviews are conducted one-on-one (one interviewer and one interviewee), but
sometimes, due to time constraints, several people are interviewed at the same time.
 There are five basic steps to the interview process:
 Selecting interviewees, designing interview questions, preparing for the interview,
conducting the interview, and post interview follow-up.
1. Selecting Interviewees:
 The first step in interviewing is to create an interview schedule listing all the people who will
be interviewed, when, and for what purpose. The people who appear on the interview
schedule are selected based on the analyst’s information needs.

103
 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.

FIGURE 5-4 Sample Interview Schedule

2. Designing Interview Questions:

 There are two types of interview questions: closed- ended questions & open-ended questions
 Closed-ended questions are those that require a specific answer. They are similar to
multiple-choice or arithmetic questions on an exam. Closed-ended questions are used when
an analyst is looking for specific, precise information (e.g., how many credit card requests
are received per day). In general, precise questions are best.
 Closed-ended questions enable analysts to control the interview and obtain the information
they need. However, these types of questions don’t uncover why the answer is the way it is,
nor do they uncover information that the interviewer does not think to ask ahead of time.
 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 control over the information that is revealed during the interview.
3. Preparing for the Interview
 It is important to prepare for the interview in the same way that you would prepare to give a
presentation.

104
 The interviewer should have a general interview plan listing the questions to be asked in the
appropriate order; should anticipate possible answers and provide follow-up with them; and
should identify segues between related topics.
 The interviewer should confirm the areas in which the interviewee has knowledge in order
not to ask questions that he or she cannot answer.
 Review the topic areas, the questions, and the interview plan, and clearly decide which have
the greatest priority in case time runs short.
4. Conducting the Interview
 In starting the interview, the first goal is to build rapport with the interviewee, so that he or
she trusts the interviewer and is willing to tell the whole truth, not just give the answers that
he or she thinks are wanted. The interviewer should appear to be professional and an
unbiased, independent seeker of information.
 The interview should start with an explanation of why the interviewer is there and why he or
she has chosen to interview the person; then the interviewer should move into the planned
interview questions.
5. 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 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 forty-eight hours of the interview, because the longer the interviewer waits,
the more likely he or she is to forget information.

B. Joint Application Development (JAD)

 JAD is an information-gathering technique that allows the project team, users, and
management to work together to identify requirements for the system.
 IBM developed the JAD technique in the late 1970s, and it is often the most useful method
for collecting information from users. Capers Jones claims that JAD can reduce scope creep
by 50 percent, and it avoids the requirements for a system being too specific or too vague,
both of which cause trouble during later stages of the SDLC.
 JAD is a structured process in which ten to twenty users meet together under the direction
of a facilitator skilled in JAD techniques.
105
  The facilitator is a person who sets the meeting agenda and guides the discussion but
does not join in the discussion as a participant.
 He or she does not provide ideas or opinions on the topics under discussion in order
to remain neutral during the session. The facilitator must be an expert in both group
process techniques and systems analysis and design techniques.
 One or two scribes assist the facilitator by recording notes, making copies, and so on.
Often the scribes will use computers and CASE tools to record information as the
JAD session proceeds.

1. Selecting Participants Selecting JAD participants:- is done in the same basic way as
selecting interview participants. Participants are selected based on the information they can
contribute, to provide a broad mix of organizational levels, and to build political support for the
new system. The need for all JAD participants to be away from their office at the same time can
be a major problem. The office may need to be closed or operate with a skeleton staff until the
JAD sessions are complete.
2. Designing a JAD Session JAD sessions:- can run from as little as half a day to several weeks,
depending upon the size and scope of the project. In our experience, most JAD sessions tend to
last five to ten days, spread over a three-week period. Most e-JAD sessions tend to last one to
four days in a one-week period. JAD and e-JAD sessions usually go beyond the collection of
information and move into analysis. For example, the users and the analysts collectively can
create analysis deliverables, such as the functional models, structural models, or the requirements
definition.
3. Preparing for a JAD Session:- As with interviewing, it is important to prepare the analysts
and participants for a JAD session. Because the sessions can go beyond the depth of a typical
interview and are usually conducted off-site, participants can be more concerned about how to
prepare. It is important that the participants understand what is expected of them. If the goal of
the JAD session, for example, is to develop an understanding of the current system, then
participants can bring procedure manuals and documents with them. If the goal is to identify
improvements for a system, then they can think about how they would improve the system prior
to the JAD session.
4. Conducting a JAD Session:- Most JAD sessions try to follow a formal agenda, and most
have formal ground rules that define appropriate behavior. Common ground rules include

106
following the schedule, respecting others’ opinions, accepting disagreement, and ensuring that
only one person talks at once.
5. Post-JAD Follow-up: As with interviews, a JAD post session report is prepared and
circulated among session attendees. The post session report is essentially the same as the
interview report. Because the JAD sessions are longer and provide more information, it usually
takes a week or two after the JAD session before the report is complete.

C. Questionnaires
 A questionnaire is a set of written questions used to obtain information from individuals.
 Questionnaires are often used when there is a large number of people from whom
information and opinions are needed.
 In our experience, questionnaires are a common technique with systems intended for use
outside 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 distribution can save a significant amount of money as compared to distributing
paper questionnaires.
Good Questionnaire Design

Participants
 As with interviews and JAD sessions, the first step is to identify the individuals to whom the
questionnaire will be sent.

107
 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 an
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 to 50 percent of paper
and e-mail questionnaires are returned. Response rates for Web-based questionnaires tend to
be significantly lower (often only 5 to 30 percent).

Designing a Questionnaire:
 Developing good questions is critical for questionnaires because the information on a
questionnaire cannot be immediately clarified for a confused respondent.
 Questions on questionnaires must be very clearly written and leave little room for
misunderstanding, so closed-ended questions tend to be most commonly used.
 Questions must clearly enable the analyst to separate facts from opinions.
 Opinion questions often ask the respondent the extent to which they agree or disagree (e.g.,
Are network problems common?), whereas factual questions seek more precise values (e.g.,
How often does a network problem occur: once an hour, once a day, once a week?). For
guidelines on questionnaire design.

Administering the Questionnaire

 The key issue in administering the questionnaire is get- ting participants to complete the
questionnaire and send it back. Dozens of marketing research books have been written about
ways to 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.
 Systems analysts have additional techniques to improve response rates inside the
organization, such as personally handing out the questionnaire and personally contacting
those who have not returned them after a week or two, as well as requesting the
respondents’ supervisors to administer the questionnaires in a group meeting.

108
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.
D. Document Analysis
 Project teams often use document analysis to understand the as-is system.
 Under ideal circumstances, the project team that developed the existing system will have
produced documentation, which was then updated by all subsequent projects.
 In this case, the project team can start by reviewing the documentation and examining the
system itself.
 Unfortunately, most systems are not well documented, because project teams fail to
document their projects along the way, and when the projects are over, there is no time to go
back and document. Therefore, there may not be much technical documentation about the
current system available, or it may not contain updated information about recent system
changes.
 However, there are many helpful documents that do exist in the organization: paper reports,
memorandums, policy manuals, user training manuals, organization charts, and forms.
 Problem reports filed by the system users can be another rich source of information about
issues with the existing system.
 But these documents (forms, reports, policy manuals, organization charts) only tell part of the
story. They represent the formal system that the organization uses.
 Quite often, the “real or informal system differs from the formal one, and these differences,
particularly large ones, give strong indications of what needs to be changed. For example,
forms or reports that are never used likely should be eliminated.
 Likewise, boxes or questions on forms that are never filled in (or are used for other purposes)
should be rethought.
 The most powerful indication that the system needs to be changed is when users create their
own forms or add additional information to existing ones. Such changes clearly demonstrate
the need for improvements to existing systems. Thus, it is useful to review both blank and
completed forms to identify these deviations.
 Likewise, when users access multiple reports to satisfy their information needs, it is a clear
sign that new information or new information formats are needed.
109
FIGURE 5-5 Performing a Document Analysis

E. Observation
 Observation, the act of watching processes being performed, is a powerful tool for gathering
information about the as-is system because it enables the analyst to see the reality of a
situation, rather than listening to others describe it in interviews or JAD.
 Observation is a good way to check the validity of information gathered from other sources
such as interviews and questionnaires.

110
 In many ways, the analyst becomes an anthropologist as he or she walks through the
organization and observes the business system as it functions.
 The goal is to keep a low profile, to not interrupt those working, and to not influence those
being observed. Nonetheless, it is important to understand that what analysts observe may
not be the normal day-to-day routine because people tend to be extremely careful in their
behavior when they are being watched.
 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 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.

Workflow Analysis Modeling

 Workflow analysis modeling help to facilitate standard analysis methodologies.
 A workflow is a depiction of a sequence of operations, declared as work of a person,
work of a simple or complex mechanism, work of a group of persons, work of an
organization of staff, or machines.
 A workflow diagram is a graphic representation of all the major steps of a process. It can
help you:
 Understand the complete process.
 Identify the critical stages of a process.
 Locate problem areas.
 Show relationships between different steps in a process.
 With the help of such diagram it is possible to see the path of the task in a workflow, the
person who is responsible for its execution on each stage.
 Workflow diagram is a sort of flowcharts that consist of six types of blocks.

Workflow Diagram Symbols

111
Practical work analysis
 The first step in planning a workflow application is to analyze the business process you
want to define.
 The steps involves in purchase order task of the Sales Supervisor at a fictitious distributor
firm are:
1. Receive a request for an estimate
2. Verify the stock balance
3. Issue the estimate
4. Place order
5. Receive materials ordered
6. Checking and Inspection
7. Send material to SOP
Workflow Diagram

112
Practical work analysis
 It is important to focus on the main job when you list steps, because if surrounding
business factors, such as financial considerations or stock management, also are listed,
then the story is blurred.
 It is important to focus on the main job when you list steps, because if surrounding
business factors, such as financial considerations or stock management, also are listed,
then the story is blurred.
 workflow includes the communication among the people involved in the business
process.

113
  The people involved in the earlier example are:
 Sales supervisors
 Customer
 Stock keeper
 Delivery person
 Each step has a pool of information. For example, if you order a product, then
information, such as the product name, quantity, and price, is involved.
 The information pools have a relationship to each other.
 If you draw a picture of how the information goes around these steps with such
relationships considered, you will understand the relationship in each process more.
Practical work analysis
The information relation of each process

Types of work flow

User-level WFD
 Models entities and workflows described by single user
 Presents a single user’s view point but includes more than one entity and can model
workflows across functional areas
114
  Discover formal as well as informal flows of information.

Combined user level WFD

 Integrated view of all entities and workflows
 Identify inconsistencies in user-level WFDs
 Reveals redundancies, inefficiencies
 Can be used to identify high level business processes
 Each internal entity performs a process to generate flows to and process flows
from external entities.
 Flows between internal entities can also indicate a major process
 Can be used to define system boundaries

115
Organizational level WFD
 Collapse all internal entities in combined user-level WFD, into a single internal entity
 External entities and the flow of information between the organization and external
entities
 Equivalent to Context level DFD

116
Selecting the Best design Strategy
Each of the requirements elicitation techniques just discussed has strengths and weaknesses. No
one technique is always better than 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. 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.

FIGURE 5-6 Comparison of Requirements-gathering Techniques:

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 improvements, or
 developing the to-be 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.

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.

117
 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.
 Questionnaires can provide a medium depth of information, soliciting both facts and opinions
with little understanding of why.

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.

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 attempting to refine the information.
 All techniques suffer integration problems to some degree, but JAD sessions are designed to
improve integration because all information is integrated when it is collected, not afterward.
 If two users provide conflicting information, the conflict becomes immediately obvious, as
does the source of the conflict. The immediate integration of information is the single most
important benefit of JAD that distinguishes it from other techniques, and this is why most
organizations use JAD for important projects.

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.

118
 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.

Cost
 Cost is always an important consideration.
 In general, questionnaires, document analysis, and observation are low-cost techniques
(although observation can be quite time consuming). The low cost does not imply that they
are more or less effective than the other techniques.
 We regard interviews and JAD sessions as having moderate costs. In general, JAD sessions
are much more expensive initially, because they require many users to be absent from their
offices for significant periods, and they often involve highly paid consultants.
 However, JAD sessions significantly reduce the time spent in information integration and
thus cost less in the long term.

119
 CHAPTER SIX
SYSTEM DESIGN
7.0. INTRODUCTION
 This section deals with the design phase of the system development lifecycle.
 During the system design phase, we design an information system that satisfies the
requirements.
 We must design all aspects of the system from input and output screens to reports,
databases, and computer processes.
 Database design methodology has 2 main phases:
 Logical database design;
 Physical database design.

7.1. Systems Design

During analysis, the focus is on understanding what the system should do (i.e., the requirements),
whereas during design, the focus is on the solution (i.e., specifying how the system will be built
and what the structural components of the new system will be).

Systems design is really a bridge process. The objective of systems analysis is to thoroughly
understand the organization’s informational needs or requirements and to document those
requirements in a set of specifications. The objective of software construction is to build a
system that satisfies those requirements.

Systems design, then, is the bridge that takes us from requirements to solution. The objective of
systems design is to define, organize, and structure the components of the final solution system
that will serve as the blueprint for construction.

Another way to think about systems design is that whereas analysis tells us what the solution
needs to do, design describes how the system will be configured and constructed.

System Design is defined as those tasks that focus on the specification of a detailed computer-
based solution. It is also known as physical design. System design methods focus on technical or
implementation concerns of the system. System designers play a vital role. System Analyst helps
as a facilitator in system design.

120
Systems design is the Bridge from requirements to implementation
 First step in structured design where focus is on the solution. It defines:
 What system will do (from the requirements)

 Design is an abstract concept that has different meanings depending on the context. Design
also can include many different activities. Depending on the size and scope of the project and
the product being designed, the design activities may be simple, one-person activities or the
design activities may be complex involving many people, models, and resources.

7.2. Database Design

What is data?
 Data is nothing but facts and statistics stored or free flowing over a network, generally it's
raw and unprocessed.
 Data becomes information when it is processed, turning it into something meaningful.
 What is database: The database is a collection of inter-related data which is used to retrieve,
insert and delete the data efficiently.
 It is also used to organize the data in the form of a table, schema, views, and reports, etc.
 Using the database, you can easily retrieve, insert, and delete the information.
 For example: The college Database organizes the data about the admin, staff, students and
faculty etc.

What is DBMS?
DBMS File System
DBMS is a collection of data. In DBMS, the File system is a collection of data. In this
user is not required to write the procedures. system, the user has to write the procedures for
managing the database.
Searching data is easy in DBMS Searching is difficult in File System
DBMS is structured data Files are unstructured data
No data redundancy in DBMS Data redundancy is there in file system
Memory utilization well in DBMS Memory utilization poor in file system

A DBMS is software that allows creation, definition and manipulation of database, allowing
users to store, process and analyses data easily.
121
 DBMS provides us with an interface or a tool, to perform various operations like creating
database, storing data in it, updating data, creating tables in the database and a lot more.
 DBMS also provides protection and security to the databases.
 It also maintains data consistency in case of multiple users.

DATABASE APPLICATIONS – DBMS:

 Applications where we use Database Management Systems are:
 Telecom: There is a database to keeps track of the information regarding calls made, network
usage, customer details etc.
 Industry: Where it is a manufacturing unit, warehouse or distribution centre, each one needs
a database to keep the records of ins and outs
 Banking System: For storing customer info, tracking day to day credit and debit
transactions, generating bank statements etc.
 Sales: To store customer information, production information and invoice details.
 Airlines: To travel though airlines, we make early reservations; this reservation information
along with flight schedule is stored in database.
 Education sector: Database systems are frequently used in schools and colleges to store and
retrieve the data regarding student details, staff details, course details, exam details, payroll
data, attendance details, fees details etc.

Characteristics of DBMS
 Data stored into Tables: Data is never directly stored into the database. Data is stored into
tables, created inside the database.
 Reduced Redundancy: In the modern world hard drives are very cheap, but earlier when
hard drives were too expensive, unnecessary repetition of data in database was a big problem.
But DBMS follows Normalization which divides the data in such a way that repetition is
minimum.
 Data Consistency: On Live data, i.e. data that is being continuously updated and added,
maintaining the consistency of data can become a challenge. But DBMS handles it all by
itself.

122
 Support Multiple user and Concurrent Access: DBMS allows multiple users to work on
it(update, insert, delete data) at the same time and still manages to maintain the data
consistency.
 Query Language: DBMS provides users with a simple Query language, using which data
can be easily fetched, inserted, deleted and updated in a database.

Advantages of DBMS
 Controls database redundancy: It can control data redundancy because it stores all the data
in one single database file and that recorded data is placed in the database.
 Data sharing: In DBMS, the authorized users of an organization can share the data among
multiple users.
 Easily Maintenance: It can be easily maintainable due to the centralized nature of the
database system.
 Reduce time: It reduces development time and maintenance need.
 Backup: It provides backup and recovery subsystems which create automatic backup of data
from hardware and software failures and restores the data if required.
 multiple user interface: It provides different types of user interfaces like graphical user
interfaces, application program interfaces

Disadvantages of DBMS
 Cost of Hardware and Software: It requires a high speed of data processor and large
memory size to run DBMS software.
 Size: It occupies a large space of disks and large memory to run them efficiently.
 Complexity: Database system creates additional complexity and requirements.
 Higher impact of failure: Failure is highly impacted the database because in most of the
organization, all the data stored in a single database and if the database is damaged due to
electric failure or database corruption then the data may be lost forever.

What is Database Design?

 Designing of database is most important responsibility of the software professionals who are
dealing with the database related projects. For this they follow the Design Methodology. It
helps the designer to plan, manage, control, and evaluate database development projects.

123
 Design methodology: A structured approach that uses procedures, techniques, tools, and
documentation aids to support and facilitate the process of design.

Purpose of Database Design

 The main purpose of database systems is to manage the data. Consider a university that keeps
the data of students, teachers, courses, books etc. To manage this data we need to store this
data somewhere where we can add new data, delete unused data, update outdated data,
retrieve data, to perform these operations on data we need a Database management system
that allows us to store the data in such a way so that all these operations can be performed on
the data efficiently.

 Structure the data in stable structures, called normalized tables

 Not likely to change over time
 Minimal redundancy
 Develop a logical database design that reflects actual data requirements
 Develop a logical database design from which a physical database design can be
developed
 Translate a relational database model into a technical file and database design that
balances several performance factors
 Choose data storage technologies that will efficiently, accurately and securely process
database activities

7.3. Levels of Data Abstraction

Database systems are made-up of complex data structures. To ease the user interaction with
database, the developers hide internal irrelevant details from users. This process of hiding
irrelevant details from user is called data abstraction. This is also called as 'The Three-
Schema Architecture’, which can be used to separate the user applications and the physical
database.

124
We have three levels of abstraction:
1. Conceptual (view) Level:
 The process of constructing a model of the information used in an enterprise, independent of
all physical considerations.

The conceptual database design phase begins with the creation of a conceptual data model of
the enterprise, which is entirely independent of implementation details such as the target
DBMS, application programs, programming languages, hardware platform, performance issues,
or any other physical considerations.

 View level: Highest level of data abstraction. This level describes the user interaction with
database system.
 This is a lowest level, which describes entire database.
 Example: All application programs.

2. Logical Level:

 It is a process of constructing a model of the information used in an enterprise based on

specific data model, but independent of a particular DBMS and other physical
considerations.

The logical database design phase maps the conceptual model on to a logical model, which is
influenced by the data model for the target database (for example, the relational model). The
logical data model is a source of information for the physical design phase.

125
The output of this process is a global logical data model consisting of an Entity- Relationship
diagram, relational schema, and supporting documentation that describes this model, such as a
data dictionary. Together, these represent the sources of information for the physical design
process, and they provide the physical database designer with a vehicle for making tradeoffs that
are so important to an efficient database design.

 Logical level: This is the middle level of 3-level data abstraction architecture. It describes
what data is stored in database.
 This is next higher level that describes what data and what relationships in the database.
Example:
Each record
type customer = record cust_name: sting;
cust_city: string; cust_street: string;
end;
 Logical data format—The way in which a human being views data.
 Logical design—A stage in the design phase that matches the conceptual design to the
requirements of the selected DBMS an is, therefore, software-dependent. It is used to
translate the conceptual design into the internal model for a selected database management
system, such as DB2, SQL Server, Oracle, IMS, Informix, Access, and Ingress.
 The logical view is what the data look like, regardless of how they are stored.
 The physical view is the way data exist in physical storage. It deals with how data are stored,
accessed, or related to other data in storage. Four views of data exist: three logical and one
physical. The logical views are the user’s view, the programmer’s view and the overall
logical view, called a schema.

3. Physical Level:
 Physical level: This is the lowest level of data abstraction. It describes how data is actually
stored in database. You can get the complex data structure details at this level.
 Physical data format—The way in which the computer ―sees the data.
 This is a lowest level, which describes how the data is actually stores.
 Example: Customer account database can be described.

126
 It is a description of the implementation of the database on secondary storage; it describes
the base relations, file organizations, and indexes used to achieve efficient access to the data,
and any associated integrity constraints and security measures.

Whereas logical database design is concerned with the what, physical database design is
concerned with the how. The physical database design phase allows the designer to make
decisions on how the database is to be implemented. Therefore, physical design is tailored to a
specific DBMS. There is feedback between physical and logical design, because decisions taken
during physical design for improving performance may affect the logical data model.

For example, decisions taken during physical for improving performance, such as merging
relations together, might affect the structure of the logical data model, which will have an
associated effect on the application design.

7.4. Instance and schema in DBMS

 Definition of schema: Design of a database is called the schema. Schema is of three types:
Physical schema, logical schema and view schema.
 The design of a database at physical level is called physical schema, how the data stored in
blocks of storage is described at this level.
 Design of database at logical level is called logical schema, programmers and database
administrators work at this level, at this level data can be described as certain types of data
records gets stored in data structures, however the internal details such as implementation of
data structure is hidden at this level (available at physical level).
 Design of database at view level is called view schema. This generally describes end user
interaction with database systems.

Definition of instance: The data stored in database at a particular moment of time is called
instance of database. Database schema defines the variable declarations in tables that belong to a
particular database; the value of these variables at a moment of time is called the instance of that
database.

DBMS ARCHITECTURE:

127
 Database management systems architecture will help us understand the components of
database system and the relation among them.
 The architecture of DBMS depends on the computer system on which it runs.
 the basic client/server architecture is used to deal with a large number of PCs, web servers,
database servers and other components that are connected with networks.
 The client/server architecture consists of many PCs and a workstation which are connected
via the network.
 DBMS architecture depends upon how users are connected to the database to get their
request done.

TYPES OF DBMS ARCHITECTURE

There are three types of DBMS architecture:
1. Single tier architecture
2. Two tier architecture
3. Three tier architecture
1-Tier Architecture:
 In this type of architecture, the database is readily available on the client machine, any
request made by client doesn’t require a network connection to perform the action on the
database.
 Any changes done here will directly be done on the database itself. It doesn't provide a handy
tool for end users.
 The 1-Tier architecture is used for development of the local application, where programmers
can directly communicate with the database for the quick response.
2. Two tier architecture
 In two-tier architecture, the Database system is present at the server machine and the DBMS
application is present at the client machine, these two machines are connected with each
other through a reliable network.
 Whenever client machine makes a request to access the database present at server using a query
language like sql, the server perform the request on the database and returns the result back to the
client.
 The application connection interface such as JDBC, ODBC are used for the interaction between
server and client.

128
3-Tier Architecture
 In three-tier architecture, another layer is present between the client machine and server
machine.
 In this architecture, the client application doesn’t communicate directly with the database
systems present at the server machine, rather the client application communicates with server
application and the server application internally communicates with the database system
present at the server.

DATA MODELS:
 Data Model is the modeling of the data description, data semantics, and consistency
constraints of the data.

129
 It provides the conceptual tools for describing the design of a database at each level of data
abstraction.
 Therefore, there are following four data models used for understanding the structure of the
database:
Four Types of DBMS systems are:
 Hierarchical database
 Network database
 Relational database
 ER model database
Hierarchical DBMS
In a Hierarchical database, model data is organized in a tree-like structure. Data is Stored
Hierarchically (top down or bottom up) format. Data is represented using a parent-child
relationship. In Hierarchical DBMS parent may have many children, but children have only one
parent.

Network Model
The network database model allows each child to have multiple parents. It helps you to address
the need to model more complex relationships like as the orders/parts many-to-many
relationship. In this model, entities are organized in a graph which can be accessed through
several paths.

130
Relational model
Relational DBMS is the most widely used DBMS model because it is one of the easiest. This
model is based on normalizing data in the rows and columns of the tables. Relational model
stored in fixed structures and manipulated using SQL.

Relational Model (RM) represents the database as a collection of relations. A relation is nothing
but a table of values. Every row in the table represents a collection of related data values. These
rows in the table denote a real-world entity or relationship.
The table name and column names are helpful to interpret the meaning of values in each row.
The data are represented as a set of relations. In the relational model, data are stored as tables.
However, the physical storage of the data is independent of the way the data are logically
organized.

Relational Model Concepts

1. Attribute: Each column in a Table. Attributes are the properties which define a relation. e.g.,
Student_Rollno, NAME,etc.
2. Tables – In the Relational model the, relations are saved in the table format. It is stored along
with its entities. A table has two properties rows and columns. Rows represent records and
columns represent attributes.
3. Tuple – It is nothing but a single row of a table, which contains a single record.
4. Relation Schema: A relation schema represents the name of the relation with its attributes.
5. Degree: The total number of attributes which in the relation is called the degree of the relation.
6. Cardinality: Total number of rows present in the Table.
7. Column: The column represents the set of values for a specific attribute.
8. Relation instance – Relation instance is a finite set of tuples in the RDBMS system. Relation
instances never have duplicate tuples.
9. Relation key - Every row has one, two or multiple attributes, which is called relation key.

131
10. Attribute domain – Every attribute has some pre-defined value and scope which is known as
attribute domain

Entity-Relationship Model
Entity-Relationship (ER) Model is based on the notion of real-world entities and relationships
among them. While formulating real-world scenario into the database model, the ER Model
creates entity set, relationship set, general attributes and constraints.

ER model
 ER model stands for an Entity-Relationship model. It is a high-level data model. This model
is used to define the data elements and relationship for a specified system.
 It develops a conceptual design for the database. It also develops a very simple and easy to
design view of data.
 In ER modeling, the database structure is portrayed as a diagram called an entity-relationship
diagram.

For example, suppose we design a school database. In this database, the student will be an entity
with attributes like address, name, id, age, etc. The address can be another entity with attributes
like city, street name, pin code, etc and there will be a relationship between them.

132
Component of ER Diagram

133
7.5. Process of Database Design
a. Requirements Collection and Analysis:
 This is the first step in designing any database application.
 This is an informal process that involves discussions and studies and analyzing the
expectations of the users & the intended uses of the database.
 Under this, we have to understand the following.
1. What data is to be stored n a database?
2. What applications must be built?
3. What operations can be used? Example: For customer database, data is cust-name,
cust-city, and cust-no.

b. Conceptual database design:

The information gathered in the requirements analysis step is used to develop a higher-level
description of the data.
The goal of conceptual database design is a complete understanding of the database structure,
meaning (semantics), inter-relationships and constraints.

Characteristics of this phase are as below.

1. Expressiveness:
 The data model should be expressive to distinguish different types of data, relationships
and constraints.
2. Simplicity and Understandability:
 The model should be simple to understand the concepts.
3. Minimality:
 The model should have small number of basic concepts.
4. Diagrammatic Representation:
 The model should have a diagrammatic notation for displaying the conceptual schema.
5. Formality:
 A conceptual schema expressed in the data model must represent a formal specification
of the data. Example:
Cust_name : string; Cust_no : integer; Cust_city : string;

c. Logical Database Design:

134
Under this, we must choose a DBMS to implement our database design and convert the
conceptual database design into a database schema.
The choice of DBMS is governed by number of factors as below.
1. Economic Factors.
2. Organizational Factors.

Explanation is as below.
1. Economic Factors: These factors consist of the financial status of the applications.
a. Software Acquisition Cost: This consists buying the software including language options such
as forms, menu, recovery/backup options, web based graphic user interface (GUI) tools and
documentation.
b. Maintenance Cost: This is the cost of receiving standard maintenance service from the vendor
and for keeping the DBMS version up to date.
c. Hardware Acquisition Cost: This is the cost of additional memory, disk drives, controllers and
a specialized DBMS storage.
d. Database Creation and Conversion Cost: This is the cost of creating the database system from
scratch and converting an existing system to the new DBMS software.
e. Personal Cost: This is the cost of re-organization of the data processing department.
f. Training Cost: This is the cost of training for Programming, Application Development and
Database Administration.
g. Operating Cost: The cost of continued operation of the database system.

2. Organizational Factors: These factors support the organization of the vendor, can be
listed as below.
a. Data Complexity: Need of a DBMS.
b. Sharing among applications: The greater the sharing among applications, the more the
redundancy among files and hence the greater the need for a DBMS.
c. Dynamically evolving or growing data: If the data changes constantly, it is easier to cope with
these changes using a DBMS than using a file system.
d. Frequency of ad hoc requests for data: File systems are not suitable for ad hoc retrieval of
data.
e. Data Volume and Need for Control: These 2 factors needs for a DBMS.

135
Example: Customer database can be represented in the form of tables or diagrams.

3. Schema Refinement:
Under this, we have to analyze the collection of relations in our relational database schema to
identify the potential problems.

4. Physical Database Design:

Physical database design is the process of choosing specific storage structures and access paths
for the database files to achieve good performance for the various database applications.
This step involves building indexes on some tables and clustering some tables. The physical
database design can have the following options.
1. Response Time:
This is the elapsed time between submitting a database transaction for execution and receiving a
response.
2. Space Utilization:
This is the amount of storage space used by the database files and their access path structures on
disk including indexes and other access paths.
3. Transaction Throughput:
This is the average number of transactions that can be processed per minute.
5. Security Design:
In this step, we must identify different user groups and different roles played by various users.
For each role, and user group, we must identify the parts of the database that they must be able to
access, which are as below.

7.6. Designing Forms and Reports

 System inputs and outputs are produced at the end of the analysis phase
 Precise appearance was not defined during this phase
 Forms and reports are integrally related to DFD and E-R diagrams
Designing Forms and Reports: Key Concepts
 Form
 A business document that contains some predefined data and may include some
areas where additional data are to be filled in
 An instance of a form is typically based on one database record
136
  Report
 A business document that contains only predefined data
 A passive document for reading or viewing data
 Typically contains data from many database records or transactions
Common Types of Reports:
 Scheduled: produced at predefined time intervals for routine information needs
 Key-indicator: provides summary of critical information on regular basis
 Exception: highlights data outside of normal operating ranges
 Drill-down: provides details behind summary of key-indicator or exception reports
 Ad-hoc: responds to unplanned requests for non-routine information needs

The Process of Designing Forms and Reports

 User-focused activity
 Follows a prototyping approach
 Requirements determination
 Who will use the form or report?
 What is the purpose of the form or report?
 When is the report needed or used?
 Where does the form or report need to be delivered and used?
 How many people need to use or view the form or report?
 Prototyping
 Initial prototype is designed from requirements
 Users review prototype design and either accept the design or request changes
 If changes are requested, the construction-evaluation-request cycle is repeated
until the design is accepted

Deliverables and Outcomes

 Design specifications are major deliverable and contain three sections
Design specifications have three sections:
1. Narrative overview: characterizes users, tasks, system, and environmental factors
2. Sample design: image of the form (from coding sheet or form building development tool)

137
3. Testing and usability assessment: measuring test/usability results (consistency, sufficiency,
accuracy, etc.)

General Formatting Guidelines for Forms and Reports

 Highlighting
 Use sparingly to draw user to or away from certain information
 Blinking and audible tones should only be used to highlight critical information
requiring user’s immediate attention
 Methods should be consistently selected and used based upon level of importance
of emphasized information

138
General Formatting Guidelines for Forms and Reports
 Displaying Text
 Display text in mixed upper- and lowercase and use conventional punctuation
 Use double spacing if space permits. If not, place a blank line between
paragraphs
 Left-justify text and leave a ragged right margin
 Do not hyphenate words between lines
 Use abbreviations and acronyms only when they are widely understood by users
and are significantly shorter than the full text
 Displaying tables and lists
 Labels
 All columns and rows should have meaningful labels
 Labels should be separated from other information by using highlighting
 Redisplay labels when the data extend beyond a single screen or page

139
 Formatting columns, rows and text
 Sort in a meaningful order
 Place a blank line between every 5 rows in long columns
 Similar information displayed in multiple columns should be sorted
vertically
 Columns should have at least two spaces between them
 Allow white space on printed reports for user to write notes
 Use a single typeface, except for emphasis
 Use same family of typefaces within and across displays and reports
 Avoid overly fancy fonts
 Formatting numeric, textual and alphanumeric data
 Right-justify numeric data and align columns by decimal points or other
delimiter
 Left-justify textual data. Use short line length, usually 30 to 40 characters
per line
 Break long sequences of alphanumeric data into small groups of three to
four characters each

140
141
142
Designing Interfaces and Dialogues
 Focus on how information is provided to and captured from users
 Dialogues are analogous to a conversation between two people
 A good human-computer interface provides a unifying structure for finding, viewing and
invoking the different components of a system
The Process of Designing Interfaces and Dialogues
 User-focused activity
 Parallels form and report design process
 Employs prototyping methodology
 Collect information
 Construct prototype
 Assess usability
 Make refinements
 Deliverables

143
  Design Specifications
 Narrative
 Sample Design
 Testing and usability assessment
Designing Interfaces
 Designing Layouts
 Standard formats similar to paper-based forms and reports should be used
 Screen navigation on data entry screens should be left-to-right, top-to-bottom as
on paper forms
Designing Layouts
 Flexibility and consistency are primary design goals
 Users should be able to move freely between fields
 Data should not be permanently saved until the user explicitly requests this
 Each key and command should be assigned to one function
Structuring Data Entry

144
Controlling Data Input
 One objective of interface design is to reduce data entry errors
 Role of systems analyst is to anticipate user errors and design features into the system’s
interfaces to avoid, detect, and correct data entry mistakes
 Table 8-9 describes types of data entry errors
 Table 8-10 lists techniques used by system designers to detect errors

145
7.7. Providing Feedback
1. Status Information
 Keeps users informed of what is going on in system
 Displaying status information is especially important if the operation takes longer
than a second or two
2. Prompting Cues
 Best to keep as specific as possible
3. Error and Warning Messages
 Messages should be specific and free of error codes and jargon
 User should be guided toward a result rather than scolded
 Use terms familiar to user
 Be consistent in format and placement of messages
Providing Help
 Place yourself in user’s place when designing help

146
  Guidelines
 Simplicity
 Help messages should be short and to the point
 Organization
 Information in help messages should be easily absorbed by users
 Demonstrate
 It is useful to explicitly show users how to perform an operation
 Context-Sensitive Help
 Enables user to get field-specific help
 Users should always be returned to where they were when requesting help

Designing Dialogues
 Dialogue
 Sequence in which information is displayed to and obtained from a user
 Primary design guideline is consistency in sequence of actions, keystrokes, and
terminology
 Three-step process
1. Design dialogue sequence
2. Build a prototype
3. Assess usability

Designing the Dialogue Sequence

 Define the sequence
 Have a clear understanding of the user, task, technological and environmental
characteristics
 Dialogue Diagram
 A formal method for designing and representing human-computer dialogues using
box and line diagrams
 Consists of a box with three sections
1. Top: Unique display reference number used by other displays for
referencing dialogue
2. Middle: Contains the name or description of the display

147
 3. Bottom: Contains display reference numbers that can be accessed from
the current display

7.8. Designing Dialogues:

Building Prototypes and Assessing Usability
 Often optional activities
 Task is simplified by using graphical design environment

148
7.9. Electronic Commerce Application:
Designing the Human Interface at Pine Valley Furniture
 Design Guidelines
Navigation via cookie crumbs
 A technique that uses a series of tabs on a Web page to show users where
they are and where they have been in the site
 Tabs are hyperlinks to allow users to move backward easily within the site
 Two important purposes
 Allows users to navigate to a point previously visited
 Shows users where they have been and how far they have gone
from point of entry into site

149
Electronic Commerce Application: Design Guidelines
 Lightweight Graphics
 The use of small images to allow a Web page to be displayed more quickly
 Forms and Data Integrity
 All forms that record information should be clearly labeled and provide room for
input
 Clear examples of input should be provided to reduce data errors
 Site must clearly designate which fields are required, which are optional and
which have a range of values
 Template-based HTML
 Templates to display and process common attributes of higher-level, more
abstract items
 Creates an interface that is very easy to maintain
Summary
 Designing Forms and Reports
 General guidelines for designing forms and reports
 Formatting text, tables and lists
 Design guidelines for interfaces
 Layout design
 Structuring data entry fields
 Providing feedback
 Designing help
 Human-Computer dialogue design
 Interface design guidelines unique to the Internet

150