ARBA MINCH UNIVERSITY

ARBA MINCH INSTITUTE OF TECHNOLOGY (AMIT)

FACULTY OF COMPUTING AND SOFTWARE ENGINEERING

Online Information Management System for

Faculty of Computing and Software Engineering

Group – members:

1. Belachew Tinishu -------------------RAMIT/T/0005/11

2. Bisrat Mengistu ---------------------RAMIT/1606/10

3. Rediet Aschalew --------------------RAMIT/1804/10

4. Daniel Mathewose -----------------RAMIT/1620/10

5. Miheret Jehad -----------------------RAMIT/1738/10

6. Yichalem Birhane -------------------RAMIT/1869/10

Adviser: Eniyew T.

A senior project

Submitted to FCSE, AMIT, Arba Minch University, in partial fulfillment for the requirement of the
Degree of Bachelor Science in Information Technology (IT)

Arba Minch, Ethiopia

June, 2021
Approval Sheet

Approved by Board of examiners:

______________________ ____________________ ___________________

Adviser Name Signature Date

______________________ ____________________ ___________________

Examiner Name Signature Date
Acknowledgment

Primarily we would like to thanks God for being able to complete this final project phase1 with
success. Next, we would like to express our sincere gratitude to several individuals and the faculties
staffs for supporting us throughout our Graduate study. First, we wish to express our sincere gratitude
to our advisor instructor Enyew T, for his enthusiasm, patience, insightful comments, helpful
information, practical advice and unceasing ideas that have helped us tremendously at all times in our
project and writing of this document. Finally, we would like to express our sincere gratitude to our
faculty dean, that his supporting and helping us during information gathering is greet helping us to
success our work in meaningful. We also express our sincere thanks for the faculty staffs and chairs for
supporting us in different manners.

Thanks for all your encouragement!

11
 
Abstract

Information is one of the most valuable possessions of any organization or person. Since information is
worth a lot it has to be well managed and organized to be used. This system is designed so that it can
solve problems related to information management in FCSE. This paper and the following three
describe computer systems to store, retrieve, and manipulate information. These have all utilized time-
shared computer systems. All have evolved toward a system constructed of modular parts and having a
high degree of user interaction. Considerable attention has been given to implementation in a form
suitable for simple transfer to systems of adequate capacity with minimal programming effort. The
databases involved are all hierarchical in an organization. The major parts are a language facility, a
database manager, a processing package, and numerous coordinated administration functions. The parts
are currently assembled into a package that can be applied to an arbitrary hierarchically structured
database with little user effort. After the creation of the computer, the problem to organize information
and infer conclusions out of much different information is not that difficult. Hence, the proposed
system is used to manage almost all kinds of information used in FCSE. The proposed system is
expected to solve the problem of information loss, loss of time, and many other problems related to
information management in the faculty by analyzing, designing, and implementation of the system.

Keywords: Store, Retrieve, Manipulate, Information, Time-shared

Contents
Approval Sheet..........................................................................................................................................I
Acknowledgment......................................................................................................................................II
Abstract....................................................................................................................................................III
Chapter one................................................................................................................................................1
1. Introduction........................................................................................................................................1
1.1. Background of FCSE in Arba Minch University........................................................................1
1.1.1. Mission of AMIT.................................................................................................................2
1.1.2. Vision of AMIT...................................................................................................................2
1.2. Background.................................................................................................................................2
1.3. Team Composition......................................................................................................................2
1.4. Statement of the Problem............................................................................................................3
1.5. Objective of the project...................................................................................................................4
1.5.1. General Objective....................................................................................................................4
1.5.2. Specific Objective....................................................................................................................4
1.6. Feasibility study..........................................................................................................................5
1.6.1. Technical feasibility................................................................................................................5
1.6.2. Operational Feasibility............................................................................................................5
1.6.3. Assessment feasibility.............................................................................................................5
1.6.4. Economic feasibility................................................................................................................5
1.6.5. Behavioral /Political feasibility...............................................................................................5
1.6.6. Schedule feasibility..................................................................................................................6
1.7. Scope and Significance of the Project.........................................................................................8
1.8. Limitation of the project..............................................................................................................8
1.9. Target beneficiaries of the system...............................................................................................8
1.10. Methodology...............................................................................................................................2
1.10.1. Data Source..........................................................................................................................2
1.10.2. Fact-finding Techniques......................................................................................................2
1.10.3. Analysis and Design Approach............................................................................................2
1.10.4. Overview of Project Phases.................................................................................................2
1.10.5. Artifacts to Produce.............................................................................................................3
Chapter two................................................................................................................................................6
2. Introduction of existing system..........................................................................................................6
2.1. Major functions on the existing system.......................................................................................6
2.2. Business rules..............................................................................................................................6
2.3. Report generated in the existing system......................................................................................7
 2.4. Forms and other documents of the existing systems...................................................................7
