CHAPTER THREE

DESIGN METHODOLOGY

INTRODUCTION

With the current trend of software development, a vast number (both generic and customized)

system have been developed using different development methodologies, approaches,

models, and techniques. One of such systems is this online system of current study. This

project is aimed at developing a system that facilitates easy administration and processing of

student complaints and dissatisfaction in Nigerian Universities (Crawford University).

This chapter presents the system design methodologies adopted in the course of the

development of this system.

3.1 SYSTEM ANALYSIS

Systems analysis is the dissection of a system into its component pieces to study how those

component pieces interact and work.

Systems analysis is also the process of examining a business situation for the purpose of

developing a system solution to a problem or devising improvements to such a situation

(Kendall, Kenneth, and Julia Kendall, 2005).

System analysis is a problem solving technique that deals with the breaking down of a system

into its component piece for the purpose of studying how the components of the system

function efficiently and interact to accomplish their individual purpose. It describes what the

system should do to meet the information needs of its users. It is an in-depth study of the end
user information needs that produces functional requirement that are used as the basis for the

design of a new system. It collectively describes the early phases of the system development

and is usually independent of any technology that will be used to implement the system.

Mostly, we do a system analysis in order to perform a system design.

The development of the proposed model is not only depending on how the system works. It

also depends on the working flow process that is being identified and need to be implemented

and followed. The proposed complaint handling model is a method, platform or web-

application to ensure that the complaint process is addressed and handled properly.

3.1.1 SYSTEM INVESTIGATION

It can be seen as a process of examining or inquiring facts into something carefully.

Therefore, from the statement above or definition above, system investigation can be defined

as a method of carrying out feasibility study of a particular organization or environment as to

obtain impediment on the already existing syndrome.

Automating brings about reduction of the less useful job workers in the loading department,

but increases the use of computer, hence high demand of computer operators and analysts.

In system investigation, the analyst plays a major role. He is only concerned with what is

happening in accordance to the organizations policies and practices. The resources used in

the system must be defined. The personal equipment and facilities must be noted in a way

that will portray their relation to the system for these to be done efficiently, the analyst

(researcher) must note the following;-

 i. Analyze the organization chart and determine the actual line of authority.

ii. Verify the procedure manually representing the actual operation and also what

resources are being used.

iii. Prepare a flow chart to reflect the system.

During the process of carrying out this interview, the interviewer has an objective in which he

wants to achieve, and they are as follows:-

i. The advantage of automating the complaint department.

ii. To have a look on already existing complaint forwarding and processing

procedures.

iii. To know the reaction of the staff towards the automation of the department.

During the course of investigation, the research adopts some methods which include:-

Interview method,

Observation method and,

Review of documents.

1. INTERVIEW METHOD

This is a mode of collecting facts through discussion. To make this method successful, the

following techniques were applied by the interviewer.

i. Planning how to approach the interviewee so as not to create inconvenience for him.

ii. Avoid difficult questions.

 iii. Been tactical.

iv. Using of Jargons that the interviewee understood.

v. Interruption of irrelevant answer was applied.

vi. Differentiation between an opinion and fact was made.

2. OBSERVATION METHOD

In this mode of fact collection, the researcher went to offices to observe the workers at work.

Periodic observation (observation at pre-determined time) was made and this type of

observation is known as system observation. In both observations adequate concentration was

given to discover what interviewee was not able to make clear to the researcher.

3. REVIEW OF DOCUMENT

This mode of fact collection involves examination of document used by the university for the

processing and admission of complains and dissatisfaction.

3.2 SYSTEM DESCRIPTION AND ARCHITECTURE

The design and development of this system employs the 3-tier web architecture. The web

based system being developed is based on the Client/Server Architecture. That is, both the

server and the client application are responsible for some sort of processing. In this

architecture, the database and the engine that provides the data services for the database are

located on a machine in a network, and the application requesting data services on another
machine in a network. This application is referred to as the client application; the data

services engine is called the server application. Client/server provides a more efficient

operation in that the amount of network traffic required to perform a particular database

request is significantly less that the same request performed in a file server environment.

Web application is commonly structured as a 3-tier application.

3.2.1 Web Browser

The web browser constitutes the first tier, a middleware engine using some dynamic web

content technology such as Asp.net, PHP, Cold Fusion and JSP. The database is the third tier.

