Module 3

System Analysis and Development and its models

3.1 SYSTEM CONCEPTS

The word ‘System’ is used in day to day life very frequently in describing the subjects, such
as the traffic system, education system, business system, etc. The system provides a
meaningful framework for describing and understanding the features and functions of the
subject.
System is defined as a set of elements arranged in an orderly manner to accomplish an
objective. Some examples are given in Table 3.1.

Table 3.1 Examples of System

Systems Elements Objective

Computer Input, process and output devices. Oper- Process the data and provide informa-
ating system, compliers, packages. tion.
Accounting Financial transactions, accounting prin- Process the transactions and produce
ciples and rules, transaction processing monthly books of accounts and the in-
methods of accounting. formation for financial management.
Business organisation People, plant and machinery, product Produce goods and services to achieve
and services, communications, trans- the business objectives of service, turn-
port, materials. over and profits.

It is to be noted that a system is not a randomly arranged set. It is arranged with some logic governed by
rules, regulations, principles and policies. Such an arrangement is also influenced by the objective the
system desires to achieve. For example, if a computer system is designed to perform commercial data
processing, then the elements will be the data entry de-vices, a CPU, a disk, a memory, application
programmes and a printer. If a computer system is designed to achieve the objectives of design,
engineering, and drawing processing, then the elements will be the graphic work stations, the graphic
processor, and the languages suitable for engineering and design applications, and plotters for drawing
the output.
Hence, a clear statement of objectives brings a precision and an order into the selection of
elements and their arrangement in the system. Any disorder would create a disturbance in the
system, affecting the accomplishment of the objective.
If a system in any field is analysed, it will be observed that it has three basic parts, which are
organised in an orderly manner. These three parts can be represented in a model as shown in
Fig. 3.1.

Fig. 3.1 Parts of a System

A system may have single input and multiple outputs or may have several inputs and outputs.
For example, a business organisation system has several inputs and multiple objectives, such
as sales, profit, service and growth. The choice of inputs and processing methodology is
governed by the objectives set for the system. Any misalignment in this arrangement would lead
to a wasteful collection of inputs, and its processing will fail to achieve the desired objective.
All the systems operate in an environment. The environment may influence the system in its
design and performance. When a system is designed to achieve certain objectives, it
automatically sets the boundaries for itself. The understanding of boundaries of the system is
essential to bring a clarity in explaining the system components and their arrangement.
If an additional objective is to be introduced in the system, it may to be possible as the new
objective may fall outside the boundaries or the scope of the system. For example, a system
designed to spread literacy amongst a large population cannot achieve the objective of
excellence in knowledge and understanding of the language. A computer system designed for
commercial data processing cannot achieve the objective of design and drafting, as the system
elements and its boundaries do not permit it. A generalised model of the system in an
environment will be as shown in Fig. 3.2.

Fig. 3.2 Generalised Model of a System

The environment influences the choice of inputs, the method of processing, and the nature
and contents of the outputs.
Since the systems are designed for specific objectives/outputs, the designer provides a filter
around the system to control the influence on the system. For example, take a manufacturing
system, where the objective is to produce products of desired quality. Since the raw material and
the processes are selected with this objective, the quality control systems exercise a control on
the quality of incoming raw material and keep a continuous watch on the process parameters to
keep the desired quality of production. The quality control systems, therefore, provide a filter
around the manufacturing system which protects the system from the undesirable influences of
the environment.
The designer of the system, therefore, has to consider the environment and select appropriate
inputs, and filtering mechanism to protect the system for the undue or undesirable influences
of the environment.
Most of the failures of the systems lie in the area of selection of the inputs and the pro-cesses,
and not providing the appropriate filtering systems.

3.2 SYSTEMS CONTROL

Since the systems are designed to achieve specific objectives, ensuring the achievement of the
objectives through system control, becomes the integral part of the system design. The control
calls for, in the first place, a measurement of the output in some terms. The device that measures
the output is called a sensor. The next step is to set the standard or norm of the output as an index
of the system performance. The sensor measures the output and compares it with the standard. If
the measured output compares well with the standard, the system provides a feedback to continue
the operations.
If the measured output does not compare well with the standard, then a feedback is provided
to the system to stop the operations. The process of comparison of a measured output with
the standard is done by a unit called as comparison unit.
The mechanism, which provides a signal to the system, about the quality of performance,
favourable or adverse, is called a feedback mechanism.
Many times, the system may not have an appropriate mechanism to act on the signal which
it receives. It is, therefore, necessary to provide an in-built mechanism which will decide,
based on the feedback to stop, regulate or continue the system operations. Such a
mechanism is called a corrective unit and it is responsible for ensuring the system
performance. The corrective unit, in its performance, will act on inputs and processes to bring
the system under control.
The process of measuring the output, comparing with the standard, sending the signal to the corrective
unit and the corrective unit acting upon it, is called a control. Any break down in this path will affect the
system performance adversely. A system set for a specific objective, devoid of any control, will perform
in a disorderly manner and can disturb the system equilibrium. The role of a control is to regulate the
system operations and performance, and keep it in an equilibrium condition. The control, therefore, is
the heart and brain of the system.
The control could either be internal or external to the system. For example, in an air conditioning system,
switching on and off of the compressor is automatic and hence it is an internal
control. In the roads and traffic system, the traffic policeman acts as a control system, which is
external to the traffic system. Most of the modern systems have an in-built automatic control
systems.
The information system can be understood in terms of system concepts. The information system
receives the inputs of the data and the instructions (a set of the Computer Programmes) to
process the data according to the given instructions and give the output of the processed results.
The information systems are designed in a particular environment of business, industry and management.
When the environmental factors or the inputs change, the system process is under a stress. Stress beyond
a limit affects the other system elements which in turn affects the achievements of the goal. A system may
have the ability to manage the stress and still be in a condition to achieve the desired goal. Unmanageable
stress leads to a system failure.
The concept of control is based on the condition of a feedback. If the feedback is positive, i.e., the
measure of the output compares favourably with the standard or norm, the control will keep the
system operating in the same condition. However, if the feedback is negative, i.e., the measure of the
output is unfavourable when compared to the standard or norm, the control will act on the input or
process to bring back the system to the state of equilibrium. The control system model with a control
feature is shown in the Fig. 3.3.

Fig. 3.3 Control System Model

The manner in which the MIS supports the management of business is illustrated in the
Table 3.2.

Table 3.2 MIS and Support to Business

System components Business system Management information system

Inputs Raw materials, plant and ma- Data from transactions of purchase, production
chinery, manufacturing, selling and sales, receipts and payments.
arrangement, accounting.
Process Purchasing, manufacturing, sell- Transaction processing and data processing.
ing, accounting.
Outputs Quantity of production, sales, Computation of production in numbers, sales in
stock, income and profit. value, stocks in weight, income and profit in ru-
pees.
Sensor Profit. Income less assigned cost.
Comparison unit Expectation of profit vs actual Algebraic comparison module to compare income
profit. vs budgeted income profit vs budgeted profit.
Standard Profit, Target. Budgeted profits of various products.
Feedback Balance Sheet and Analysis. Exception reports after analysis showing products
earning profit below the budget.
Corrective unit Managing Director. Marketing Manager.
Business decisions. Pricing, advertising and promoting decisions.

3.3 TYPES OF SYSTEM

A system is defined and determined by its boundaries and objectives. It is quite likely that a system
is an arrangement of smaller systems in a logical order. When many smaller systems together make
a larger system, the smaller systems are called the subsystems of the larger system. A large system
can be split or decomposed into smaller subsystems up to a certain level. This decomposition can go
down to a level where the input and the output are more or less same. The decomposition of a system
into subsystems can be in a serial form or it could be in a matrix form as shown in Figs. 3.6 and 3.7.

Fig. 3.6 Subsystems in Serial Order