2.5. Bottlenecks of the existing system..............................................................................................8
2.5.1. Performance.........................................................................................................................8
2.5.2. Input and Output..................................................................................................................8
2.5.3. Security and Control............................................................................................................9
2.6. Practices to be preserved.............................................................................................................9
2.7. Proposed system..........................................................................................................................9
2.8. Requirements of the proposed system.........................................................................................9
2.8.1. Functional requirements of the proposed system....................................................................9
2.8.2. Nonfunctional requirements..................................................................................................10
Chapter Three...........................................................................................................................................12
3.1. Introduction to System Analysis...................................................................................................12
3.2. System Requirement specification (SRS).................................................................................13
3.2.1. Use case Diagram..............................................................................................................13
3.2.2. Use case Documentation....................................................................................................13
3.2.3. Sequence Diagram.............................................................................................................24
3.2.4. Activity Diagram...............................................................................................................30
3.2.5. Class Diagram....................................................................................................................38
3.2.6. User interface prototype.....................................................................................................39
3.2.7. Supplementary specifications............................................................................................40
References................................................................................................................................................42
Bibliography............................................................................................................................................42
Webliography...........................................................................................................................................42
List of Figures
Figure 1 Schedule......................................................................................................................................6
Figure 2 use case diagram........................................................................................................................13
Figure 3 Login Sequence Diagram..........................................................................................................24
Figure 4 Scheduling Sequence Diagram..................................................................................................25
Figure 5 Attending lecture Sequence Diagram........................................................................................26
Figure 6 Post Notification Sequence Diagram.........................................................................................27
Figure 7 Registration of lecturer Activity Diagram.................................................................................28
Figure 8 Student case application Sequence Diagram.............................................................................28
Figure 9: view profile of lctures...............................................................................................................29
Figure 10 Login Activity Diagram..........................................................................................................30
Figure 11 View Profile of chairs Activity Diagram.................................................................................31
Figure 12 scheduling Activity Diagram...................................................................................................32
Figure 13 Reporting Milestone Activity Diagram...................................................................................33
Figure 14 Registration of users Activity Diagram...................................................................................34
Figure 15 Post notification Activity Diagram..........................................................................................35
Figure 16 Lecturers Attendance Activity Diagram..................................................................................36
Figure 17 Attending lecturer Activity Diagram.......................................................................................37
Figure 18 Class Diagram.........................................................................................................................38
Figure 19 User Interface Prototype..........................................................................................................39
List of Tables
Table 1 Team composition.........................................................................................................................2
Table 2 Budget breakdown........................................................................................................................6
Table 3 Overview of the project..............................................................................................................10
Table 4 Development tools......................................................................................................................12
Table 5 Login use case description..........................................................................................................22
Table 6 Posting Notification use case description...................................................................................23
Table 7 Attending lecturer use case description......................................................................................25
Table 8 Scheduling use case description.................................................................................................26
Table 9 Registration of lecturers use case description.............................................................................27
Table 10 Registration of chairs use case description...............................................................................28
Table 11 View profile of chairs use case description..............................................................................29
Table 12 View profile of lecturers use case description..........................................................................30
Table 13 Reporting milestone use case description.................................................................................31
Table 14 Attendance signing use case description..................................................................................32
Abbreviations

FCSE- - - - - - - - - - > faculty of computing and software engineering

AMIT- - - - - - - - - - -> Arba minch institute technology

DBMS- - - - - - - - - - >Database management system

 Chapter one

1. Introduction
Information management System is a process for identifying all the information the project
stakeholders need to make informed decisions. This project is introducing that the Information
management System for FCSE in AMIT work by placing every user like the administrators,
deans, chairs, lecturers and students at the center, and Internet connection as a powerful enabler.
These systems have also a variety of functions and can be utilized in Faculty of Computing and
software engineering, from student case related management to responsibilities of the system
administrator.
In addition to that the important feature and function of the proposed system are managing
different student cases in the faculty, assigning and offering courses to instructors and……. Are
the pilar activities of the system.

1.1. Background of FCSE in Arba Minch University

FCSE is one of the faculties in Arba Minch Institute of Technology that was established with its
own vision and goal. Realizing the importance of Computer Science and IT and the acute
shortage of skilled manpower in the field, the Department of Computer Science and Information
Technology, Arba Minch University Institute of Technology, Arba Minch University was
established with the vision and mission to promote Computer Science and Information
Technology education at Graduate and Post Graduate level to fulfill the technocratic need of the
country. In starting phase department launched an Advanced Diploma program in Computer
Science in 1995 E.C (now Closed). The first curriculum for the BSc degree program was adopted
in 1996 E.C. under the Faculty of Engineering. In addition to this, the university launched a
second BSc Degree program in Information Technology in 2004 E.C. Currently both the
programs run under the Computer Science and IT department under Arba Minch Institute of
Technology (AMIT). In addition, the department started M.Sc. in Computer Science in 2011 E.C.
In addition to it, the department has a summer B.Sc. Computer Science, B.Sc. Information
Technology and M.Sc. Information Technology. All programmers are successfully running with
adequate quality and commitment to accomplish the vision and mission of the department,
university, and nation at large.

