GOMBE STATE UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE

COSC 204: SYSTEMS ANALYSIS AND DESIGN (3CU)

2023/2024 SESSION

INTRODUCTION
Computers are everywhere today, and microchips impact every part of our lives. We live in a
world not only of ubiquitous computing but of pervasive communication and connectivity. An
incredibly large part of our everyday lives depends on computer chips, connection links, and
application software. You have grown up in this world of high technology. You use
smartphones, laptops, iPads, notepads, electronic game equipment, and so on. Your mobile
devices provide daily (if not hourly) text messages, tweets, videos, snapshots, Internet access,
games, and much more. Many of you will soon begin to develop application software and some
have already developed one or you have a friend who has written applications for laptops,
smartphones, iPads, etc. You have already start taking programming classes; and some of you
have taught yourself how to write computer application programs. Given that we live in this
world of high-tech gadgets, we might ask, “What is systems analysis and design, and why is it
important?” How does the development of new technology and new application software
utilize systems analysis and design? In other words, what role does systems analysis and design
play in the development of high-tech solutions and applications? First, let’s remind ourselves
two important definitions.

A computer application is a computer software program that executes on a computing device

to carry out a specific function or set of related functions. Sometimes, computer application is
shortened to app (such as an iPhone app or a Facebook app).
An information system is a set of interrelated computer components that collects, processes,
stores (usually in a database), and provides as output the information needed to complete
business tasks.

A system is a combination of parts or components, which work together to control a task or

activity. A system can also be defined as an orderly grouping of interdependent components
linked together according to a plan to achieve a specific objective. For example, a system in the
payroll department keeps track of checks, whereas an inventory system keeps track of supplies,
the two systems are separate. The study of system concepts has three basic implications:

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

2. Interrelationships and interdependence must exist among the components.
3. The objectives of the organization as a whole have a higher priority than the objectives
of its subsystems.

CLASSIFICATION OF A SYSTEM

Classification of systems can be done in many ways.

 Physical or Abstract system

 Open or Closed System
 Manmade information system

PHYSICAL SYSTEM: Physical systems are tangible entities that we can feel and touch. These may
be static or dynamic in nature. For example, take a computer center. Desks and chairs are the
static parts, which assist in the working of the center. The dynamic systems are constantly
changing. Computer systems are dynamic system. Programs, data, and applications can change
according to the user's needs.

ABSTRACT SYSTEM: Abstract systems are conceptual. These are not physical entities. They may
be formulas, representation or model of a real system.

OPEN SYSTEMS: Systems that interact with their environment. Practically most of the systems
are open systems. An open system has many interfaces with its environment. It can also adapt
to changing environmental conditions. It can receive inputs from, and delivers output to the
outside of system. An information system is an example of this category.

CLOSED SYSTEMS: Systems that don't interact with their environment. Closed systems exist in
concept only.

MAN MADE INFORMATION SYSTEM: The main purpose of information systems is to manage
data for a particular organization. Maintaining files, producing information and reports are few
functions. An information system produces customized information depending upon the needs
of the organization. These are usually formal, informal, and computer based.

Formal Information Systems: It deals with the flow of information from top management to
lower management. Information flows in the form of memos, instructions, etc. But feedback
can be given from lower authorities to top management.

Informal Information systems: Informal systems are employee based. These are made to solve
the day to day work related problems. Computer-Based Information Systems: This class of
systems depends on the use of computer for managing business applications.

COMPONENTS/ ELEMENTS OF A SYSTEM

System is a set of components working together to achieve some goal. The basic elements of
the system may be listed as:

 Resources
 Procedures
 Data/Information
 Intermediate Data
 Processes

RESOURCES: Every system requires certain resources for the system to exist. Resources can be
hardware, software or liveware. Hardware resources may include the computer, its peripherals,
stationery etc. Software resources would include the programs running on these computers
and the liveware would include the human beings required to operate the system and make it
functional.

PROCEDURES: Every system functions under a set of rules that govern the system to accomplish
the defined goal of the system.

DATA/INFORMATION: Every system has some predefined goal. For achieving the goal, the
system requires certain inputs, which are converted into the required output. The main
objective of the System is to produce some useful output. Output is the outcome of processing.
Output can be of any nature e.g. goods, services or information.

INTERMEDIATE DATA: Various processes process system's Inputs. Before it is transformed into
Output, it goes through many intermediary transformations. Therefore, it is very important to
identify the Intermediate Data. For example, in a college when students register for a new
semester, the initial form submitted by student goes through many departments. Each
department adds their validity checks on it.

Finally, the form gets transformed and the student gets a slip that states whether the student
has been registered for the requested subjects or not. It helps in building the System in a better
way. Intermediate forms of data occur when there is a lot of processing on the input data. So,
intermediate data should be handled as carefully as other data since the output depends upon
it.

Systems also exhibit certain features and characteristics, some of which are:

 Objective
 Standards
 Environment
 Feedback
 Boundaries and interfaces

OBJECTIVE: Every system has a predefined goal or objective towards which it works. A
system cannot exist without a defined objective. For example, an organization would have
an objective of earning maximum possible revenues, for which each department and each
individual has to work in coordination.

STANDARDS: It is the acceptable level of performance for any system. Systems should be
designed to meet standards. Standards can be business specific or organization specific.

For example, take a sorting problem. There are various sorting algorithms. But each has its own
complexity. So such algorithm should be used that gives most optimum efficiency. So there
should be a standard or rule to use a particular algorithm. It should be seen whether that
algorithm is implemented in the system.

ENVIRONMENT: Every system whether it is natural or man made co-exists with an environment.
It is very important for a system to adapt itself to its environment. Also, for a system to exist it
should change according to the changing environment. For example, we humans live in a
particular environment. As we move to other places, there are changes in the surroundings but
our body gradually adapts to the new environment. If it were not the case, then it would have
been very difficult for human to survive for so many thousand years.

FEEDBACK: Feedback is an important element of systems. The output of a system needs to be

observed and feedback from the output taken so as to improve the system and make it achieve
the laid standards. Also some feedback can come from customer (regarding quality) or it can
be some intermediate data (the output of one process and input for the other) that is required
to produce final output.

BOUNDARIES AND INTERFACES: Every system has defined boundaries within which it operates.
Interfaces are another important element through which the system interacts with the outside
world. System interacts with other systems through its interfaces. Users of the systems also
interact with it through interfaces. Therefore, these should be customized to the user needs.
These should be as user friendly as possible.
 SYSTEMS DEVELOPMENT LIFE CYCLE
System development can generally be thought of having two major components: systems
analysis and systems design. In System Analysis more emphasis is given to understanding the
details of an existing system or a proposed one and then deciding whether the proposed
system is desirable or not and whether the existing system needs improvements. Thus, system
analysis is the process of investigating a system, identifying problems, and using the
information to recommend improvements to the system.

System design is the process of planning a new business system or one to replace or
complement an existing system. Analysis specifies what the system should do. Design states
how to accomplish the objective. The figure below depicts the process of building system.

Process of building a system.

PLANNING

Project Identification and Initiation

Where do project ideas come from? A project is identified when someone in the organization
identifies a business need to build a system. This could occur within a business unit or IT, be
discovered by a steering committee charged with identifying business opportunities, or evolve
from a recommendation made by external consultants. Once the project sponsor identifies a
project that meets an important business need and he or she can identify the business
requirements and business value of the system, it is time to formally initiate the project. In
most organizations, project initiation begins with a technique called a system request.

Examples of business needs include:

Supporting a new marketing campaign

Reaching out to a new type of customer, or

Improving interactions with suppliers

Drop in market share,

Poor customer service levels, or increased competition.

New business initiatives and strategies are created and a system is required to enable them.

Identification of unique and competitive ways of using IT

Taking advantage of emerging technology

The project sponsor

The project sponsor is someone who recognizes the strong business need for a system and has
an interest in seeing the system succeeds. He or she will work throughout the SDLC to make
sure that the project is moving in the right direction from the perspective of the business. The
project sponsor serves as the primary point of contact for the system.
System Request
A system request is a document that describes the business reasons for building a system and
the value that the system is expected to provide. The project sponsor usually completes this
form as part of a formal system project selection process within the organization. Most system
requests include five elements: project sponsor, business need, business requirements,
business value, and special issues.

Feasibility study

It is the measure and the study of how beneficial the development of the system would be to
the organization. This is known as feasibility study. The measurement of feasibility is known as
feasibility study. There are number of aspects which are taken into consideration while the
feasibility studies. Firstly the project team is formed then with the help of flowcharts and other
forms of documentations the characteristics of the system are identified. The system is
evaluated and measured against the expected performance. A suitable candidate is selected for
the job and a final report is made and presented to the management for further evaluations.