In a serial system processing, the entire output of a subsystem is the input to the next subsystem and
so on. In the matrix arrangement the different outputs go to different sub-systems. A subsystem
receives more than one input from other subsystems.
In any system, the inputs are transformed into the output by the process. We say that the process is
transparent to us when we are able to understand the system. But, if the process of
 Fig. 3.7 Subsystems Operating in Matrix Order

input transformation is not visible and understandable then we say that the system is a
black box and the process is not transparent as shown in Fig. 3.8.

Fig. 3.8 Black Box System

A large system is always complex and difficult to understand. Therefore, for viewing it in a
different way, the system is split into the smaller subsystems.
Most of the systems can be viewed in a hierarchical structure. For example, a bill passing system in a
commercial organisation can be shown in a hierarchical structure in Fig. 3.9.

Fig. 3.9 Hierarchical Structure of the System

Breaking the system in a hierarchical manner provides a way to structured systems analysis. It gives
a clear understanding of the contribution of each subsystem in terms of data flow and decisions, and
its interface to the other subsystems.
The systems can be classified in different categories based on the predictability of its output and the degree of
information exchange with the environment. A system is called deterministic when the inputs, the process and
the outputs are known with certainty. In a deterministic system, you can predict the output with certainty. A system
is called probabilistic, when the output can only be predicted in probabilistic terms. The accounting system is
deterministic while the demand forecasting system is a probabilistic one. A deterministic system operates in a
predictable manner while a probabilistic system behaviour is not predictable.
If a system is functioning in isolation from the environment, then the system does not have any
exchange with the environment nor is it influenced by the environmental changes. Such a system is
called a closed system. If the system has exchange with the environment and is influenced by the
environment then it is called an open system. All kinds of accounting systems, viz., cash, stocks,
attendance of employees are closed systems. Most of the systems based on rules and principles are
closed systems.
The systems which are required to respond to changes in the environment, such as marketing,
communication and forecasting are open systems. All open systems must have a self-organising
ability and a sensitivity to absorb and adjust to the environmental changes. The business
organisation systems are open systems. The systems of manufacturing are closed systems.
The information system is a combination of a person (the user of information), the hard-ware
and the software. The hard ware-software system is a closed deterministic system but in
combination with the user it is an open and a probabilistic system.
Generally the deterministic systems are closed, and the probabilistic systems are open. The deterministic
and the closed systems are easy to computerise as they are based on facts and their behaviour can be
predicted with certainty. A fixed deposit accounting system, an invoicing system, and share accounting
systems are examples of closed and deterministic systems.
The probabilistic and the open systems are complex in ever aspect. Hence, they call for
considerable amount of checks and controls so that the system behaviour or the performance
can be controlled. All such systems must ideally have self organising corrective system to keep
the system going its desired path.
For example, the pricing systems are probabilistic and open. They are to be so designed that the changes
in the taxes and duties, the purchase price and the supply positions are taken care of, in the sales price
computation. Since the pricing system operates under the influence of the environment, it has to be
designed with flexible computing routines to determine the price. The building of self-organising processing
routines to respond to the environmental influences is a complex task both in terms of the design and
operations of the system.

3.4 HANDLING SYSTEM COMPLEXITY

Information systems are relatively complex as compared to physical systems, and, therefore,
they should be handled properly enabling the system designer to understand, design, develop
and implement.
To handle the complexity, the system can be viewed as an assembly of subsystems each with a clear
definition of the boundaries, interfaces and their connectivity. The subsystems then are put in the
hierarchical order to provide a structural view showing the developmental path to the designer. The
process is called factorisation of the system into subsystems.
Another method of handling the complexity is to resort to simplification by clustering the
subsystems together. Handling all the subsystems together with their interconnections is
difficult.
The number of interconnections increases with the increase in the number of subsystems. Each
interconnection acts as a channel for the input-output communication. The process of simplification
provides a way to handle these interconnections and reduce the complexity. The method of
simplification is as follows:
1. Identify the subsystems which have to be together for the functional ‘cohesion.’
2. Form a cluster of these subsystems and identify interconnections in this cluster.
3. Form clusters of the remaining subsystems.
4. Connect the clusters with an interface.
To illustrate the above let us discuss materials management system can be taken up.

Materials Management System

The above system can be subdivided into the following subsystems for the purpose of
handling the complexity as shown in Step 1 below:
(A) Procurement system.
(B) Purchase order follow up system.
(C) Receipts accounting system.
(D) Material requirement planning system.
(E) Material issue requisition system.
(F) Bill passing and payment system.
(G) Inventory control system.
Materials management system is divided into seven subsystems from A to G and their
interconnections are identified as specified in Step 2. See Fig. 3.10.

Fig. 3.10 Step 2—Subsystems with Interconnections

The subsystems can be clustered in a number of ways. In the example, we have clustered the
subsystems on the basis of the managerial function such as purchase, accounting and planning as
shown in Fig. 3.11. We can also cluster the subsystems by operating departments. In that case the
subsystems A, B, C, and E will be a cluster, F will be the second cluster, and D and G will be the
third cluster. The operating departments are Materials, Finance, Production Planning and Control,
respectively.
Fig. 3.11 Step 3—Formation on Clusters on the Basis of Managerial Function

The choice of the basis for clustering will depend on the view taken by the designer of the system to handle
the complexity. If the degree of complexity is more because of the functions, the choice of clustering will
be based on the functions. But if the degree of complexity is more because of the operations, the clustering
will be on the basis of the operations.
When the subsystems are clustered together and connected, the designer faces the problem of tight
connectivity. The connectivity becomes tight because a close coordination is required among the clusters
in terms of time and resources. This requires two clusters to operate in a synchronised manner. When the
subsystems are of open type, where the environmental ex-change causes a lot of behavioural influence,
the synchronisation becomes extremely difficult. A failure in synchronisation leads to the breakdown of the
system.
The solution to the problem of tight connectivity is to decouple the clusters from each other by
providing an interface between the clusters. The process of decoupling makes the two clusters
operationally independent of each other. The decoupling, the Step 4, in the present example is shown
in Fig. 3.12 by providing an interface between the purchase and the stock subsystems, and also
between stock and planning systems.
The problem of right connectivity and providing interface arises from the requirement of having
the input information from the other subsystem on time. So basically it is a problem of
synchronised communication in the information exchange between the two clusters. The
interface provides an operational independence by allowing the other subsystem to operate on
the limited information already stored.
Fig. 3.12 Step 4—Decoupling of Subsystems’ Cluster by Stock Information Interface

However, the benefits of the operational independence are not without the extra cost of
providing an interface because as a subsystem, the interface also needs to be designed,
keeping in view the specified needs of the interfaced subsystems.
The use of decoupling mechanism should be considered as the last alternative for reducing the
rigid requirements of a communication exchange. The designer as far as possible should
endeavour to avoid interfaces to control the cost of information system. The modern hard-ware
and software offer solutions to resolve these problems.

System Efficiency and Effectiveness

The performance of the system can be measured by two factors, viz., the efficiency and the
effectiveness. The efficiency indicates the manner in which the inputs are used by the system. Being
efficient means the system uses inputs in a ‘right’ way. If the input-output ratio is ad-verse, we say that
the system is inefficient though it produces the desired output.
The effectiveness is the measure for deciding whether the system provides the desired out-put or not.
Being effective means producing the right output in terms of quantity and quality. When the system is
ineffective, the system is out of control and it needs a major correction.
A system has to be effective and efficient for the highest utility to the user of the system. Broadly
speaking, the effectiveness is a measure of the goodness of the output, while the efficiency is a measure
of the productivity, i.e., the measure of the output against the input.

Post Implementation Problems in a System

The system designer designs and develops the information systems and implements them within
the organisation. When systems are allowed to run for some time, they tend to become
disorganised, resulting into system inefficiency. The process of decay and its cause is called
‘Entropy.’ The designer is thus called upon to introduce a negative entropy, i.e., to provide a course
of action, whereby the decay is arrested and the system is brought back to the state of equilibrium,
producing the desired objectives. The process of providing a negative entropy is called system
maintenance. Every system is provided with a maintenance procedure as given in Table 3.3.