1
 1.1.1. Mission of AMIT

Arba Minch University has a mission of offering relevant and quality education and training;
conducting demand driven research and rendering accessible community services.
1.1.2. Vision of AMIT

Arba Minch University aspires to be a leading university in Ethiopia, a center of excellence in

the field of water resources in Africa and competitive in the world by 2025

1.2. Background

Information worth a fortune to an organization, thus it is expected to be managed accordingly.

For the past few years, there has been an improvement in technologies the lead to information
organization that resulted in the retaining of the quality of the information, and it also contributed
to the availability of the information within a short period. Existing systems on Information
Management have some problems with an information organization type used as well as the
availability of the information both for the administrators and staff members. The current
systems in an IMS have a database logical structure, the design has not succeeded in capturing
all the necessary elements or the logical structure should be designed, or that requirements have
changed during the time, but changes have not been implemented to the database. The problem
with data integrity, the validity, and consistency of the stored data this problem usually arises
from duplication of relevant data. The problem with the database management system, all the
problems relating to the DBMS in use i.e. old database management systems. There were gaps
like the stability/reliability of the DBMS, lacing tools, limited capability to manage the data, and
other similar gaps. This system is designed so that the existing problems can be solved. So that,
information availability is assured in FCSE.

1.3. Team Composition

Even though, the responsibility is assigned to each group member every activity is carried out by
every member. The responsibilities are only for organization and management purposes.

2|Page
Table 1 Team composition

Project Title Information Management System for Faculty of Computing and Software Engineering (IMSFCSE)
Prepared By S. No Name Id. No Email/Mobile Responsibility
1. Belachew Tinshu C/0005/11 0961416295 Data collector and
Observation
2. Bisrat Mengistu RAMIT/1606/10 0924362959 Finance and group
management
3. Rediet Aschalew RAMIT/1804/10 0937630481 Analysis and Designer
4. Daniel Mathewose RAMIT/1620/10 0938260179 Testing and
Deployment
5. Miheret Jihad RAMIT/1738/10 0917899777 Implementation
6. Yichalem Birhane RAMIT/1869/10 0909032276 Documentation
Date June,2021
Adviser Eniyew T.

1.4. Statement of the Problem

As time goes forward the number of information increases within the organization (FCSE),
but the faculty does not have the necessary system to organize the information, to make the
information available to all staff workers including administrators and other researchers.

The faculty is not using currently up-to-date information management systems including
interfaces, programming languages, database management systems. Since the current system
uses a hard-copy storage system for most information, the number of users that can access
the information is limited. The document my worn out and the information will no more be
available to users. The digital system is also prone to failure because of compatibility, the
limited number of clients, old hardware, old database management systems, old platform, etc.

The common problems over the existing system are:

 There is lack of security over the manual collected information. That means the system
has no authenticated information management system in the faculty and easily exploited
to hackers and illegal users.

 The current system uses hard copy system for information storage and the number of
users to access the information is limited. There fore the information is not more be
available to users

3|Page
  The existing system has limited capacity using old devices and the accessibility is not ell
performed.

 The current system is no informative, it needs expert support.

1.5. Objective of the project

1.5.1. General Objective

The main goal of this study is to develop a web-based information management system for AMU
FCSE staff and students.

1.5.2. Specific Objective

The specific objectives will be achieved by following the implementation through successive
activities:

 To analyze what information is used in FCSE.

 To suggest what type of system should be adopted to the environment.

 To identify and define problem.

 To gather requirements featuring to the faculty.

 To analyse the existing system.

 To test the performance of the existing system.

 To implement the solution based on the requirement and design of the system.

 To test the system if it is in accordance with the requirement and if does what it says it does.

 To prepare documentation for the proposed system.

1.6. Feasibility study

The initial investigation points to the question whether the project is feasible. Feasibilities are
done to identify the best system that will meet the entire environment. These include an

4|Page
identification, descriptions, evaluations of the proposed system and selections of the best
solutions for the job.

1.6.1. Technical feasibility

Resource availability will directly affect the ability to achieve acceptable system, this evaluation
determines whether the software and hardware need for the proposed system is available or not.
The proposed system will feasible because hardware and software are available and are cost
effective.

1.6.2. Operational Feasibility

Since the design is very easy to everybody to interact with the system it will not have any
operational problem. Anybody who can read English language can interact with the system.

1.6.3. Assessment feasibility

Requires that teachers have a clear and complete understanding of the learning goals, have tasks
that will allow them to see if these goals are being met, and finally, have the ability to interpret
the evidence collected from these observations.

1.6.4. Economic feasibility

Economically the project is implementable because it does not require much outcome and we
will get the money that it requires to implement the project from our parents and

Others who can help us.

1.6.5. Behavioral /Political feasibility

The political feasibility is a feasibility that makes sure the system does not break law. Our
system does not violent with any law, hence the system is politically feasible.

1.6.6. Schedule feasibility

Schedule feasibility is a feasibility that makes sure that the proposed system completed in a time
given and we are dead sure that we will complete the developing the system in a given time
frame since all member of the team are quit dedicate and potential.