There are number of rules to follow in the feasibility study, some of them are:

1) Forming a team for the specific project and appointing a suitable leader.

2) Preparing layouts and flowcharts of the system.

3) Enumerate the candidate systems.

4) Identify and describe the characters of the candidate systems.

5) Determining the performance of each candidate system with the standards set.

6) Reviewing the performance of the system and performing the cost analysis.

7) Selecting the best candidate for the system and preparing the final report for the
management.

As noted earlier number of factors determines the feasibility of the system but the 3 prime
factors for the feasibility study are technical, economical and behavioral factors. Feasibility
study is important in all the organizations before setting up any system.

Steps in Feasibility Analysis

Feasibility analysis is carried out in following steps:

1. Form a Project Team and Appoint a Project Leader: First of all project management
group of the organization forms separate teams for independent projects. Each project
team comprises of one or more systems analysts and programmers with a project
leader. The project leader is responsible for planning and managing the development
activities of the system.
2. Start Preliminary Investigation: The systems analyst of each project team starts
preliminary investigations through different fact finding techniques.
3. Prepare the Current Systems Flowchart: After preliminary investigations, the analysts
prepare the systems flowchart of the current system. These charts describe the general
working of the system in a graphical way.
4. Describe the Deficiencies in the Current System: On studying the systems flowcharts,
the analysts identify and describe the deficiencies in the current system.
5. Determine Objectives of the Proposed System: The major objectives of the proposed
systems are listed by each analyst and are discussed with the project leader.
6. Prepare the Proposed Systems Flowchart: After determining the major objectives of the
proposed system, the analysts prepare their systems flowcharts. Systems flowcharts of
the proposed system are compared with those of current system in order to ensure that
they meet the objectives.
7. Determine the Technical Feasibility: The existing computer systems (hardware and
software) of the concerned department are identified and their technical specifications
are noted down. The analysts decide whether the existing systems are sufficient for the
technical requirements of the proposed system or not.
8. Determine the Economic Feasibility: The analysts determine the costs and benefits of
proposed system in order to ensure that the project is economically feasible.
9. Determine the Operational Feasibility: After determining the economic feasibility, the
analysts identify the responsible users of the system and hence determine the
operational feasibility of the project.
10. Presentation of Feasibility Analysis: During the feasibility study, the analysts also keep
on preparing the feasibility study report. At the end of feasibility analysis, the feasibility
analysis report is given to the management along with the oral presentation.

Types of Feasibility

During feasibility analysis, the analyst considers the three main types of feasibility: technical,
economical and operational feasibility, all of which are interrelated.

 Technical Feasibility: During this study, the analyst identifies the existing computer
systems (hardware and software) of the concerned department and determines
whether these technical resources are sufficient for the proposed system or not. If they
are not sufficient, the analyst suggests the configuration of the computer systems that
are required. The analyst generally pursues two or three different configurations which
satisfy the key technical requirements but which represent different costs. During
 technical feasibility study, financial resources and budget are also considered. The main
objective of technical feasibility is to determine whether the project is technically
feasible, provided it is economically feasible.
 Economic Feasibility: Economic feasibility is the most important study that determines
the cost and benefits of the proposed system and compares with the budget. The cost
of the project should not outweigh the budget. The cost of the project includes the cost
of hardware, software, development and implementation. Cost/benefit analysis is the
common method to determine the benefits that are expected from the proposed
system and compare them with the costs expected to spend on development of the
system. If benefits are found to be more than costs, then the analyst decides to
continue the development of the proposed system otherwise considers it economically
not feasible. The feasibility study presents both tangible (e.g., increased productivity,
low operating cost, etc.) and intangible benefits (e.g., improved organizational planning,
improved asset utilization, etc.) in a formal way Following are some techniques used in
determining economic feasibility.

Techniques Used to Determine Economic Feasibility

Cost-Benefit Analysis is the process of isolating and estimating costs and benefits. In order to do
a cost-benefit analysis, two sides of the ledger must be considered - system costs and benefits
from the system; if a system is economically feasible, then the benefits should outweigh the
system costs within a defined period of time acceptable to the user/client.

Four different measures in Cost-Benefit Analysis:

1) Payback Analysis

2) Return on Investment

3) Net Present Value

4) Profitability Index

In order to do a thorough cost-benefit analysis, we need to know:

1) Development Costs
2) Annual Operating Costs

3) Annual Benefits

4) Economic Life of the System (e.g expected to last 5 years)

5) Required Rate of Return (e.g 15%)

Technique 1: Payback Analysis

It determines how much time will lapse before accumulated benefits overtake accumulated and
continuing costs. Payback is very useful when a project is very time sensitive

Development Costs( D)
Payback Period (T )=
Annual Revenues− Annual Operating Costs( P)

Example 1:

Investment costs of ℵ 4,000,000 to develop and reduces costs by ℵ 2,000,000 annually.

ℵ 4,000,000
Payback period D/P= =2 years
ℵ 2,000,000

Example 2:

Investment costs ℵ 5,000,000 to develop and reduces costs by ℵ 3,000,000 annually.

ℵ 5,000,000
Payback period D/P= =1.67 years
ℵ 3,000,000

Technique 2: Internal Rate of Return (IRR)

It is a measure of the relationship between what is invested in a project and the net benefits
from the project. Here the company may also have stated minimum IRR for its projects .
IRR = estimated lifetime benefits-estimated lifetime costs /estimated lifetime costs

estimated lifetime benefits−estimated lifetime costs

IRR=
estimated lifetime costs

Examples:

Example 1

Estimated lifetime Benefit = ℵ 10,000,000

Estimated lifetime Cost = ℵ 4,000,000

ℵ 10,000,000−ℵ 4,000,000 ℵ 6,000,000 1.5

IRR= = = lifetime
ℵ 4,000,000 ℵ 4,000,000 project

1.5
year lifetime=0.3=30 % annual IRR
5

Example 2

Estimated lifetime Benefit = ℵ 9,000,000

Estimated lifetime Cost = ℵ 5,000,000

ℵ 9,000,000−ℵ 5,000,000 ℵ 4,000,000 0.8

IRR= = = lifetime
ℵ 5,000,000 ℵ 5,000,000 project

0.8
year lifetime=0.267=26.7 % annual IRR
3

Technique 3: Present Value & Net Present Value

This technique calculates the costs and benefits of the system in terms of today's currency
value and takes into account the time value of money. eg. at 10% annual interest, ℵ 1 today is
worth ℵ 1.10 at the end of one year, then ℵ 1.10 x 1.10 = ℵ 1.21 at the end of two years, etc.

NPV = Present Value of Total Benefits - Present Value of Total Costs

If NPV is > 0, then the project is economically feasible.

Technique 4: Profitability Index

This technique attempts to measure risk by determining ratio of PV of benefits (Present Value)
to the Development Costs. ie. PV of benefits for two projects may be the same, but if
development costs of one is five times that of another, then you would want to choose the
project with the lower risk.

Present Value of Benefits

PI =
Present Value of Development Costs

If PI > 1 then the project is profitable.

 Operational Feasibility: When it is found that the project is both economic and technical
feasible, the next step is to determine whether it is operationally feasible or not. During
operational feasibility study, it is determined whether the system will operate in the
way that user wants.
 Social Feasibility: Social feasibility is a determination of whether a proposed project will
be acceptable to the people or not. This determination typically examines the
probability of the project being accepted by the group directly affected by the proposed
system change.
 Management feasibility: It is a determination of whether a proposed project will be
acceptable to management. If management does not accept a project or gives a
negligible support to it, the analyst will tend to view the project as a non-feasible one.
 Legal feasibility: Legal feasibility is a determination of whether a proposed project
infringes on known Acts, Statutes, as well as any pending legislation. Although in some
instances the project might appear sound, on closer investigation it may be found to
infringe on several legal areas.
 Time feasibility: Time feasibility is a determination of whether a proposed project can be
implemented fully within a stipulated time frame. If a project takes too much time it is
likely to be rejected.
After the feasibility study, a document is prepared that is known as ‘Feasibility Study Report’.
Besides this report, the analyst also gives the oral presentation of feasibility study to the
management.

This report analyses the importance of Feasibility Analysis to businesses when they are deciding
on the viability of a proposed business venture involving the implementation or improvement
of an information system.

What is Structured Analysis?