As a preventive measure, a negative entropy is provided as a part of the system routine.

The steps are:
(a) A periodical review of the system,
(b) User meetings to assess the current utility of the system and the level of satisfaction,
(c) Subjecting the system to an audit check through the test data,
(d) Running the system under audit trail,
(e) Bringing out system modifications.

Table 3.3 Examples of System Maintenance Procedure (Negative Entropy)

System Indications of entropy Negative entropy

Human body Loss of weight, headache Medical check-up and prescribed diet
and medicines.
Computer System halts, read and write errors. Preventive maintenance and replace-
ment of sensitive components.
Data processing Errors and omissions in the data on Review and introduction of the stream-
increase. lined procedures.
Information processing Decline in the utility and satisfaction, Resetting the goals of information
changed information needs system. Add revised information needs
and modify the information system.

The another post implementation problem that the system designer faces is a forced change in the
goal due to the other systems in the organisation having undergone the change. An-other possibility
is that the existing goal may have to be modified at a new level. If the system designed is capable
enough to absorb the forced change of goal, then system decay is not possible. However, if the
system design is inflexible, then it is not possible to accommodate the forced changes and then the
system decay beings.
Problems of system decay arise in the organisation because the business environment changes, leading
to a modification in the business goals and objectives. Such a change induces down the line changes in
the objectives, targets and focus. The information needs of the man-agers change as result of the changes
all around. Such a change in the requirement forces a change in the MIS goals, calling modifications to the
information systems to meet the revised information needs. The system changes could be in the area so
hardware and software. The change may call for more hardware and software resources such as storage
and processing capability or terminal facilities in a wider area for access to more users. The system may
be required to write additional application programmes, more query screens, widen the scope of the
database, and provide the end user with computing facility. The system designer can easily handle such
post implementation problems, if the information system plan is developed for the organisation with a long
term objective.
The designer should keep in mind that the organisation is an open system bound to receive new inputs in
an unplanned and unscheduled manner and the organisation should adapt itself to these new inputs to
continue its existence. While designing the system, appropriate features should be provided to adopt the
changes which will be forced on the system. The efficiency of the information system is high if these
changes are easily accommodated in a short time. It should also be borne in mind that when
one deals with such changes, the core systems do not undergo a significant change.
The keys to handle the post implementation problems in the systems are:
(a) The core system design must be comprehensive and flexible to undergo a quick
change.
(b) The associated peripheral systems should be built with a flexible design.
The most successful way or handling these problems is to have a business analyst in the
organisation and perceive the business needs of the information and user object oriented
technology for efficient system design.
3.7 THE NEED FOR SYSTEM ANALYSIS
When you are asked to computerise a system, it is necessary to analyse the system from different
angles. The analysis of the system is the basic necessity for an efficient system design. The need for
analysis stems from the following points of view.

System Objective
It is necessary to define the systems objective(s). Many a times, it is observed that the systems
are historically in operation and have lost their main purpose of achievement of the objectives.
The users of the system and the personnel involved are not in a position to define the
objective(s). Since you are going to develop a computer based system, it is necessary to redefine
or reset the objective(s) as a reference point in context of the current business requirement.

System Boundaries
It is necessary to establish the system boundaries which would define the scope and the
coverage of the system. This helps to sort out and understand the functional boundaries of
the system, the department boundaries in the system, and the people involved in the system.
It also helps to identify the inputs and the outputs of the various subsystems, covering the
entire system.

System Importance
It is necessary to understand the importance of the system in the organisation. This would
throw more light on its utility and would help the designer to decide the design features of the
system. It would be possible then to position the system in relation to the other systems for
deciding the design strategy and development.

Nature of the System

The analysis of the system will help the system designer to conclude whether the system is
the closed type or an open, and a deterministic or a probabilistic. Such an understanding of
the system is necessary, prior to design the process to ensure the necessary design
architecture.

Role of the System as an Interface

The system, many a times, acts as an interface to the other systems. Hence through such an
interface, it activates or promotes some changes in the other systems. It is necessary to
understand the existing role of the system, as an interface, to safeguard the interests of the
other systems. Any modifications or changes made should not affect the functioning or the
objectives of the other systems.

Participation of Users
The strategic purpose of the analysis of the system is to seek the acceptance of the people
to a new development. System analysis process provides a sense of participation to the
people. This helps in breaking the resistance to the new development and it also then ensures
the commitment to the new system.

Understanding of Resource Needs

The analysis of the system helps in defining the resource requirements in terms of hardware
and software. Hence, if any additional resources are required, this would mean an investment.
The management likes to evaluate the investment from the point of view of return on such
investment. If the return on the investment is not attractive, the management may drop the
project.

Assessment of Feasibility
The analysis of the system helps to establish the feasibility from different angles. The system
should satisfy the technical, economic and operational feasibility.
Many times, the systems are feasible from the technical and economic point of view; but they
may be infeasible from the operational point of view.

The assessment of feasibility will save the investment and the system designer’s time. It would
also save the embarrassment to the system designer as he is viewed as the key figure in such
projects. One can approach the system analysis and design exercise in a systematic manner
in steps, as shown in Table 3.4 below.
Table 3.4 Steps in System Analysis and Design

Steps Elaboration Explanation

Need for information Define the nature of information. Also Identify the users and application of
who wants and who uses. the information for achieving the ob-
jectives.
Define the system Decide the nature, type of the system Helps to determine the system owner-
and its scope. ship, its benefits and complexity.
Feasibility Technical success Hardware and software availability and
capability, for implementation.
Economic viability Study investment and benefits.
Assess the improvement in value of the
information. Determine the
return on investment.
Operational Effectiveness Examine whether the system will per-
form as desired in terms of time and
results. Are the users ready to use the
system?
Detailing of the require- Identify in precise terms, the strategic, Study the sources of generating the
ments functional and operational information information. Establish I/O linkages.
needs. Modify the existing system to satisfy
the needs.
Conceptual system de- Determine the inputs, process and out- Conceptualisation is necessary to un-
sign puts, and design a conceptual mode. derstand the system process.
Detailing the system de- Draw the document flow charts and Helps in bringing a clarity in the data-
sign the dataflow diagrams, the data and flow. The responsibility centres and the
system hierarchy diagrams, the data, process centres are identified.
information versus its users mapping
table.
Structuring the system Break the system into its hierarchical Helps in understanding the data flow
design structure. from one level to the other and the pro-
cesses carried out at each level.
Conceptual model of Define step by step the usage of files, Helps to put down the data processing
computer system processes and interface. Define the flow in the computerised system. Draw
data structures and draw system flow the computer system charts.
diagrams.
Break the system in pro- Make a physical conversion of the sys- Modules will be data entry, data vali-
gramme modules tem into the programme structures in dation, data processing, reporting and
a logical order. storing.
Contd...
Contd...

Develop the test data Test the modules and the integrity of Confirms whether the system design
test cases for checking the system in terms of input versus is satisfactory. Suggests the
the system ability output. Plan white box and black box modifications.
testing.
Install the system Install on the hardware. Install, test and run the system before
the user is exposed in a live mode.
Implementation Train the personnel. Run the system in Helps to identify the user problems
parallel. Prepare a system manual. and provide solutions.
Review and mainte- Review the system through audit trail and Helps to maintain the system quality
nance test data, use change management and the quality of information through
system for modifications. modification, if necessary.

Black Box Testing is a software testing method in which the internal

structure/design/implementation of the item being tested is not known to the tester.
Only the external design and structure are tested.

White Box Testing is a software testing method in which the internal

structure/design/implementation of the item being tested is known to the tester.

3.8 SYSTEM ANALYSIS OF THE EXISTING SYSTEM