5|Page
We are using the following schedule outline as shown below using a Gantt chart

Tasks and Schedule

Figure 1 Schedule

Required Resources with Costs

Budget is the money required to complete the proposed project for different activities held in the
proposed study. So, for a time being the proposed project is requiring a total of twenty-six
thousand and one hundred and fifteen-birr (40595 ETB) birr only to accomplish this proposed
study, and the specific budget needed for each particular activity is mentioned in the table below.

Table 2 Budget breakdown

6|Page
No Items to be Budgeted No of days Cost per unit Total Cost Reason
(in Birr)
1. Data gathering 15 days 50 birr per day 750 For Data Gathering paid as a
thank you for cooperation to
volunteers
2. Computer During all phases of 20,000 birrs 20,000 For data processing,
development and implementation,
analysis deployment, testing,
designing
3. Data Collection from 6 expert per 4 days 50 per expert per 300 For data collectors
experts day

4. Transportation 10 trips 20 per single trip 200 For transportation

5. Flash Disk 1 unit (32 Gb) 1 400 For data backup

6. Paper 1 packet 30 30 For data collection

7. Mobile card 50 100 5000 For communication

8. Hard Copy 3 600 1800 For thesis printing

9. Binding 3 300 900 For binding Thesis

10. Contingency 5% of total 1215 For unexpected

The total budget to be estimate=40595 ETB Only

1.7. Scope and Significance of the Project

This project is studied specifically for FCSE. Thus, it is mainly used in FCSE but can also be
applied in any other faculties or other organization. Therefore, the scope of this project focuses
on FCSE managing student case, lecturer attendance control, faculty chair management,
organizing schedule and class, and etc. Even though the system can also be applied in similar
areas.

The project is significant to the institution in such a way that,

7|Page
  Improves information organization system.

 Student case handling

 Course assignment

 Increase in information quality.

 Provides reliable information by limiting access to the database.

 Improves the habit of resource saving of the organization

1.8. Limitation of the project

The project has limitations such as:
 Network problem could be another problem. That means no network no access.
 If the server is down, there might be a problem to attend the activities of the students and
lecturers.
 The administrator of the system or the dean must register student and organize
classrooms and also schedule manually.
 The lecturer must set its objective to process and follow plans achieved.

1.9. Target beneficiaries of the system

This project’s target is to make information related to the faculty available for all users that are
members of the institution in some or another way. Most users that will get a benefit from this
project are listed below:

1. Students. 4. Lecturers.

2. System administrators. 5. dean

3. Chair of the faculty

8|Page
 1.10. Methodology
1.10.1. Data Source

 We have used primary data sources, interviewing staff members of the faculty,
and field observation is the major methods. Since we are also members of the
faculty as a student, it was not that challenging to see the problems and come up
with a feasible solution.

 Internet is one of the most used data sources for our project, we have used the
internet to get any information on already done researches and to get a basic
understanding of the problems, terms, and solutions.

 We have managed to collect types of information that are used in the faculty
using an interview method of data collection. Hence, staff members were very
helpful, by supporting us with a basic understanding of the field of study.

Generally, staff members, the internet, existing researches, observation, books are the major
sources of data.

1.10.2. Fact-finding Techniques

 Interview: - Interviewing staff members, students, other concerned subjects

 Observation: - By observing how information is managed and how things are done in the
faculty.

 Searching Internet: - By using different websites to get information on existing systems.

 Books: - To get a basic understanding of the problems and getting candidate solutions.

1.10.3. Analysis and Design Approach

We have used the descriptive research design method to get ourselves familiar with how the
faculty manages its information, where information is needed when that information is used, and
how the information is managed, and also how it should have been managed. Since, descriptive

9|Page
research aims to accurately and systematically describe a population, situation, or
phenomenon. It can answer what, where, when, and how questions, but not why questions. A
descriptive research design can use a wide variety of research methods to investigate one or more
variables.

We also used the exploratory research designing method to find out why the quality of
information and its availability is very low. Since exploratory research is the research that helps
to learn the essence of the problem; to make sure that there is a problem, and to find out the
character of this problem. This is the simplest kind of research. They are carried out in the form
of free discussions with experts specially selected for this purpose or analysis of secondary
information.

1.10.4. Overview of Project Phases

Table 3 Overview of the project

Phases Task Description

Phase I Data collection and Project proposal Collection data for Project Proposal Preparation
preparation
Phase II System analysis and Design Analysis of problem and findings to come up with
requirement and designing based on those requirements
Phase III Implementation, Testing, and Implementing the specified requirements and testing if the
Documentation requirements are very well satisfied and preparing
documentation from the findings on the problem domain
and solution domain.
Where solution domain contains
System analysis and design.

1.10.5. Artifacts to Produce

Inception

 To develop and justify the business case for the system

 To describe the initial requirements

10 | P a g e
  To determine the scope of the system

 To identify the people, organizations, and external systems that will interact with
