B U S IN E SS

RE Q U I RE M E NT
D O CU M E N T
FOR
INTERNSHIP MANAGEMENT
A P P L I C AT I O N

Submitted by:TEAM SURMURR

1. INTRODUCTION
1.1 Overview
This document provides a comprehensive description on how the project, Development of an
Internship Management System and Two Way Database synchronization was
conducted, explaining specifically how the project was analyze, design and eventually
implemented.The project involves two independent systems (an Internship Management
System and an Online Application Portal) which have been developed separately and how
data is synchronized between their databases.

1.2 Problem Statement

In todays world where information and communication technology systems have become
ubiquitous with different vendors providing various kinds of management software with different
range of applicability, it is rather surprising that internship at AES-SONEL is managed without
one. It is easy to find a staff typing each applicants internship offer letter on Microsoft word.
Given the vast number of applicants that are accepted per month or year, this approach
is laborious. Furthermore, the usage of Microsoft Excel as a database for storing records
further makes the whole process very difficult to manage and unwieldy.
In addition, the manual creation of various reports not only makes the process time consuming
but also is wastage of human resource effort that would have been used to perform other tasks.
Finally, the fact that one cannot apply and check the status of his application online makes
the whole process too demanding for applicants who are required in most cases to travel or go
to the agency just to submit an application.
This project attempts to provide a solution to these problems.

1.3 Report Architecture

This project report is organized into five main chapters. The first is the Literature Review,
the second is the Methodology, the third is the Requirements Analysis and Specification, the
fourth is the Analysis and Design, the fifth is the Implementation.
The Literature Review chapter will give a description of the different methods available to solve
the problem, their merits and demerits.
The Methodology chapter will give a combination of the methods by which the project
was conducted and controlled, and also, the methods in software development that was
applied. Arguments will be provided regarding the method that was chosen.
The Requirements Analysis chapter will provide the requirements of the project, specifically
the functional and non functional requirements of the systems.
The Analysis and Design chapter will provide detail description on how the system
was analyzed. UML diagrams will be used to show the general view of the system. A
description of the User Interface Design, the Information Domain Modeling, the Data Modeling
and the Choice of Architecture will be provided.
The Implementation chapter will provide a description on how the system was
implemented using the output from the analysis and design phase as input. An explanation of
the architecture of implementation will be provided and reasons why the architecture was
chosen.

2.LITERATURE REVIEW
This chapter of the report describes the different methods, architectures and frameworks that
were considered in order to execute the project. Their merits and demerits are also provided.

2.1. Software Development Approach Considered

In order to analyze, design and implement the software system, two approaches to software
development were considered: Object Oriented Approach and Structured Approach.

2.1.1. Object Oriented Approach

The object-oriented approach is a development strategy based on the concept that systems should
be built from a collection of reusable parts called objects

2.1.2. Structured (Traditional) Approach

The structured approach is a development strategy based on the concept that a system should
be separated into two parts: data (modeled using a data model) and functionality (modeled using
a process model). Following the structured approach, you develop applications in which data are
separate from behavior both in the design model and in the system implementation

2.2. Architecture of Implementation

Two software architectural patterns were considered: MVC and 3-Tier architecture.
2.2.1. Model, View and Controller (MVC)
MVC divides a given software application into three interconnected parts (a Model, a View and a
Controller), so as to separate internal representations from the ways that information is presented to
or accepted from the user . Shown below is a diagram of the MVC architectural pattern. It shows a
typical collaboration of the MVC components:

2.2.2. 3-Tier Architecture

Three-tier architecture is a client-server architecture in which the user interfacecomputer data
storage and data access are developedand maintained as independent modules.

2.3. Frameworks Considered

The programming language used for implementing the application is PHP. PHP was chosen
because of the stakeholders specification. In this regard, PHP frameworks were considered: CAKE
PHP

2.4. Database Synchronization Technology