Structured Analysis is a development method that allows the analyst to understand the system
and its activities in a logical way.

It is a systematic approach, which uses graphical tools that analyze and refine the objectives of
an existing system and develop a new system specification which can be easily understandable
by user.

It has following attributes −

 It is graphic which specifies the presentation of application.

 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.
 It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development.
They are −

 Data Flow Diagrams

 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English

 Pseudocode
Data Flow Diagrams (DFD) or Bubble Chart
It is a technique developed by Larry Constantine to express the requirements of system in a
graphical form.

 It shows the flow of data between various functions of system and specifies how the
current system is implemented.
 It is an initial stage of design phase that functionally divides the requirement
specifications down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user and analyst or
analyst and system designer.
 It gives an overview of what data a system processes, what transformations are
performed, what data are stored, what results are produced and where they flow.

Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the
user wants a notational language for communication. However, it requires a large number of
iterations for obtaining the most accurate and complete solution.

The following table shows the symbols used in designing a DFD and their significance –
Types of DFD

DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points that
differentiate a physical DFD from a logical DFD.

Context Diagram

A context diagram helps in understanding the entire system by one DFD which gives the
overview of a system. It starts with mentioning major processes with little details and then goes
onto giving more details of the processes with the top-down approach.

The context diagram of mess management is shown below.

 Data Dictionary
A data dictionary is a structured repository of data elements in the system. It stores the
descriptions of all DFD data elements that is, details and definitions of data flows, data stores,
data stored in data stores, and the processes.

A data dictionary improves the communication between the analyst and the user. It plays an
important role in building a database. Most DBMSs have a data dictionary as a standard
feature. For example, refer the following table −

Decision Trees
Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.

Decision trees depict the relationship of each condition and their permissible actions. A square
node indicates an action and a circle indicates a condition. It forces analysts to consider the
sequence of decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe what
other combinations of conditions you can take for testing. It is a single representation of the
relationships between conditions and actions.

For example, refer the following decision tree −

Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise manner
which is easily understandable.

 It is useful in situations where the resulting actions depend on the occurrence of one or
several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the actions.

Components of a Decision Table

 Condition Stub − It is in the upper left quadrant which lists all the condition to be
checked.
 Action Stub − It is in the lower left quadrant which outlines all the action to be carried
out to meet such condition.
 Condition Entry − It is in upper right quadrant which provides answers to questions
asked in condition stub quadrant.
 Action Entry − It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.

The entries in decision table are given by Decision Rules which define the relationships between
combinations of conditions and courses of action. In rules section,

 Y shows the existence of a condition.

 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.

For example, refer the following table −

Structured English
Structure English is derived from structured programming language which gives more
understandable and precise description of process. It is based on procedural logic that uses
construction and imperative sentences designed to perform operation for action.

 It is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all logic in terms of sequential decision
structures and iterations.

For example, see the following sequence of actions −

Pseudocode
A pseudocode does not conform to any programming language and expresses logic in plain
English.

 It may specify the physical programming logic without actual coding during and after the
physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most appropriate tool that would suit your
requirements −

 Use DFD at high or low level analysis for providing good system documentations.
 Use data dictionary to simplify the structure for meeting the data requirement of the
system.
 Use structured English if there are many loops and actions are complex.
 Use decision tables when there are a large number of conditions to check and logic is
complex.
 Use decision trees when sequencing of conditions is important and if there are few
conditions to be tested.
Input Design
In an information system, input is the raw data that is processed to produce output. During the
input design, the developers must consider the input devices such as PC, MICR, OMR, etc.

Therefore, the quality of system input determines the quality of system output. Welldesigned
input forms and screens have following properties −

 It should serve specific purpose effectively such as storing, recording, and retrieving the
information.
 It ensures proper completion with accuracy.
 It should be easy to fill and straightforward.
 It should focus on user’s attention, consistency, and simplicity.
 All these objectives are obtained using the knowledge of basic design principles
regarding −
o What are the inputs needed for the system?
o How end users respond to different elements of forms and screens.

Objectives for Input Design

The objectives of input design are −

 To design data entry and input procedures

 To reduce input volume
 To design source documents for data capture or devise other data capture methods
 To design input data records, data entry screens, user interface screens, etc.
 To use validation checks and develop effective input controls.

Data Input Methods

It is important to design appropriate data input methods to prevent errors while entering data.
These methods depend on whether the data is entered by customers in forms manually and
later entered by data entry operators, or data is directly entered by users on the PCs.

A system should prevent user from making mistakes by:

 Clear form design by leaving enough space for writing legibly.

 Clear instructions to fill form.
 Clear form design.
 Reducing key strokes.
 Immediate error feedback.
Some of the popular data input methods are :

 Batch input method (Offline data input method)

 Online data input method
 Computer readable forms
 Interactive data input

Input Integrity Controls

Input integrity controls include a number of methods to eliminate common input errors by end-
users. They also include checks on the value of individual fields; both for format and the
completeness of all inputs.

Audit trails for data entry and other system operations are created using transaction logs which
gives a record of all changes introduced in the database to provide security and means of
recovery in case of any failure.

Output Design
The design of output is the most important task of any system. During output design,
developers identify the type of outputs needed, and consider the necessary output controls and
prototype report layouts.

Objectives of Output Design

The objectives of input design are −

 To develop output design that serves the intended purpose and eliminates the
production of unwanted output.
 To develop the output design that meets the end users requirements.
 To deliver the appropriate quantity of output.
 To form the output in appropriate format and direct it to the right person.
 To make the output available on time for making good decisions.

Let us now go through various types of outputs −

External Outputs

Manufacturers create and design external outputs for printers. External outputs enable the
system to leave the trigger actions on the part of their recipients or confirm actions to their
recipients.

Some of the external outputs are designed as turnaround outputs, which are implemented as a
form and re-enter the system as an input.
Internal outputs

Internal outputs are present inside the system, and used by end-users and managers. They
support the management in decision making and reporting.

There are three types of reports produced by management information −

 Detailed Reports They contain present information which has almost no filtering or
restriction generated to assist management planning and control.
 Summary Reports They contain trends and potential problems which are categorized
and summarized that are generated for managers who do not want details.
 Exception Reports They contain exceptions, filtered data to some condition or standard
before presenting it to the manager, as information.

Output Integrity Controls

Output integrity controls include routing codes to identify the receiving system, and verification
messages to confirm successful receipt of messages that are handled by network protocol.

Printed or screen-format reports should include a date/time for report printing and the data.
Multipage reports contain report title or description, and pagination. Pre-printed forms usually
include a version number and effective date.

Forms Design
Both forms and reports are the product of input and output design and are business document
consisting of specified data. The main difference is that forms provide fields for data input but
reports are purely used for reading. For example, order forms, employment and credit
application, etc.

 During form designing, the designers should know −

o who will use them
o where would they be delivered
o the purpose of the form or report
 During form design, automated design tools enhance the developer’s ability to
prototype forms and reports and present them to end users for evaluation.

Objectives of Good Form Design

A good form design is necessary to ensure the following −

 To keep the screen simple by giving proper sequence, information, and clear captions.
 To meet the intended purpose by using appropriate forms.
 To ensure the completion of form with accuracy.
  To keep the forms attractive by using icons, inverse video, or blinking cursors etc.
 To facilitate navigation.

Types of Forms

Flat Forms

 It is a single copy form prepared manually or by a machine and printed on a paper. For
additional copies of the original, carbon papers are inserted between copies.
 It is a simplest and inexpensive form to design, print, and reproduce, which uses less
volume.

Unit Set/Snap out Forms

 These are papers with one-time carbons interleaved into unit sets for either
handwritten or machine use.
 Carbons may be either blue or black, standard grade medium intensity. Generally, blue
carbons are best for handwritten forms while black carbons are best for machine use.

Continuous strip/Fanfold Forms

 These are multiple unit forms joined in a continuous strip with perforations between
each pair of forms.
 It is a less expensive method for large volume use.

No Carbon Required (NCR) Paper

 They use carbonless papers which have two chemical coatings (capsules), one on the
face and the other on the back of a sheet of paper.
 When pressure is applied, the two capsules interact and create an image.

SYSTEM ANALYSIS ACTIVITIES

Systems Analysis: Is a process of collecting and interpreting facts, identifying the problems, and
decomposition of a system into its components.

What are Requirements?

As you can see from the previous section, requirements and models that represent them are a
key focus of analysis phase activities. Most of the analyst’s time is devoted to requirements:
gathering information about them, formalizing them by using models and prototypes, refining
and expanding them, prioritizing them, and generating and evaluating alternatives. But to fully
understand those activities, you need to answer a fundamental question: What are
requirements?