our system

 To develop an initial risk assessment, schedule, and estimate for our system
 To develop initial tailoring of the Unified Process to meet our exact needs

At this stage, we have developed a proposal of the system from the above outputs. Generally, we
have been able to get the project proposal as an output.

Elaboration

This phase has several goals:

 To produce a proven, architectural baseline for our system

 To evolve our requirements model to the "80% completion point"

 To develop a coarse-grained project plan for the entire Construction phase

 To ensure that the critical tools, processes, standards, and guidelines have been
put in place for the construction phase
 To understand and eliminate the high-priority risks of your project

Generally, SRS (system requirement specification) will be the output of this stage

Construction Phase

 To describe the remaining requirements

 To flesh out the design of our system

 To ensure that our system meets the needs of its users and fits into our organization's
overall system portfolio

 To complete component development and testing, including both the software product
and its documentation

11 | P a g e
  To minimize development costs by optimizing resources

 To achieve adequate quality as rapidly as possible

 To develop useful versions of your system

Generally, analysis, system design, the prototype will be the output of this phase.

Transition Phase

 The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment (delivery and feedback) activity.

 Software is given to end-users for beta testing and user feedback reports both defects and
necessary changes.

 After the transition phase, the software increment becomes a usable software release.

 Generally, a fully tested implemented system will be the output of this stage.
Documentation also will be developed at this stage.

Development Tools

Table 4 Development tools

Activities Tools/ Programs Uses

Client-side coding HTML/JSX For interface designing

JavaScript is used which
is how react based
interface designs are
made
Client-side scripting JavaScript For business logic
Platform Linux (Arch Linux) Environment for running
nodejs server fast, and it
is lightweight uses less
ram than other server
environments
Database server MongoDB For persistent data storage

12 | P a g e
Webserver Nodejs Server for backend and
frontend
Server-side scripting JavaScript To code server-side logic
in nodejs
Browsers IE 5.5/6.0/7.0, Mozilla Firefox To run and debug react
3.0./chrome/chromium interface and to see how
data flows in the business
logic
Editors Visual Code IDE for javascript
Documentation MS Word, Edraw Max, Excel Word processing,
designing, diagrams
User Training MS PowerPoint For presentation
Varied technologies React is updates, nodejs updates,
Linux updates

Chapter two

2. Introduction of existing system

An existing system for information management in Arba Minch institute of technology faculty of
software engineering and computing is semi-digital, that is to mean that the system is not totally

13 | P a g e
digital but some information, related to the institution, is still manual. The faculty uses folders to
store papers that contain reports, employee documents, plans, schedules, receipts and other files.
Those folders take up spaces in a drawer or shelf. Those files are organized and categorized in
manually. Each time file is needed, the secretary needs to go manually to the shelf where the
required files is put.

2.1. Major functions on the existing system

The major functions in the existing system are all done manually, these functions are listed
below:

 Inserting a new document into an existing file by finding the category of the file and the
shelf containing the required category.

 File is found by going into the shelf containing the file category and searching in the
folder.

2.2. Business rules

Business rules in the Faculty of Computing and Software Engineering are as follows:

1. Chairs assign courses for the instructors and prepare the schedule.

2. The dean controlling activities of department chairs.

3. Student present their case to the faculty dean and faculty dean forward to the chair
4. Scheduling classes
5. Reporting the progresses

6. The dean assigns department chair in the faculty.

7. Each chair in the faculty can controls activities of lecturers.

8. Each chair can prepare courses for their respective classification, e.g. programming
chair must prepare programming courses, examinations, lecturers for specified
courses.

14 | P a g e
 9. Each lecturer can report their activities to the chairs.

10. Lecturers can give their respective courses to students.

2.3. Report generated in the existing system

Reports generated in the existing system is basically activates of the lectures for the chairs to
review. The other is activities of chairs for the department dean to review.

 Reporting the weekly class progress and class by the chair

 Reporting the schedules

 Reporting student case

2.4. Forms and other documents of the existing systems

 Lecturer planes and course outline.
 Chairs list
 Lectures list
 Student prepare the letter describing the case to the dean
 Course schedule submitted or prepared by the chairs
These are forms generated in the faculty.

2.5. Bottlenecks of the existing system

Existing system for information management in the faculty has a lot of problems. These
problems are basically a result of the documents type. Most document types in the faculty is of a
hard copied that are organized in a hard folder in a categorized shelf. Due to this the following
bottlenecks exist in the system. These are:
 Course offering balancing and distributing equal benefits for instructors
 Student case handling and management
 Identify the Varity of the student cases
 Searching document takes a lot of time.

15 | P a g e
  The course covered by the instructor might not be similar between the student report and
the instructors
 Creating file also takes time.
 Editing file is almost impossible.
 File might be lost.
 The files get older within a short time.
 A lot of time is wasted.
 Man power is needed to sort the files.
 The files might not get sorted accurately.
 Taking backup of the files is almost impossible.
2.5.1. Performance

The performance of the system is clearly poor because of the file organization method used and
also because it uses man power. Searching specific file might take from hours to days and in
worst case to months. Therefore, the current system does have a serious performance issue.

