CSC 411

System Analysis and Design

COURSE CONTENT
System Concept; System Development Life Cycle
System Analysis: Fact gathering Techniques, data flow diagrams, Process description data
modeling.
System Design: Structure Charts, form designs, security, automated Tools for design. UML
modelling

MODULE ONE

1.1 Overview of System Analysis and Design

Systems Analysis and Design is a field in which students learn approaches and different
techniques for building system more effectively and efficiently.

This materials provides a basic understanding of system characteristics, system design, and
its development processes. It is a good introductory guide that provides an overview of all
the concepts necessary to build a system.

Systems development is systematic process which includes phases such as planning,

analysis, design, deployment, and maintenance. Here, in this material, we will primarily
focus on:

 Systems analysis
 Systems design

1.1.1 Systems Analysis

It is a process of collecting and interpreting facts, identifying the problems, and

decomposition of a system into its components.

1|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
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.

1.1.2 Systems Design

It is a process of planning a new business system or replacing an existing system by

defining its components or modules to satisfy the specific requirements. Before planning,
you need to understand the old system thoroughly and determine how computers can best
be used in order to operate efficiently.

System Design focuses on how to accomplish the objective of the system.

System Analysis and Design (SAD) mainly focuses on −

 Systems
 Processes
 Technology

1.1.3 What is a System?

The word System is derived from Greek word Systema, which means an organized
relationship between any set of components to achieve some common cause or objective.
A system is “an orderly grouping of interdependent components linked together according to a plan
to achieve a specific goal.”

Constraints of a System
A system must have three basic constraints −

 A system must have some structure and behavior which is designed to achieve a
predefined objective.
 Interconnectivity and interdependence must exist among the system components.
 The objectives of the organization have a higher priority than the objectives of its
subsystems.
For example, traffic management system, payroll system, automatic library system, human
resources information system.

2|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
1.2 Properties of a System
A system has the following properties −

Organization

Organization implies structure and order. It is the arrangement of components that helps to
achieve predetermined objectives.

Interaction

It is defined by the manner in which the components operate with each other.

For example, in an organization, purchasing department must interact with production

department and payroll with personnel department.

Interdependence

Interdependence means how the components of a system depend on one another. For
proper functioning, the components are coordinated and linked together according to a
specified plan. The output of one subsystem is the required by other subsystem as input.

Integration

Integration is concerned with how a system components are connected together. It means
that the parts of the system work together within the system even if each part performs a
unique function.

Central Objective

The objective of system must be central. It may be real or stated. It is not uncommon for an
organization to state an objective and operate to achieve another.

The users must know the main objective of a computer application early in the analysis for
a successful design and conversion.

3|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
1.3 Elements of a System
The following diagram shows the elements of a system −

Figure 1.1: Element of a System

Outputs and Inputs

 The main aim of a system is to produce an output which is useful for its user.
 Inputs are the information that enters into the system for processing.
 Output is the outcome of processing.
Processor(s)
 The processor is the element of a system that involves the actual transformation of
input into output.
 It is the operational component of a system. Processors may modify the input either
totally or partially, depending on the output specification.
 As the output specifications change, so does the processing. In some cases, input is
also modified to enable the processor for handling the transformation.

Control
 The control element guides the system.
 It is the decision–making subsystem that controls the pattern of activities governing
input, processing, and output.
 The behavior of a computer System is controlled by the Operating System and
software. In order to keep system in balance, what and how much input is needed is
determined by Output Specifications.
Feedback
 Feedback provides the control in a dynamic system.
 Positive feedback is routine in nature that encourages the performance of the system.
 Negative feedback is informational in nature that provides the controller with
information for action.

4|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
Environment
 The environment is the “supersystem” within which an organization operates.
 It is the source of external elements that strike on the system.
 It determines how a system must function. For example, vendors and competitors of
organization’s environment, may provide constraints that affect the actual
performance of the business.
Boundaries and Interface
 A system should be defined by its boundaries. Boundaries are the limits that identify
its components, processes, and interrelationship when it interfaces with another
system.
 Each system has boundaries that determine its sphere of influence and control.
 The knowledge of the boundaries of a given system is crucial in determining the
nature of its interface with other systems for successful design.

1.4 Types of Systems

The systems can be divided into the following types −
1.4.1 Physical or Abstract Systems
 Physical systems are tangible entities. We can touch and feel them.
 Physical System may be static or dynamic in nature. For example, desks and chairs
are the physical parts of computer center which are static. A programmed computer
is a dynamic system in which programs, data, and applications can change according
to the user's needs.
 Abstract systems are non-physical entities or conceptual that may be formulas,
representation or model of a real system.
1.4.2 Open or Closed Systems
 An open system must interact with its environment. It receives inputs from and
delivers outputs to the outside of the system. For example, an information system
which must adapt to the changing environmental conditions.
 A closed system does not interact with its environment. It is isolated from
environmental influences. A completely closed system is rare in reality.
1.4.3 Adaptive and Non Adaptive System
 Adaptive System responds to the change in the environment in a way to improve
their performance and to survive. For example, human beings, animals.
 Non Adaptive System is the system which does not respond to the environment. For
example, machines.
1.4.4 Permanent or Temporary System
 Permanent System persists for long time. For example, business policies.
 Temporary System is made for specified time and after that they are demolished. For
example, A DJ system is set up for a program and it is dissembled after the program.

5|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
1.4.5 Natural and Manufactured System
 Natural systems are created by the nature. For example, Solar system, seasonal
