Module 3. Systems analysis and design

Lesson 6

SYSTEMS ANALYSIS AND DESIGN

6.1 Introduction

This lesson will discuss the objectives of systems analysis and design. Various activities involved in systems analysis and design like requirement analysis, feasibility study, graphical tools, input/ output design, codes design, data validation, files design, program design, system development, hardware and software requirement, implementation, testing, maintenance, etc., are elucidated in this lesson. These topics will be useful for understanding the system which will be helpful in designing the system at later stage.

In early days, system analysis and design was concerned with manmade system involving inputs, processes and outputs. But in modern times, system analysis and design deals with the process of examining and understanding the working of an existing system of an organization, identifying problems (if any) with an objective to improve the same through better methods, technology and procedures. In general, the phrase “System Analysis and Design” relates to the complete process of developing a system which involves the following steps:

1. Systems analysis

Systems design
Systems development
Systems implementation
Systems maintenance

6.2 Systems Analysis

Systems analysis is a process of collecting and interpreting facts about the present system, diagnosing problems, analyzing the business requirements and recommending improvements based on information gathered. In other words, systems analysis means identification, understanding, and examining the system, which creates base for system design in order to achieve pre-determined goals/ objectives of the system. System analysis is carried out with the following objectives

· To understand the functioning of present system.

· To analyze the users requirement for initiating computer based information system.

· To develop a logical model of feasible solution to solve problems.

Systems analysis is basically a detailed study of all important business aspects under consideration and thus the study becomes a basis for the proposed system. The proposed system may be a new system or some modification in the existing system. Systems analysis is a logical process for understanding the system. The emphasis is on investigation to know how the system is currently working, to identify requirement of users from the system and to determine what best can be done to solve the problem.

6.3 Systems Design

Logical design of an information system developed during system analysis phase defines functions and features of the system and relationship among its components. Logical design includes output that must be produced by the system; input needed by the system, and processes that must be performed by the system without regard to how tasks will be accomplished physically. During system designing phase, logical design is translated into physical design with respect to user requirements, data flow of existing system, I/O specification of the existing system. In contrast to logical design, physical design is a plan for actual implementation of the system. Physical design specification must answer the following:

I. How data will be entered?

II. How the files are organized?

III. How reports will be generated?

IV. What will be format or layout of reports?

6.4 Systems Development

During systems development phase, analyst mainly focuses on constructing a workable system which will fulfill the requirements as per the specifications laid down in system analysis and design phase. System analyst monitors the operation of development of system to ensure higher levels of satisfaction and performance. Database and tables are created for storing data using database management software packages (DBMS), programs are written for data entry with data validation checks to ensure accurate and reliable input into databases, report generation, creating GUIs, procedures, module, menus, etc. using computer programming languages or 4GL software packages. Plans are worked out to test performance of overall system.

6.5 Systems Implementation

Once the development of information system is successfully completed, it is ready for implementation. In the implementation phase, newly developed system is installed at the user’s site. In other words it is the process of replacing the existing system with a new system. During this process, transition from old system to new system should be smooth and acceptable to users to avoid any unpleasant situation or chaos which may lead to rejection of the system. The new system may be a replacement of a manual system or a major modification in the existing computer based information system. Therefore, SA should carefully plan and design methods for changeover from old system to new system.

6.6 Systems Maintenance

Job of system analyst does not finish after implementation of the system at user’s site rather his real acid test starts after implementation of software as most of his time will be spent on maintaining the system and meeting the users’ requirement. As the organizations are in dynamic and competitive world, evaluation and maintenance is a continuous process. Corrective actions are taken based on the users’ feedback to evaluate the system. During maintenance phase, system analyst mainly focus on incorporating the changes occurring due to factors like external environmental, internal policy, users preferences, software and hardware platforms etc. to make system more efficient and effective. It should be ensured that all related components and modules of the system must be corrected whenever faults are detected and fixed. Process of monitoring, evaluating, and modifying of existing system to make the required or desirable improvements is terms as system maintenance. Different types of maintenance undertaken by SA are Corrective maintenance, Adaptive maintenance, Enhancement maintenance, Preventive maintenance

Detailed activities covered in above mentioned steps are summarized in table 6.1.