In order to synchronize the databases of both systems,MySQL replication was
considered. MySQL replication enables data from one MySQL database server (the master) to be
replicated to one or more MySQL database servers.Replication is asynchronous by
default. The slaves need not to be connected permanently to receive updates from the master.
Depending on the configuration, the whole database or selected tables within a database can be
replicated. Replication is base on the binary logging mechanism. The MySQL instance operating
as
the
master
writes
updates
as
events
to
the
binary
log.
Slaves are configured to read the binary log from the master and to execute the events in the
binary log on the slaves local database. Each slave must be configured with information about
the master host name, log file name, and position within that file

3. IMPROVEMENTS TO THE EXISTING SYSTEM

This project was initiated mainly to address the problems encountered in the management of
internship at any organization. Below are some of the problems that can be identified with
the current system and the ways that this project attempts to solve.
The manual creation of each applicants internship offer letter using Microsoft Word is a
real wastage of time and human resource effort. The new system will offer the possibility
to generate this letter automatically.
There is lack of data independence and efficient access with the current system. Records stored on
Microsoft Spread sheet in windows may not open properly in Open Office in Linux. The new
system will run on any platform efficiently.
The fact that an applicant cannot apply and track his application online makes the whole process
too demanding for applicants who are forced to go to the agency just to drop an application. Also,
collecting
paper
documents
from
applicants
can
easily
lead
to
the
lost
of applicants documents considering the vast number of applicants who apply regularly.

With the new system, applicants will be able to apply and check the status of their
application online.
Changes made to data cannot easily be seen by other staffs in the same unit and as far as security
is concerned, there is the tendency that people without the right grant or
permission can easily gain access to the stored data if they manage to gain access to the
management staff computer.
The new system will employ a unified database, making it easy for changes to be seen by
everyone. Also, security will be enforced by granting each user a username and password.
The new system will offer the possibility to track and trace human errors. Also, because many
aspects will be automated human error is reduced.
The fact that the current system is not web-based, it is impossible to manage internship
remotely. Since the new system is web-based and will run on a webserver, remote access
is possible via a network.

The problem of data redundancy is also addressed as records will be stored in a well
normalized database. Thus, the new system benefits from the advantages of a database
management system.

4. METHODOLOGY ADOPTED
This chapter provides a combination of the methods by which the project was conducted and
controlled, and also, the software development method applied. In addition, arguments are
provided regarding the methods chosen.
The object oriented approach and the Rational Unified Process (RUP) framework to software
development was adopted to analyze, design and implement the software system. Rationale for
adopting the object oriented approach and RUP framework is explained below:

4.1.Rationale for Adopting the Object Oriented Approach

The Object Oriented Approach was adopted over the Structured Approach because of the
following reasons:

The complexity of this project.

My familiarity with the approach.
Much more suitable for this project.
The dominance of object oriented paradigm and its related technologies in market and
industry.
The technical and theoretical capabilities of the method.
The wide acceptance in industry.
Wide range of development languages and tools to choose from.

4.2.Rationale for Adopting the Rational Unified Process

RUP framework was adopted over the Agile Unified Process (AUP) framework because of the
following reasons:

My familiarity with the framework.

My interest in a detailed and well-defined software process.

RUP was much more suitable for this project. AUP encourages frequent client interaction
and increase collaboration (good idea), which was not the case in this project as clients
were usually very busy. Thus, adopting AUP will have resulted in requirements that will
suffer.

4.3. Reasons for Using PHP CAKE Framework

It has been around for a long time and thus is easy to find answers on the web.
It has a light footprint.