system.
 Manufactured System is the man-made system. For example, Rockets, dams, trains.
1.4.6 Deterministic or Probabilistic System
 Deterministic system operates in a predictable manner and the interaction between
system components is known with certainty. For example, two molecules of
hydrogen and one molecule of oxygen makes water.
 Probabilistic System shows uncertain behavior. The exact output is not known. For
example, Weather forecasting, mail delivery.
1.4.7 Social, Human-Machine, Machine System
 Social System is made up of people. For example, social clubs, societies.
 In Human-Machine System, both human and machines are involved to perform a
particular task. For example, Computer programming.
 Machine System is where human interference is neglected. All the tasks are
performed by the machine. For example, an autonomous robot.
1.4.8 Man–Made Information Systems
 It is an interconnected set of information resources to manage data for particular
organization, under Direct Management Control (DMC).
 This system includes hardware, software, communication, data, and application for
producing information according to the need of an organization.
Man-made information systems are divided into three types −
 Formal Information System − It is based on the flow of information in the form of
memos, instructions, etc., from top level to lower levels of management.
 Informal Information System − This is employee based system which solves the
day to day work related problems.
 Computer Based System − This system is directly dependent on the computer for
managing business applications. For example, automatic library system, railway
reservation system, banking system, etc.

1.5 Systems Models

1.5.1 Schematic Models
 A schematic model is a 2-D chart that shows system elements and their linkages.
 Different arrows are used to show information flow, material flow, and information
feedback.
1.5.2 Flow System Models

6|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
  A flow system model shows the orderly flow of the material, energy, and
information that hold the system together.
 Program Evaluation and Review Technique (PERT), for example, is used to abstract
a real world system in model form.
1.5.3 Static System Models
 They represent one pair of relationships such as activity–time or cost–quantity.
 The Gantt chart, for example, gives a static picture of an activity-time relationship.
1.5.4 Dynamic System Models
 Business organizations are dynamic systems. A dynamic model approximates the
type of organization or application that analysts deal with.
 It shows an ongoing, constantly changing status of the system. It consists of −
o Inputs that enter the system
o The processor through which transformation takes place
o The program(s) required for processing
o The output(s) that result from processing.
o

1.6 Categories of Information

There are three categories of information related to managerial levels and the decision
managers make.

Figure 1.2: Categories of Information

7|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
1.6.1 Strategic Information
 This information is required by topmost management for long range planning
policies for next few years. For example, trends in revenues, financial investment,
and human resources, and population growth.
 This type of information is achieved with the aid of Decision Support System (DSS).
1.6.2 Managerial Information
 This type of Information is required by middle management for short and
intermediate range planning which is in terms of months. For example, sales
analysis, cash flow projection, and annual financial statements.
 It is achieved with the aid of Management Information Systems (MIS).
1.6.3 Operational information
 This type of information is required by low management for daily and short term
planning to enforce day-to-day operational activities. For example, keeping employee
attendance records, overdue purchase orders, and current stocks available.
 It is achieved with the aid of Data Processing Systems (DPS).

8|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
 MODULE TWO

Systems Development
Process
2.1 System Development Life Cycle - (SDLC)
This chapter covers the following topics:

 Information systems overview;

 System development lifecycle;
 Preliminary investigation;
 Analysis and requirements capture;
 Design;
 Implementation;
 Maintenance;
 Methodology, tools and techniques.

2.1 Information System Overview

 An information system may be defined as a set of components (e.g., people, hardware,
software, tools, procedures, standards, data) all working together to accomplish a set of
goals or objectives. The system receives inputs from the environment and transforms (or
processes) the input to outputs that will be useful for decision-making. A boundary
separates the system from the outside world. Figure 2.1 illustrates an information system.
System developers usually have very little control over the environment. They can however
exercise considerable control within the system.

 An information system consists of several components (or modules) all working together to
accomplish the system’s objectives. The modules interact with one another to perform the
various business functions. For example, the output from one module may become the

9|Page – CSC 411 – SYS TEM ANALYS IS & DES IGN - FOA
input to another module. Each module does a specific task or a set of related tasks. It may
also use data stores (files) to store and/or retrieve information.

Information system
Boundary
Hardware, Software,
Inputs Tools, Procedures, Outputs
Standards, Data,
People

Figure 2.1: Information System Overview

2.2 System Development Life Cycle

 System development is a complex process, and must be well-defined.
The term System Development Life Cycle (SDLC) is defined as a systematic approach
required for the implementation of new or modified Information System.
 It is a conceptual model which includes policies and procedures for developing or
altering systems throughout their life cycles.
 It is usually done in several stages/phases, but just five is presented here – preliminary
investigation, analysis and requirements capture, design, implementation and
maintenance.

Preliminary
investigation

Analysis and
Maintenance requirements
SDLC capture

Implementation Design

Figure 2.2: System Development Life Cycle

10 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 An effective System Development Life Cycle (SDLC) should result in a high quality
system that meets customer expectations, reaches completion within time and cost
evaluations, and works effectively and efficiently in the current and planned
Information Technology infrastructure.
 SDLC is used by analysts to develop an information system. SDLC includes the
following activities:

 requirements
 design
 implementation
 testing
 deployment
 operations
 maintenance

2.2 Phases of SDLC

Systems Development Life Cycle is a systematic approach which explicitly breaks down the
process into phases that are required to implement either new or modified Information
System.

PRELIMINARY