2.5.2. Input and Output

The current system does use physical file as an input and output. The file is processed by
manually.
2.5.3. Security and Control

The physical information and files are not secure enough. Anyone with a key to the file storage
room can access those files and might even take files. Controlling files in manually is very hard.
If file is lost it will not be known until it is checked. Some information documents whereabouts
might also be forgotten. Therefore, it is not secure and well controlled.

2.6. Practices to be preserved

There is no practice to preserve. Since all the information containing documents are of physical
type.

16 | P a g e
 2.7. Proposed system

The proposed system is called information management system for faculty of computing and
software engineering. The main idea of the system is to digitize non-digital documents and using
database system to store data.
To overcome existing system limitations up-to-date computerized
 Database system

 User interface

 Security system

 Management system

will be used.

2.8. Requirements of the proposed system

The outcomes or expected outputs of the proposed system is shown in two categories as in
functional requirement and non-functional requirement.

2.8.1. Functional requirements of the proposed system

Functional requirements define the basic system behavior of the proposed system. Essentially,
they are what the system does or must not do, and can be thought of in terms of how the system
responds to inputs.
The common functional requirements of the proposed system are:
Registration:
The system can register each and every beneficiaries of the system like, registration of students,
courses, lectures, chairs, dean, classes.

Time saving:
This is one of the common functions of the proposed system. Time is the most important
resource therefore we use wisely as possible. So, the system is possible to do something
quickly and end faster.

17 | P a g e
Adding schedule:

The proposed system can possible to add schedule and courses for the assigned class

Adding class progress:

Customize class progress to make it easier to track and compare the performance of learners in a
given courses

2.8.2. Nonfunctional requirements

Performance

 The system shall be fast on processing and responding requests

 The system shall provide the requested data from database as fast as possible.

Reliability

The system is must be reliable when requesting a data. The server must restart after failure.
Maintainable

The system must be maintainable using object-oriented design methodology. When one
subsystem is maintained the other should work with the newly modified subsystem.
Scalability

The system shall be scalable by incorporating object-oriented methodology as its design method.
New components and subsystems shall be added in such a way that the addition of the new
component does not interfere with the existing components and subsystems.
Usability

The system must be usable by making the interface untestable, adding working subsystems,
making the whole system suitable to the environment and the society.
User Interface

User interface shall be

 Understandable

18 | P a g e
  Easy to use

 Memorable

 Attractive

 Suitable for each functionalities of the system.

Security and Access permissions

 Student information shall be visible only to assigned lecturer, admin only.

 Password of all users shall be encrypted.

 User modification shall be allowed only to administrator.

 The system must use https protocol

Backup and Recovery

 During failure the system shall be able to restart and restore session.

 The database shall be able to store all information in ‘. sql’ for backup.

Chapter Three

3.1. Introduction to System Analysis

On this chapter of the document, the system’s basic idea and its structural view will be presented.
System analysis is used to show and understand the core idea of the system. This stage of
analysis will help to increase the quality of the system developed, to provide more information to
the stakeholders, to understand system requirement more deeply.

19 | P a g e
Modern analysis method will be used that is object-oriented method of analysis is used. Use case
is used to illustrate how the system works internally and externally as well.

3.2. System Requirement specification (SRS)

The system requirement specification is a document that describes what is expected from the
system.
3.2.1. Use case Diagram

Figure 2 use case diagram

3.2.2. Use case Documentation

Table 5 Login use case description

Use case 1 Login

Actor Lecturer, dean, chair
Use case description The user inserts email(id) and password then the system
checks the information provided, then authorizes the user if
valid else gives information about the wrong user

20 | P a g e
 credentials.
Pre-conditions  The user must be registered in the system’s database.
 The user must know its user id and password.
Flow of actions System User
1. System shows login page
2. User gives id and
password on the
loaded login
page input area.
3. The system validates the
input if valid proceeds to
the next step.
4. The system authenticates
the user based on the user
id.
5. If valid user identifies the
user type.
6. Proceeds to home page.

Alternative action-1  User gives invalid input then the system displays
“invalid input” message and prompts user for input
again
Alternative action-2  User is not registered then the system prompts the
user “User unknown you must be registered to use
the system”
Alternative action-3  The input password is invalid, then the system shows
message “wrong password, please try again” and
prompts the user again.
Alternative action-3  The user inserts wrong email(id), then the system
shows “User unknown must be registered first”
Termination outcome  The system loads the homepage and the user will be
logged in.

Table 6 Posting Notification use case description

Use case 2 Posting notification

Actor Chairs
Use case description The chairs can post in the homepage of lecturers and also dean if there is a
new upcoming event or if something new is updated or added

21 | P a g e
Pre-conditions  The user must be chair and logged in
Flow of actions System User

1. User selects new Post

page
2. The system provides an empty
area for putting a new event
detail.

3. The user inserts details

about the new event and
if any can add photo.
4. Clicks post.

5. The system stores the data into

database.