When the objectives of the information system are finalised, as the first step towards
development, it is necessary to analyse the existing system.
Such an analysis helps in achieving the following:
• Understanding the existing system.
• Understanding the objectives achieved by the existing system.
• Evaluating the system for computerisation and its placement in the total MIS design.
• Knowing whether the system is feasible technically and operationally.
• Are the information needs fully justified?
• If so, is the cost of the system design justified to increase the value of the
information?

Procedure of Analysing the Existing System

System analyst while analysing the existing system should:
1. Carry out the analysis of the system at a place where the system is functioning. This step will
ensure that the analyst is accepted as one of those operating the system.
2. Note down the key personnel in the system besides the head of the department. The key
personnel are those who contribute towards the system operations.
3. Spend some time with the operating personnel and observe the system to
understand the finer details of the system.
4. Define the scope of the system and its objective. The scope will cover the boundaries
of the system. Further, should identify the problems faced in the system which cause
difficulties in achieving the objectives.
5. Collect all the documents which are raised in the system. These documents carry data
form one point to another. The documents could be printed or handwritten. While collecting the
documents, the analyst should note down who raises the document, the purpose it achieves, and
the manner in which it is distributed.

6. Collect separately the outputs which as statements, reports, memos, etc. made in the
system to throw more light on the information it generates. If these reports and the statements are
sent to other departments, make a note of it. Also find out if any register or notebook is maintained at
various points, which act as data storage and reference. Note down against each such document, its
use.
7. Make a list of rules, formulae, guidelines, policies, etc., which are used in running
the system.
8. Note down the check points and the controls used in the system to ensure that the data
flow is complete, processing of the data is correct and the analysis is precise.
9. Study the flow of data in the system in units, summary and aggregates from
document to document and from one stage to the other.
10. Make a small system note as a base document and seek an appointment with each head of the
department to discuss the system. In the discussion, ensure that your sys-tem view and understanding is
the same as that of the head of the department. Ascertain from him whether he has any other objectives
which the system should achieve.
11. Examine whether the achievement of the system’s objectives is feasible in the present
system. This means, examining whether adequate data exists, whether it can be pro-cessed by the
rules, methods, model, already there to generate information. If so, will the information be correct,
precise and complete. Further, can it be processed on time to be useful to the user or the decision
maker?
12. If there are problems in the feasibility of implementation, then examine whether the
present system can be modified by introduction of documents, controls, procedures and
systems. If this is not possible, redefine the scope of the system and objectives in the light of the
study.
13. Draw a revised system flow chart to indicate how the system runs the major steps of
processing the information. This chart should include all the modifications which had been
suggested and accepted.
14. Discuss the flow chart with the personnel operating the system so that they under-
stand the system. Impress upon them that they should run the system as per the flow chart, and
resist any deviations therefrom that would cause a disturbance in the sys-tem. Explain the
modified system in such a way that the user would appreciate the changes.
15. Make a list of the outputs (statements, reports) containing information. Get the con-
tents of the reports approved by the head of the department.
16. Analyse the requirements of the information and reports from the utility point of view.
More the information, higher is the cost of its generation. Decide the utility based on the value
of information.
17. Compare the costs of the old and the new system, and benefits offered.
18. Obtain approval of the new system from the users and the top management.
19. Write a system manual for use of the people in the department and for reference to
the other users of the system.
3.9 SYSTEM ANALYSIS OF A NEW REQUIREMENT
It is not always necessary that the analysts are required to conduct the analysis of the existing
system. In a number of cases when legacy systems have outlived their utility or a new
business environment requires a totally radical approach, the analyst is called for redesigning
the processes, practices and procedures.
Today’s business world is beyond the four walls of the organisation. The vendors and the customers
are being treated as trusted business partners of the organisation. This change in the management
philosophy calls for a change in the information management function in the organisation. It cuts across
all the facets of processing the data and the information, right from the input to the output and its
distribution. The conventional confidential access to the information, and the practice of authorising a
person to make decisions has undergone a substantial change. The decision centres in the organisation
have been diffused and a substantial delegation of decision-making has taken place at the lower level.
The characteristic change in the organisation is that it is being looked as a process organisation as
against a functional organisation. The work culture is changing from the single hierarchical command
control principle to the collaborative working through work groups principle. These work groups are
empowered to make decisions with an access to support the information. In such changed environment,
the information system architecture, the design and processes, and the hardware-software configuration
should be restructured to meet this changed requirement of information. The trend is towards building
a system which is potentially flexible, adaptable to the new technology, easy to use, and which enables
the user to meet his own needs through his knowledge and expertise.
The system analyst, in such a virgin situation of policy change, has to think globally, taking into
consideration the technology, the user, and the business it serves. He is required to make analysis to
evolve the system and the technology strategy, and configuring them to work for executing the business
strategy through the information support. The system analyst has to choose between the client server
versus the Host-slave processing strategy. He has to make a choice between the different variants of
Unix OS, Windows NT and so on. He has to choose the language platform and select a variety of
packages, and put them together to achieve the information support goal. He will also be confronted
with techno-commercial issues arising out of the multiple vendors dealing with different technologies.
Putting all the system components together to achieve the information processing strategy success is
quite a complex job requiring a vision and a foresight.
Hence, the System Analysis and Design, in such situations, is an exercise at a macro level
with a top-down approach in understanding the requirement.
The information system development cycle for a new application consists of the five
major stages:
1. Definition of the system and its objective
2. Development of the system (Analysis-Design-Programming)
3. Installation of the system
4. Operations of the system
5. Review and evaluation
The details of this system development cycle are given in Table 3.5.

Table 3.5 System Development Cycle

Stages in development cycle Steps in each stage Purpose

Definition of the system Define the system and its elements. The stage assures clarity to the users
and its objective Determine the system boundaries of the system and the System Design-
and scope. Set the objectives for the er. The terms of reference are also set.
system in line with the business ob-
jectives.
Development of the sys- The system analysis of the existing More clear understanding of real life
tem business systems and changes there- situations, problems and weaknesses.
in.
System analysis of similar systems. This step ensures that the information
Decision-making needs are identified requirements are defined as a support
and corresponding information needs to decision-making.
are defined.
A feasibility of system is examined. The technical, economic and opera-
tional feasibility is ascertained before
a major effort is spent on the system.
A conceptual design of the system. The post feasibility understanding of
the system for users and designer.
An initial prototype of the system The step ensures the supply of the
basic information needs. It helps to re-
fine and revise the information needs
and then the conceptual design.
Structured break-up of the system in Helps to understand the system func-
the smaller subsystems/processes in tioning adn brings a clarity in the in-
hierarchical order for development. put and outputs of each subsystem.
Design a computer system output de- Ensures step by step approach to a
sign, input design, processing design, computer system design and pro-
procedure design. Flow charting the vides clarity to the user and designer
system and documentation. This in- through documentation.
cludes a database design architecture
and application development design.
Installation of the system The system is tested and installed on The step ensures that the operational
and testing. the hardware for implementation. problems are resolved and the user
Switching over to computer system gets live experience of the system.
after thorough operational tasting. Modifications, if any, are carried out.
Checks and controls are ensured
through testing and the parallel runs.
Operations of the system The system is operated in full course The user confidence is built and the
and existing systems (if any) discon- designer simultaneously evaluates
tinued. the performance of the computer sys-
tem.

Contd...
Contd...

Review and Evaluation A review is taken whether the This is an audit by the designer for
system objectives are being met improvement through test data and
with and what are the problems in audit trail.
the smooth running. Steps are
taken to resolve them.

Following the system development cycle approach is the best bet for the successful
completion of any system project. The main advantage of the approach is that the process
helps the analyst to conceive, develop, design and implement the system. Following the
procedure provides the basis for management and control of the project as each step in the
process is a well defined task.
The most important step in the process is the definition and the objectives of the system.
Unless the user and the designer agree on this point, it will be risky to proceed further. The
systems analysis is the second most important step in the cycle. The designers who spend
more time on this step succeed in completing the project effectively. About 30 per cent of the
time should be spent in the first two phases and about 10 per cent of the time in the post
implementation review and evaluation. The prototyping step is a critical step where the user
understands the system in the initial stage and helps to try out the ideas in the system leading
to the process design of the information system. The life cycle procedure is a tool for the
system designer. Its meticulous following is a safe method to accomplish the system
objectives.