INVESTIGATION

Figure 2.3: SDLC Development Phases

11 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
2.2.1 Preliminary Investigation
 In this phase, the system analyst (with the cooperation of the customer) investigates
the current or existing system to determine if the system is adequate (perhaps only
needing some minor modifications) or there is a need for a new system.

 If the analyst is convinced that there is a need for a new system then this phase will
look into its feasibility – whether it is feasible from the financial, technical, social
and legal points of view.

 If the proposed system is not feasible, it is dropped and the system development
stops. However, if the analyst feels that there is definitely a need for the system and
that the system is feasible, system development moves on to the next phase.

2.2.2 Analysis & Requirements Capture Phase

 In this phase, the current or existing system is analyzed in greater detail to
determine what it does and why it is not satisfactory. The analyst studies the system
to gain an in-depth knowledge about the system – inputs, processing, storage,
outputs – to determine the problem areas. The analyst will typically use a
combination of fact-finding techniques such as document gathering (organizational
charts, program code, and procedures and standards manuals), observation,
questionnaire and interviews.

 To get detailed information about the system, the analyst will typically ask probing
questions that start with what, why, when, where, who and how? The analyst
analyses the responses to these questions to determine the bottlenecks or problems
inherent in the system.

 To analyze the system, the analyst may use techniques such as Data Flow Diagram
(DFD) and Entity-Relationship Diagram (ERD). These techniques will be discussed
later in this material.

 A Data Flow Diagram (DFD) is used to present this information graphically. It uses
the following four symbols:

DFD Symbol Meaning

Data flow

12 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 Input / Output

Process

Storage

Figure 2.4: Data Flow Diagram

Entity-Relationship Diagram (ERD) – Relate the functional enties and dfine the
relationship between them

Figure 2.5: Entity Relationship Diagram

 One way to analyze the system is to look at all the system modules and for each
module, determine what (input) goes into that module, what processing

13 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 (transformation) takes place, what data stores (files) are used, and where the output
goes.

 The analysis will reveal shortcomings in the existing system in meeting current and
future requirements.

 Once the analysis is completed, the analyst (in consultation with the customer)
validates and establishes the system requirements.

 System requirements fall into two categories – functional and non-functional

requirements.

Functional requirements. This refers to functional input and output items (e.g., data
entry and validation, computations, queries and reports) that the client needs in order to
do business. The client will not accept the new system unless it includes all these
functions.

Non-functional requirements. This refers to functions such as security, performance,

usability, portability etc) that are essential but which are not directly related to the
business functions. The client will also insist that the system has these features.

 The final system will be evaluated against these requirements. All the functional
requirements as well as all or most of non-functional requirements must be present
in the new system before the client will accept the system.

 A system that does not meet the requirements will be considered a failure.

2.2.3 Design Phase

 In this phase, the analyst proposes a design that will solve the client’s problems (or
seize a business opportunity).

 System design is concerned with how the final system will work.

 It includes process design, database design, interface design and network design as
shown below.

14 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 Process Database Interface Network

Design Design Design Design

 There are several parts in system design: process design, database design, interface
design and network design.

 System design includes all these parts except possibly the last one, which is not
needed for a stand-alone system.

(i). Process Design

 Process design describes how modules (or functions) of an information system are
structured (organized) and how they will interact with one another to perform the
various business tasks.

 One approach typically used is the decomposition approach.

 In this approach, the system (or application) is decomposed (or broken up) into
several high-level modules. Then each of these high-level modules is further broken
up into lower-level modules, and so on.

 This is done so that each module is small and manageable, and does a specific task
(or a set of related tasks).

 A Structure Chart (SC) is typically used to show the hierarchy of the modules in a
system. The higher-level modules describe higher-level functionality while the
lower-level modules describe the detailed functionality. The higher-level modules
invoke or call the lower-level modules to perform needed tasks.
A system must also show where the sources of data, who or which system will
eventually receive the output, how the data flows through the system (processes),
what each process does to the data and what files or data stores it will use.

The logic for each process must also be included. This usually takes the form of Structured
English. Each process describes the input it receives (from the data source or from other
processes), the processing it does, the files it uses, and the output it sends to the destination
or other processes.

Process design thus captures the functionalities of a system. Eventually process design
leads to the production of code.

15 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
(ii). Database Design
Database design is concerned with identifying the business entities relevant to the
application, and how they are related to one another (i.e., the business rules). It is also
concerned with identifying the attributes needed for each of the entities.

 The Entity Relationship Diagram (ERD) is used to present this information

graphically.

 The entities are then converted to a set of a set of tables and their relationships (one-
to-one, one-to-many, etc) established - RM. If the tables are not in normal form, they
are normalized so that they are free from insertion, deletion and update anomalies.
(Data normalization will be discussed in detail later.).

 The main concern in database design is to ensure that the database is in normal form.
However, if performance is critical, there may be a need to de-normalize the
database.

 Databases must be designed so that they maintain entity integrity, domain integrity
and referential integrity.

(iii). Interface Design

Interface design is concerned with how the users will use the functionalities provided in the
system. Typical user interfaces will include menu systems, command buttons, dialog, text,
list, check and combo boxes, option buttons, frames, scroll bars, and image and timer.
Interface design is also concerned with the use of colours, animation, pictures and audio.

Usability is the main concern in interface design. Users must find the interface simple and
easy to use. It must appeal to users, easy to navigate, minimize errors, easy to undo, is
consistent, and causes less strain to the body.