Requirements:
The requirements for a system are the descriptions of what the system should do— the services
that it provides and the constraints on its operation. These requirements reflect the needs of
customers for a system that serves a certain purpose such as controlling a device, placing an
order, or finding information. The process of finding out, analyzing, documenting and checking
these services and constraints is called requirements engineering (RE). In some cases, a
requirement is simply a high-level, abstract statement of a service that a system should provide
or a constraint on a system. At the other extreme, it is a detailed, formal definition of a system
function.

Levels of Requirements
There are two levels of requirements: User requirements and System requirements.

User requirements
User requirements are statements, in a natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under which it must operate.

System requirements
System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements document (sometimes called a
functional specification) should define exactly what is to be implemented. It may be part of the
contract between the system buyer and the software developers.

Different levels of requirements are useful because they communicate information about the
system to different types of reader. The system requirements provide more specific information
about the services and functions of the system that is to be implemented.

The readers of the user requirements are not usually concerned with how the system will be
implemented and may be managers who are not interested in the detailed facilities of the
system. The readers of the system requirements need to know more precisely what the system
will do because they are concerned with how it will support the business processes or because
they are involved in the system implementation.

Classes of Requirements
There are two classes of requirements-Functional and non-functional requirements

Functional requirements
These are statements of services the system should provide, how the system should react to
particular inputs, and how the system should behave in particular situations. In some cases, the
functional requirements may also explicitly state what the system should not do. When
expressed as user requirements, functional requirements are usually described in an abstract
way that can be understood by system users. However, more specific functional system
requirements describe the system functions, its inputs and outputs, exceptions, etc., in detail.
In principle, the functional requirements specification of a system should be both complete and
consistent. Completeness means that all services required by the user should be defined.
Consistency means that requirements should not have contradictory definitions.

Non-functional requirements
These are constraints on the services or functions offered by the system. They include timing
constraints, constraints on the development process, and constraints imposed by standards.
Non-functional requirements often apply to the system as a whole, rather than individual
system features or services. Non-functional requirements, as the name suggests, are
requirements that are not directly concerned with the specific services delivered by the system
to its users. They may relate to emergent system properties such as reliability, security,
response time, and store occupancy. Alternatively, they may define constraints on the system
implementation such as the capabilities of I/O devices or the data representations used in
interfaces with other systems.

Examples of non-functional requirements

Reliability

Security

Response time

Store occupancy

Throughput etc.

capabilities of I/O devices

Requirements specification
Requirements specification is the process of writing down the user and system requirements in
a requirements document. Ideally, the user and system requirements should be clear,
unambiguous, easy to understand, complete, and consistent.. The user requirements for a
system should describe the functional and nonfunctional requirements so that they are
understandable by system users who don’t have detailed technical knowledge. Ideally, they
should specify only the external behavior of the system. The requirements document should
not include details of the system architecture or design.

Four high-level activities in Requirements Engineering

Feasibility Study-These focus on assessing if the system is useful to the business or not.

Elicitation and Analysis- discovering requirements

Specification - converting these requirements into some standard form

Validation - checking that the requirements actually define the system that the customer wants

Requirements elicitation and analysis

After an initial feasibility study, the next stage of the requirements engineering process is
requirements elicitation and analysis. In this activity, Systems Analyst work with customers and
system end-users to find out about the application domain, what services the system should
provide, the required performance of the system, hardware constraints, and so on.
Figure 8: Requirement Elicitation and Analysis process

A process model of the elicitation and analysis process is shown in Figure 8. Each organization
will have its own version or instantiation of this general model depending on local factors such
as the expertise of the staff, the type of system being developed, the standards used, etc. The
process activities are:

1. Requirements discovery

2. Requirements classification and organization

3. Requirements prioritization and Negotiation

4. Requirements specification

Requirements Discovery
Requirements discovery (sometime called requirements elicitation) is the process of gathering
information about the required system and existing systems, and distilling the user and system
requirements from this information. Sources of information during the requirements discovery
phase include documentation, system stakeholders, and specifications of similar systems. You
interact with stakeholders through interviews and observation and you may use scenarios and
prototypes to help stakeholders understand what the system will be like. Stakeholders range
from end-users of a system through managers to external stakeholders such as regulators, who
certify the acceptability of the system. All stakeholders must be considered during the
requirements elicitation process.

System analysis is conducted for the purpose of studying a system or its parts in order to
identify its objectives. It is a problem solving technique that improves the system and ensures
that all the components of the system work efficiently to accomplish their purpose. Analysis
specifies what the system should do. System analysis includes the following:

 Requirement determination
 Requirement structuring
 Fact finding techniques

Requirements determination is the beginning sub phase of analysis. In this sub phase, analysts
should gather information on what the system should do from as many sources as possible.
There are some traditional methods to help collecting system requirements, such as
interviewing, survey, directly observing users. Is also a collection of information is at the core of
systems analysis. Interviewing, questionnaires, directly observing and analyzing documents are
four main methods adopted by system analysts to collect information.

Interviewing is one of the primary ways to gather information about an information system. A
good system analyst must be good at interviewing and no project can be conduct without
interviewing. There are many ways to arrange an effectively interview and no one is superior to
others. However, experience analysts commonly accept some following best practices for an
effective interview:

 Prepare the interview carefully, including appointment, priming question, checklist,

agenda, and questions.

 Listen carefully and take note during the interview (tape record if possible)

 Review notes within 48 hours after interview.

 Be neutral

 Seek diverse views

Questionnaires have the advantage of gathering information from many people in a

relatively short time and of being less biased in the interpretation of their results. Choosing

right questionnaires respondents and designing effective questionnaires are the critical
 issues in this information collection method. People usually are only use a part of functions

of a system, so they are always just familiar with a part of the system functions or

processes. In most situations, one copy of questionnaires obviously cannot fit to all the

users. To conduct an effective survey, the analyst should group the users properly and

design different questionnaires for different group. Moreover, the ability to build good

questionnaires is a skill that improves with practice and experience. When designing

questionnaires, the analyst should concern the following issues at least:

 The ambiguity of questions.

 Consistence of respondents’ answers.

 What kind of question should be applied, open-ended or close-ended?

 What is the proper length of the questionnaires?

Directly observing users. People are not always very reliable informants, even when they try to

be reliable and tell what they think is the truth. People often do not have a completely accurate

appreciation of what they do or how they do it. This especially true concerning infrequent

events, issues from the past, or issues for which people have considerable passion. Since people

cannot always be trusted to reliably interpret and report their own actions, analyst can

supplement and corroborate what people say by watching what they do or by obtaining

relatively objective measures of how people behave in work situation. However, observation

can cause people to change their normal operation behavior. It will make the gathered

information biased.
Analyzing procedures and other documents. By examining existing system and organizational

documentation, system analyst can find out details about current system and the organization

these systems support. In documents analyst can find information, such as problem with

existing systems, opportunities to meet new needs if only certain information or information

processing were available, organizational direction that can influence information system

requirements, and the reason why current systems are designed as they are.

Requirements Structuring: Is the process to use some kind of systematical and standard, well-
structured methods to model the real world. Traditionally, we use data flow diagram for
process modeling, decision table or decision tree for logic modeling, and Entity-relationship
diagram for data modeling. These modeling tools usually separately model only one face of the
real world.

Traditionally, there are three basic methods for requirements structuring:

 Data flow diagrams, it is widely used for process modeling

 Structure English, decision tables, and decision trees, they are used for logic modeling

 Entity and relationship diagram, it is used for data modeling

Fact Finding Techniques: Fact finding is process of collection of data and information based on

techniques which contain sampling of existing documents, research, observation,

questionnaires, interviews, prototyping and joint requirements planning. There are seven

common fact-finding techniques:

1. Sampling of existing documentation, forms and databases: The best way to analyse the
existing system is to collect facts from existing documentation rather than from human
sources. There are various kinds of documents to collect facts from existing documents.
These include: e-mails, customer complaints, suggestion box notes and reports that
document the problem area, problem performance reviews, samples of completed
manual forms and reports and samples of completed computerized forms and report
2. Research and Site visits: Is the process of examining the problems which had previously
solved by other sources that can be either human or documents. To solve the
requirements of problem, the analyst visits to other organization that had previously
experienced for similar problems. In addition, the analyst can also find the information
from database, reference books, case studies and Internet.
3. Observation of the work environment: Another fact finding technique is observation. In
this technique, system analyst participates in the organization, studies the flow of
documents, applies the existing system, and interacts with the users. Observation can
be a useful technique when the system analyst have user point of view. Sampling
technique called work sampling is useful for observation. By using this technique,
system analyst can know how employees spend their days.