6. The system shows success

message at the end, after
inserting the new event into
database.

Alternative action-1  User gives empty content then the system displays “User must
provide at least textual content” message and prompts user for
input again
Termination  New post will be added to the database and notification will be
queued.
outcome

Table 7 Attending lecturer use case description

Use case 3 Attending lecturer

Actor Chairs
Use case description The chairs will check if the lecturer was giving classes appropriately
Pre-conditions  The user must be registered in the system’s database.

22 | P a g e
  The user must know its user id and password.
 The lecturer must take picture of student attendance with the
appropriate date.
 The lecturer must fill attendance paper with the appropriate
information.
Flow of actions System User
1. System shows lecturers
list page

2. Select any lecturer to view

its activity.
3. The system loads
current activity of the
lecturer from database.

4. The user views the activity

5. The system stores the
and leaves a comment if
comment on the
any.
database.

Termination outcome  The system loads the homepage and the user will be logged
in.

Table 8 Scheduling use case description

Use case 4 Scheduling

Actor Chairs
Use case description The chair will set starting and ending time of class with classroom
number.

23 | P a g e
Pre-conditions  The user must be logged in
Flow of actions System User

1. The user selects set scheduling.

2. The system shows

scheduling page.

3. User sets schedule and lecturer and

also classroom number.

4. The system checks if

the classroom and
lecturer is in the
database.
5. The system inserts
the schedule into
database.
6. The system shows
success message to
the user.

Alternative action-1  User gives invalid input then the system displays “invalid input”
message and prompts user for input again
Alternative action-3  The inserted classroom is not in the database or does not exists,
then the system shows messages “inserted classroom does not
exist or it is not registered in the database”
Termination  The inserted schedule will be stored in the database.
outcome

Table 9 Registration of lecturers use case description

Use case 5 Registration of lecturers

Actor Chairs
Use case description The chair can register lecturer by inserting details about the lecturer.
Pre-conditions  The user must be registered in the system’s database.
 The user must be logged in.

24 | P a g e
Flow of actions System User

1. User selects register lecturer.

2. The system shows register
lecturer page.

3. The chair inserts

information about the
lecturer.

4. The system stores the user

detail in the database.
5. The system emails the user
password and username
using the email of the user.
6. Shows success message to
the user.

Alternative action-1  User gives invalid input then the system displays “invalid input”
message and prompts user for input again
Alternative action-2  User already exists, then the system shows message “User already
exists!”
Termination  The new lecturer will be registered and emailed upon registration.
outcome

Table 10 Registration of chairs use case description

Use case 6 Registration of chairs

Actor Dean
Use case description The dean can register chairs by providing details about the chairs.
Pre-conditions  The user must be registered in the system’s database.
 The user must be logged in.
 The user must be dean
Flow of actions System User

1. User selects register chair.

25 | P a g e
 2. The system shows
register chairs page.

4. The dean inserts information

about the chairs.

3. The system stores

the user detail in
the database.
4. The system emails
the user password
and username using
the email of the
user.
5. Show’s success
message to the user.

Alternative action-1  User gives invalid input then the system displays “invalid
input” message and prompts user for input again
Alternative action-2  User already exists, then the system shows message “User
already exists!”
Termination outcome  The new chair will be registered and emailed upon
registration.

Table 11 View profile of chairs use case description

Use case 7 View profile of chairs

Actor Chair, dean

Use case description The dean and the chair can view the profile of specific chair.

Pre-conditions  The user must be registered in the system’s database.

 The user must be logged in.
System User

1. User selects view profile.

2. The system shows view

26 | P a g e
 profile page.
3. The system lists chairs in the
database only for the dean

4. The dean selects chair from

the list.

5. The system retrieves the data

from database and show
profile of the chair.
6. The dean makes some
changes or no changes the
saves the profile.

7. The system updates the user

detail in the database.
8. The system emails the user
password and username
using the email of the user,
with changes made to the
profile.
9. Show’s success message to
the user.

Alternative action-1  User gives invalid input then the system displays “invalid input”
message and prompts user for input again
Alternative action-1  If the user is chair, then the system only shows its own profile but not
others chair’s profile
Termination outcome  The dean or the chair change the profile and view the profile details.

Table 12 View profile of lecturers use case description

Use case 8 View profile of lecturers

Actor Chair, dean, lecturer

Use case description The dean, the chair and the lecturer can view the profile of specific lecturer.

Pre-conditions  The user must be registered in the system’s database.

 The user must be logged in.
Flow of actions System User

1. User selects view lecturers.

27 | P a g e
 2. The system shows view
lecturer’s page.
3. The system lists lecturers in
the database only for the dean
and chair

4. The dean or the chair selects

5. The system retrieves the data
specific lecturer from the list.
from database and show
profile of the lecturer.

6. The dean or chair make some

changes or no change and click
7. The system updates the user
saves the profile.
detail in the database.
8. The system emails the user
password and username using
the email of the user, with
changes made to the profile.
9. Show’s success message to
the user.