(iv). Network Design

Network design is concerned with the architecture of the system when it is implemented in
a geographically distributed environment. It describes the network architecture/topology,
transmission media, transmission mode, protocols and communications devices (e.g.,
multiplexers, hubs, routers) that are used to transmit data from one node to another.

16 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
2.2.4 Implementation
Implementation is concerned with writing code for the various modules and then testing them for
errors. A suitable language (e.g., Visual Basic, Visual C++, Java) is selected and code is written for
each of the modules. The code is written according to accepted coding standards.

(i). Module Testing

Testing is usually performed in stages. First, each module is tested using appropriate test data. This
is called module or unit testing. There are several approaches available for testing modules such as
statement testing, branch testing and path testing.

(ii). Integration Testing

After all the modules have been successfully tested individually, they are integrated and tested
again to detect any errors that may occur while linking the modules. This is called integration
testing. Again, there are several approaches available to perform integration testing such as bottom-
up, top-down, or a combination of both.

(iii). Functional & Performance Testing

After the integration test is complete, the system is also tested to see if it meets all the functional and
performance requirements. These are called functional testing and performance testing.

After the database has been designed and code for the modules have been written and tested, the
system is ready for installation. The current system (if any) is replaced with the new system. This
may be done using the parallel, phased, pilot or direct approach.

Once installed, the system is said to be in production (i.e., operational).

2.2.5 Maintenance
Although maintenance is not part of system development, it is nevertheless an important phase in
the system development lifecycle (SDLC). Studies have shown that about 60 to 70 percent of all IT
budget goes to maintenance.

Systems undergo changes for several reasons such as errors in the system (not discovered during
testing), new business requirements, need for performance improvement or changes in the
environment. So the system must be modified to accommodate these requirements as and when

17 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
needed throughout its life. This is called system maintenance. That means adequate resources must
be committed to maintain the system until the system becomes obsolete and a new system is built.

SUMMARY

Feasibility Study or Planning

 Define the problem and scope of existing system.
 Overview the new system and determine its objectives.
 Confirm project feasibility and produce the project Schedule.
 During this phase, threats, constraints, integration and security of system are also
considered.
 A feasibility report for the entire project is created at the end of this phase.
Analysis and Specification
 Gather, analyze, and validate the information.
 Define the requirements and prototypes for new system.
 Evaluate the alternatives and prioritize the requirements.
 Examine the information needs of end-user and enhances the system goal.
 A Software Requirement Specification (SRS) document, which specifies the software,
hardware, functional, and network requirements of the system is prepared at the end
of this phase.
System Design
 Includes the design of application, network, databases, user interfaces, and system
interfaces.
 Transform the SRS document into logical structure, which contains detailed and
complete set of specifications that can be implemented in a programming language.
 Create a contingency, training, maintenance, and operation plan.
 Review the proposed design. Ensure that the final design must meet the
requirements stated in SRS document.
 Finally, prepare a design document which will be used during next phases.

18 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
Implementation
 Implement the design into source code through coding.
 Combine all the modules together into training environment that detects errors and
defects.
 A test report which contains errors is prepared through test plan that includes test
related tasks such as test case generation, testing criteria, and resource allocation for
testing.
 Integrate the information system into its environment and install the new system.
Maintenance/Support
 Include all the activities such as phone support or physical on-site support for users
that is required once the system is installing.
 Implement the changes that software might undergo over a period of time, or
implement any new requirements after the software is deployed at the customer
location.
 It also includes handling the residual errors and resolve any issues that may exist in
the system even after the testing phase.
 Maintenance and support may be needed for a longer time for large systems and for
a short time for smaller systems.

19 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
Life Cycle of System Analysis and Design

The following diagram shows the complete life cycle of the system during analysis and
design phase.

Figure 2.6: Life Cycle of System Analysis and Design

20 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 MODULE THREE

DESIGN STRATEGIES

3.1 Approaches to System Design

The two most commonly used approaches for designing systems are the
decomposition or function-based approach and the object-based
approach.

3.1.1: The function-based or decomposition approach is a structured

systems approach. It is a top-down approach that decomposes a system into
a hierarchy of modules such that the higher-level modules describe the
system in general terms while the lower-level modules describe the system
in more specific terms.

It is also referred to as the top-down strategy, uses the modular approach to develop
the design of a system.

In this approach, the system development begins from a high-level (or

general) description and then moves down to a low-level (or detailed)
description. Figure 3.1 illustrates this approach.

Figure 3.1: The function-based or decomposition approach

21 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
In this technique, the highest-level module or main module for developing the
software is identified. The main module is divided into several smaller and simpler
submodules or segments based on the task performed by each module. Then, each
submodule is further subdivided into several submodules of next lower level. This
process of dividing each module into several submodules continues until the lowest
level modules, which cannot be further subdivided, are not identified.

3.1.2: The object-based or composition approach is a bottom-up approach. It

builds or composes a system using small units or modules called objects. The objects
are self-contained modules that encapsulate both data and functions (often called
methods). The objects are self-contained in the sense that data within an object are
manipulated by functions within the object. Higher-level objects are then built using
the lower-level objects. Finally, the entire system is built. Figure 3.2 illustrates this
approach.

Figure 3.2: The object-based or composition approach

22 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
The object-oriented approach uses the Unified Modelling Language or UML (due
to Booch, Jacobson and Rumbaugh) to specify the various aspects of a system. The
UML is a specification language; it is used to specify the different aspects of a
system. It has its own notations and covers all the phases.