5. REQUIREMENTS ANALYSIS
This chapter explains specifically how the requirements of the software systems were captured. It
provides the functional and non functional requirements of the system.
The requirements for both systems (Internship Management System and Online Application
Portal) were captured in the Requirements Analysis and Definition phase of the project. This was
done via preparation of questionnaires with sample questions for the interns to answer. Also,
meeting sessions were organized for face-to-face conservations with the students. In each
meeting session, audio recorder was used to capture the conversation, hence enforcing better
requirements capture.
After the requirements were captured, a Software Requirement Specification (SRS) document
was produced.
Illustrated below are the functional and non functional requirements of the systems. The
following labels are used to prioritize the requirements:
Must have - Refers to those requirements that together create the core functionalities of the
system.
Should have - Refers to those requirements that although are not part of the core functionalities,
however, they can be very useful and will be implemented if the project schedule allows to do
so.
Nice to have - Refers to those requirements that do not play a main role in the functionality of the
system, at least at the scope of this project; however, they would give more facilities to the users if
the schedule allows them to be implemented.
The labels are given the following prefix: M to Must have, S to Should have and N to Nice to
have

5.1. Functional Requirements

Functional requirements are those features of the system by which the system fulfills the core
responsibility that is expected to accomplish

5.1.1. Functional Requirements of the Internship Management System (IMS)

The table below shows the functional requirements of the IMS. Each requirement is given an
Identification id which will be used as a cross reference in the Use Case Model template to state
which requirements the use case satisfies. Also, the requirements are prioritize in order of
importance.
Table 5.1: Functional Requirements of the Internship Management System

ID Functional Requirements

Importance

To keep and maintain applicants information

To keep and maintain interns information.

To allow management staff notify applicants on the status of their

application via applicants email.

To allow management staff notify applicants on the status of their

application via sms.

To allow management staff or usetr to search applicants by first

name, last name or full name

To allow user to search interns by first name,last name or full name

To allow user to review applicants curriculum vitae, attestation of

registration and recommendation letter

To allow user to print internship offer letter, internship extension letter and
internship attestation in English language.

To allow user modify his personal profile.

10

To allow user generate a pdf version of internship offer letter

11

To keep and maintain internship supervisors information

12

To keep and maintain signatories information

13

To keep and maintain different units in the organization.

14

To allow manager to create or add a new staff to the system.

15

To automatically generate report on the number of applications received

per month, per year or within a given period.

16

To automatically generate report on the number applicants accepted per

month, per year, within a given period, per fields of study, per university,
per unit of welcome and per region

17

To automatically generate report on the number of internship reports

received per month,year or within a given period

18

To automatically generate report on the number of interns evaluated per

month,year,or within a given period of time

19

To provide reports on interns with an excellent remark

20

To provide reports on the number of evaluation files received.

21

To provide a list of applicants whose internship offer letter is ready.

22

To provide a list of interns whose internship attestation is ready

23

To fetch all applications from the Online Application Portal.

24

To synchronize with the Online Application Portal database. Thats, they

must be data exchange between the two databases

25

To allow manager to manage recorded logs.

26

To allow other staff members to view recorded logs.

5.1.2. Functional Requirements of the Online Application Portal (OAP)

The table below shows the functional requirements of the OAP. Each requirement is given an
Identification id which will be used as a cross reference in the Use Case Model template to state
which requirements the use case satisfies. Also, the requirements are prioritize in order of
importance.

Table 5.2: Functional Requirements of the Online Application Portal

ID

Functional Requirements

1
2
3
4
5
6
7
8
9
1
0
1
1
1
2
1
3

To allow applicant to create an account.

Importanc
e

To allow applicant to create an application.

To allow applicant to edit his application.
To allow applicant to save his application and complete it in different sessions
To allow applicant to submit his application.
To allow applicant to check the status of his application.
To allow applicant to modify his personal profile.
To allow applicant to share a testimonial about his internship experience
To allow applicant to recover his password.
To record each successful login attempts in a log file.
To allow administrators to login and manage the portal.
To allow an admin to add a new admin to the system.
To allow an admin to modify his profile.

5.2.1. Non Functional Requirements of the Internship Management