Table 16.1 Summary of activities involved in systems development

Sr. No.

Phases/ Activities

Key Questions

Results

Systems Analysis Phase

Need recognition:

· Preliminary survey/ initial investigation

· What is the problem or opportunity?

· Why computerized system is required?

· Statement of scope and objectives

· Performance criteria

Feasibility study:

· Evaluation of existing system and procedures

· Analysis of alternative candidate systems

· Cost estimates

· What are the user’s demonstrable needs?

· Is the problem worth solving?

· How can the problem be redefined?

· Whether the solution to the problem will be cost effective, technical and operational viable?

· Economic Technical and Operational feasibility

· Cost benefit analysis

· System scope and objectives

· Statement of new scope and objectives

iii

Detailed system study:

· Study the existing system in detail to understand terminology, components, procedure, workflow and data flow, relationship between components

· Data collection

· What must be done to solve the problem?

· What are the facts?

· Statement showing the working of existing system

· Logical model of the system – data flow diagrams, Data dictionary, system flow chart

· Pertinent data

· Questionnaires/interviews for data collection

System requirements:

· Identify input and output requirements and their formats

· Hardware and software requirements

· How the system interact with outer environment

· How different components are interacting with each others

· More suitable new input and output formats

· Specifications for Hardware and software requirements

Iteration for improvement:

· Above mentioned activities are repeated

· How a system can further be improved?

· Final result of system study and analysis phase

Systems Design Phase

General design specification:

· Translation of logical design to physical design

· How must the problem be solved?

· What is the new system processing flow?

· Physical design of the system

· Flow of information into and out of the system

· Implementation plan

Input–Output design:

· Identify inputs to the system

· Identify output of the system

· How the reports will be generated

· How the data will be entered

· How the data will be validated

· What will be the formats or layout of input and output

· New formats for output reports

· New formats/ screens for data entry forms

· Different types of data validation checks used during data entry

· Devices and method to be used for generating output and data entry

iii

File and Database design:

· Storage of input data and generated data

· How to design an efficient database

· How the data will be stored in data files using the concepts of normalization?

· What will be the structure of data files?

· How the data files will be related to each other?

· Logical design of database

· Schema and sub-schema of database

· Classification of data files

· Identification of primary key for each data file

· Creation of relationship between data files

Code design:

· Designing of codes for input and output data to identify and retrieve record uniquely in files

· How to design efficient coding pattern

· List of codes for different data items for input and output

Procedure and Program logic design:

· Identify procedures of the system to be designed and developed for processing input/ output data

· Does the user approve the system?

· How to develop logic of programs using different tools?

· Algorithms, flow charts and pseudo codes of programs for data entry, output reports, menu design, intermediate data processing etc.

Systems Development Phase

Database creation:

· Create the designed data base using a DBSM or some other file creation method

· Which DBMS should be selected to meet the organization requirements?

· Physically creation of database using logical design

Program writing (i.e. coding):

· Writing of programs using SQL or some other programming languages like VC++, C++, VB, Java, VB.net etc.

· Which programming language should be used for writing programs?

· Programs for solving problems, data entry, report generation, menus etc.

iii

Testing:

· Program testing

· Module testing

· System testing

· Complete quality and performance testing

· How well do individual programs/ modules test out?

· How ready are programs for acceptance test?

· Test plans

· Formal system test

· Performance of software with respect to hardware

Systems Implementation Phase

File/ system conversion (installation):

· Software is installed at client site

· Data is entered in files using new software or existing data is converted into file/ database structure of new system

· What is the actual operation?

· Are there delays in loading/ converting data files?

· Plan of to change over to new system (At once/ Parallel/ Location wise/ Modular)

· Data is entered in new files/ database

User training:

· Train the end users about the operation of software developed and exception handling

· Exposure to executive staff about the software and its capabilities

· What to teach the users?

· How to train the staff?

· Plan for training the staff (Brainstorming sessions/ Seminars/ Operational/ Awareness/ On Job trainings, etc.)

iii

Documentation:

· Prepare different kind of manuals with respect to level of usage

· Are manuals ready?

· User manual for beginners

· Technical manual

· System manual

Post-implementation, Maintenance and Review Phase

Evaluation:

· The implemented system is evaluated by end users