Bottom-Up Strategy follows the modular approach to develop the design of the
system. It is called so because it starts from the bottom or the most basic level
modules and moves towards the highest level modules.

In this technique,

 The modules at the most basic or the lowest level are identified.
 These modules are then grouped together based on the function performed by
each module to form the next higher-level modules.
 Then, these modules are further combined to form the next higher-level
modules.
 This process of grouping several simpler modules to form higher level
modules continues until the main module of system development process is
achieved.

3.2 Good Design Characteristics

A good design has several characteristics. These include modularity, cohesion and
low coupling.

3.2.1 Modularity

A system is said to be modular if it is decomposed (i.e., broken up) into simpler,

well-defined modules and inter-modular interfaces. The reason why modularity is
desirable is because a system that is modular is easy to understand, delegate, code,
test, document and maintain.

23 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
3.2.2 Coupling
Coupling refers to the degree of dependency that exists between modules. Two
modules are said to be tightly coupled if each depends on the other for its proper
functioning. That means a bug in one module may affect or infect the other module.
If one module is modified, the other may also need to be modified. Thus, high
coupling between modules should be avoided. System developers should build
modules that are loosely coupled.

There are several levels or types of coupling:

(i). Data coupling. Two modules are said to be data coupled if they only
communicate with one another by passing data. Other than communicating via data,
the two modules are independent; each performs its own functions irrespective of
how or what the other module does. When two modules are data coupled, it is
important to ensure that only useful data are passed. This will help to minimize the
dependency. Passing unnecessary or tramp data will increase the dependency,
especially when making changes.

(ii). Stamp coupling. Two modules are said to be stamp coupled if their data
communication takes the form of an entire data structure or record. Stamp coupling
may result in passing redundant or tramp data, which will increase the dependency.

(iii). Control coupling. Two modules are said to be control coupled if their
dependency is based on passing control information or flags. Control coupled
modules represent a higher level of dependency since they need to coordinate with
one another by passing control information.

24 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
(iv). Common coupling. Two modules are said to be common coupled if they both
use the same global data or variables (e.g., the values of variables declared before the
main() function in a C/C++ program). Common coupled modules also represent a
higher level of dependency as any inadvertent modification of these data by one
module can cause problems to other modules.

(v). Content coupling. Two modules are said to be content coupled if one module
modifies the contents of the other module (e.g., a module using a pointer to modify
the value of variable in another module in a C/C++ program). Content coupling
represents the highest level of dependency.

The above types are ordered from the best (loosely coupled) to the worst (tightly
coupled) with data coupling having the least dependency and content coupling
having the highest dependency.

Quality checks for coupling can be performed on modules appearing in the DFD or
Structure Chart.

3.2.3 Cohesion

A module is said to be cohesive if all the instructions in the module are aimed at
accomplishing a single task or a small set of related tasks (i.e., the instructions are
functionally related). A cohesive module is easy to understand, code, debug,
document and maintain. A module that is not cohesive, i.e., one that performs
several different tasks) is more difficult to understand, code, debug, document and
maintain.

25 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
There are several levels or types of cohesion (from the most desirable to the least
desirable):

(i). Functional cohesion. Refers to a module whose instructions are functionally

related, i.e., they work together to accomplish a single well-defined function. An
example of a functionally cohesive module would be one that make enquiries, adds,
deletes and modifies customer records.

(ii). Sequential cohesion. Refers to modules whose instructions are input-output

related, i.e., where the output from one instruction becomes the input to the next
instruction, and so on. An example of sequential cohesion would be a module that
reads data from employee time card, validates the data, computes the gross pay,
computes the net pay, and prints the cheque. Although this type of cohesion is not
serious, reuse is weakened because the module bundles instructions that perform
several functions.

(iii). Communicational cohesion. Refers to modules whose instructions accomplish

several tasks using the same information. An example of communicational cohesion
would be a module that reads customer records, make enquiries, and updates the
records. It is better to separate the instructions and put them in separate modules so
that they are easier to maintain.

(iv). Procedural cohesion. Refers to modules whose instructions accomplish several

different tasks but are combined because there is a specific order in which the tasks
are to be completed. As in the case of communicational cohesion, it is better to
separate the instructions and put them in separate modules so that they are easier to
maintain.

26 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
(v). Temporal cohesion. Refers to modules whose instructions are grouped
together because of time factor. An example of temporal cohesion would be a
module that performs start-up operations such as displaying a greeting message,
declaring and initialling variables, and opening files.

(vi). Logical cohesion. Refers to modules whose instructions accomplish logically

similar functions. An example of logical cohesion would be a module that performs
string processing functions, such as copying and concatenating strings.

(vii). Coincidental cohesion. Refers to modules whose instructions have little or no

relationship with one another. This is the worst form of cohesion and should be
avoided.

Quality checks for cohesion can be performed on modules in the DFDs or Structure
Charts.

Object-oriented designs are generally superior to function-based designs in terms of

design quality (as well as software reusability) as they generally produce modules
that are highly modular, cohesive and which have low coupling.

3.3 Factors Affecting System Complexity

To develop good quality of system software, it is necessary to develop a good

design. Therefore, the main focus on while developing the design of the system is
the quality of the software design. A good quality software design is the one, which
minimizes the complexity and cost expenditure in software development.
The two important concepts related to the system development that help in
determining the complexity of a system are coupling and cohesion.