4. Questionnaires: Questionnaires are also one of useful fact-finding technique to collect

information from large number of users. Users fill up the questions which are given by
the system analyst and then give the answers back to the system analyst.
Questionnaires can save time because system analyst does not need to interview each
of users. There are two types of questionnaires:

1. Free-format questionnaires: In free-format questionnaires, users are allowed to answer

questions freely without immediate response. The results are also useful in learning
about feelings, opinions, and experiences of the respondents.
2. Fixed-format questionnaires: The purpose of fixed-format questionnaires is to gather
information from predefined format of questions. Users are allowed to choose the
result from the given answers. There are three types of fixed-format questions:
multiple-choice questions (Yes or No type), rating questions (Strongly agree, Agree, No
opinion, Disagree, Strongly disagree), ranking questions (numbering according to the
preferences).

5. Interviews: Interview is the most commonly used technique to collect information from
the face-to-face interviews. The purpose of interview is to find, verify, clarify facts,
motivate end-users involved, identify requirements and gather ideas and opinions. The
role of interview includes interviewer who is system analyst and interviewee who are
system owner or user. Interviewing technique needs good communication skills for
interaction between system analyst and user. There are two types of interviews.

1. Unstructured Interview: An interview that is conducted with only a general goal

or subject in mind and with few. Open-ended questions type is used in
unstructured interview that allows user to answer freely in an appropriate way.
2. Structured Interview: Structured interview is an interview which contains
predefined set of questions. In structured interview, close-ended questions type
is used to limit answers to specify choices, short and direct responses from the
interviewees.
 6. Prototyping: Another fact-finding technique is known as prototyping which collects the
requirement facts of the system. Prototyping is sampling a small working model and it is
more related to pre-design of the information system.
7. Joint requirements planning: JRP is the structured group work meeting to identify,
analyze problems and define the requirements of system. JRP is becoming increasingly
common in systems planning and systems analysis to obtain group consensus on
problems, objectives and requirement.

SYSTEM DESIGN

System design is the phase that bridges the gap between problem domain and the existing
system in a manageable way. This phase focuses on the solution domain, i.e. “how to
implement?”

It is the phase where the SRS document is converted into a format that can be implemented
and decides how the system will operate.

Types of System Design

Logical Design

Logical design pertains to an abstract representation of the data flow, inputs, and outputs of
the system. It describes the inputs (sources), outputs (destinations), databases (data stores),
procedures (data flows) all in a format that meets the user requirements.

While preparing the logical design of a system, the system analyst specifies the user needs at
the level of detail that virtually determines the information flow into and out of the system and
the required data sources. Data flow diagram, E-R diagram modeling are used.

Physical Design

Physical design relates to the actual input and output processes of the system. It focuses on
how data is entered into a system, verified, processed, and displayed as output.

It produces the working system by defining the design specification that specifies exactly what
the candidate system does. It is concerned with user interface design, process design, and data
design.

It consists of the following steps −

 Specifying the input/output media, designing the database, and specifying backup
procedures.
 Planning system implementation.
  Devising a test and implementation plan, and specifying any new hardware and
software.
 Updating costs, benefits, conversion dates, and system constraints.

Architectural Design

It is also known as high level design that focuses on the design of system architecture. It
describes the structure and behavior of the system. It defines the structure and relationship
between various modules of system development process.

Detailed Design

It follows Architectural design and focuses on development of each module.

Conceptual Data Modeling

It is representation of organizational data which includes all the major entities and relationship.
System analysts develop a conceptual data model for the current system that supports the
scope and requirement for the proposed system.

The main aim of conceptual data modeling is to capture as much meaning of data as possible.
Most organization today uses conceptual data modeling using E-R model which uses special
notation to represent as much meaning about data as possible.

Entity Relationship Model

It is a technique used in database design that helps to describe the relationship between
various entities in an organization.

Terms used in E-R model

 ENTITY: It specifies distinct real world items in an application. For example: vendor,
item, student, course, teachers, etc.
 RELATIONSHIP: they are the meaningful dependencies between entities. For example,
vendor supplies items, teacher teaches courses, and then supplies and course are
relationship.
 ATTRIBUTES: It specifies the properties of relationships. For example, vendor code,
student name.
 Below are the following of the symbols used in E-R model and their respective
meanings:

Three types of relationships can exist between two sets of data: one-to-one, one-to-many, and
many-to-many relationships.
 CODING/ IMPLEMENTATION
CODING
The system design needs to be implemented to make it a workable system. This demands
the coding of design into computer understandable language, i.e. programming language. This
is also called the programming phase in which the programmer converts the program
specifications into computer instructions, which we refer to as programs. It is an important
stage where the defined procedures are:
 Transformed the data into control specifications by the help of a computer language.
 The programs coordinate the data movements and control the entire process in a
system.
 It is generally felt that the programs must be modular in nature. This helps in fast
development, maintenance and future changes, if required.

IMPLEMENTATION
After having the user acceptance of the new system developed, the implementation phase
begins. Implementation is the stage of a project during which theory is turned into practice. The
major steps involved in this phase are:
 Acquisition and Installation of Hardware and Software
 Conversion
 User Training
 Documentation

The hardware and the relevant software required for running the system must be made fully
operational before implementation. The conversion is also one of the most critical and
expensive activities in the system development life cycle. The data from the old system needs
to be converted to operate in the new format of the new system. The database needs to be
setup with security and recovery procedures fully defined. During this phase, all the programs
of the system are loaded onto the user’s computer. After loading the system, training of the
user starts. Main topics of such type of training are:
 How to execute the package
 How to enter the data
 How to process the data (processing details)
 How to take out the reports

After the users are trained about the computerized system, working has to shift from manual to
computerized working. The process is called ‘Changeover’. The following strategies are
followed for changeover of the system.

 Direct Changeover: This is the complete replacement of the old system by the new
system. It is a risky approach and requires comprehensive system testing and training.
 Parallel run: In parallel run both the systems, i.e., computerized and manual, are
executed simultaneously for certain defined period. The same data is processed by both
the systems. This strategy is less risky but more expensive because of the following:
1. Manual results can be compared with the results of the computerized system.
 2. The operational work is doubled.
3. Failure of the computerized system at the early stage does not affect the working of the
organization, because the manual system continues to work, as it used to do.

 Pilot run: Ii involves implementing the complete new system at a selected location of
the company. The group that uses the new system is called the pilot site. The old system
continues to operate for the entire organization including the pilot site. In this type of
run, the new system is run with the data from one or more of the previous periods for
the whole or part of the system. The results are compared with the old system results. It
is less expensive and risky than parallel run approach. This strategy builds the
confidence and the errors are traced easily without affecting the operations.

System Documentation

System documentation serves as the technical specifications for the information system (IS) and
how the objectives of the IS are accomplished. Users, managers and IS owners need never
reference system documentation. System documentation provides the basis for understanding
the technical aspects of the IS when modifications are made.

 It describes each program within the IS and the entire IS itself.

 It describes the system’s functions; the way they are implemented, each program's
purpose within the entire IS with respect to the order of execution, information passed
to and from programs, and overall system flow.
 It includes data dictionary entries, data flow diagrams, object models, screen layouts,
source documents, and the systems request that initiated the project.
 Most of the system documentation is prepared during the system analysis and system
design phases.
 During systems implementation, an analyst must review system documentation to verify
that it is complete, accurate, and up-to-date, and including any changes made during
the implementation process.

Documentation Control

Documentation is a process of recording the information for any reference or operational

purpose. It helps users, managers, and IT staff, who require it. It is important that prepared
document must be updated on regular basis to trace the progress of the system easily.

User documentation should include:

 A system overview that clearly describes all major system features, capabilities, and
limitations.
 Description of source document content, preparation, processing, and, samples.
 Overview of menu and data entry screen options, contents, and processing instructions.
  Examples of reports that are produced regularly or available at the user’s request,
including samples.
 Security and audit trail information.
 Explanation of responsibility for specific input, output, or processing requirements.
 Procedures for requesting changes and reporting problems.
 Examples of exceptions and error situations.
 Frequently asked questions (FAQs).
 Explanation of how to get help and procedures for updating the user manual.

However, the documentation involves the following:

 Program documentation
 System documentation
 Operations documentation
 User documentation