The middle-tier may be multi-tiered. That is, it can be composed of several other servers with

designated responsibilities, hence the over-all architecture is said to be N-tier.

A fundamental rule in 3-tier architecture is that the client has no direct line of communication

with the data tier. That is, all communications are routed through the middleware tier.

The web browser constitutes the client. It is a software application that enables a user to

display and interact with text, images and other information that are located on the web page

or a local area network.

Web browsers also known as thin clients are used to access information on web servers.

Examples of web browser are Microsoft Internet Explorer, Google Chrome, Mozilla Firefox,

Netscape, Opera, Safari, Flock, Rock Melt and Maxthon.

Browsers communicate with web servers using the Hypertext Transfer Protocol (HTTP) to

fetch web pages and it allows web browsers to submit information to web servers as well as

fetch web pages from them. The primary language of browsers is the HTML (Hypertext

Markup Language), which consists of tags that are used to describe a web page. Most
browsers have some level of support for JavaScript and Extensible Markup Language

(XML).

3.2.2 Web Server (Middleware)

The web transactions take place on the servers. The web server is responsible for

communicating with the browser while the database server is responsible for storing the

required information. The web server takes all requests from the clients, responds to the

request and serves the appropriate web pages back to the clients. These languages work with

web servers to interpret requests from clients, process request and interact with other

programs that may be needed to fulfill the transactions and indicate to the web server the

actual page to serve the client.

3.2.3 Database Server

This is a program that provides database services to other computer programs or computers.

Database Management Systems (DBMS) provide functionality to database servers. They are

responsible for storing, retrieving and manipulating the data in the database or other

repositories. The database in use for the system is MySQL 5.5.16. SQL means Structured

Query Language.

3.3 SOFTWARE SPECIFICATIONS

As earlier stated in chapter one, the services required of the proposed system include but are

not limited to the following:

 1. To create an efficient system that can process students complaints.

2. To efficiently gather student/staff complaint through a fully automated system that

not only saves lot of time but also gives fast results.

3. To automate a web based complaint management system so as to eliminate the use

of paper.

In order to provide these services, there is the need to specify both functional and non-

functional requirements of the proposed system.

3.3.1 Functional Requirements

Functional requirements are statements of the services that a system should provide, how the

system should react to particular types of input and the behaviour of the system in predefined

situations.

For the proposed Online Complaint Management System, each complainant must be

registered by the administrator.

Since the proposed system is not going to be only meant for a particular department, it must

be able to multithread with the following departments too; Security department, Welfare

Department, Academics Department and finally, Administrative Department.

3.3.2 Non-Functional Requirements

Non-functional requirement is a requirement that specifies criteria that can be used to judge

the operation of a system, rather than specific behaviors. This should be contrasted with

functional requirements that define specific behavior or functions. The plan for implementing
functional requirements is detailed in the system design. The plan for implementing non-

functional requirements is detailed in the system architecture.

These statements specify how the system services are rendered. The constraints on the

proposed web-based Complaint Management System are:

i. Access to all functions of different profile holders in the system should be granted

only after successful verification and authentication of users (students, operators and

administrator) with usernames and passwords.

ii. All students are uniquely identified by their matriculation numbers.

3.4 SYSTEM DESIGN

System design is a task that focuses on the application of a detailed computer based solution.

It is also called physical design. It is a complementary problem solving technique to system

analysis that resembles a systems component pieces back into complete, improved and

working system. This may involve adding, deleting, and changing pieces relative to the

original system. System design specifies how the system will accomplish the objectives from

system analysis. System design is the structural implementation of the system analysis. It

serves as the overall plan or model that consists of all the specifications about the system, its

form and structure.

3.4.1 System Modeling

System modeling is a graphical representation of a system and what is desired. System

models facilitate improved communication between system users, system analysts, system
designers and system builders. Modeling is an act of building one or more graphical

representations of a system. A model is a description of reality; it is the abstract

representation of some concrete entity. The proposed system model is built using Unified

Modeling Language (UML). The UML is a modeling language which provides a set of

methods that are used to describe a software system in terms of objects/diagrams. It uses

diagrams that provide different perspective views of the system parts. In any development

that aims at producing useful artifacts, the main focus of both analysis and design activities is

on models. A model is quicker and easier to build. A model can evolve as we learn more

about a task or a problem. Also, a model can represent real or imaginary things from any