27 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
3.3.1 Coupling
Coupling is the measure of the independence of components. It defines the degree of
dependency of each module of system development on the other. In practice, this
means the stronger the coupling between the modules in a system, the more difficult
it is to implement and maintain the system.
Each module should have simple, clean interface with other modules, and that the
minimum number of data elements should be shared between modules.
(i). High Coupling
These type of systems have interconnections with program units dependent on each
other. Changes to one subsystem leads to high impact on the other subsystem.

Figure 3.3: Highly coupling component

(ii). Low Coupling

These type of systems are made up of components which are independent or almost
independent. A change in one subsystem does not affect any other subsystem.

28 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
Figure 3.4: Low coupling component

(iii). Coupling Measures

 Content Coupling − When one component actually modifies another,then the
modified component is completely dependent on modifying one.
 Common Coupling − When amount of coupling is reduced somewhat by
organizing system design so that data are accessible from a common data
store.
 Control Coupling − When one component passes parameters to control the
activity of another component.
 Stamp Coupling − When data structures is used to pass information from one
component to another.
 Data Coupling − When only data is passed then components are connected
by this coupling.

3.3.2 Cohesion
Cohesion is the measure of closeness of the relationship between its components. It
defines the amount of dependency of the components of a module on one another.
In practice, this means the systems designer must ensure that −
 They do not split essential processes into fragmented modules.

29 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
  They do not gather together unrelated processes represented as processes on
the DFD into meaningless modules.
The best modules are those that are functionally cohesive. The worst modules are
those that are coincidentally cohesive.

The worst degree of cohesion

Coincidental cohesion is found in a component whose parts are unrelated to

another.

 Logical Cohesion − It is where several logically related functions or data

elements are placed in same component.
 Temporal Cohesion − It is when a component that is used to initialize a
system or set variables performs several functions in sequence, but the
functions are related by timing involved.
 Procedurally Cohesion − It is when functions are grouped together in a
component just to ensure this order.
 Sequential Cohesion − It is when the output from one part of a component is
the input to the next part of it.

30 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 MODULE 4
Methodology, Tools & Techniques

System development involves selecting suitable methodology, tools and techniques.

Methodology System
Tools
Developmen

Techniques

Figure 4.1: Methodology, Tools & Techniques

4.1 Methodology. The client may specify which methodology (e.g., structured,
object-oriented) to use. Each methodology has its own strengths and weaknesses. So
the client and developer must discuss and select a methodology that is suitable for
the application and the organization. The methodology selected may determine
which tool or techniques to use.

4.1.1 : Structured Design

Structured design is a data-flow based methodology that helps in identifying the

input and output of the developing system. The main objective of structured design
is to minimize the complexity and increase the modularity of a program. Structured
design also helps in describing the functional aspects of the system.

31 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
In structured designing, the system specifications act as a basis for graphically
representing the flow of data and sequence of processes involved in a software
development with the help of DFDs. After developing the DFDs for the software
system, the next step is to develop the structure chart.

Figure 4.2: Data Flow Diagram

4.1.2: Structured Charts

Structured charts are a recommended tool for designing a modular, top down
systems which define the various modules of system development and the
relationship between each module. It shows the system module and their
relationship between them.
It consists of diagram consisting of rectangular boxes that represent the modules,
connecting arrows, or lines.
 Control Module − It is a higher-level module that directs lower-level
modules, called subordinate modules.
 Library Module − It is a reusable module and can be invoked from more than
one point in the chart.

32 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
Figure 4.3: Structure Chart

4.1.3: Approaches to Design a Structured Chart

We have two different approaches to design a structured chart −
 Transform-Centered Structured Charts − They are used when all the
transactions follow same path.
 Transaction–Centered Structured Charts − They are used when all the
transactions do not follow the same path.

4.1.4: Objectives of Using Structure Flowcharts

 To encourage a top-down design.
 To support the concept of modules and identify the appropriate modules.
 To show the size and complexity of the system.
 To identify the number of readily identifiable functions and modules within
each function.
 To depict whether each identifiable function is a manageable entity or should
be broken down into smaller components.

4.2 Case tools. Case tools (e.g., System Architect, Visible Analyst, Rational Rose)
help system developers to simplify and speed up the system development process.
They also help to reduce the system development cost. Systems developed using

33 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
case tools are usually of a higher quality because they follow accepted standards for
coding and documentation. There are several features available in a case tool such as
diagramming, design checking and code generation.

4.3 Techniques. Techniques such as entity-relationship diagram (ERD), data flow

diagram (DFD), class, use case, and sequence diagrams are used to help us
understand and model a system better. Different methodologies use different
techniques. For example, the structured methodology uses techniques such as ERD
and DFD while the object-oriented methodology uses techniques such as class, use
case, and sequence diagrams.

Exercise 2

2.1 Describe briefly the main features of an information system.

2.2 Discuss briefly the system development life cycle (SDLC).

2.3 What is data modeling? Discuss the technique you would use to model business
data.

2.4 List and discuss the five software life cycle models.

2.5 Why is the purpose of (a) methodology, (b) tool and (c) technique in system
development?

34 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 MODULE FIVE
Software Life Cycle Models

The software development process consists of a set of steps that encompass

methods, tools, and procedures. These steps are often referred to as software
development paradigms or software life-cycle models. A paradigm for software
development is chosen based on the nature of the project and applications, the
methods and tools to be used, and the controls and deliverables that are required.