Program Documentation

 It describes inputs, outputs, and processing logic for all the program modules.
 The program documentation process starts in the system analysis phase and continues
during implementation.
 This documentation guides programmers, who construct modules that are well
supported by internal and external comments and descriptions that can be understood
and maintained easily.

Operations Documentation

Operations documentation contains all the information needed for processing and distributing
online and printed output. Operations documentation should be clear, concise, and available
online if possible..

User Documentation

It includes instructions and information to the users who will interact with the system. For
example, user manuals help guides, and tutorials. User documentation is valuable in training
users and for reference purpose. It must be clear, understandable, and readily accessible to
users at all levels.

The users, system owners, analysts, and programmers, all put combined efforts to develop a
user’s guide. The documentation of the system is also one of the most important activity in the
system development life cycle. This ensures the continuity of the system. There are generally
two types of documentation prepared for any system. These are:

1. User or Operator Documentation

 2. System Documentation

1. The user documentation is a complete description of the system from the users’
point of view detailing how to use or operate the system. It also includes the
major error messages likely to be encountered by the users.
2. The system documentation contains the details of system design, programs,
their coding, system flow, data dictionary, process description, etc. This helps to
understand the system and permit changes to be made in the existing system to
satisfy new user needs.

TESTING
Before actually implementing the new system into operation, a test run of the system is done
for removing the bugs, if any. It is an important phase of a successful system. After codifying the
whole programs of the system, a test plan should be developed and run on a given set of test
data. The output of the test run should match the expected results. Sometimes, system testing
is considered as part of implementation process. Using the test data following test run are
carried out:

 Program test
 System test

 Program test: When the programs have been coded, compiled and brought to working
conditions, they must be individually tested with the prepared test data. Any
undesirable happening must be noted and debugged (error corrections)
 System Test: After carrying out the program test for each of the programs of the system
and errors removed, then system test is done. At this stage the test is done on actual
data. The complete system is executed on the actual data. At each stage of the
execution, the results or output of the system is analyzed. During the result analysis, it
may be found that the outputs are not matching the expected output of the system. In
such case, the errors in the particular programs are identified and are fixed and further
tested for the expected output. When it is ensured that the system is running error-free,
the users are called with their own actual data so that the system could be shown
running as per their requirements.

The dimensions of software quality include the following characteristics:

 Accessibility. The degree to which a diverse group of people, including individuals who
require adaptive technologies such as voice recognition and screen magnifiers, can
comfortably use the software.
 Compatibility. The suitability of the software for use in a variety of environments, such
as with different OSs, devices and browsers.
 Efficiency. The ability of the software to perform well without wasting energy,
resources, effort, time or money.
 Functionality. Software's ability to carry out its specified functions.
  Installability. The ability of the software to be installed in a specified environment.
 Localization. The various languages, time zones and other such features software can
function in.
 Maintainability. How easily the software can be modified to add and improve features,
fix bugs, etc.
 Performance. How fast the software performs under a specific load.
 Portability. The ability of the software to be easily transferred from one location to
another.
 Reliability. The software's ability to perform a required function under specific
conditions for a defined period of time without any errors.
 Scalability. The measure of the software's ability to increase or decrease performance in
response to changes in its processing demands.
 Security. The software's ability to protect against unauthorized access, invasion of
privacy, theft, data loss, malicious software, etc.
 Testability. How easy it is to test the software.
 Usability. How easy it is to use the software.

Software quality assurance vs quality control vs testing

The concept of software quality is introduced to ensure the released program is safe and
functions as expected. It can be defined as “the capability of a software product to satisfy
stated and implied needs under specific conditions. Additionally, quality refers to the degree to
which a product meets its stated requirements.”

Quality assurance (QA), quality control (QC), and QA software testing are three aspects of
quality management to ensure that a program works as intended Often used interchangeably,
the three terms cover different processes and vary in their scope, though they have the same
goal to deliver the best possible digital product or service.
What is quality assurance?

Quality assurance is a broad term, explained on the Google Testing Blog, as “the continuous
and consistent improvement and maintenance of process that… gives us confidence the product
will meet the need of customers.” QA focuses on organizational aspects of quality management,
aiming to improve the end-to-end product development life cycle, from requirements analysis
to launch and maintenance.

QA plays a crucial role in the early identification and prevention of product defects. Among its
key activities are

 setting quality standards and procedures,

 creating guidelines to follow across the development process,
 conducting measurements,
 Reviewing and changing workflows to enhance them.
QA engages external stakeholders and a broad range of internal specialists, including business
analysts (BAs), QA engineers, and software developers. Its ultimate goal is to establish an
environment ensuring the production of high-quality items and, thus, to build trust with clients.

What is quality control

Quality control is a part of quality management that verifies the product’s compliance with
standards set by QA. Investopedia defines it as a “process through which a business seeks to
ensure that product quality is maintained or improved and manufacturing errors are reduced or
eliminated.”

While QA activities aim to prevent issues across the entire development process, QC is about
detecting bugs in the ready-to-use software and checking its correspondence to the
requirements before the product launch. It encompasses code reviews and testing activities
conducted by the engineering team.

What is software testing?

Testing is the primary activity of detecting and solving technical issues in the software source
code and assessing the overall product usability, performance, security, and compatibility. It
has a narrow focus and is performed by test engineers in parallel with a development process
or at the dedicated testing stage (depending on the methodological approach to the software
development cycle).

Software testing principles

Formulated over the past 40 years, the seven principles of software testing represent the
ground rules for the process.

Testing shows the presence of mistakes. Testing aims to detect the defects within a piece of
software. But no matter how hard you try, you’ll never be 100 percent sure there are no
defects. Testing can only reduce the number of unfound issues.

Exhaustive testing is impossible. There is no way to test all combinations of data inputs,
scenarios, and preconditions within an application. For example, if a single app screen contains
ten input fields with three possible value options each, test engineers need to create 59,049
(310) scenarios to cover all possible combinations. And what if the app contains 50+ of such
screens? Focus on more common scenarios to avoid spending weeks creating millions of less
possible ones.

Early testing. As mentioned above, the cost of an error grows exponentially throughout the
stages of the software development life cycle (SDLC). Therefore, it is important to start testing
the code as soon as possible to resolve issues and not to snowball.
Defect clustering. Often called an application of the Pareto principle to software testing, defect
clustering implies that approximately 80 percent of all errors are usually found in only 20
percent of the system modules. If you find a bug in a particular component, there might be
others. So, it makes sense to test this area of the product thoroughly.

Pesticide paradox. Running the same set of tests repeatedly won’t help you find more issues.
As soon as you fix the detected errors, the previous scenarios become useless. Review and
update them regularly to spot hidden mistakes.

Testing is context-dependent. Test applications differently regarding the industry or goals.

While safety could be of primary importance for a fintech product, it is less significant for a
corporate website, emphasizing usability and speed.

Absence-of-errors fallacy. The absence of errors does not necessarily lead to a product’s
success. No matter how much time you have spent polishing the code, the software will fail if it
does not meet user expectations.

Some sources note other principles besides the basic ones:

 Testing must be an independent process handled by unbiased professionals.

 Test for invalid and unexpected input values as well as valid and expected ones.
 Conduct tests only on a static piece of software (you should make no changes in the process of
testing).
 Use exhaustive and comprehensive documentation to define the expected test results.

Yet the above-listed seven points remain undisputed guidelines for every software testing
professional.

When testing happens in the software development life cycle

As mentioned above, testing happens at the dedicated stage of the software development life
cycle or in parallel with the engineering process, it depends on the project management
methodology your team sticks to.

POST IMPLEMENTATION
Post implementation is a tool or standard approach for evaluating the outcome of the project
and determine whether the project is producing the expected benefits to the processes,
products or services. It enables the user to verify that the project or system has achieved its
desired outcome within specified time period and planned cost. The objectives of post
implementation are as follows

 To determine the success of a project against the projected costs, benefits, and
timelines.
 To identify the opportunities to add additional value to the project.
  To determine strengths and weaknesses of the project for future reference and
appropriate action.
 To make recommendations on the future of the project by refining cost estimating
techniques.

MAINTENANCE
Maintenance is necessary to eliminate errors in the system during its working life and to tune
the system to any variations in its working environments. It has been seen that there are always
some errors found in the systems that must be noted and corrected. It also means the review of
the system from time to time. The review of the system is done for:
 knowing the full capabilities of the system
 knowing the required changes or the additional requirements
 Studying the performance.

Software quality measures if the software meets both its functional and nonfunctional
requirements.

 Functional requirements identify what the software should do. They include technical