· Is the key system running?

· Users requirements and standards are met

Maintenance:

· Collect feedback of users about the system

· Focus on changes associated with error correction, exceptional situation occurred, performance of system, backups and recovery of data files, etc.

· Should the system be modified?

· Updated the system as per the requirements/ suggestions

· Satisfied users

iii

Enhancement:

· Addition of new plans/ modules/ schemes due to changes in users priorities, environmental factors, organizational requirements, etc.

· How to incorporate new plans/ modules in the existing system?

· Steps involved in system analysis, design and implementations are repeated to add new modules

6.7 Requirement Analysis

Requirement analysis is a way of translating user’s ideas and requirement about the problem into formal documents which laid down foundation of system design and development. This is the most difficult and error prone activity because of communication gap between users and developer. Generally user does not understand software thus, not able to explain their requirement and SA does not understand user’s problem/ application. A properly conducted requirement analysis has following benefits:

· It will satisfy the business requirement which would be acceptable to users.

· It bridges the communication gap between user and system analyst.

· It reduces development cost by overcoming errors and misunderstanding at an early stage.

· It serves as benchmarks to measure overall acceptability of the developed system.

Requirement analysis is basically to learn and collect information about system under consideration. Various methods for collecting information about organization in order to study the existing system and to identify system requirements are:

· Interviewing

· Documents

· Questionnaires

· Observation

6.8 Feasibility Study

Feasibility study tries to ascertain whether the system is viable or not for the organization. System request is passed through a series of tests like what is the problem to be solved? Is the problem even worth solving? Whether it is worthwhile to proceed further or not? The series of tests is called a feasibility study or analysis which determines likelihood that the proposed system will be useful to the organization or not. Feasibility analysis is an important part for every system under consideration for development. Objective of feasibility analysis is to assess various alternative systems and to propose most suitable system for development. Depending on the system request, feasibility study may be quite simple that can be done in few hours only or it may be complex and extensive fact finding which may take number of days or months. For example, if the milk procurement section wants that reports to be produced in different order from the existing system, analyst can decide quickly whether request is feasible. On the other hand, a proposal from milk market section, for developing a new market research system to predict sales trends require more efforts. Feasibility of a proposed system can be assessed in terms of operational, technical, and economical feasibility.

6.8.1 Operational feasibility

An operational feasibility of system means that the proposed system has been accepted by the users and will be used effectively after it has been developed and implemented. Operational feasibility of a system ensures that the system will work after its implementation. Human resource of the organization has to be competent and enthusiastic to accept the change which is likely to take place by implementing the proposed system. In other words, management, employees, customers, users etc. must be willing and able to support the new proposed system. If users have difficulty with a new system then it may be rejected and will not produce expected benefits. Therefore motivation and involvement of users is must from beginning in development of the proposed system. Operational feasibility depends on several vital issues and analyst must answer following questions:

I. Is their sufficient support from management and users?

II. Are the current methods acceptable to user or they need change?

III. Will proposed system not result in loss of control in any area?

IV. Will the new system result in reduction of employees?

V. If yes, what will happen to the affected employees?

Analyst must get positive answers to these questions to make system operationally feasible. Generally a system developed with active involvement of users and as per rules, regulations, organization culture, union agreements, etc. would be operational feasible.

6.8.2 Technical feasibility

A technical feasibility means that the organization has resources and capability to procure the required technology and equipment (hardware, software etc) to develop, install and operate the proposed system within specified time period. Besides this, the proposed system should be capable of meeting all requirements of people working in the organization. System should be flexible and expendable to sustain for longer period. To satisfy management and users, system must ensure security, reliability, accuracy and accessibility of data in most technical way. While assessing the technical feasibility, analyst must consider following questions:

I. Does necessary technology exist for developing and implementing the proposed system and can it be acquired?

II. Does organization have requisite technical expertise? If not, can it be acquired?

III. Are the proposed devices and media capable to hold the volume of data required?

IV. Will the proposed system be compatible with the coming up technology?

V. Will the existing resources like hardware, software and employees be used?

6.8.3 Economical and financial feasibility