Software development paradigms are still the subject of research but it is now clear
that a number of different general paradigms (models) of software development can
be identified, each exhibiting strengths and weaknesses, but all having a series of
generic phases in common (definition, development, and maintenance).

In this section, we will look at the following software life cycle models:

 Build & fix model;

 Waterfall model;
 Rapid prototyping model;
 Incremental model;
 Spiral model.

5.1 Build & Fix Model

In this model, the software product is constructed without any design or

specification. The system developers simply build the product that is reworked as
many times as necessary to satisfy the customer. Figure 2.3 illustrates this model.

35 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 Build
first

Modify until the

Customer is

Maintenance

Retirement
Development

Figure 5.1: Build & Fix Model

Although the build and fix model may appear simple and inexpensive, it is totally
unsatisfactory, as the effort and cost of changes during the later stages of system
development as well as during system maintenance will be extremely high. This is
because of the unstructured nature of the model.

5.2 Waterfall Model

The waterfall model was first put forward by Royce in 1970. A modified version of
the model is shown in Figure 2.4. In this model, first the system requirements are
determined and checked by the customers, system developers and the software
quality assurance (SQA) group. Then the specifications for the software are drawn
up. That is, a document is produced stating what the software is expected to do. This
phase is complete once the client and the SQA group approve the software
specification. Once the client has signed off the specification document, the planning
phase commences and a detailed timetable for developing the software is drawn.
This plan is also checked for correctness by the SQA group. After the client has
approved the developer's duration and cost estimates for the software, the design

36 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
phase begins. The software specification document tells what the software must do
while the design document tells how the software will do it.

This model recognizes the importance of backtracking (feedback) and iteration in the
software process. From each stage, the system developer can go back to the previous
stages should there be any errors. For example, during implementation, errors in
specification (e.g., omissions, inconsistencies) may surface requiring backtracking.
The model allows the developer to go back to the requirements and specifications
stage to fix those errors, then redesign the system, and then implement it.

It is obvious that errors detected late are the most expensive to correct. Therefore,
each stage should be properly verified and validated (against user requirements) to
avoid expensive iterations.

The waterfall model has the following main advantages:

 It is easy to identify milestones.

 It is easy to separate one stage from another.

The waterfall model has the following main disadvantages:

 It implies that any stage should be frozen before continuing with the later stages
(resulting in premature requirements, design, coding, etc.)

 It assumes that user requirements can be precisely specified. Unfortunately

customers rarely know precisely what they want, and software engineers rarely
understand the business context of their customers.
 It requires the customer to be extremely patient, as he (or she) has no way of
assessing how far the development process has got until he sees the nearly-
finished product!

 It is still unrealistic. In many software projects strict sequencing of phases is not

actually obeyed. For example, related activities such as coding can take place
during the design phase or integration testing. Milestone dates seem to be
somewhat arbitrary, and a significant part of the activities cross stage boundaries.

37 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 Requirements
analysis and
specification

Design

Implementation

Maintenance

Retirement
Development

Figure 5.2: Waterfall Model

5.3 Rapid Prototyping Model

Rapid prototyping is a process that enables the developer to create a model of the
software to be built. It is a working model that is functionally equivalent to a subset
of the target software. The subset usually consists of data input screens (or forms),
user interface (menus, dialog box, etc) and reports.

In this model, the system developer first builds a rapid prototype and then lets the
customer (or user) interact and experiment with it. If the rapid prototype does what
the customer wants and the customer is happy with it, the developer draws up a
specification with the assurance that the product meets the customer's real needs.

38 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
The software process then continues on with the design and implementation stages.
Figure 5.3 illustrates the rapid prototyping model.

Rapid prototype

Specification

Design

Implementation

Maintenance

Retirement
Development

Maintenance

Figure 5.3: Rapid Prototyping Model

The rapid prototype model can take one of two forms:

A model that depicts human-computer interaction in a form that enables the user to
understand how such interaction will occur.

A working prototype (functional prototype), which implements some subset of the

functions required of the desired software.

39 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
Both types of prototype can be used to help users express their requirements more
precisely.

Prototypes may also be classified as throwaway and evolutionary.

5.4 Throwaway Prototype

The sequence of events for the throwaway prototyping paradigm is illustrated in

Figure 5.4.

Establish Develop Evaluate Specify

*
outline prototype prototype system
specification

**

* At this point the prototype Validate Design &

is thrown away. the system Implement
the system

** The development of the

actual system begins.

Figure 5.4: Throwaway Prototype

Like all approaches to software development, prototyping begins with requirements

gathering. The system developer and customer meet and define the overall
objectives for the software, identify whatever requirements are known, and outline
areas where further definition is mandatory. A quick design then occurs. The quick
design focuses on representation of those aspects of the software that will be visible
to the user (for example, inputs, user interface and outputs). The quick design leads
to the rapid construction of a prototype. The prototype is evaluated by the
customer/user and is used to refine requirements for the software to be developed.
A process of iteration occurs as the prototype is tuned to satisfy the needs of the

40 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
customer while at the same time enabling the developer to better understand what
needs to be done.

The prototype is used as a tool for requirement analysis. After evaluation the
prototype is thrown away and the actual production of the operational system
begins.

The prototyping process and the production process are clearly separated.

The benefits of developing a throwaway prototype early in the software process are:

 Misunderstandings between software developers and users may be identified as

the system functions are demonstrated.

 Missing user services may be detected.

 Difficult-to-use or confusing user services may be identified and refined.

 Software development staff may find incomplete and/or inconsistent