3.10 SYSTEM DEVELOPMENT MODEL

In order to design a good system, traditionally, the developers have used the Waterfall model
as shown in Fig. 3.19.
As waterfall flows from the top to the bottom, the system model shows the development
process from the top to the bottom in steps. As water does not rise from a lower level to a
higher level, it is presumed that once a step in the model is over, it is not required to go back.
This model fits well when the changes into the requirement specifications are not required
frequently. The minor changes can be taken care of through a maintenance process or
through small design changes. The waterfall model applies well to the basic rule based data
and information processing systems in accounting materials, production and personnel.
However, some systems are more dynamic and require changes in specifications more of-
ten to continue to be useful. These modifications are termed as the versions of the basic mod-
el. One of the popular model developed by Boehm is a Spiral model as shown in Fig. 3.20.
A spiral model fits well, when we are developing large systems, where the specifications
cannot be ascertained in one stroke completely and correctly. Some of them get surfaced
when the system is put to use after its testing. The continuous revision of these steps in the
system development is very common and then the designers call them as versions. The new
version provides an additional functionality, features, and facilities to the user, and addresses
the issues of the users of the system viz. performance, response, security and so on,
irrespective of which development model is used in developing the system. The user wants
the sys-tem to be user friendly, reliable and effective, and one which gives correct results,
while the developer wants, the system easy to modify, easy to understand, portable and
compatible to other systems.
Waterfall Model
 Linear sequential model.
 Oldest model, since the 70s.
 Most widely used in software engineering.
Documentation is produced at every stage.
 Problems: Inflexible partitioning of the project into distinct stages makes it difficult to
respond to changing customer requirements.
 Applicability:
 Appropriate when requirements are well understood.
 Changes will be fairly limited during the design process.
 Large interactive systems.
 Mostly used for large systems engineering projects.
Fig. 3.19 Waterfall Model

Spiral Model (Iterative)

 Objective setting: Specific objectives for the phase are identified.

 Risk assessment and reduction: Risks are assessed and activities put in place to
reduce the key risks.
 Development and validation: A development model for the system is chosen which
can be any of the generic models.
 Planning: the project is reviewed and the next phase of the spiral is planned.

 Risk driven process model.

 Different risk patterns can lead to choosing different process models.
 What is risk?
 Situations or possible events that may cause a project to fail to meet its goal.
 Example risks:
 Experienced staff leave the project.
 Hardware which is essential for the system will not be delivered on
schedule.
Fig. 3.20 Spiral Model

 Advantages:
 Risks are explicitly assessed and resolved throughout the process.
 Software engineers can start working on the project earlier rather than wading
through a lengthy early design process.
 Disadvantages:
 Requires highly skilled people in risk analysis and planning.
 Requires more time, and is more expensive.
 Estimates of budget and time are harder to judge at the beginning of the
project since the requirements evolve through the process
Prototype
• Prototyping is an information-gathering technique.
• Prototypes are useful in seeking user reactions, suggestions, innovations, and revision
plans.
• Prototyping may be used as an alternative to the systems development life cycle.
Four Kinds of Prototypes
• Patched-up prototype.
• Nonoperational scale model.
• First-of-a-series.
• Prototype that contains only some of the essential system features.
Patched-up Prototype
• This is a working model with all the features but is inefficient.
• Users can interact with the system.
• Storage and retrieval of data may be inefficient.
• May contain only basic features.
Nonoperational Scale Models
• A nonoperational scale mode is one that is not operational, except for certain features
to be tested
• Prototype input and output
First-of-a-Series Prototype
• Pilot system is created.
• Prototype is an operation model.
• Useful when many installations of the same information system are planned.
• An example is a system to be installed in one location, tested and modified as
necessary, and later implemented in other locations.
Selected Features Prototype
• An operational model includes some, but not all, of the final system features.
• With the acceptance of these features, later essential features are added.
• Some menu items are available.
• System is built in modules.
• These are part of the actual system.
Prototype Development Guidelines
• Work in manageable modules.
• Build the prototype rapidly.
 • Modify the prototype in successive iterations.
• Stress the user interface.
Prototype Advantages
• Potential for changing the system early in its development
• Opportunity to stop development on an unworkable system
• Possibility of developing a system that closely addresses users needs and expectations
Prototype Disadvantages
• Managing the prototyping process is difficult because of its rapid, iterative nature.
• Incomplete prototypes may be regarded as complete systems.
Prototype Evaluation – The User’s Role
• The user’s role is honest involvement.
• Three ways the user is involved:
• Experimenting with the prototype.
• Giving open reactions to the prototype.
• Suggesting additions to and/or deletions from the prototype.
Rapid Application Development (RAD)
RAD, or rapid application development, is an object-oriented approach to systems
development that includes a method of development as well as software tools.
RAD Phases
The three broad phases to RAD are :
• Requirements planning.
• RAD design workshop.
• Implementation.
Requirements Planning Phase
• Users and analysts meet to identify objectives of the application or system
• Oriented toward solving business problems
RAD design workshop
• Design and refine phase.
• Use group decision support systems to help users agree on designs.
• Programmers and analysts can build and show visual representations of the
designs and workflow to users.
• Users respond to actual working prototypes.
• Analysts refine designed modules based on user responses.
Implementation Phase
• As the systems are built and refined, the new systems or partial systems are tested and
introduced to the organization.
• When creating new systems, there is no need to run old systems in parallel.
When to Use RAD
• The team includes programmers and analysts who are experienced with it.
• There are pressing reasons for speeding up application development.
• The project involves a novel ecommerce application and needs quick results.
• Users are sophisticated and highly engaged with the goals of the company.
Advantages of RAD
• Speed
• Portability
• Maintainability and modifiability
• Data oriented systems
Disadvantages of RAD
• May try and hurry the project too much
• Loosely documented
• Never ending
• Inadequate analysis
Which software process model is best?
 Depends on the project circumstances and requirements.
 Combinations of models are used sometimes to get the benefits of more than one
model.
 Criteria for evaluating models:
 Risk management.
 Quality / cost control.
 Visibility of progress.
 Early system functionality.
 Customer involvement and feedback.
The definition of a good system varies with the system’s environment. In some systems the
performance is the key measure of a good system while in other cases the ability to change
fast is a key measure of a good system. In some cases the user friendliness could be a
measure of good system. In all the cases, however, the correctness of the result is a common
measure, making them reliable and dependable for the business operations.
The speed and response are the performance measures in case of large volume transaction
based systems designed for real time applications. The flexible design is a measure of
performance where the system needs continuous modifications to meet the revised
requirements of the specifications. When it comes to complex system the user friendliness
and the ease of operations become the measures of a good system. In other words, a good
system design considers the environment and the users, and incorporates all the needs and
expectations so that its utility is the highest.

The System Development Methods