Economic feasibility means that the projected benefits of proposed system should outweigh the estimated cost. Proposed system will involve cost on deriving system requirement specifications, hardware, software, installation, maintenance, site preparation, training and consumable cost. Costs can be one time investment or recurring in nature. Projected benefits should justify investment in the system since finance is the main constraints for any system to be accepted or rejected. Management must be satisfied with benefits to be derived by implementing the proposed system. While assessing the economical feasibility, analyst must consider following questions and should get positive answers to these questions to make the system economical feasible:

I. Whether total cost is within the allocated budget? Does the additional cost make overall business competitive and consequently resulting in maximizing profit?

II. Do the benefits in form of reduced cost per unit in the long run, improve customer services and whether improved resource utilization justifies the investment?

Analyst must perform cost and benefit analysis of the proposed system and alternate solutions before making any recommendations to the management.

6.9 Data and Process Modeling Techniques

These techniques are used by systems analyst during system analysis to depict how various processes of a system transform data into useful information in graphical form. Output of process modeling activity is a logical model that supports business operations and meets requirements of managers and users. A logical model shows what the system must do, regardless of how it will be accomplished physically. System analyst may use one or more of the following traditional and structured analysis tools to represent system data and process graphically.

I. System flow chart

II. Data flow diagram (DFD)

III. Data dictionary

IV. Decision tree

V. Decision table

6.9.1 System flow chart

A system flowchart is a graphical/ pictorial representation of the system’s discrete physical components such as programs, procedures, files, reports, screens, etc. It is a valuable presentation tool to show the interaction and interlinking of major components of a system in sequential order to achieve final meaningful results through the system. It serves as a system roadmap.

Since system flow chart emphasizes on physical implementation details about the system therefore it is not an appropriate modeling tool at an early stage of systems analysis. However, it could be a useful modeling tool at the end of the systems analysis activity, when the user implementation model is being developed.

Different symbols are used to show various components in a system flow chart. For example rectangular boxes represent operational aggregates of computer software e.g., computer programs, job steps, runs, or other units of computer software, magnetic tape and hard disk symbols are used to represent different kinds of physical files, on-line terminals and telecommunication links etc. Some of the important symbols used in drawing a system flow chart are shown in fig. 6.1 given below:

Fig. 6.1 System flow chart symbols

Example: A typical system flow chart for milk receipt and billing system in brief is shown in fig. 6.2 given below. The same concept is shown in two styles.

Fig. 6.2 System flow chart for milk receipt and billing system

6.9.2 Data flow diagram

DFD is a graphical or pictorial representation of logical flow of data. This tool describes the movement or flow of data within an information system from beginning up till end regardless of whether the system is manual or automated. DFD shows only data flow not the program logic or processing steps. It models a system by using external entities from which data flows to a process which transforms data and creates output data flows which go to other processes or external entities or files. Data in files may also flow to processes as inputs. Main advantage of DFD is that it provides a logical model of the system that shows what a system does rather than how it is being done. Aim is to clarify system requirements and identify major processes, transformations of data, data stores and external entities to ensure developed model is accurate and easy to understand. DFD is also known as bubble charts as it consists of a series of bubbles joined by lines.

A DFD uses four pictorial symbols to represent processes, data flows, data store, and external entities. Several versions of DFD symbols exist but all serves the same purpose. Two major thoughts for drawing DFD are shown in fig. 6.3 given below.

	Gane and Sarson	Yourdon
External Entity
Process
Data Store
Data Flow

Fig. 6.3 DFD symbols used in two different schemes

a. External Entity: External entity is a source or destination of data. It can be files, departments, person, vendors, customer, other information systems etc. External entities show the system boundaries and how a system interacts with outside world. These are also called terminators since they are data origins (source) or final destination (sink). Name of the external entity is written inside the symbol.

b. Process: Process is the people or procedures involved in the system that are used to transform data. It receives input data, processes it and produces output. In DFDs a process is just like a black box for which underling details are not shown except input, output and general function of the process. Process name is written inside the symbol.

c. Data store: Data store is a data repository in a system. These are used to show the data stored by a process within a system like files, registers, documents, reports, vouchers, etc. The stored data are used or shared by other processes of the system at later stage. A data store must be connected to a process with a data flow. Name of the data store is written inside the symbol.