domain. A useful model has just the right amount of detail and structure and represents only

what is important for the task at hand.

The UML diagrams are listed below:

i. Use Case Diagram

ii. Activity Diagram

3.4.1.1 THE USE CASE DIAGRAM

The UML use case diagram can be used to describe the main processes in a system and the

interactions between the processes (use case) and external systems or individuals, called

actors. Once the use case overview is developed it can be expanded to show more detail

including sub processes and processes that are sometimes added to other processes. To define

an interaction between a use case and an actor, you write a generic scenario called the use

case description. The use case description is subsequently used to generate specific scenarios

and interaction diagrams as seen in Fig 3.4.1.1

 Complaint
Register
Book
Operator (Station)

Web Complaint

Forward Sub Complaint

Close

Forward GCO (Division) Assign

Dept Off.

Forward Reject

Reply

Escalate Feedback
Punish

GCO (Zone, Board)

Instruct

Represents System functionality as a Use Case.

GCO Grievance Cell Officer

FIG 3.4.1.1 USE CASE DIAGRAM

3.4.1.2 ACTIVITY DIAGRAM

An activity diagram describes activities and flows of data or decisions between activities. An

activity diagram usually provides a wider view of business processes that occur within a

system as seen in Fig 3.4.1.2

STATION DIVISION Dept. ZONE Dept. Rly Board

Customer Officer Officer

1. Complaint

2. Register and forward to division

3. Assign to dept.

4. Feedback (not final)

5. Escalate to Zone

6. Escalate to Board

7. Instruction from Board

8. Instruction from Zone

9. Assign to dept.

9. Feedback (not final)

10. Issue Penalty to Concerned department

11. Close the complaint and send an ack. to customer

FIG 3.4.1.2 ACTIVITY DIAGRAM

3.4.1.3 DATA FLOW DIAGRAM

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an

information system, modeling its process aspects. Often they are a preliminary step used to

create an overview of the system which can later be elaborated. DFDs can also be used for

the visualization of data processing (structured design).

 CUSTOMER

2
UNIT REGISTER A

COMPLAINT FORWARD

ASSIGN

5
4

CLOSE
FEEDBACK
3.4.1.4 SYSTEM FLOWCHART

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as

boxes of various kinds, and their order by connecting these with arrows.
 START

INPUT

UNITNAME , USERNAME

AND PASSWORD AND

VALIDATE
VALID

UNITNAME

,
DISPLAYS AGAIN INPUT
USERNAM
ALL PENDING UNITNAME , USERNAME
E
COMPLAINTS AND PASSWORD AND
AND VALIDATE
REGISTER PASSWOR

COMPLAINT D
PRINT AN
/DEFICIENC

SEARCH Y ACKNOWLEDGEMENT

FOR A EXTERNAL

COMPLAINT
COMPLAIN FORWARD A
/DEFICIENC
REPORT T
COMPLAINT
Y
ASSIGN A COMPLAINT
GENERATIO
GENERATE A
N
REPORT/COMPARATIVE
PROVIDE
DBA ANALYSIS
LOGOUT
FEEDBACK
OPERATION ADD/MODIFY/DELETE

S THE FIELDS OF TABLES

3.5 BENEFITS OF THE PROPOSED SYSTEM DESIGN

1. Improve students security and welfare administration.

2. Scalability

3. Flexibility

4. High level of system integrity

5. Easier implementation

3.6 USERS OF THE PROPOSED SYSTEM

The main users of the system are:

i. Students

ii. Operators

iii. Administrators

3.6.1 Students

The registered students can log into the system, lodge their complaints and the system will

automatically categorize the complaint into the department that is responsible for taking

action on such complaint and hence, process the complaint and stores the complaint, whereby

administrators and operators will be able to act upon it and giving it priority which will be at

levels.
3.6.2 Operators

These people oversee the running of computer systems, ensuring that the machines are

running and physically secured. Operators in this case, are the people who will access the

students complaints, process the complaints and forward the complaints to relevant level for

further actions to be taken.

3.6.3 Administrator

In addition to user management, the administrator is a person employed to maintain and

operate a computer system and/or network.

Administrator in this proposed system primary function is to edit, delete and keep records of

volatile complaints made by students, staff or visitors. However, Administrators too can

manipulate the system itself because of their adequate technical know-how and privileges.
 Add users to the system

Edit system users

Administrator
Add courses, departments
and colleges