The traditional software development methods are the Structured Systems Analysis and De-
sign (SSAD) by Ross; the Requirement Driven Design by Alford and the Structured Analysis
and Structure Design (SASD) by Yourdon. All these methods deal with the functions and data
separately. The modern methodology is object-oriented, where the functions and the data
definitions are viewed together as an object.
A system developed with the SSAD and the similar approaches are difficult to maintain. The
reason is that for each function and its behaviour the data structure is defined. The
functionality behaves correctly under the conditions of the rigid data definition and structure.
However, in real life the data format changes, calling for a change in the programmes to meet
the revised format and its processing. The length of the programme and its complexity in-
creases due to first checking the data condition, and then moving the control to an appropriate
command set for its processing. The SSAD is, therefore, easy to understand but difficult to
maintain. The user of the system does not think in terms of the data and its definition but
thinks in terms of the functionality or process producing a result. In the SSAD approach,
therefore, the user must have two views on the system to understand. The first view on the
data and the second on its functionality. The two views create a problem of understanding the
system correctly.
The Object Oriented Technology (OOT) approach differs from the SSAD approach. The
difference is that the OOT views the system and then models it in terms of an item called the
Object, where the function and the data are defined at its lowest level where changes rarely
occur. The OOT views the functions and the data as one integrated entity. If reflects the
requirements directly into the objects.
In the SSAD approach, the requirement is fulfilled through defining and associating the data
for each function. While in the OOT approach the requirement is fulfilled, through the object(s)
processing, where the object itself is based on the behaviour. If a new requirement arises the
new object(s) view is taken and the model is modified in that portion only leaving the rest of
the design and the programme structure as it is. In the OOT approach the changes boil down
to the lowest level in most of the cases.
A good object model of the system does not require any changes at a ‘Class’ or ‘Super Class’
level. They are, generally, at the instance level. For example, in invoice preparation, new
functionality is required to calculate the invoice amount. In SSAD this would need a condition
definition for recognition, then the changes in the data and process flow, further defining the
output of the new requirement. In OOT the same situation would be handled by creating an
instance where only the computing behaviour is different from the others. The instance is
created by using the principle of inheritance. Hence the change in the system and the
programme progress is only at the lowest level and is local, not running across the total model
of the system.
In short, for a given business functionality the objects are defined in different categories and the
system design is built through the objects and it is processed through object processing. Hence,
in a business organisation to conduct a business, it requires the customer orders, purchase
indents, material indents, work orders, purchase orders, receipts, issues, payments, delivery
notes, packing notes, excise gate passes, invoices, bills, vouchers, etc. In the OOT usage the
analysis is made of the business operations, and it is modelled into objects. For example, the
object class ‘ORDER’ will handle all kinds of orders, viz., the customer orders, purchase orders,
pay orders, appointment orders and so on. The objects are constructed for the documents,
transactions and operations. The method which uses the objects in modelling and processing is
called as the object oriented methodology.
Whether it is a Waterfall model or a Spiral model of system development, or whether it is the
SSAD approach or object oriented technology approach of system development, the following
steps of the development are common.
• Requirement Analysis
• Requirement Definition
• System Design
Input Design
Process Design
Output Design
• System Development
Structuring the modules
Developing the modules
Unit Testing
Integration of the Modules
Integrated System Testing
Implementation
Maintenance
The requirement analysis is carried out from the top downwards in the organisation hierarchy,
linking the goals and the objectives of the business organisation, with the strategy mix decided
to achieve them. In this phase the information needs of the individuals, groups and functions are
analysed from a decision-making or a support point of view. Such information needs would fully
satisfy the operational and management information needs. Once the needs are justified, the
next step is to define them in clearer terms for the purpose of development. The requirement
definition brings clarity in the content and its application in various ways in the organisation.

The third step is to design a physical and a logical system through which the outputs are
designed. The processes which would give the outputs are determined, and the data which
would be required by these processes is finalised in terms of definition, source, and quality.
And further, the collection, creation, validation and storage of the input data is also decided.
The fourth step is to break the system design into modules in the hierarchical top-down
structure of facilitate the development effort as well as its implementation.
Once the modules are developed, the unit testing is carried out to confirm data transaction
and outputs’ validity and accuracy. In this testing, the transaction level processes are checked
to confirm the input-process-output relation, and the data storage and the transaction level
updating.
When the unit testing is over and the module level processing is confirmed, the modules are
put together to generate the information as determined in the requirement definition. The
process of putting the modules together is a process of integration. It is intended to produce
the results of data integration.
The system so developed is tested as a whole for several aspects such as information, quality,
performance, utility, user acceptance and so on.
Once the system testing is complete, the system is implemented at site, on the hardware and
software platform. The implementation step has its own procedure starting from the
installation of the hardware and the software, training the users, and then shifting to a fully
designed system. While implementing the system some minor modifications/adjustments,
may be required for the ease of acceptance by the user.
Even after complete installation, the system may require modifications or changes in terms of functions
and features over a period of time. The process of introducing these new requirements without disturbing
the time tested basic system is called maintenance. Such changes are required swiftly and hence they
are required to be carried out very easily. The system is designed keeping this natural requirement in
post implementation period.
A good system design and its implementation has high user acceptance because it helps to
solve the problems in achieving business performance.

3.11 STRUCTURED SYSTEM ANALYSIS AND DESIGN (SSAD)

The structured systems analysis develops a conceptual, logical, and graphical model of the
system. It is developed with reference to the objective and taking into consideration the
constraint under which the system operates. The model is developed with symbols as given
in Fig. 3.21.
 Process of
Transforming the
Data

Fig. 3.21 Symbols in SSAD

For example, the logical model of the customer order processing and issuing the order
acceptance can be shown in the DFD model, using these symbols (Fig. 3.22)

Fig. 3.22 Data Flow Diagram

This model illustrates the following:

1. Documents in the system.
2. Sources of documents.
3. Process centre for converting the customer order into the order acceptance.
4. Use of stored data in the process centre.
5. Output or documents provided by the process centre and its destination.
Such dataflow diagrams (DFDs) provide a logical clarity in terms of input, output, use of stored
data or master data already available in the system.
The use of DFDs can be made by detailing the system in a hierarchical manner. In this process,
we are detailing the activities which are performed in the system in its logical order as shown in
Fig. 3.23.

Fig. 3.23 DFD of Customer Order Processing

In the example of order processing, the processing is carried out in three stages—validating,
commercial processing and decision-making for customer order acceptance.
The main system is divided into three levels in its logical order. It conveys that unless the
customer order is validated and commercially accepted, it will not be processed for an order
acceptance decision. It also indicates that at each level, which stored data in the system is
used.
After detailing the system in the DFDs, the system designer has to define the data in the dictionary.
The data dictionary is an assembly of the data used in the system giving its picture definition and
its use. For example, the customer is a data entity and its presentation in the dictionary will be
defined with specifications. The customer name is defined of thirty character length and the pin
code is defined as six character length.

Data Dictionary for Data Flow Analysis

A Data Dictionary (DD) is intended to provide a complete documentation of all the elements
of a Data Flow Diagram, namely data items, data stores, and data flows. The data dictionary
is a reference work of data about data (metadata).
Data described in a DD carries the following details:
Data type: Data item/data store/data flow
Data name: Name of data item/data store/data flow
Data aliases: Alternate names used for convenience by multiple users
Data description: A short description of data, explained in simple terms
Data characteristics: Characteristics of each data type.
A data item is characterised by its type (numeric/ alphanumeric), width, etc.
A data store is characterised by its composition (set of data items),
Organisation (sequential, random), etc.
A data flow is characterised by its origin, destination, etc.
The third task which the system designer undertakes is to define, in detail, the process of
transformation in its logical order. For example, the process of the customer order acceptance
validation will be graphically modelled as shown in Fig. 3.24. The figure shows the process
design of the order acceptance decision.

Below we describe the contents of a DD for a sample data item, data store and data flow for
a payroll accounting.

i) DATA ITEM

• Data type: Data item

• Data name: G-SALARY
• Data aliases: Wages
• Data description: Monthly gross salary of an employee

Data characteristics
Type: Numerical
Width: 7.2
4 digits for the rupee component
1 digit for the decimal point
2 digits for the paise component
Associated data stores: Payroll file, Personnel file
Associated data processes: Payroll file, PF accounting, Personnel information systems
Gross salary is based on employees designation, and hence falls within a specified range.

ii) DATA STORE

Data Type: Data Store
Data Name: Payroll File
Data Aliases: Salary File
Data Description: Master File on employee for payroll accounting