System (IMS)
The table below shows the non functional requirements of the IMS. Each non
functional requirement is indicated in the left column, while the right column indicates
what the system must fulfill to satisfy the requirement.

Table 5.3: Non Functional Requirements of the IMS

Requirement
Description
Category
Performance
The load time for user interface screen shall
Requirement
take no longer than five seconds
The login information shall be verified within
five seconds
Queries shall return results within five
seconds
Design
Constraints
Standard
Compilance

Reliability
Availability

Security

Maintainability

The Internship Management System shall be a webbased application

There shall be consistency in variable name within
the system.
The graphical user interface shall have a consistent
skin
The Internship Mangement System must be highly
reliable and should easily recover from errors
The Internship Management System shall be
available 99.99% of time during normal working
hours
Access to the individual user account will be
protected by a user login screen that requires a
username and password.
To further enhance the security of the system, all
passwords will be stored in encrypted format
Each successful login attempt shall be recorded in a
log file
The system must be easy to maintain

.
5.2.2. Non functional Requirements of the Online Application Portal
(OAP)
The table below shows the non functional requirements of the OAP. Each non
functional requirement is indicated in the left column, while the right column
indicates what the system must fulfill to satisfy the requirement.
Table 5.4: Non Functional Requirements of the OAP
Requirement
Description
Category

Performance
Requirement

Design
Constraints
Standard
Compilance

Reliability

Availability
Security

Maintainability

The load time for user interface screen shall

take no longer than five seconds
The login information shall be verified within
five seconds
Queries shall return results within five
seconds

The Online Application Portal requires each applicant to have

an email address in order to create an account
There shall be consistency in variable name within
the system.
The graphical user interface shall have a consistent
skin
The portal must be highly reliable. Instructive
messages shall be provided at various places to
guide users
The Online Application Portal shall be available all
the time
Access to the individual user account will be
protected by a user login screen that requires a
username and password.
To further enhance the security of the system, all
passwords will be stored in encrypted format
Each successful login attempt shall be recorded in a
log file
The system must be easy to maintain

6. ANALYSIS AND DESIGN

This chapter provides details on how both systems were analyzed and designed. Analysis
refers to understanding the problem while Design refers to coming out with a blueprint of
the system. Also, this chapter shows how the application will meet the requirements
specified in the Software Requirements Specification (SRS) document. It describes
the rationale for design decisions taken and provides a basis for implementation and
unit test. The Object Oriented Approach and Rational Unified Process (RUP) were used
specifically to analyze and design the system. A detail Software Design Document (SDD)
for each system was produced on a separate document. Both documents are included in the
CD attached to this report.
6.1. Use Case Modeling

Use Case Modeling is a powerful modeling technique that can be used to capture and
organize requirements. Use Case Modeling has two perspectives, a Use Case Diagram
and a Use Case Model template which simplifies the explanation of the use case.
Shown below is the use case diagram for both the Internship Management System
(IMS) and Online Application Portal (OAP).

a. Use Case Diagram of the Online Application Portal

Figure 6.1: Use Case Diagram of the Online Application Portal

b. Use Case Diagram of the Internship Management System

Figure 6.2: Use Case Diagram of the Internship Management System

6.2. User Interface Design

User Interface Design describes the functionality of the system from the users perspective.
That is, it explains how the users will use the system to complete all the expected
features and the feedback information that will be displayed for the user. In this case, UML
Activity diagram and State Chart diagram are used to design the UI. Also, following the
diagrams are screen sketches of the major UI elements.
6.2.1. Activity Diagrams
Activity diagrams model the behaviors of a system and the way in which these behaviors
are related in an overall flow of the system

a. Activity Diagram of the Online Application Portal

Figure 6.3: Activity Diagram of the OAP

b. Activity Diagram of the Internship Management System

Figure 6.4: Activity Diagram of the IMS (Behavior of an employee and

the system)
6.2.2. State Chart Diagrams
State Chart diagram illustrates how an element (often a Class) can move between
states, classifying its behavior according to transition triggers and constraining guards.
Other aspects of State Chart diagrams further depict and explain movement and behavior