d. Data flow: Data flow is a path that shows movement of data from one process and to another process in a system from origin to destination. Data flow names appear above, below, or alongside the line. Data flow names represent one or more data items.

6.9.2.1 Procedure for drawing a DFD

Step 1: Represent the whole system by a single process and identify its input and outputs. This is known as context diagram or zero level DFD. A context DFD is a top level view of a system that shows boundaries and scope of the system. To draw context level DFD put a single process symbol in the centre which represents the entire system. Then place external entities around the central process symbol and use data flows to connect entities to it. Data stores are not being used in context diagram because these are internal to the system. Information about names and contents of external entities and data flows are collected during fact gathering process.

Step 2: Context diagram shows the most general view of a system which contains only one process. This is just like a black box. To know more details about the system next level of DFD are drawn. To draw next level of DFD, identify major processes of the system and draw DFD considering these major processes only and also identify inputs and outputs for each and every major process. This is known as top level DFD or first level DFD.

Step 3: After identification of major processes in first level DFD, an analyst has to identify processes from first level DFD which can be further expanded. Analyst then draws DFD of a particular process identified with expansion. This is known as exploded DFD or Expanded DFD.

6.9.2.2 General rules for drawing DFD

Processes should be uniquely named and numbered
Data flows within the system must be named
Context DFD must fit on the single page
Process name in the context DFD should be the name of the system
Do not cross the lines

Example: Fig 6.4 shows a context diagram for milk procurement and billing system (MPBS).

Fig. 6.4 Context diagram or zero level DFD of MPBS

6.9.3 Data dictionary

A data dictionary is a structured repository of description of data item involved in a system. As discussed earlier, DFDs describe the logical model of a system in which details of input and output data items is not shown. The details of data items are documented separately in data dictionary. A data dictionary is an organized collection of precise and accurate definition of all processes, data elements, data structures, data stores and data flows of a systems. Data structure consists of a group of data elements and data element is simplified unit of data which cannot be further decomposed. For example employee name may consist of three parts as first name, middle name, surname. Thus employee name is data structure and its parts are data elements. Data structures also known as records are meaningful combination of related data elements that is included in a data flow or retained in a data store.

6.9.4 Decision tree

A decision tree is a graphical representation for describing logical conditions, actions and rules. It describes all actions that result from various combinations of conditions as per logical rules. The graphical representation of conditions and outcomes resembles with the branches of a tree. The branches of a tree depends the logical alternatives. It is drawn horizontally with the root on left side and branches to the right. Though, it is easy to construct, read and update a decision tree for a simple problem but as the complexity increases it becomes tedious to draw and update.

Example: Following figure 6.5 shows the subsidy given to dairy farmers on technical inputs to the farmers by dairy plants for promotion of dairy in the area.

Fig. 6.5 An example of decision tree

6.9.5 Decision table

Decision table describes a logical structure with all possible combination of conditions, actions and decision rules for initiating an action on occurrence of various conditions. It shows conditions and actions in a simplified and orderly manner in a form of matrix of rows and columns. Decision table describes the same information as discussed in decision tree but in a tabular form. Analysts may also use other tools like decision tree, structured English, pseudo codes to describe a logical process and to ensure to cover all combination of logical possibility. A decision table is a better tool to represent combinations of complex conditions while decision tree is effective to describe relatively simple process. A decision table consists of four sections as described below and shown in table 6.2:

· Condition stub (upper left part): All conditions are written in this area.

· Action stub (lower left part): All actions are written in this area.

· Condition entry (upper right part): All possible combination of conditions are marked either by ‘Y’ or ‘N’ where ‘Y’ is for true and ‘N’ for falseness of condition.

· Action entry (lower right part): In this part the action which will be taken as per the combination of action specified in condition entry is shown by marking ‘X’ in front of action that will be taken with respect to the condition.

Table 6.2 Structure of a decision table

Example: Following example (Table 6.3) shows a decision table constructed to determine rates of fresh milk received from farmers.

Table 6.3 Decision table describing rules for determining rates of fresh milk

Conditions	Decision Rules
Fat% and SNF% within specified range	Y	N	N
Low Fat% and SNF%		Y	N
High Fat% and SNF%			Y

Normal Rate	X		X
Penalty		X
Incentive			X