details, data manipulation and processing, calculations or any other specific function
that specifies what an application aims to accomplish.
 Nonfunctional requirements: also known as quality attributes determine how the
system should work. Nonfunctional requirements include portability, disaster recovery,
security, privacy and usability.

If a major change to a system is needed, a new project may have to be set up to carry out the
change. The new project will then proceed through all the above life cycle phases.

Types of Maintenance

System maintenance can be classified into three types:

 Corrective Maintenance: Enables user to carry out the repairing and correcting leftover
problems. It has to do with repairing that are broken.
 Adaptive Maintenance: Enables user to replace the functions of the programs. It consist
pf adapting software to changes in the environment. e.g some programs run on Ubuntu
os.
 Perfective Maintenance: Enables user to modify or enhance the programs according to
the users’ requirements and changing needs.
 Preventive. These changes are done to keep software from failing and include tasks
such as restructuring and optimizing code.
 SOFTWARE LICENSING AND PATENTS

A software license is a legally binding document that restricts the use and distribution of
software.

Typically, software licenses provide users with the right to one or more copies of the software
without violating copyright. The license outlines the responsibilities of the parties that enter
into the agreement and may place restrictions on how the software can be used.

Software licensing terms and conditions generally include fair use of the software, the
limitations of liability, warranties, disclaimers and protections if the software or its use infringes
on the intellectual property rights of others.

Licenses typically are for proprietary software, which remains the property of the organization,
group or individual that created it; or for free software, where users can run, study, change and
distribute the software. Open source is a type of software where the software is developed
collaboratively, and the source code is freely available. With open source software licenses,
users can run, copy, share and change the software similar to free software.

Over the last two decades, software vendors have moved away from selling software licenses
on a one-time basis to a software-as-a-service subscription model. Software vendors host the
software in the cloud and make it available to customers, who pay a subscription fee and access
the software over the internet.

Although copyright can prevent others from copying a developer's code, a copyright cannot
stop them from developing the same software independently without copying. A patent, on the
other hand, enables a developer to prevent another person from using the functional aspects of
the software a developer claims in a patent, even if that other person developed the software
independently.

In general, the more technical software is, the more likely it can be patented. For example, a
software product could be granted a patent if it creates a new kind of database structure or
enhances the overall performance and function of a computer.

SYSTEM DEVELOPMENT METHODOLOGIES

As we discussed earlier, the Systems Development Life Cycle (SDLC) provides the foundation for
the processes used to develop an information system. A methodology is a formalized approach
to implementing the SDLC. There are many different systems development methodologies;
some are discussed in this section. They are:

1. Waterfall Mode
2. Rapid Application Development (RAD)
i. Iterative development Methodology
ii. System prototyping
iii. Throwaway Prototyping
3. Agile Development
i. Extreme Programming (XP)
ii. Scrum
iii. Dynamic Systems Development Method (DSDM)

Waterfall Model
This model is named “waterfall model” because its diagrammatic representation resembles a
cascade of waterfalls.

With waterfall development, analysts and users proceed sequentially from one phase to the
next (See Figure 2). The key deliverables for each phase are typically voluminous (often,
hundreds of pages) and are presented to the approval committee and project sponsor for
approval as the project moves from phase to phase. Once the work produced in one phase is
approved, the phase ends and the next phase begins. As the project progresses from phase to
phase, it moves forward in the same manner as a waterfall. While it is possible to go backward
through the phases (e.g., from design back to analysis), it is quite difficult.

Advantages of Waterfall development methodology

i. Identifying requirements long before programming begins and limiting changes to

the requirements as the project proceed
ii. It is easy to understand and reinforces the notion of “define before design” and
“design before code”. The model expects complete & accurate requirements early in
the process, which is unrealistic.
Figure 2: Water Fall Methodology

Problems of waterfall model

i. It is difficult to define all requirements at the beginning of a project

ii. This model is not suitable for accommodating any change
iii. A working version of the system is not seen until late in the project’s life
iv. It does not scale up well to large projects.
v. Real projects are rarely sequential.

Rapid Application Development (RAD)

Rapid application development is a collection of methodologies that emerged in response to
the weaknesses of waterfall development and its variations. RAD incorporates special
techniques and computer tools to speed up the analysis, design, and implementation phases in
order to get some portion of the system developed quickly and into the hands of the users for
evaluation and feedback. CASE (computer-aided software engineering) tools, JAD (Joint
Application Development) sessions, etc. may play a role in RAD. While RAD can improve the
speed and quality of systems development, it may also introduce a problem in managing user
expectations. As systems are developed more quickly and users gain a better understanding of
information technology, user expectations may dramatically increase and system requirements
may expand during the project (sometimes known as scope creep or feature creep).
RAD may be conducted in a variety of ways.

Iterative development Methodology

Iterative development breaks the overall project into a series of versions that are developed
sequentially. The most important and fundamental requirements are bundled into the first
version of the system. This version is developed quickly by a mini-waterfall process, and once
implemented, the users can provide valuable feedback to be incorporated into the next version
of the system. (See Figure 3).

Advantages:

 Iterative development gets a preliminary version of the system to the users quickly so
that business value is provided.
 Since users are working with the system, important additional requirements may be
identified and incorporated into subsequent versions.

Disadvantages:

 Users start working with a system that is intentionally incomplete.

 Users must accept that only the most critical requirements of the system will be
available in the early versions.
  Users must be patient with the repeated introduction of new system versions.

Figure 3: Iterative Development Methodology

System Prototyping
System prototyping performs the analysis, design, and implementation phases concurrently in
order to quickly develop a simplified version of the proposed system and give it to the users for
evaluation and feedback (See Figure 4). The system prototype is a “quick and dirty” version of
the system and provides minimal features. Following reaction and comments from the users,
the developers reanalyze, redesign, and re-implement a second prototype that corrects
deficiencies and adds more features. This cycle continues until the analysts, users, and sponsor
agree that the prototype provides enough functionality to be installed and used in the
organization.

Advantages:

 System prototyping provides a system for early-users evaluation and reassures users
that progress is being made.
 It is very useful when users have difficulty expressing requirements for the system.

Disadvantages

 Lack of careful, methodical analysis prior to making design and implementation

decisions.
 System prototypes may have some fundamental design limitations that are a direct
result of an inadequate understanding of the system’s true requirements early in the
project.

Figure 4: System Prototyping

Throwaway Prototyping
Throwaway prototyping includes the development of prototypes, but uses the prototypes
primarily to explore design alternatives rather than as the actual new system (as in system
prototyping). As shown in Figure 5, throwaway prototyping has a fairly thorough analysis phase
that is used to gather requirements and to develop ideas for the system concept. A design
prototype is not intended to be a working system. It contains only enough detail to enable
users to understand the issues under consideration. A system that is developed by this type of
methodology probably requires several design prototypes during the analysis and design
phases. Each of the prototypes is used to minimize the risk associated with the system by
confirming that important issues are understood before the real system is built. Once the issues
are resolved, the project moves into design and implementation. At this point, the design
prototypes are thrown away, which is an important difference between this approach and
system prototyping, in which the prototypes evolve into the final system.

Advantages:
Thorough analysis and Design with refining key issues before a system is built.

Usually produces more stable and reliable systems

Disadvantage
Prototypes do not become the final system; therefore it may take longer to deliver the final
system.
Figure 5 Throwaway Prototyping

AGILE DEVELOPMENT
Agile development is a group of programming-centric methodologies that focus on streamlining
the SDLC. Much of the modeling and documentation overhead is eliminated; instead, face-to-
face communication is preferred. A project emphasizes simple, iterative application
development in which every iteration is a complete software project, including planning,
requirements analysis, design, coding, testing, and documentation (See Figure 6). Cycles are
kept short (one to four weeks), and the development team focuses on adapting to the current
business environment. There are several popular approaches to agile development, including:

i. Extreme Programming (XP)

ii. Scrum
iii. Dynamic Systems Development Method (DSDM)

Extreme programming

Extreme programming emphasizes customer satisfaction and teamwork. Communication,

simplicity, feedback, and courage are core values. Developers communicate with customers
and fellow programmers. Designs are kept simple and clean. Early and frequent testing provides
feedback, and developers are able to courageously respond to changing requirements and
technology. Project teams are kept small. An XP project begins with user stories that describe
what the system needs to do. Then, programmers code in small, simple modules and test to
meet those needs. Users are required to be available to clear up questions and issues as they
arise. Standards are very important to minimize confusion, so XP teams use a common set of
names, descriptions, and coding practices. XP projects deliver results sooner than even the RAD
approaches, and they rarely get bogged down in gathering requirements for the system. For
small projects with highly motivated, cohesive, stable, and experienced teams, XP should work
just fine. However, if the project is not small or the teams aren’t jelled, then the likelihood of
success for the XP project is reduced.
Figure 7: Extreme Programming (XP)