a. State Chart Diagram of the Online Application Portal

Figure 6.5: State Chart Diagram of the OAP

b. State Chart Diagram of the Internship Management System

Figure 6.6: State Chart Diagram of the IMS (Behavior of the Manager and
the system)
6.3. Information Domain Modeling

Information Domain Modeling models the information domain of the systems. It

shows how different entities (people, things, and data) relate to each other; in other words,
it shows the static structures of the system. It typically shows the kind of things business
people talk about in an organization (Bell). Class diagram was used to model the
information domain for both systems.
6.3.1. Class Diagram of the Online Application Portal
Shown below is a class diagram of the OAP. Detail explanation of each class member
function is found in page 9 and page 20 of the SDD for the OAP.

Figure 6.17: Class Diagram of the OAP

6.3.2. Class Diagram of the Internship Management System

Shown below is a class diagram of the IMS.

Figure 6.18: Class Diagram of the IMS

6.4. Data Modeling

This section describes how the information domain described above is transformed
into data structures. It provides a description of how the major entities are stored,
processed

and organized. Data Modeling in this context is also referred to as

Conceptual Database Design.

Because an object oriented methodology is used to analyze and design the system, the
classes in the information domain modeling are mapped into Entity Relationship Diagram
(ERD). Provided below are Extended Entity Relationship (EER) diagrams for both
systems.
6.4.1. EER Diagram of the OAP

6.4.2. EER Diagram of the IMS

6.5. Physical Database Design

This refers to transforming the conceptual database design to relational tables. Here,
data dictionary is provided showing the different tables of the application.
6.5.1. Data Dictionary for the Internship Management System
Table 6.1: Sessions Table
Column
session_id
ip_address
user_agent
last_activity
user_data

Type
varchar(40)
varchar(45)
varchar(120)
int(10)
Text

Null
No
No
No
No
No

Default
0
0
0

Table 6.2: Academics Table

Column

Type

Null

academic_id
applicant_id

int(11)
int(11)

No
No

institution_name
institution_location
Field
Specialty
Level
degree_program
graduation_date
anticipated_graduation_date
institution_country

varchar(100)
varchar(100)
varchar(255)
varchar(45)
int(2)
varchar(45)
Date
varchar(15)
char(2)

No
No
No
Yes
No
No
Yes
Yes
No

Defaul
t

Links to

Applicants>applicant id

NULL

NULL
NULL

Table 6.3: Applicants Table

Column
applicant_id
last_name
first_name
birth_date
Gender
country_of_residence

Type
int(11)
varchar(50)
varchar(50)
Date
char(1)
char(2

Null
No
No
No
No
No
)No

Default

Phone
Language
Email
City
country_of_citizenship

varchar(25)
varchar(25)
varchar(50)
varchar(255)
char(2)

Yes
No
No
No
No

NULL

account_id

int(11)

Yes

NULL

Links to

Countriescountry code

Countriescountry code

6.5.2. Data Dictionary for the Online Application Portal (OAP)

The tables, Applicants, Academics, Trainings, Applications and Documents for the
Online Application Portal have the same structure as that of the Internship Management
System shown above. These were the tables involved in data synchronization. More tables
for the OAP include the following:
Experience Table - For storing interns internship experience
Account Table - For storing online accounts
Page Table - For storing pages
Subject Table - For storing different subjects
Administrator Table - For storing administrators account

6.6. Choice of Architecture

6.6.1. Choice of Architecture for the OAP
The Online Application Portal (OAP) exploit the power of the client-server architecture
as do most web applications. The users will be able to access the application via a webbrowser by entering the URL of the website on their browser. The Component diagram
below is a simple illustration of the client-server architecture. A server component
perpetually listens for requests from client components. When a request is received, the
server processes the request, and then sends a response back to the client. Thus, a server
provides services to the client base on the clients request.