Alternative action-1  User gives invalid input then the system displays “invalid input”
message and prompts user for input again
Alternative action-2  If the user is lecturer they can only view and edit its own profile.
Termination outcome  The dean, the chair or the lecturer change the profile and view the profile
details.

Table 13 Reporting milestone use case description

Use case 9 Reporting milestone

Actor Lecturer
Use case description The lecturer sets milestones and show and set activity status with
percentage.
Pre-conditions  The user must be registered in the system’s database.
 The user must be logged in.
Flow of actions System User

1. User selects milestone.

2. The system shows milestone

28 | P a g e
 page.

3. User selects add

milestone.
4. The system inserts the new
milestone with value 0.

5. The lecturer checks

6. The marks finished activities finished activities.
and update database.

7. At 100% system notifies the

chair.

Alternative action-1  The lecturer did not complete on time the system notifies the
chair and the lecturer “Milestone must be reached on the given
time, please try to complete all activities on time”
Termination outcome  The system will update the status of the lecturer.

Table 14 Attendance signing use case description

Use case 10 Attendance signing

Actor Lecturer
Use case description The lecturer will report daily work if it is done by capturing student
attendance and uploading.
Pre-conditions  The user must be registered in the system’s database.
 The user must be logged in.
Flow of actions System User

29 | P a g e
 1. User selects attendance.
2. The system shows view
attendance page.

3. The system generates QR

code for the current
schedule.
4. Click submit

5. Store the data

Alternative action-1  User gives invalid input or no captured image of attendance then
the system displays “invalid input or no image file, please insert
attendance image of students” message and prompts user for input
again

Termination  The lecturer’s attendance will be set

outcome

30 | P a g e
 3.2.3. Sequence Diagram

Figure 3 Login Sequence Diagram

31 | P a g e
Figure 4 Scheduling Sequence Diagram

32 | P a g e
Figure 5 Attending lecture Sequence Diagram

33 | P a g e
Figure 6 Post Notification Sequence Diagram

34 | P a g e
Figure 7 Registration of lecturer Activity Diagram

Figure 8 Student case application Sequence Diagram

35 | P a g e
 Figure 9: view profile of lectures

36 | P a g e
 3.2.4. Activity Diagram

Figure 10 Login Activity Diagram

37 | P a g e
Figure 11 View Profile of chairs Activity Diagram

38 | P a g e
Figure 12 scheduling Activity Diagram

39 | P a g e
Figure 13 Reporting Milestone Activity Diagram

40 | P a g e
Figure 14 Registration of users Activity Diagram

41 | P a g e
Figure 15 Post notification Activity Diagram

42 | P a g e
Figure 16 Lecturers Attendance Activity Diagram

43 | P a g e
Figure 17 Attending lecturer Activity Diagram

44 | P a g e
 3.2.5. Class Diagram

Figure 18 Class Diagram

45 | P a g e
 3.2.6. User interface prototype

Figure 19 User Interface Prototype

46 | P a g e
 3.2.7. Supplementary specifications
Usability Requirement:

 The system will usable in that:

 The user interface will be easy to understand.

 The system is very clear in its functionality.

 Managers must be able to manage user easily

Reliability

Mean Time Between Failures (MTBF) – The mean time of failure of the system is roughly
estimated to be one year.

Mean Time to Repair (MTTR) – The system is repaired in 15 days after the system is failed.

Reliability Requirement

 The system will store each user’s data accurately and user management is very reliable.

Performance Requirement

 The system should work and respond within 10 min maximum.

Supportability Requirement

 The system shall support most modern web browsers and devices.

 The system shall support current network infrastructure.

Design Constraints

Design constraints represent design decisions that have been mandated and must be adhered to
and

 Programming language – JavaScript

47 | P a g e
  Database – Moongose database system

 Visual code for the coding environment

 Nodejs for the back-end

 React for the front-end

Security

There is a complete security module in the system which helps to secure the system. The
security module includes password system JWS token. This helps to ensure the security
of the system and the system is not exposed to threats for the outer world. If the user
knows the password and with assigned token, then the user is able to use the system else
he is not allowed to enter the system. This enhance the security of the system.

Interfaces
User Interfaces

Attractive and correspond with the functionality of the system.

Software Interfaces

 moongose database system

48 | P a g e
References

Bibliography
1) Artymiak, J. (2011). Common Gaps in Information systems. Retrieved from
https://issuu.com/academic-conferences.org/docs/ejise-volume8-issue2-article462

2) Kontio, J. (2011). Common Gaps in Information systems. Artymiak, Jacek. Retrieved

from https://issuu.com/academic-conferences.org/docs/ejise-volume8-issue2-article462

3) Technology, A. M. (n.d.). The background of Arba Minch Institute of Technology.

Retrieved from https://smis.amu.edu.et/app/webroot/media/transfer/doc/se.pdf

Webliography
1) https://smis.amu.edu.et/app/webroot/media/transfer/doc/se.pdf

2) https://issuu.com/academic-conferences.org/docs/ejise-volume8-issue2-article462

49 | P a g e