Add, Edit and Remove

Complains

Edit system variables and

information

Manages the operators

Manages the students

Updates the program

regularly

USE CASE DIAGRAM SHOWING ADMINISTRATOR PRIVILEGES

3.7 DATABASE DESIGN

A database is any collection that is specially organized for rapid search and retrieval by a

computer. Databases are structured to facilitate the storage, retrieval, modification, and

deletion of data in conjunction with various data-processing operations. A database

management system (DBMS) extracts information from the database in response to queries.

The MySQL database for this system has ten (10) tables in it:
 TABLE DEFINITIONS

Table 3.7.1

Active Semester Table

Field Type Null

id int(11) No

semester varchar(50) latin1_swedish_ci No

session varchar(25) latin1_swedish_ci No

status tinyint(1) No

dateset date No

Table 3.7.2

Colleges Table

Field Type Null

id int(11) No

college_name varchar(100) latin1_swedish_ci No

Table 3.7.3

Complain Table
 Field Type Null

id int(11) No

cid int(11) No

concern varchar(30) latin1_swedish_ci No

cother varchar(20) latin1_swedish_ci No

name varchar(50) latin1_swedish_ci No

status varchar(30) latin1_swedish_ci No

sother varchar(20) latin1_swedish_ci No

nnotified varchar(50) latin1_swedish_ci No

witness varchar(50) latin1_swedish_ci No

dept varchar(25) latin1_swedish_ci No

idate date No

cdate datetime No

explain text latin1_swedish_ci No

active tinyint(1) No

comment text latin1_swedish_ci No

Table 3.7.4

Courses Table
 Field Type Null

id int(11) No

course_name varchar(100) latin1_swedish_ci No

course_code varchar(15) latin1_swedish_ci No

dept_id int(11) No

least_level_id int(11) No

lecturer_id int(11) No

units int(11) No

exam tinyint(1) No

instructions text latin1_swedish_ci No

nos int(11) No

Table 3.7.5

Departments Table

Field Type Null

id int(11) No

dept_name varchar(50) latin1_swedish_ci No

college int(11) No
Table 3.7.6

Levels Table

Field Type Null

id int(11) No

level varchar(25) latin1_swedish_ci No

Table 3.7.7

Operators Table

Field Type Null

id int(11) No

staffID varchar(11) latin1_swedish_ci No

title varchar(5) latin1_swedish_ci No

firstname varchar(25) latin1_swedish_ci No

lastname varchar(25) latin1_swedish_ci No

role varchar(20) latin1_swedish_ci No

phone varchar(25) latin1_swedish_ci No

image varchar(100) latin1_swedish_ci No

dateset datetime No

valid_session int(11) No
Table 3.7.8

Role Table

Field Type Null

id int(5) No

role_name varchar(30) latin1_swedish_ci No

Table 3.7.9

Students Table

Field Type Null

id int(11) No

title varchar(30) latin1_swedish_ci No

firstname varchar(25) latin1_swedish_ci No

middlename varchar(25) latin1_swedish_ci No

lastname varchar(25) latin1_swedish_ci No

level varchar(25) latin1_swedish_ci No

matric varchar(15) latin1_swedish_ci No

 Field Type Null

valid_session int(11) No

dept int(11) No

college int(11) No

email varchar(100) latin1_swedish_ci Yes

phone varchar(25) latin1_swedish_ci Yes

address varchar(255) latin1_swedish_ci Yes

dob date Yes

sex varchar(6) latin1_swedish_ci Yes

state varchar(100) latin1_swedish_ci Yes

nationality varchar(25) latin1_swedish_ci Yes

sponsor varchar(100) latin1_swedish_ci Yes

sponsor_address varchar(255) latin1_swedish_ci Yes

sponsor_phone varchar(25) latin1_swedish_ci Yes

sponsor_email varchar(100) latin1_swedish_ci Yes

occupation varchar(100) latin1_swedish_ci Yes

image varchar(100) latin1_swedish_ci Yes

dateset date No
Table 3.7.10

Users Table

Field Type Null

id int(11) No

username varchar(15) latin1_swedish_ci No

password varchar(1000) latin1_swedish_ci No

role varchar(25) latin1_swedish_ci No

orole varchar(25) latin1_swedish_ci No

datecreated date No

lastlogin date No

no_of_visits int(11) No

online binary(1) No