Figure 6.21: Architecture of the OAP

6.6.2. Choice of Architecture for the IMS
The Internship Management System (IMS) exploit the power of the client-server
architecture. Users will be able to access the application via a web-browser. The UML
Component diagram below is a simple illustration of the client-server architecture. A
server component perpetually listens for requests from client components. When a request
is received, the server processes the request, and then sends a response back to the client.
Thus, a server provides services to the client base on the clients request. The diagram
below depicts two major components represented as module 1 and module 2. Module 1
represents the Internship Management System while modules 2 represent the Online
Application Portal. Within Component 1, are 3 sub-components

which illustrate the client-server architecture of the Internship Management System. Also,
the relation called synchronization logic indicates that Component 1 (IMS) provide the
logic for communicating with the Online Application Portal.

Figure 6.22: Architecture of the IMS

6.6.3. Rationale for Choosing the Client Server Architecture
A Client-Server Architecture consists of two types of components: clients and servers. A
server component perpetually listens for requests from client components. When a
request is received, the server processes the request, and then sends a response back to
the client. Below are the benefits of the Client-Server architecture:

a. Data Processing capability despite the location

We are in an era which undergoes a transformation from machine-centred systems to
user centred systems. Through a client/server system users can directly log into a system
despite of the location or technology of the processors.

b. Easy maintenance
Since client/server architecture is a distributed model representing dispersed
responsibilities among independent computers integrated across a network, its an
advantage in terms of maintenance. Its easy to replace, repair, upgrade and relocate a
server while clients remain unaffected. This unawareness of change is called
encapsulation.

c. Security

Servers have better control access and resources to ensure that only authorized clients can
access or manipulate data and server-updates are administered effectively.

d. Flexibility

Client-Server architecture is flexible and hence allows new technology to be easily

integrated.

e. Scalability
Client-Server architecture is scalable hence new features can be upgraded when needed.

f. Centralization

Access, resources and data security are controlled through the server.

g. Interoperability
All components (clients, network, and servers) work together.
Base on these benefits, the Client-Server architecture was chosen.

7. IMPLEMENTATION

Implementation in this context refers to programming. This is the phase that gave birth to
the system. The outputs from the analysis and design phase are used as input in this phase.
The main activity in this phase is programming.

7.1. Programming Languages and Tools Used

a. Languages

PHP (Hypertext Preprocessor) - Language used to program the logic of the system.
Specifically, Code Igniter framework was used.
JavaScript and Jquery Library - was used to enhance the look and feel of the system. It
was also used to improve usability.
Ajax - Was used for form submission and to improve usability.
HTML5 - Was used to design the graphical user interface.
CSS3 - Was used to design the graphical user interface.
Unified Modeling Language (UML) - Language used to develop a model for the system.
C Programming Language - Was used to count the number of distinct occurrences of
languages in a text file and sort them out in alphabetical order for
used in a web form.

b. Software Packages and Tools Used

Planner (version 0.14.6) - Was used to develop the software development project plan for the
project.

Microsoft Visio (version 10) - Was used in the requirements phase to design basic
templates of how the system was going to look like.
Enterprise Architect (version 10.0) - Was used to draw the UML diagrams.
Komodo Edit, version 8.5.3 - Text editor used for coding the system.
JetBrainsPhpStorm 6.0.2 - IDE used for coding the system.
Google Chrome(Version32.0.1700.77), Firefox(version28), Safari and Internet
Explorer were the browsers used for testing the system.
MySQL Workbench - Was used to develop the Extended Entity Relationship (EER)
diagram.
XAMPP for Linux (Version 1.8.3-1) - It includes the following packages:
Web Server (Apache, version 2.4.4)
PHP, version 5.5.3
Database (MySQL, version 5.6.12)
Linux mint 17 (64 bits) and Windows 7 (64bits) were the platforms used for
development.