Selecting the Appropriate Development Methodology

As the previous section shows, there are many methodologies. The first challenge faced by
project managers is to select which methodology to use. Choosing a methodology is not simple,
because no one methodology is always best. Many organizations have standards and policies to
guide the choice of methodology. You will find that organizations range from having one
“approved” methodology to having several methodology options to having no formal policies at
all. Figure 7 summarizes some important methodology selection criteria

System Development Methodology Selection Criteria

ROLE OF SYSTEM ANALYST

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

designing and implementing information systems. Systems analysts assess the suitability of
information systems in terms of their intended outcomes and liaise with end users, software
vendors and programmers in order to achieve these outcomes. A systems analyst is a person
who uses analysis and design techniques to solve business problems using information
technology. Systems analysts may serve as change agents who identify the organizational
improvements needed, design systems to implement those changes, and train and motivate
others to use the systems.

Role of System Analyst

A systems analyst may:

 Identify, understand and plan for organizational and human impacts of planned systems,
and ensure that new technical requirements are properly integrated with existing
processes and skill sets.
 Plan a system flow from the ground up.
 Interact with internal users and customers to learn and document requirements that are
then used to produce business requirements documents.
 Write technical requirements from a critical phase.
 Interact with software architect to understand software limitations.
 Help programmers during system development, e.g. provide use cases, flowcharts, UML
and BPMN diagrams.
 Document requirements or contribute to user manuals.
 Whenever a development process is conducted, the system analyst is responsible for
designing components and providing that information to the developer.

Attributes of a System Analyst

A system analyst is a person who conducts a methodical study and evaluation of various aspects
related to business to identify the desired objectives and work out procedures to attain them.

The system analyst is a person with unique skills; common sense, a structured framework and a
disciplined approach to solving problems are a part of the analysis. Therefore the analyst
requires a combination of skills, experience, personality and common sense. The fact that a
system is designed for a specific user also means that the analyst must have interpersonal skills.
The different interpersonal skills that a system analyst should have are as follows:

1. Communication Skills: System analyst should have the ability to articulate and speak and
knack of working with all levels of managerial positions of the organization.
2. Understanding: System analyst should have the ability to identify problems and assess their
solution, grasping of company goals and objectives, show sensitivity to the impact of the system
on people at work and understanding their problems,

3. Teaching & selling ideas: System analyst should have the skill to educate other people in the
use of computer systems and selling ideas and promoting innovations in problem solving using
computers.

The various technical skills that a system analyst should have are as follows:

1. Creativity: The analyst should be creative to help the users to model ideas into real plans and
developing candidate systems to match user requirements.

2. Problem Solving & project management: System analyst should have the skill of problem
solving, developing alternative solutions, scheduling, overcome constraints, coordinating team
efforts and managing costs and accounts.

3. Dynamic interface: System analyst should be a perfect blend of both technical and non-
technical skills in functional specifications and general design. He should also have a
questioning attitude and inquiring mind.

4. Thorough knowledge of computers: System analyst should have the knowledge of basics of
computers and business functions.

In addition to these personal qualifications, the system analyst should have proper academic
qualifications in system analysis and design or other computer oriented similar degrees

4.3 Multifaceted of Role of Analyst

A System Analyst is responsible for maintaining organizations computer systems. They analyze
the computer systems in place, troubleshoot issues and procedures, and create a solution. It is
their job to keep the computer systems safe and secure. They will do security, internet updates,
and all computer systems.

Systems analyst is required in order to identify weaknesses, workarounds and solutions on an IT

project. They are experts in analyzing problems and forming solutions.

More so, among the roles an analyst performs are change agent, monitor, architect, psychologist,
salesperson, motivator and politician.

ChangeAgent

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.
It is important, that the user accept change. Analyst can secure user acceptance is through user
participation during design and implementation.

In the role of a change agent, the systems analyst may select various styles to introduce change
to the user organization. The styles range from that of persuader (the mildest form of
intervention) to imposer (the most severe intervention). In between there are the catalyst and
the confronter roles. When the user appears to have a tolerance for change the persuader or
catalyst style is appropriate. On the other hand, when drastic changes are required, it may be
necessary to adopt the confronter or even the imposer style. No matter what style is used, the
goal is same: to achieve acceptance of the candidate system with a minimum of resistance.

Investigator and monitor

In defining a problem, the analyst will collect and put together all the information to determine
why the present system does not work well and what changes will correct the problem. This
work is similar to that of an investigator- extracting the real problems from existing systems and
creating information structures that uncover previously unknown trends that may have a direct
impact on the organization.

Related to the role of investigator is that of monitor. To undertake and successfully complete a
project, the analyst must monitor programs in relation to time, cost, and quantity of these
resources, time is the most important. If time “gets away”, the project suffers from increased
costs and wasted human resources. Implementation will also get delayed.

Architect

As architect an analyst must create detailed physical design of candidate system. He aids users
in formalizing abstract ideas and provides details to build the end product-the candidate
system.

Psychologist

The analyst plays the role of a psychologist in the way he reaches people interprets their
thoughts, assesses their behavior, and draws conclusions from these interactions.
Understanding interfunctional relationships is important. It must be aware of people’s feelings
and be prepared to get around things in a graceful way. The art of listening is important in
evaluating responses and feedback.

Salesperson

Selling change can be crucial as initiating change. Selling the system actually takes place at each
step in the system life cycle. Sales skills and persuasiveness are crucial to the success of the
system.
Motivator

A candidate system must be well designed and acceptable to the user. The analyst role as a
motivator becomes obvious during the first few weeks after implementation and during times
when turn over results in new people being trained to work with the candidate system. The
amount of dedication it takes to motivate users often taxes the analyst’s abilities to maintain
the pace.

Politician

In implementing a candidate system, the analyst tries to appease all parties involves. Diplomacy
and finesse in dealing with people can improve acceptance of the system. In as much as a
politician must have the support of his or her constituency, so is the analyst’s goal to have the
support of the users staff. He or she represents their thinking and tries to achieve their goals
through computerization.

In summary these multiple roles require analysts to be orderly, approach a problem in a logical,
methodical way and pay attention to details.

Place of Analyst in MIS Organization

MIS (management information systems) analysts are individuals who work in an information
systems environment for an organization with the primary responsibility to provide direction
and guidance concerning an organization meeting strategic goals related to processing and
security of data and software application management. The basic requirements for the position
include excellent verbal and written skills and a technical background in systems management.
Among the functions of an analyst in an MIS organization are:

 Creates Information Systems Strategies

An MIS analyst creates strategies for the deployment of information systems or computer
systems concepts. This includes budgeting for equipment, software and personnel
requirements reflected in the annual strategic plan for the organization. Strategies created by
an MIS analyst also reference how data is processed, a review of data processing agreements in
support of other departments and branches in the organization, risk management assessments
and training objectives for IT (information technology) personnel.

 Data Security Structure

The MIS analyst coordinates with the data security officer to establish system policies regarding
security of data and information through computer networks. Policies are established for the
control and management of user ids and passwords that govern access to files, systems
programs and utilities. In most computer programming environments, the analyst creates
partitioning instructions to separate programs that are in production and active programs on
the system.

 Supervises IT Personnel

The MIS analyst is a supervisor of a branch or division with oversight of several positions under
the organizational structure of information systems management. Positions of supervisory
responsibility include computer programmers, data processing operators, data security officers,
project managers and network analysts. The analyst interviews and hires potential employees
for the MIS department and creates or updates job descriptions for positions in an MIS
structure and reviews employee performance reports submitted by supervisors regarding
information technology personnel.

 Coordinates Implementation of Technology

The MIS analyst is responsible for planning and implementing technologies, including
installation of new hardware systems, telecommunications equipment, and network servers
and designing the network topology for an organization. The analyst approves software
versions through program releases to upgrade operating systems and computer programs that
are created in-house by computer programmers.

MIS analysts examine how an organization’s staff uses information, what tools they have
available, and how they want to improve their methods. They then research the best solutions
to existing issues by reading industry literature and consulting with colleagues. Analysts may
recommend simple changes to existing processes so information flow improves. More likely,
however, they implement the latest hardware technology and software applications. They test
their solution to ensure it is working correctly and then train existing staff to work with the new
developments.