requirements as the prototype is developed.

 A working, albeit limited, system is available quickly to demonstrate the

feasibility and usefulness of the application to management.

The prototype serves as a basis for writing the specification for a production quality
system.

Some of the disadvantages are:

 Sometimes the cost of prototype development represents an unacceptably large

fraction of total cost.

 If the customer and developer do not agree that the prototype is intended to
serve as a mechanism for defining requirements and that it would be discarded
(at least part of it), the customers may force the developer to convert the
prototype to the working system using a few fixes. Similarly, the developer may
become familiar with the prototype and may be reluctant to discard it.

41 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
5.5 Evolutionary Prototyping

In this approach the prototyping and the production process are merged. This
means the prototype gradually evolves to become the final product. This model is
useful in situations when it is extremely difficult (or impossible) to establish detailed
user requirements such as in user interface design and AI applications.

The evolutionary prototyping is shown in Figure 5.5

Develop Build prototype Use prototype

abstract system System

specification

Deliver System
system adequate

Figure 5.5 : Evolutionary Prototyping

5.5.1 The advantages of evolutionary prototyping include:

 Systems are developed and delivered rapidly.

 System development costs are reduced.

 As users are involved in the development, the system is likely to be appropriate

for their real needs (leading to high user satisfaction).

The disadvantages are:

 The development process is not visible to managers. If systems are developed

quickly, it is not cost effective to produce a great deal of system documentation.

42 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
 Systems are usually poorly structured. Continual change tends to corrupt the
software structure. Maintenance is therefore likely to be difficult and costly.

5.6 Incremental Model

Incremental development avoids the problems of constant change, which

characterize evolutionary prototyping. An overall system architecture is established
early in the process to act as a framework. Systems component are incrementally
developed and delivered within this framework. Once these have been validated
and delivered, neither the framework nor the components are changed unless errors
are discovered. User feedback from delivered components, however, can influence
the design of components scheduled for later delivery. Figure 5.6 illustrates the
incremental model.

Define
requirement

Design Build Validate

Specify
system system increment
system
architecture increment
increment

No

Deliver System Validate Integrate

final
Yes system increment
complete
system

Figure 5.6: Incremental Model

43 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
5.6.1 The advantages of the incremental model include:

 Developing software this way avoids the big bang effect. Instead of building
software, the software grows. With the incremental approach the user is closely
involved in planning the next step.

 Attention is first focused on the essential features. Additional functionality is

included only if and when it is needed. Systems thus developed tend to be leaner
and yet provide sufficient support to their users (over-functionality is avoided).

5.6.2 The disadvantages include:

 The requirements tend to be constrained by the architecture that is established.

 Another non-technical problem is that this approach does not fit well with
established contractual models for software developers. Many organizations that
use traditional engineering models for software procurement find it impossible to
adapt to the form of contract, which this approach requires.

5.7 Spiral Model

There is risk involved in all system development. The following are some possible
risks:

 The software does not meet the customer's requirements.

 The software does not meet the desired quality.

 The cost of software exceeds the budget allocated for it.

 The development time exceeds the time budgeted for it.

 Key project personnel leave the project, causing the project to stall or be
abandoned.

 There may be a similar product that is superior to the current product being
developed causing it to be obsolete.

The spiral model aims to minimize risk through the use of prototypes and other
means. Risk analysis is performed at each phase of system development. Before

44 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
commencing each phase, an attempt is made to control or resolve the identified
risks. The project is terminated if it is impossible to resolve all the significant risks
identified.

To illustrate, consider the risk of not capturing the user requirements correctly. This
could be due to lack of competence of the system analyst, lack of user participation,
or absence of requirements’ review. These problems can be overcome by employing
personnel who have good communication skills and who are familiar with the
application, by involving users, and by conducting reviews. Similarly, if there is a
high risk of staff turnover, the organization may preempt the problem by offering
competitive salaries and successful project completion bonus, by making them sign a
contract that they cannot leave the project until the project is completed.

The spiral model is illustrated in Figure 5.7.

Figure 5.7: The Spiral Model

45 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A
5.7.1 Some of the advantages of spiral model are:

 The emphasis on alternatives and constraints encourages reuse of existing

software.
 It increases the quality of the software developed.
 It minimizes the risks such as spending too much or too little time and money on
testing.
 Maintenance is treated simply as another cycle in the spiral model.

5.7.2 Some of the disadvantages of spiral model are:

 The model is suitable only for internal or in-house development of large software
where the client and developer belong to the same organization. This is because if
the significant risks cannot be resolved, the project can be terminated. However,
this is difficult if the client is another organization since this may involve a breach
of contract and legal implications arising from that breach.

 It is not always easy to analyze the project risks accurately. It takes competent
analysts to assess the risks involved.

 The spiral model is applicable only to large-scale software projects. It makes no

sense to perform risk analysis if the cost of performing the risk analysis is high as
relative to the project cost.

This section discussed several software life cycle models. All of them include the
main generic stages, but the logic of the software process is different in each model.

Besides the above mentioned software lifecycle models, there is also the object-
oriented software lifecycle model. The object oriented software process model places
a lot of emphasis on software reusability. Building systems from reusable
components is likely to change the traditional view of the software development
process. The software development process will become one of assembly rather than
one of creation. We encourage the reader to explore this new software process
paradigm on his own.

46 | P a g e – C S C 4 1 1 – S Y S T E M A N A L Y S I S & D E S I G N - F O A