Data Characteristics
Composition: Employee Name, Designation, Basic Salary, Department, Gross Salary
Organization: Sequential File
Volume: 1000 records (approximately)
Size: 350 K Bytes (approximately) per record
Associated Data Processes: Payroll Accounting, PF Accounting
Inbound Data Flow
Outbound Data Flow
Comments: This file gets updated every month at the time of payroll processing. On an
average, in a large organisation, about 5 records are deleted per month ( retiring/leaving the
organisation) and about 10 records are added per month (new appointments).
iii) DATA FLOW
• Data type: Data flow
• Data name: DATA ON EMPLOYEES
• Data aliases
• Data description: data on employees required for payroll processing
Data Characteristics
Origin: Accounts office
Destination: Process 1 in payroll accounting
Contents: EMP-NAME, Designation, B-Salary, Department
Associated data processes: Payroll accounting
Associated data stores
Comments

Reasons for Using a Data Dictionary

• Provide documentation.
• Eliminate redundancy.
• Validate the data flow diagram.
• Provide a starting point for developing screens and reports.
• To develop the logic for DFD processes.
 Fig. 3.24 Customer Validation: Process Model

Decision Tables
A decision table displays and documents clearly the processing logic for each
processing step identified in a DFD.

A decision table has the following structure.

Combination of conditions
Condition 1 Y
Condition 2 · · · ·
Condition 3 Y
Action 1
Action 2 Y · · · ·
This table is to be read from top to bottom, one column at a time.
For example, interpret column 1 as follows:
If conditions 1 and 3 are satisfied, then take action 2.
Decision tables are a precise yet compact way to model complicated logic. Decision tables,
like if-then-else and switch-case statements, associate conditions with actions to perform.
But, unlike the control structures found in traditional programming languages, decision
tables can associate many independent conditions with several actions in an elegant way.

• Decision tables make it easy to observe that all possible conditions are accounted
for.
• Decision tables can be used for:
– Specifying complex program logic
– Generating test cases (Also known as logic-based testing)
– Logic-based testing is considered as:
– structural testing when applied to structure (i.e. control flow graph of an
implementation).
functional testing when applied to a specification.

Decision Tables – Structure

Conditions - (Condition stub) Condition Alternatives – (Condition Entry)

Actions – (Action Stub) Action Entries

 Each condition corresponds to a variable, relation or predicate Possible values for

conditions are listed among the condition alternatives
 Boolean values (True / False) – Limited Entry Decision Tables
 Several values – Extended Entry Decision Tables
 Don’t care value

 Each action is a procedure or operation to perform

  The entries specify whether (or in what order) the action is to be performed

To express the program logic we can use a limited-entry decision table consisting of four
areas called the condition stub, condition entry, action stub and the action entry:
Condition stub
Action stub
Condition entry
 • We can specify default rules to indicate the action to be taken when none of the other rules
apply.
• When using decision tables as a test tool, default rules and their associated predicates
must be explicitly provided.

Rule5 Rule6 Rule7 Rule8

Condition1 X No Yes Yes

Condition2 X Yes X No

Condition3 Yes X No No

Condition4 No No Yes X

Default Yes Yes Yes Yes

action
Decision Table – Example

Conditions Printer does not print

Y Y Y Y N N N N

A red light is flashing

Y Y N N Y Y N N

Printer is unrecognized
Y N Y N Y N Y N

Actions Heck the power cable

X

Check the printer-computer cable

X X

Ensure printer software is installed

X X X X

Check/replace ink
X X X X

Check for paper jam

X X
Decision Table – Example

Decision Table Development Methodology

1. Determine conditions and values

2. Determine maximum number of rules
3. Determine actions
4. Encode possible rules
5. Encode the appropriate actions for each rule
6. Verify the policy
7. Simplify the rules (reduce if possible the number of columns)
Decision Tables – Usage

• The use of the decision-table model is applicable when :

– the specification is given or can be converted to a decision table .
– the order in which the predicates are evaluated does not affect the interpretation of
the rules or resulting action.
– the order of rule evaluation has no effect on resulting action .
– once a rule is satisfied and the action selected, no other rule need be examined.
– the order of executing actions in a satisfied rule is of no consequence.
• The restrictions do not in reality eliminate many potential applications.
– In most applications, the order in which the predicates are evaluated is immaterial.
– Some specific ordering may be more efficient than some other but in general the
ordering is not inherent in the program's logic.

Decision Tables – Issues

• Before using the tables, ensure:

– rules must be complete
• every combination of predicate truth values plus default cases are explicit
in the decision table
– rules must be consistent
• every combination of predicate truth values results in only one action or set
of actions

The graphical model of the validation process indicates that this process decides whether the
customer order is to be accepted for commercial processing. The decision of acceptance is based
on the type of customer and further on the specifications such as the size, the type and the zone.
To summarise, the Structured Systems Analysis has three steps, viz., the modelling of the system
in the DFDs, constructing the data dictionary and process modelling. The SSAD provides a
methodology to the system designer to analyse the existing system in an orderly manner and
enables him to put the proposed system in a logical order. Since the entire system is presented in a
graphical manner, the communication with the users becomes easy and effective. Any change in
the post-implementation phase is easy to implement as it is possible to know its implications on the
other processes.
WHY DO BUSINESSES NEED SYSTEMS ANALYSTS?

A computerized system enables an organization to provide accurate information and respond

faster to the queries, events etc. If a business needs computerized information system, a Systems
Analyst is required for analysis and design of that system.

Responsibilities of System Analysts

The duty of a systems analyst is to coordinate the efforts of all groups to effectively develop and
operate computer based information systems.

Defining Requirements:
The most important and difficult duty of an analyst is to understand the user’s requirements.
Several fact-finding techniques are used like interview, questionnaire, and observation, etc.

Prioritising Requirements by Consensus:

There is a need to set priority among the requirements of various users. This can be achieved by
having a common meeting with all the users and arriving at a consensus.

Analysis and Evaluation:

A systems analyst analyses the working of the current information system in the organization and
finds out the extent to which they meet user’s needs. On the basis of facts and opinions, systems
analyst finds the best characteristics of the new or modified system which will meet the user’s
stated information needs.

Solving Problems:
Systems analyst is an information system problem solver. An analyst must study the information
system problem in depth and suggest alternate solutions to management.

Drawing up Functional Specifications:

The key duty of systems analyst is to obtain the functional specifications of the system to be
designed.

Designing Systems: Once the specifications are accepted, the system analyst along with system
designer designs the system. System analyst must also create a system test plan.
Data Administration:
Systems analysts as Data Analysts along with Database Administrators analyse database
requirements, design and construct the databases.

Telecommunications:
Systems analysts as Network Analysts along with Network Administrators design, implement and
manage the computer networks like local and wide area networks that will ultimately be used by
systems and applications.

System Development:
Systems analysts and programmers are organized into permanent teams that support the
information systems and applications for specific business function.
System development unit includes a centre for excellence, which is a group of experts
(experienced systems analysts, system designers, and system builders) who establish and
enforce methods, tools, techniques and quality for all system development projects.

Evaluating Systems:
System analyst must critically evaluate a information system after it has been in use for a
reasonable period of time. The time at which evaluation is to be done, how it is to be done and
how user’s comments are to be gathered and used, must be decided by the system analyst.

End-user Computing:
The growing base of personal computers and local area networks in the end user community are
supported. This provides installation services, training and helps desk services. Analyst also
provides standards and consulting to end users that develop their own systems with PC power
tools such as spreadsheets and PC database management systems. In this centre, analysts may
work as End-user computing consultants.

Computer Operations:
All of the shared computers including mainframes, minicomputers and other computers are put to
operation and the same is coordinated. Systems Analysts may work as Capacity Analysts in this
area. Every analyst should know the management structure of a traditional information services
organization.
Roles of System Analysts:

Change Agent:
The analyst may be viewed as an agent of change. A candidate system is designed to introduce
change and reorientation in how the user organization handles information or makes decisions.
Then, it is important that the user accepts change. For user acceptance, analysts prefer user
participations during design and implementation.

Investigator and Monitor:

A systems analyst may investigate the existing system to find the reasons for it’s failure. The role
of an investigator is to extract the problems from existing systems and create information
structures that uncover previously unknown trends that may have a direct impact on organization.
The role of a Monitor is to undertake and successfully complete a project. In this role, system
analysts must monitor programs in relation to time, cost and quality.

Architect:
The analyst’s role as an architect is liaison between the user’s logical design requirements and the
detailed physical system design. As architect the analyst also creates a detailed physical design of
candidate systems. A systems analyst makes the design of information system architecture on the
basis of end user requirements. This design becomes the blue print for the programmers.

Psychologist:
In system development, systems are built around people. The analyst plays the role of
psychologist in the way analyst reaches people, interprets their thoughts, assesses their behaviour
and draws conclusions from these interactions. Psychologist plays a major role during the phase
of fact finding.

Motivator:
System acceptance is achieved through user participation in its development, effective user
training and proper motivation to use the system. The analyst’s role as a motivator becomes
obvious during the first few weeks after implementation and during times when turnover results in
new people being trained to work with the candidate system.

Intermediary:
In implementing a candidate system, the analyst tries to appease all parties involved. Diplomacy in
dealing with people can improve acceptance of the system. The analyst’s goal is to have the
support of all the users. System analyst represents their thinking and tries to achieve their goals
through computerization.
These multiple roles require analysts to be orderly, approach a problem in a logical way, and pay
attention to details. They prefer to concentrate on objective data, seek the best method, and be
highly prescriptive. They appear to be cool and studious. They focus on method and plan, point
out details, are good at model building, perform best in structured situations, and seek stability and
order.

Role and Responsibilities of the Database Administrator:

The success of a database environment depends on central control of database design,

implementation, and use. This central control and coordination is the role of the database
administrator (DBA).

Central Control and Coordination:

The same data is used by many applications (users) in many departments of the organization.
Ownership of and responsibility for the data is shared by departments with diverse and often
conflicting needs. One task of the DBA is to resolve such differences.

Clearly, proper database management means that central control is needed to ensure adherence
to common standards and an installation-wide view of hardware and software needs. This central
control is the responsibility of the DBA. For these and other reasons, it is important that the DBA
function be set up at the very beginning of the database development cycle.

The DBA in the Information Systems Organization:

DBA is best placed as a functional manager with an status equivalent to the systems,
programming, and operations managers. The DBA should have direct responsibility for all aspects
of the continued operation of the database. It is also useful to give the DBA at least partial control
over the programming and IS operation standards, since the DBA must have the ability to ensure
that DBMS-compatible standards are understood and observed.

The DBA also needs administrative skill to set up and enforce the standards and procedures for
using the database; technical ability to understand the factors governing hardware performance,
with considerable knowledge both of the operating system software and the DBMS being used;
a thorough knowledge of existing and future applications; and skills to produce an efficient
database design that meets the application requirements.
Management Support:

To be effective, the DBA must be recognized and supported by both IS and user group
management. With an in-depth understanding of the database operation and the service it
provides to the organization, the DBA needs to be recognized as a center of competence for all
matters involving the design or use of the database.

Establishing Database Procedures and Standards:

Standards and procedures are more effectively established as part of the initial planning, rather
than later after problems have arisen. This section discusses the general points to consider when
defining procedures and standards.
Database Procedures:
Procedures for effective control of the database environment should be established at the very
beginning of the organization’s use of a DBMS.
Data Security Procedures:
The DBA is the one who must monitor the procedures and correct the results of violations.

Setting Standards:
Much of this documentation attempts to define guidelines for a database environment.
larger user groups comprising various areas or geographic locations usually lack the contact
necessary for proper controls.

Review the standards at least as often as you add to them, and remove or revise outdated ones.
Provide an overview of changed/deleted/added standards to users.

Maintaining Procedures and Standards:

The maintenance of database documentation should be treated as a natural part of the application
development process.
The data dictionary is a major tool in this documentation process.
With a wide knowledge of current database applications, future plans, and responsibility for the
integrity of the database, the DBA should be involved in the design of the data validation
procedures inherent in each system that inputs data to the database.

Assisting in Database Design:

As an independent function, the DBA is the only person who can provide such an objective view of
the resulting database design.
Educating Users
Users can be oversold on the benefits which are to be derived from DBMS technology, despite the
efforts of the system analyst or DP resources manager. Such topics as flexibility, program/data
independence and data availability can lead to unjustified expectations and give rise to a false
sense of creative freedom.

Selecting Applications Suitable for the Database System:

When an installation acquires a DBMS, it is only natural that analysts and programmers will be
eager to use it. Every new application suddenly seems to require DBMS technology. Someone has
to take a firm grasp of this situation and control the selection of applications that truly are suitable
for DBMS technology. That person is the DBA.
The DBA, as a center of competence in database matters, is thus the ideal person to oversee the
selection of new database projects.

Advising on System Development:

As far as involvement in systems development is concerned, the DBA should be responsible for
the process of defining and describing new data entities and relationships, using uniform data
definition procedures. the DBA’s is the task of maintaining records of the organization’s logical
database and controlling what part of it is and is not implemented.

Database Documentation:
Database documentation includes the recording of the procedures, standards, guidelines and
database descriptions necessary for the proper, efficient and continuing use of the database.

Passwords and User Identification:

User ID and password information needs to be stored securely by the DBA, as only the DBA and
the affected users should have access to it.
Backup Procedures:
The content of backup files, as either database or file copies should be recorded together with the
following information.
What state (or point in time) the backup data refers to;
Identification of the data that can be backed up;
The volume of data that is involved;
The backup facilities that should be used in order to re-establish the database to that state;
The frequency and schedule of database backup operations.

Restart and Recovery Procedures:

The DBA is responsible for formulating and supervising procedures for restarting the DBMS after
failure; recovering the database to a recent checkpoint (if necessary), thus removing the need to
repeat database maintenance work; controlling the priority and sequence of database restoration.

DBMS Performance and Measurement:

The DBA has a continuing role in maintaining and improving the performance of the database
system. To do this, the DBA must monitor the performance of the system and try alternative
design strategies to improve it. As work patterns change in the company, both the volume and
relative proportion of types of transactions may change. This may affect performance and design
changes may be necessary to counteract it.

Education and Training:

The DBA is responsible for education and training in database concepts and the procedures and
techniques involved in operating in the database environment. The DBA develops the training
curriculum and selects the content of the training materials to be used.

Database Design:
Database designers need training in the design methodology preferred at the site so that they can
quickly become productive.

Database Query and Report Generation:

The content of this type of training will depend largely upon whether it is being given to data
processing or user personnel. The former will require training in the commands and facilities of the
query facilities to be used (for example, Natural) together with details of how to construct and run a
request. The user, on the other hand, will require much more specialized training. It will need to be
geared much more closely to the application system that the DBA is to use.
Database Organization:
As mentioned elsewhere, the DBA is responsible for the formulation and definition of the data
relationships for the purpose of defining logical data structures. These data structures should
reflect the DBA’s knowledge of foreseeable developments and include the needs of other related
users.

Determining Physical Storage Requirements:

It is the DBA’s responsibility to provide assistance to the project team in determining the physical
storage requirements for a particular application system.

Role and Responsibilities of the Database Designer:

A database designer is in charge of designing, developing, executing and preserving a company's

data management systems.

One of the most important responsibilities of a database designer is to form relationships between
various elements of data and give it a logical structure.

Understand the organisation's data to skilfully carry out the company's database design projects

Install and configure relational database management system on the company's server

Design database schemas and create databases for varied projects of the company

Handle the creation of new users, define roles and privileges and grant access to them

Assist application development teams to easily connect to the databases

Track the performance of the databases and fix issues quickly to facilitate smooth functioning

Use the best techniques for enhanced scalability and efficiency of large databases

Understand complex problems, devise solutions and transform them into software requirements

Conduct data research and query large and complex datasets to provide the best data modelling