Dire Dawa University

INSTITUTE OF TECHNOLOGY
SCHOOL OF COMPUTING
DEPARTMENT OF COMPUTER SCIENCE
PROPOSAL DOCUMENTATION
Title:- DDU Alumni Student System

GROUP MEMBER ID
1. ADONIYAS SISAY……………………….1206014
2. BROOK SINTAYEHU…………………….1204126
3. KALKIDANYESHITLA…………………..1200684
4. REDIET GETACHEW……………………..1201151
5. YONAS NIGUSSU………………………...1206010

Advisor Name Mr. Mikiyas M.

Advisor Signature

Dire Dawa,Ethiopia
March 5,2023
 Dire Dawa University
Institute of Technology
Department of Computer Science
Name of Student’s Team Leader: _____________________________________________
Title of Project: _________________________________________________________
Decision of the Examining Committee, please tick
 Approved
 Clarification Required
 Revise and Resubmit
 Rejected
If the decision is other than “Approved”, please provide the details below indicating
why the proposal is not approved. You can attach your comments on separate sheets
of paper if extra space is required.
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
_________________________________________________________________________________

Name and signature of Members of the Examining Board

1. _____________________ ____________________ ______________________
Examiner Signature Date
2. ____________________ ___________________ ______________________
Examiner Signature Date
3. _____________________ ____________________ ______________________
Examiner Signature Date
4. _____________________ ____________________ ______________________
Examiner Signature Date
5. _____________________ ____________________ ______________________
Examiner Signature Date _____________________
____________________ ______________________
Advisor Signature Date

i
 Table of content
List Of Tables:........................................................................................................................iv
Chapter One.......................................................................................................................1
1. Introduction..........................................................................................................................1
1.1 Background of the project..................................................................................................1
1.2 Statement of the Problem..................................................................................................1
1.3 Objective of the project......................................................................................................2
1.4 Scope and Limitation of the project....................................................................................3
1.4.1 Scope of the project.........................................................................................................3
1.4.2 Limitation of the project..................................................................................................3
1.5 Significance of the Project..................................................................................................3
1.6 Beneficiaries of the Project.................................................................................................4
1.7 Methodology......................................................................................................................5
1.7.1 Data gathering Methodology...........................................................................................5
1.7.2 Development Methodology.............................................................................................6
1.7.3Development Tools...........................................................................................................7
1.8 Software and Hardware tools.............................................................................................7
1.8.1 Software tools..................................................................................................................7
1.8.2. Hardware tools...............................................................................................................7
1.9 Feasibility Study..................................................................................................................7
1.9.1 Technical feasibility..........................................................................................................8
1.9.2 Economic feasibility.........................................................................................................8
1.9.3 Operational feasibility......................................................................................................8
1.10 Project Plan.......................................................................................................................8
1.10.1 Project Time Schedule...................................................................................................9
1.10.2 Budget Plan..................................................................................................................10
Chapter 2.........................................................................................................................11
2. Requirement elicitation......................................................................................................11
2.1 Overview of Existing System.............................................................................................11
2.2 Proposed system description............................................................................................12
2.3 Preferred Solution............................................................................................................13
2.4 Domain Modeling with CRC Cards...................................................................................13
2.5 Essential Use case Diagram...............................................................................................14

ii
2.6 Essential use case documentation....................................................................................16
2.7 Essential User interface Prototype....................................................................................18
Chapter 3.........................................................................................................................19
System Analysis......................................................................................................................19
3.1 Functional requirements of the System............................................................................19
3.2 Non-Functional Requirements..........................................................................................20
3.3 System Modeling..............................................................................................................21
3.3.1 System use case Diagram...............................................................................................21
3.3.2 System use case Diagram Documentation.....................................................................23
3.3.3 Sequence Diagram.........................................................................................................30
3.3.4 Activity Diagram.............................................................................................................33
3.3.5 Class Diagram.................................................................................................................39
CHAPTER 4.......................................................................................................................41
System Design.........................................................................................................................41
4.1 Design Goals.....................................................................................................................41
4.2 System architecture..........................................................................................................41
4.3 Sub-system Decomposition..............................................................................................43
4.4 Hardware/software Mapping...........................................................................................44
4.5 Collaboration Diagram......................................................................................................45
4.6 Deployment Diagram........................................................................................................47
4.7 Persistent data storage and management........................................................................47
4.8 Graphical user interface Design........................................................................................50
Conclusion..............................................................................................................................51
Recommendation...................................................................................................................51
References..............................................................................................................................52

iii
List Of Tables:
Table 1 Software tools.............................................................................................................................7
Table 2 Hardware tools...........................................................................................................................7
Table 3 Time schedule............................................................................................................................9
Table 4 Team role....................................................................................................................................9
Table 5 Budget plan...............................................................................................................................10
Table 6 CRC for Administrator...............................................................................................................13
Table 7 CRC for Organization.................................................................................................................14
Table 8 CRC for Alumni..........................................................................................................................14
Table 9 Ask for document use case description....................................................................................16
Table 10 Generate document use case description...............................................................................17
Table 11 Authenticate document use case description.........................................................................17
Table 12 Official transcript use case description...................................................................................23
Table 13 Original Degree use case description......................................................................................24
Table 14 Student copy use case description..........................................................................................25
Table 15 Temporary certificate use case description............................................................................26
Table 16 To whom it may concern use case description.......................................................................27
Table 17 Document authentication use case description......................................................................27
Table 18 Login use case description......................................................................................................28
Table 19 Send document use case description......................................................................................29
Table 20 Approve request use case description....................................................................................29
Table 21 Document replacement use case description.........................................................................30
Table 22 Data Dictionary for Alumni form Attributes............................................................................49
Table 23 Data Dictionary for List of Request Attributes........................................................................49
Table 24 Data Dictionary for Documents Attributes..............................................................................50
Table 25 Data Dictionary for Account Attributes...................................................................................50

iv
List of Figures
Figure 1 Essential Use Case Diagram....................................................................................................15
Figure 2 Essential User Interface Prototype..........................................................................................18
Figure 3 Use case diagram.....................................................................................................................22
Figure 4 Sequence diagram for Admin..................................................................................................30
Figure 5 Sequence diagram for Login....................................................................................................31
Figure 6 Sequence diagram for clerk.....................................................................................................31
Figure 7 Sequence diagram for all login................................................................................................32
Figure 8 Sequence diagram for alumni..................................................................................................32
Figure 9 Sequence diagram for organization.........................................................................................33
Figure 10 Activity diagram for organization..........................................................................................34
Figure 11 Activity diagram for alumni...................................................................................................35
Figure 12 Activity diagram for school head...........................................................................................36
Figure 13 Activity diagram for admin....................................................................................................37
Figure 14 Activity diagram for clerk.......................................................................................................38
Figure 15 Activity diagram for login.......................................................................................................39
Figure 16 Class Diagram........................................................................................................................40
Figure 17 Architectural styles................................................................................................................42
Figure 18 Subsystem Decomposition....................................................................................................44
Figure 19 Hardware/software Mapping................................................................................................44
Figure 20 All user login..........................................................................................................................45
Figure 21 To request service.................................................................................................................46
Figure 22 For generating file.................................................................................................................46
Figure 23 Deployment...........................................................................................................................47
Figure 24 Persistent diagram.................................................................................................................48
Figure 25 User interface........................................................................................................................50

v
Abstract
The project entitled as DDU Alumni Student System for dire Dawa University using
web-based technologies. Currently Dire Dawa University uses a manual way of
giving services to the alumni Students. Because of this manual system have so many
difficulties on its progress in terms of effectiveness. Some of those difficulties are
alumni to get their document student has to be present in the university so they waste
money for transportation, food, bed e.t.c, difficulty of finding the office when the
alumni student come to the university the place of the office maybe changed, this
cause frustration for the student, Companies need a certificate and cannot bother to go
through the process of authentication of certificate, so they take a shortcut. This action
has caused the population of unemployed person who is exactly own a certificate
increase. The proposed system stands for avoiding the difficulties and side effects of
the existing system. So, the project we are going to develop will try to recommend
those problems and providing prototype of the system to be developed by the
program. Because the system to be developed is online, it includes the project design
to create a platform that authenticates alumni students documents and provides them
with various services related to their education and This system will enable alumni
students to share their academic records with potential employers, educational
institutions, and other third-party organizations etc. This project is valuable not only
for students but also for the University. Because it minimizes burden of the employees

vi
Acknowledgment
First and foremost, we would like to praise and thank the Almighty God for giving us
the strength and because of His blessing; we finally managed to accomplish this
Proposal. Without His blessing, we wouldn’t have gone this far. This assignment
cannot complete without effort and co-operation from our group member, we always
work hard to produce a good Project with our full commitment and responsibility.
Last but not least, we would like to express our thankfulness acknowledge with thanks
to our Advisor Mr.Mikiyas because without His guide our Project cannot be done
properly like this. He always gives us supports and guide on how to do our
assignment in purpose to produce a good outcome. He inspired us greatly to work in
this project.

vii
viii
Chapter One
1. Introduction
The project that going to be developed is about the DDU Alumni Student System. As
an overview, the system will be used by the university college’s administration and
student management.
The DDU Alumni Student System can handle detail about alumni students. The detail
includes official transcript, official degree, student copy, temporary certification.
In case of current system, they need a lot of time, man power etc. Here almost all
work is computerized. So the accuracy is maintained. DDU Alumni Student document
verification System is managed by an administrator. It is the job of the administrator
to give official degree, official certificate, student copy and so on.
The prevalence of fraud and forgery of degree certificates has grown with the
emergence of more accessible and affordable technologies such as printing and
copying. This poses a threat to both the certificate holder and the educational
institution that issued it. Manual verification is a laborious process, requiring multiple
levels of human interaction and taking up a lot of time, which puts an extra burden on
universities to verify all their graduates. Therefore, on the system the administrator
generates E-certification using a QR code on the temporary document which is given
to a graduate student.

1.1 Background of the project

Dire Dawa University was established in 2006 with enrollment of 754 students in
three facilities: (Faculty of Natural Science and Mathematics, Faculty of Social
Science and language and Faculty of Business and Economics) in 13 different
undergraduate academic programs with 90 teachers and 103 administrative support
staff operating with limited facilities. In 2008, an affiliate campus of Haramaya
University was merged to Dire Dawa University to construct more buildings and
workshops.
In the university most of the job is done manually using papers because this the
service is time wasting. So we try to solve the student problems, using user friendly
website and can they do many task on the system.

1.2 Statement of the Problem

1
In the existing system, alumni student to access their need, they must directly interact
with the university to get their transcript and student copy, student tempo. Further,
organization needs to have a direct contact with the university for verifying the
graduated student. However, today’s era technology trying to improve people life
style all the time. Graduated student are also demanding simplification of tasks in the
university for there needs to be fulfill. This way of fulfill need of student is difficult,
time and budget of students and organization. And also it is quite difficult to get their
need of interest.
Generally, the current system has the following problems:
 Graduated students time and budget: - To get their document student has been
present in the university so they waste money for transportation, food, bed
e.t.c.
 Limited availability: as the alumni student ask the service physically, may be
the worker not presented on their working place.
 Difficulty of finding the office when the alumni student come to the university
the place of the office maybe changed, this cause frustration for the student.
 Existing method to verifying the alumni document, anyone who one to verify
they must physical come to the university. This need to authenticate the
certification which takes up to at least 3 days.
 Companies need a certificate and cannot bother to go through the process of
authentication of certificate, so they take a shortcut. This action has caused the
population of unemployed person who is exactly own a certificate increase. At
the same time, it is unfair for them who had work hard for many years to get a
certificate compare to those who do not invest anything.
For the system to be successful in its activities well-structured system is necessary.
So, doing the activities manually is difficult to accomplish tasks easily, efficiently and
effectively.

1.3 Objective of the project

1.3.1 General Objective
The general objective of DDU Alumni Student System is to develop a web-based
application to develop a document authentication system and service for graduated.
1.3.2 Specific objective

2
  Study and analyze the existing system.
 To design the user-friendly interface.
 To model and develop the new system.
 To implementing and testing the implemented system.
 To training and maintaining the system.

1.4 Scope and Limitation of the project

1.4.1 Scope of the project
The scope of the project plans and targets in developing and implementing a DDU
Alumni Student System to replace and solve the problems with in existing system
used by Dire Dawa University.
The following are the main scope of the project:
 The project design to create a platform that authenticates alumni students
documents and provides them with various services related to their education
and career.
 The project aims to build a comprehensive system that meets the needs of the
DDU alumni community and supports their ongoing engagement with the
university.
 This system will enable alumni students to share their academic records with
potential employers, educational institutions, and other third-party
organizations.
1.4.2 Limitation of the project
This defines what our system is not going to perform or what is not including in the
system.
 The system is only design for document authentication and to provide alumni
student with a platform to ask for service.
 It does not crate to other requirement that alumni student may have.
 The system work only for graduated student.
1.5 Significance of the Project
The relevance why we have to conduct the study is:
 To shorten data-processing time: In order to done a specific job, it will not
consume much time to process.

3
  Reduce errors: Through this system, many errors will be avoided because the
system will be easy to use.
 Improve the accuracy of input: It will help the user to avoid mistakes
regarding the information that they will address to the subjects. There will be
accurate information because the system will have an update option.
 Give information easily and efficiently: It will make easier the way finding
information of the student and also it will provide accurate data.
 To request temporary certificate
 To request to whom it may concern
 To get document replacement
 To get document authentication
 To check the status of your alumni request
 To request original Student copy
1.6 Beneficiaries of the Project
The proposed system has a lot of benefits in every aspect related to students’
information management system. So the new system has the following contributions
For the organization:
 Give information easily and efficiently.
 Easily manage their alumni student.
 Decrease physical contact between people, only get contact to the right
person.
 Avoiding improper resource consumption like paper, card, file cabinets
 Avoiding data loss because of using of destroy-able components.
 Reduce error.
For the Student:
 Get their information from anywhere.
 Reduce cost to get their information.
 The system also provides a secure way for students to access services such as
temporary certificate, to check the status of their alumni request, to get
document authentication, to request original student copy
For Developer Team
 Add new knowledge.
 Get problem solving skill.

4
  Give great satisfaction

1.7 Methodology
Methodology refers to the overarching strategy and rationale of your research project.
It involves studying the methods used in your field and the theories or principles
behind them, in order to develop an approach that matches your objectives.
The team chooses object oriented analysis and design approach to analyze and design
the system, based on our preliminary analysis of the old system.
1.7.1 Data gathering Methodology
When we develop this system, data gathering plays a great role to know the tasks or
activities that can be done by the system. To do this, it is important to know what
activities are done in existing system. After we know activity which is done on the
manual system, it is easy to develop the system. We can gather data from different
sources. To gather our requirement, we use two type of data gathering methodology.
These methodologies are:
Primary source
A primary source provides direct or firsthand evidence about an event object, person,
or work of art such types of primary source are:
Interview:
We will gather information by interviewing Enrollment, academic record and alumni
directorate about the manual system and we will also gather necessary information
about the services.
Observation:
The active gathering of data from a primary source is observation. Observation of
living things makes use of the senses. The phrase refers to any information gathered
as part of the scientific endeavor. Observations can be quantitative, where a numerical
value is assigned to the observed phenomena through counting or measuring, or
qualitative, where merely the existence or absence of a property is documented. The
fundamental benefit of observation is that it is straightforward. Data can be gathered
as it happens. It is not necessary for the observer to question subjects about their
actions and reports from others.

5
By watching the workers at work, we used to be able to collect more data.
Additionally, combined with the information gleaned from the interview. Examples
include student files being stored on shelves, records posters hanging on tables,
several users needing service in each office, unstructured service (requiring a user to
visit multiple offices to receive a single service, and more. We see their time wastage
and draw the conclusion that their system has to be automated.
Secondary source
Secondary source is we do not participate in any activity directly but we can refer the
activity as secondary part. Such secondary source:
Document Analysis: For more information about the existing system we refer
relevant documents, such as others reading materials books, e-books and some
previously done project reports which are used as a reference to design the system we
are going to develop.
1.7.2 Development Methodology
Teams use the agile development methodology to minimize risk (such as bugs, cost
overruns, and changing requirements) when adding new functionality. In all agile
methods, teams develop the software in iterations that contain mini-increments of the
new functionality
allows software to be released in iterations. Iterative releases improve efficiency by
allowing teams to find and fix defects and align expectation early on. They also allow
users to realize software benefits earlier, with frequent incremental improvements .
• Reduced Maintenance: The primary goal of object-oriented development is the
assurance that the system will enjoy a longer life while having far smaller
maintenance costs. Because most of the processes within the system are encapsulated,
the behaviors may be reused and incorporated into new behaviors.
• Real-World Modeling: Object-oriented system tend to model the real world in a
more complete fashion than do traditional methods. Objects are organized into classes
of objects, and objects are associated with behaviors. The model is based on objects,
rather than on data and processing.
• Improved Reliability and Flexibility: Object-oriented system promise to be far
more reliable than traditional systems, primarily because new behaviors can be "built"
from existing objects. Because objects can be dynamically called and accessed, new
objects may be created at any time. The new objects may inherit data attributes from

6
one, or many other objects. Behaviors may be inherited from super-classes, and novel
behaviors may be added without effecting existing systems functions.
• High Code Re usability: Object-Oriented system is to design objects in a way that
can later on be used on other systems.
1.7.3Development Tools
The development tools are the hardware’s and software’s:

1.8 Software and Hardware tools

1.8.1 Software tools
To develop the System requires different types of software environments such as:
Tools Activities
Visual Studio Code To write the code
CSS, JavaScript, bootstrap Front end (client side coding)
PHP, JavaScript Back-end (Server-side coding)
HTML Client-side coding
MySQL Back-end (Database)
XAMPP, Apache Server To Test the website in local host
Mozilla Firefox, IE, Google Chrome, Browsers
Ms office word 2021 For Documentation
Edraw Max To draw UML Diagram and for designs
Table 1 software tools

1.8.2. Hardware tools

The hardware part of the operating environment is also necessary to develop the new
DDU Alumni student system. We used it in developing the system from the hardware
operating environment we listed above.
Tools Quantity Activity
PC 1 Almost all tasks of our project are performed
on computer.
USB Flash 1 Required for data movement
External Hard 2 For backup purpose
Disk
Table 2 hardware tools

1.9 Feasibility Study

7
The purpose of a feasibility study is to highlight potential issues that can arise if a
project is pursued, assess whether it is a good idea after taking into account all
relevant elements, and test the project's operational, financial, technological, and
organizational viability. A feasibility study ought to give management enough data to
determine:
Whether the project can be completed;

1. Whether the end result will be advantageous to the business and its intended users;.

2. What are the possibilities from which a solution will be chosen?

3. Exists a recommended substitute?

4. Determine whether our project is generally doable or not.

1.9.1 Technical feasibility
The proposed system can be easily maintained and repaired without requiring high
experts or technical supports, because the system will be installed in adaptable
technology’s and the employee of the organization have some knowledge about
technology by providing training and help how to use the system and can use the
system easily. So the system is technically feasible.
1.9.2 Economic feasibility
The project is economically feasible because the project reduces the cost of the
resources. But economic feasibility is expressed as cost- benefit analysis.
Costs:-our system use new technology and have centralized database cannot need
more
resources. It requires minimum amount of cost.
1.9.3 Operational feasibility
The system performs all operations to achieve the specified objective, User friendly
and interactive with the environment and the system will perform all operation that
the organization runs. And it will not have any difficulty or procedures to perform the
operation of the system. So the project is operational feasible.
1.10 Project Plan
2022G.C 2023 G.C
ID Activity Start Finish Duration December January February March April May June

8
 December January
1 Proposal 20,2022 5,2023 16 Days
System January February
2 Analysis 5,2023 6,2023 31 Days
System February February
3 Design 6,2023 29,2023 23 Days
March May
4 Implementation 10,2023 28,2023 78 Days
May June
5 Testing 28,2023 24,2023 26 Days
June June
6 Presentation 25,2023 28,2023 3 Days

1.10.1 Project Time Schedule

Table 3 time schedule

Teams role and responsibilities

Role Yonas Kalkidan Brook Redieat Adoniyas
Nigus Yeshitila Sintayeh Getache Sissay
u u w
Project Manager ×
Team meeting × ×
coordinator
Planning × ×
Data collection × × ×
Analysis × × x
System and Software × × × ×
Design
UX Designer × × x
Developer(front-end) × × ×
Developer(back-end) × × ×
Testing × × ×
Maintenance × × ×
Table 4 team role

9
1.10.2Budget Plan
Type of cost Name Quantity Unit Total price(in
prince(in birr)
birr)
Hardware Computer 1 40,000 40,000
part Flash(16Gb) 1 300 300
Paper 1 packet 300 300
Printing 2 copies 150 200
Software cost Xampp 1 Free Free
server

MS Word 1 Free Free

2013
VS code 1 Free Free

Window 10 1 Free Free

Total 40,800
Table 5 budget plan

Chapter 2
10
2. Requirement elicitation
In this chapter we try to explain Overview of Existing System Proposed Solution,
Preferred Solution, Domain Modeling with CRC cards, Essential Use case Diagram,
Essential Use case Documentation, Essential User interface Prototype
2.1 Overview of Existing System
The most common method of certificate verification now a days is a manual one,
requiring the institution or group that wants to check a result to visit the institute or
send a written request. The request will then be sent to academic affairs, which will
refer to the library or safe files to check if the person is enrolled in that organization
or not and to look for a duplicate certificate. This can take a lot of time, and
occasionally files are lost when moving from one office to another. In other cases,
they may also be missing or difficult to find.
Existing system is using manual way of performing any activities for many processes
such as:
 Verifying graduate by phone communication
 Verifying graduate by sending official transcript
 Verifying graduate through stamp and signature
 Verifying graduate by phone communication: - the graduates are going to the
organization to be hired in the organization and the organization manager will verify
the graduate by calling phone who graduates of the institute.
 Verifying graduate by sending official transcript:- the graduate wants to be hire in
the organization and the organization requests the graduate official transcript.
Then the graduate must be send the official transcript from their institute.
 Verifying graduate through stamp and signature:- the institutes are verifying the
graduate certificate through their institute stamps and signature.
The graduated person should be come to the office to request for the alumni service.
The first step is the person will pay cash in the bank and the bank will give his the
receipt. Then he go to registrar and registrar accept this receipt and they will give him
a biography form to fill it. After that they will upload to the sms then generate the
intended file.

2.2 Proposed system description

11
The proposed Alumni Student System will provide a more efficient and secure way of
verifying graduate certificates. The system will offer a user-friendly interface for
alumni and institutions or organizations to verify a graduate's credentials without the
need for manual intervention.
Institutions or organizations can access the system to verify a graduate's credentials
by searching for their name or other identifying information. The system will provide
real-time updates and alerts, ensuring timely and accurate information.
The proposed system will eliminate the need for manual verification through phone
calls or written requests, reducing the administrative workload and streamlining the
verification process. The system will be built using modern web technologies and will
be salable to accommodate a large number of users and data.
The proposed Alumni Student System will improve the efficiency and security of
graduate certificate verification, making the process more convenient for alumni and
institutions alike.
The proposed Alumni Student System can be developed using different methods
depending on the specific requirements and needs of the institution. Here are some
possible methods:
1. Web-based system: The system can be developed as a web-based application
accessible via a web browser. This method would enable users to access the
system from any device with an internet connection, making it more flexible
and accessible.
2. Mobile application: The system can be developed as a mobile application that
can be downloaded and installed on smartphones or tablets. This method
would provide a more convenient and streamlined user experience,
particularly for alumni who may be frequently on-the-go.
3. Hybrid system: The system can also be developed as a hybrid application that
combines the features of both web-based and mobile applications. This
method would provide the benefits of both web and mobile applications, such
as the flexibility and accessibility of a web-based application and the
convenience and streamlined user experience of a mobile application

4. Standalone software is a software application that is designed to run on a

single computer without requiring a network connection or a web browser. In
the context of the proposed Alumni Student System, a standalone system

12
 would refer to a software application that is installed and run locally on a
computer system, rather than accessed through a web browser.
2.3 Preferred Solution
we choose a web-based system from the above mentioned on possible methods
because of several advantages for the proposed Alumni Student System this are:
Accessibility: A web-based system can be accessed from any device with an
internet connection, including desktops, laptops, tablets, and smartphones. This
makes it more flexible and accessible for users, especially for those who may not
have access to a dedicated mobile device or prefer using a larger screen for
viewing and interacting with the system.
Ease of use: Web-based applications are generally more user-friendly and easier
to navigate than other types of applications. Users can simply log in to the system
using a web browser and access all the features and functionalities they need.
This eliminates the need to download and install additional software or
applications, reducing the complexity of the system and making it more intuitive
for users.
Cost-effective: Developing a web-based system is generally less expensive than
developing a mobile application or hybrid system. This is because web
technologies are widely available and easy to work with, and there is no need to
develop separate versions for different operating systems or devices.
2.4 Domain Modeling with CRC Cards
CRC for Admin
Administrator

Responsibility Collaborator

Alumni
Generate document

Respond for the request

Table 6 CRC for Administrator

13
CRC for Organization

Organization

Responsibility Collaborator

Insert id Administrator

Authenticate

Table 7 CRC for Organization

CRC for Alumni

Alumni

Responsibility Collaborator

Name
ID number Administrator
Graduation year
Reason
Receipt

Send request

Table 8 CRC for Alumni

2.5 Essential Use case Diagram

A use-case model is UML (Unified Modelling Language) which is a de facto standard
for object-oriented modelling, so use-cases and Use-case–based elicitation is
increasingly used for requirements elicitation. Model of how different types of users
interact with the system to solve a problem. As such, it describes the goals of the
users, the interactions between the users and the system, and the required behavior of
the system in satisfying these goals. Here is some information about our system use
case:
Actors
 Alumni
 Clerk
 Finance

14
  Organization
 Registral
Use Cases
 Official transcript
 Original Degree
 Student copy
 To whom it may concern
 Temporary certificate
 Login
 Logout
existing system

authenticate
ask for document
documentation

registrar

alumni generate
give receipt document

take document accept request

finance send approved list

accept receipt
for admin

clerk

send document
for authentication send/give
organization document

Figure 1 Essential Use Case Diagram

15
2.6 Essential use case documentation
An essential use case is complete, meaningful, and well-designed from the point-of-
view of users in some role or roles in relation to a system and that embodies the
purpose or intentions underlying the interaction.

Use case id Ucid e1

Use case name Ask and take documentation
Actor Alumni, clerk, finance and registrar
Description Alumni request and take the document.
Pre-condition The alumni must had been DDU students
Flow of events 1. The alumni request document to clerk physically.
2. The alumni then give the receipt to finance and finance
stamp paid in the copy of the receipt and give it to the
alumni.
3. The alumni then give the stamped receipt to clerk.
4. Then the clerk give the request and receipt to admin.
5. Then registrar check the student and generate the
document and give it to the clerk.
6. Then the clerk gave the document to the alumni.
7. The alumni take the document.
8. Use case end.

Alternative events Student name, ID number or both are incorrect.

A4. The admin the request to clerk and clerk gave back to the
alumni and he/she can correct the form gave back to clerk.
A4. The use case resume at step 4.
Post condition The alumni take the document.
Table 9 ask for document use case description

Use case id Ucid e2

Use case name Generate document
Actor registrar
Description The admin generate the document.
Pre-condition The request must have been sent.

16
 Flow of events 1. registral check the alumni
information.
2. The registrar order the system to
generate the request document.
3. Then the system generate the
document.
4. registrar send the document.
5. Use case end.

Alternative events Student name, ID number or both are incorrect.

The registral gave the request back to the clerk to correct it.
A4. The use case resumes at step2.
Post condition The document generated successfully.
Table 10 generate document use case description

Use case id Ucid e3

Use case name Authenticate the document
Actor Organization, clerk and registrar
Description The send the document and admin authenticate it.
Pre-condition The document must have been sent.
Flow of events 1. The organization send the document to the university.
2. The document delivered to clerk.
3. Then clerk gave it to admin.
4. Then registrar check the document by entering the
student name and id into the system.
5. Then registrar send response to the organization.
6. Use case end.

Post condition Document authenticate successfully.

Table 11 Authenticate document use case description

17
2.7 Essential User interface Prototype

Figure 2 Essential User Interface Prototype

18
Chapter 3
System Analysis
System Design is the process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements. Systems design
could be seen as the application of systems theory to product development. This
project is designed in a manner that solves the problems of the organization by
minimizing the workload that appears on the existing system. It provides more
efficient, reliable and time saving system. In this project design, the team will try to
show:
How the project is designed
What are tasks done under the whole project
The different modules and their way of functioning are described here.
Generally, the project will be designed by addressing all the above criteria of project
design.
This project design will describe how the project is designed, what tasks done under
this project and different modules and their way of functioning. This design of the
system is to involve converting the description of the proposed system into logical
and then physical design specification. We expect one can understand our new system
implementation because it gives full description about whole system. Also, one can
understand easily and enable to answer how the system developed and functioned in
simplified manner.
3.1 Functional requirements of the System
The functional requirement for the system describes the functionally or services that
the system is expected to provide.
They are fundamental building block requirements. It is a statement of exactly
what the system must do. The system has the following functional requirements:
 Generating official transcript for alumni students.
 Generating official degree for alumni students.
 Generating temporary certification for alumni students.
 Generating student copy.
 Document replacement.
 Alumni student can track their request.

19
  Authenticating graduated student tempo.
 Producing QR code for student tempo.
3.2 Non-Functional Requirements
Non-functional requirements generally specify the system’s quality attributes or
characteristics. Therefore, some of the Non-functional requirements, such as
reliability, performance, usability, error handling, and security, portability,
availability, and maintainability.
Reliable:
The system generates reliable information’s since the system retrieve all information
from the central data base.
Performance:
The system will have good performance:
 The system shall support use of multiple users at a time.
 It works very well with short response time.
Usability:
The system interface is interactive and easily understandable. The systems all
functionalities are easily usable for the user. But in order to use the system the user
should have a knowledge about how to handle a computerize system or should have
knowledge about computer.
Error Handling:
Our system handles the errors in a very efficient manner.It can tolerate to wrong
inputs and prompts the users to correct the inputs.
Security:
This system has a mechanism to restrict some resources to unauthorized users. The
system requires the user to provide his identifications before allowing accessing a
secure resource
Portability: The system can support any operating system and its platform
independent. Since we are developing a web-based system, this system can be
accessed from mobile devices, tablets, and personal computers without interruption.
Availability: The system able to give full time services to its users without any crash.
It is available for 24 hours per day and 7 days per week, unless the hardware is
interrupted and corrupted. Also, provides real information at right time.

20
Maintainability: The user interface is user friendly and interactive so it is easy to fix
while errors occur.
The failure of the system causes many problems repairing the system must not be
difficult since it undermines Users to easily fix the system.
3.3 System Modeling
A use case diagram is a way to summarize details of a system and the users within
that system. It is generally shown as a graphic depiction of interactions among
different elements in a system.
Use case diagrams will specify the events in a system and how those events flow,
however, use case diagram does not describe how those events are implemented.
A use case is a methodology used in system analysis to identify, clarify, and organize
system requirements. Use case diagrams are employed in UML (Unified Modeling
Language), a standard notation for the modeling of real-world objects and systems.
There are a number of benefits with having a use case diagram over similar diagrams
such as flowcharts.
3.3.1 System use case Diagram
A use-case model is UML (Unified Modelling Language) which is a de facto standard
for object-oriented modelling, so use-cases and Use-case–based elicitation is
increasingly used for requirements elicitation. Model of how different types of users
interact with the system to solve a problem. As such, it describes the goals of the
users, the interactions between the users and the system, and the required behavior of
the system in satisfying these goals. Here is the list of our use cases and actors.
Actors
 Alumni
 School Head
 Admin
 EMS worker
 Clerk
 Registrar
Use cases
 Generating official transcript
 Update document
 Generating temporary certification
 Generating official degree
 Generating Student copy
 Create account

21
  Update account
 Delete account
 Authenticate document
 Send document
 Take address
 View student
 Approve order
 View student list
 Add student
 Add Grade
 Write letter
 Track request
 Ask for document
 Logout
 Login
DDU Alumni Student System
Generating
Ask for official
document transcript
<<include>>

Update
Track request document
Logout <<include>>
Alumni
Generating
temporary
<<include>> certification
Write letter <<extend>>

Generating
<<include>> official degree
<<include>>

Generating
View <<include>>
<<include>> Login Student copy
School Head student list Registrar
<<include>>
<<include>>
Add Student

Approve <<include>>

order <<include>> Add Grade

<<include>>

Create
clerk View student account
<<include>>
<<include>>

Delete
account Admin
Take address <<include>>

<<include>>
EMS worker Update
account
Send document
Authenticate
document organization
22
Figure 3 use case diagram

3.3.2 System use case Diagram Documentation

Use case id Ucid1
Use case name Official transcript
Actor Registrar and alumni
Description Alumni request and registrar send the official transcript.
Pre-condition The alumni must had been DDU students and the registrar
must have an account.
Flow of events 1. Users enter into service
2. The system displays the services
3. Users choose official transcript service
4. The user fill up the user name, ID number,
graduation year and Email address text field
5. The users click submit button.
6. The system checks the validity of the user name, Id
number and Email address.
7. The system prompts successfully submit.
8. The registrar check the validity.
9. The registrar send the request document to the user
email address.
10. Use case end.
Alternative events User name, ID number or both incorrect.
The system display error message and promotes to re-enter
correct username and ID number.
The use case resumes at step4 of basic flow of events.
Post condition Document sent successfully
Table 12 Official transcript use case description

Use case id Ucid2

Use case name Original Degree
Actor Registrar and alumni
Description Alumni request and registrar send the original degree.

23
 Pre-condition The alumni must had been DDU students and pay cost
sharing and the registrar must have an account.
Flow of events 1. Users enter into service
2. The system displays the
services
3. Users choose original degree
service
4. The user fill up the user name,
ID number, graduation year,
Email address text field and
attach receipt with it
5. The users click submit button.
6. The system checks the validity
of the user name, Id number
and Email address.
7. The system prompts
successfully submit.
8. The registrar check the validity
of Id number with name and
the receipt.
9. The registrar send the request
document to the user email
address.
10. Use case end.
Alternative events User name, ID number or both incorrect.
The system display error message and promotes to re-enter
correct username and ID number.
The use case resumes at step4 of basic flow of events.
Post condition Document sent successfully
Table 13 Original Degree use case description

Use case id Ucid3

Use case name Student copy
Actor Registrar and alumni

24
 Description Alumni send request and the registrar send the copy.
Pre-condition The alumni must had been DDU students and the registrar
must have an account.
Flow of events 1. Users enter into service
2. The system displays the services
3. Users choose student copy service
4. The user fill up the user name, ID number,
graduation year and Email address text field
5. The users click submit button.
6. The system checks the validity of the user name, Id
number and Email address.
7. The system prompts successfully submit.
8. The registrar check the validity.
9. The registrar send the request document to the user.
10. Use case end.
Alternative events User name, ID number or both incorrect.
The system display error message and promotes to re-enter
correct username and ID number.
The use case resumes at step4 of basic flow of events.
Post condition Document sent successfully
Table 14 Student copy use case description

Use case id Ucid4

Use case name Temporary certificate
Actor registrar and alumni
Description Alumni send request and the registrar send the certificate.
Pre-condition The alumni must had been DDU students and the admin
must have an account.
Flow of events 1. Users enter into service
2. The system displays the
services
3. Users choose temporary
certificate service
4. The user fill up the user name,

25
 ID number, graduation year
and Email address text field
5. The users click submit button.
6. The system checks the validity
of the user name, Id number
and Email address.
7. The system prompts
successfully submit.
8. The registrar check the
validity.
9. The registrar send the request
document to the user.
10. Use case end.
Alternative events User name, ID number or both incorrect.
The system display error message and promotes to re-enter
correct username and ID number.
The use case resumes at step4 of basic flow of events.
Post condition Document sent successfully
Table 15 Temporary certificate use case description

Use case id Ucid5

Use case name To whom it may concern
Actor Alumni and School head
Description Alumni send request for to whom it may concern.
Pre-condition The alumni must had been DDU students and the school
head must have an account.
Flow of events 1. Users enter into service
2. The system displays the services
3. Users choose to whom it may concern service
4. The user fill up the user name, ID number,
Email address text field, and fill the request to
the concerned body.
5. The users click submit button.
6. The system checks the validity of the user name,

26
 Id number and Email address.
7. The system prompts successfully submit.
8. The School head check the validity.
9. The School head send the request document to
the user email address.
10. Use case end.
Alternative events User name, ID number or both incorrect.
The system display error message and promotes to re-enter
correct username and ID number.
The use case resumes at step4 of basic flow of events.
Post condition
Table 16 To whom it may concern use case description

Use case id Ucid6

Use case name Document authentication
Actor organization
Description The organization authenticate the alumni document.
Pre-condition The organization must have DDU graduated student
document.
Flow of events 1. The organization enters into the system.
2. The system displays the service button.
3. The organization enters to the service.
4. The organization choose document authentication.
5. The organization scan the document using QR code
or insert the tempo id number.
6. The system authenticates the document.
7. Use case end.

Alternative events The QR code is invalid.

The system display “document does not exist.”
Post condition Document authenticate successfully
Table 17 Document authentication use case description

Use case id Ucid7

27
 Use case name login
Actor Registrar, School head, clerk, EMS worker
Description The actors request to login to the system.
Pre-condition The actors must have an account.
Flow of events 1. The actors enter into system.
2. The system displays the services
3. The actors choose login button.
4. The actors fill up the user name and password.
5. The actors click login button.
6. The system checks the validity of the user name and
password.
7. The system login to their dashboard.
8. Use case end.
Alternative events User name, password or both incorrect.
The system display error message and promotes to re-enter
correct username and password.
The use case resumes at step4 of basic flow of events.
Post condition
Table 18 login use case description

Use case id Ucid8

Use case name Send document
Actor EMS worker
Description The EMS worker send the document to the alumni address
Pre-condition The EMS worker must have an account.
Flow of events 1. The EMS worker enter into system.
2. The system displays the services
3. The EMS worker click the document address.
4. The EMS worker match the document and the
document address
5. The EMS worker send the document to the address.
6. Use case end.
Alternative events User name, password or both incorrect.
The system display error message and promotes to re-enter

28
 correct username and password.
Post condition
Table 19 Send document use case description

Use case id Ucid9

Use case name Approve request
Actor Clerk
Description The Clerk approve order.
Pre-condition Alumni send request for document.
Flow of events 1. The worker enter into system.
2. The system displays the services
3. The worker click the requests.
4. The worker click alumni list.
5. The worker check if the alumni exist.
6. The worker give response to the request
7. Use case end.
Alternative events User name, password or both incorrect.
The system display error message and promotes to re-enter
correct username and password.
Post condition
Table 20 Approve request use case description

Use case id Ucid10

Use case name Document replacement
Actor Registrar and alumni
Description Alumni send request and the registrar send the replaced
document.
Pre-condition The alumni must had been DDU students and the registrar
must have an account.
Flow of events 1. Users enter into service
2. The system displays the services
3. Users choose student copy service
4. The user fill up the user name, ID number,
graduation year and Email address text field
5. The users click submit button.

29
 6. The system checks the validity of the user name, Id
number and Email address.
7. The system prompts successfully submit.
8. The registrar check the validity.
9. The registrar send the request document to the user.
10. Use case end.
Alternative events User name, ID number or both incorrect.
The system display error message and promotes to re-enter
correct username and ID number.
The use case resumes at step4 of basic flow of events.
Post condition Document sent successfully
Table 21 Document replacement use case description

3.3.3 Sequence Diagram

Sequence diagram typically used during analysis and design to document and
understand the logical flow of system. It Shows time sequences that are not easily
depicted in other diagrams describe the flow of messages, events, and actions between
objects.
graduate list
page Generating
home page admin page official degree data base

admin
open()
click admin ()
click generate
list() click department and
year()

submit() found ()

not found()
not found()

Generating
official degree()

Figure 4 Sequence diagram for Admin

School select write graduate

home select data student
head Write letter student
page letter base address
page letter page page
school page
headopen()
30
click student
head()
click
take id and letter()
 Figure 5Sequence diagram for Login

Select clerk select list of list of request graduate

home page data
page request page page student page

clerk
open()

click clerk()

click list of
request() display()
display list of request()

take name and id()

click graduate
student()

insert name and id()

submit()

Figure 6Sequence diagram for clerk

not found()

request denied()

request accepted()
home select authorized
login page validator data base
page login page
user
s open() 31
click login()
display
enter user
name and submit() valid()
password()
 Figure 7Sequence diagram for all login

select official
home page alumni page alumni form validator data base
degree
Alumni
open() click student
page()

select option()
display()
fill form()
submit()
valid
not valid
not valid save form()
saved()

give track
number()

Figure 8 Sequence diagram for alumni

select
authenticate Authenticate
home page page validator data base
page
organization
open()
select authenticate()
32
display()

insert id()

submit()
Figure 9Sequence diagram for organization

3.3.4 Activity Diagram

An activity diagram visually presents a serious of actions or flow of control in a
system similar to a flow chart or a data flow diagram. Activity diagram are often used
in a business process modeling. They can also describe the step in a use case diagram.
Activity modeled can be sequential and concurrent. In both cases an activity diagram
will have a beginning and an end.
An activity diagram has activity nodes and activity edges.
 Activity node: which are place holders for one or more steps within an activity.
 Activity edges: which is connection between activity nodes.
 An activity node has different control nodes (which coordinates flow among
other activity nodes).
 An initial node: is where the flow of control starts when an activity is invoked.
 A final node: is control node at which one or more flows within the given activity
stop.

33
Figure 10 Activity diagram for organization

34
Figure 11Activity diagram for alumni

35
Figure 12Activity diagram for school head

36
Figure 13 Activity diagram for admin

37
Figure 14Activity diagram for clerk

38
Figure 15Activity diagram for login

3.3.5 Class Diagram

Class diagrams are used to represent the structure of the system in terms of objects,
their notes, and the nature of the relationship between classes. It shows the static
features of the objects and does not represent any particular processing.
The class diagram describes the attributes and operations of a class and also the
constraints imposed on the system. The class diagrams are widely used in the
modeling of object-oriented systems because they are the only UML diagrams that

39

School Head

- headName:string
 can be mapped directly with object-oriented languages. The purpose of the class
diagram is to show how objects will interact with one another to achieve functional
requirements specified within the use case diagram.

1 1
n n

n
n

1
n
n
n

n 1

Figure 16Class Diagram

CHAPTER 4
System Design

40
System design refers to the process of deciding on the architecture, parts, modules,
interfaces, and data for a system in order to meet predetermined requirements.
The goal of designing is to establish the general framework upon which the system is
based and to gather adequate and clear data in order to direct the system's actual
execution.
Analysis models are converted into system design models through the process of
system design. We had been dealing with issues up to this point. In the process of
developing software, system design is the initial step into the area of solutions. This
chapter focuses on converting the analysis model into the design model that takes into
account the limitations and non-functional needs that were mentioned in the problem
statement and requirement analysis sections previously.
4.1 Design Goals
The purpose of design is to determine how the system is going to build and to obtain
the information needed to drive the actual implementation of the system. It focuses on
understanding the model how the software built.
System design is the detail investigation of system elements from logical view. After
the determination of the requirements, it is the design that follows. The design is all
about stating the design goals of the system and subdividing the system into smaller
parts to improve the problem in a modular approach.
The output of this phase includes description of each subsystems and the deployment
of the subsystems.
To give right service for the right user at the right time on subject of his/her need
make the design properly. The design goals are derive from the non-functional
requirement, which is the part of the analysis document, and they describe the quality
of the system.
4.2 System architecture
System architecture is the conceptual model that defines the structure, behavior, and
more of a system.
It provides a comprehensive view of the system, which includes its components, their
relationships, and how they interact with each other. System architecture is used to
describe the overall design of a system, including its hardware, software, network, and
other components.
It is also used to define the system's requirements, constraints, and design goals.

41
Architectural styles
The architecture used for the system is a three-tier architecture where a client can use
internet browsers to access any information related to our system provided by the
system using the internet.
Three tier architectures consist of three components distributed in three layers: A
three tier architecture is typically split into a presentation or GUI tier, an application
logic tier, and a data tier.
The client tier consists of a recent web browser, possibly extended with client-side
application components downloaded from the web server, and different clients used.

Figure 17 Architectural styles

The presentation or GUI tier contains the user interface of the application. Which
runs on the user’s computer.
It is also called client tier is responsible for formatting and presenting data on user’s
screen.
The presentation is “dumb”, meaning it does not make any application decisions. It
just forwards the user’s actions to the application logic tier.
In this tier users can use different type of devices such as PC, laptop, Tab and smart
phones to access the system from local network or through Internet.
The application logic tier makes all application decisions. This is where the
“business logic” is located.
This middle tier runs on a server and is often called the application server or server
side connects to the database and gives respond for client request.
It handles processing logic, business rule logic and data management logic.
The data tier stores the data used in the application. It is also called data storage tire

42
which uses database server for communication and executes queries completes them
via related API’s.
The data tier can typically store data safely, perform transactions, search through large
amount of data quickly etc. The client tier interacts with the web server through
simple HTML over HTTP.
4.3 Sub-system Decomposition
A subsystem decomposition for an Alumni Student System could be as follows:
1. User authentication and authorization subsystem: This subsystem will handle
user authentication, such as login and password management, and user
authorization, such as determining which users have access to specific features
and data.
2. Document database management subsystem: This subsystem will store and
manage alumni document data, including certificates, diplomas, transcripts,
and any other relevant information.
3. QR code generation and scanning subsystem: This subsystem will handle the
generation and scanning of QR codes associated with each document. The QR
code will be used to verify the authenticity of the document.
4. Document verification subsystem: This subsystem will provide a mechanism
for alumni to verify their documents online and for employers or educational
institutions to verify the authenticity of documents provided by alumni.
5. Reporting and analytics subsystem: This subsystem will provide data and
reports on document verification activity, such as the number of documents
verified and the number of failed verification attempts.
6. User feedback and support subsystem: This subsystem will handle user
feedback, such as questions and complaints, and provide support to users who
need assistance with the document verification process.

ASDVS 43
 Figure 18subsystem Decomposition

4.4 Hardware/software Mapping

Client server

Web/Application
server
HTTP
Web
Application
browser

TCP/IP

Data sever

data/shape
files

Figure 19hardware/software Mapping

4.5 Collaboration Diagram

44
 Collaboration diagram represent a combination of information taken from class,
sequence, and use case diagrams describing both static structure and dynamic
behavior of a system. Collaboration diagram show the message flow between objects
in an object oriented (OO) application, and also imply the basic associations or
relationships between classes. The rectangle represent the various objects involves
that make up the application, and the line between the classes represents the
relationships (association, aggregation, composition, dependencies, or
inheritance).Use a collaboration diagram (collaboration diagram: An interaction
diagram that shows, for one system event described by one use case, how a group of
objects collaborate with one another.) to show relationships among object roles such
as the set of messages exchanged among the objects to achieve an operation or result.

9: check()

10: response()

:login form
:database

8: step 4 continues()

4: fill username 7: try again()

and password() 6: validate()

3: display login
form() :validator

5: submit()

user 2: select login

form()

1: access user
interface()

:user interface

Figure 20all user login

2:access
:page
services() 45

:services
 Figure 21to request service

2: access
:admin page generate list

:generate list

1: access page() 3: display

generating
document()

7: return to step
4: take 4()
department and 10: response()
year()

admin

5: submit() 6: check()
9: check()

8: submit()

:validator
:database
Figure 22 for generating file

46
4.6 Deployment Diagram
Deployment modelling is used to show the hardware of the system, the software that
is installed in the hardware and also the middleware that is used to connect the
disparate machines to one and other. It also shows how the software and the hardware
components work together. We have described our 3-tier architecture using the figure
below

Client machine Application server

official
alumni transcript

original
registrar degree
Request
Request
MYSQL
organization HTTP temporary connector
certificate
Response Response Database

student copy
clerk

authentication
ems worker

document
school head replacement

track request

Figure 23Deployment

4.7 Persistent data storage and management

A data model will help us uncover and describe the entities that are important to our
system. These entities will become the tables in our database. The things we need to
remember about the entities or the attributes of our entities will become the columns
in our table. Persistent data management describes the persistent data stored by the
system and the data management infrastructure required for it. Persistent data
management deals with how the persistent data (file, database, etc) are stored and

47
managed and it outlives a single execution of the system. Information related to
programs basic information and other related information are persistent data and
hence stored on a database management system. Moreover, storing data in a database
enables the system to perform complex queries on a large data set. For complex
queries over attributes and large dataset Microsoft SQL Server is implemented, which
is a Relational Database Management System.

Figure 24Persistent diagram

48
 Alumni form
Attributes Data Type Data Size Format Key Constraints
Constraints
UID Number String (255) CSID-000-000 PK NOT NULL

First Name String (15) Text First Name NOT NULL

Last Name String (15) Text Last Name NOT NULL

Gender String (7) ‘Female/Male’ Gender NOT NULL

Phone String (15) +2519-0000-0000 Phone Number NOT NULL

Number
String (25) Text Type NOT NULL
Type
Integer (3) 000 Year of graduate NOT NULL
Year
String (15) Text Department NOT NULL
Department
String (8) Text Date of birth NOT NULL
Date of birth
Table 22Data Dictionary for Alumni form Attributes

Attributes Data Type Data Size Format Key Constraints

Constraints
UID No String (255) CSID-000-000 PK NOT NULL

First name String (15) Text First Name NOT NULL

Last name String (15) Text Last Name NOT NULL

Program String (25) Text Program NOT NULL

Year of Integer (3) 000 Year of graduate NOT NULL

graduate
Department String (15) Text Department NOT NULL

List of Request
Table 23 Data Dictionary for List of Request Attributes

Documents
Attributes Data Data Size Format Key Constraints
Type Constraints
UID Number String (255) CSID-000-000 PK NOT NULL

First Name String (15) Text First Name NOT NULL

Last Name String (15) Text Last Name NOT NULL

Gender String (7) ‘Female/Male’ Gender NOT NULL

Phone String (15) +2519-0000-0000 Phone Number NOT NULL

Number

49
 String (25) Text Type NOT NULL

Integer (3) 000 Year of graduate NOT NULL

String (15) Text Department NOT NULL

Type
Year String (8) Text Date of birth NOT NULL

TableDepartment
24 Data Dictionary for Documents Attributes

Account
Attributes Data Data Size Format Key Constraints
Type Constraints
Password String (255) CSID-000-000 PK NOT NULL

First Name String (15) Text First Name NOT NULL

Last Name String (15) Text Last Name NOT NULL

Phone String (15) +2519-0000-0000 Phone Number NOT NULL

Account String (25) Text Type NOT NULL

Department String (15) Text Department Optional

Table 25 Data Dictionary for Account Attributes

4.8 Graphical user interface Design

User Interface Prototyping is a technique, used to determine the functionality, user
interface data structure and other characteristic of a system. Prototyping is a quick
way to incorporate direct feedback from real users into a design. The anticipated user
interface prototype of the proposed system is shown

Figure 25 user interface

Conclusion

50
Considering the drawbacks of the existing system and importance of new
technologies the developed system, DDU Alumni Student System is very useful to
simplify a paper work, benefit graduated student and organizations in every aspect
and also saves time and manpower in the graduated student services. The system
works better than existing system (usability, speed, efficiency and effectiveness).
Security is also included in this system and users can access the services safely. The
system is also very useful in minimizing wastage of time and other utilities.

Recommendation
While doing this system the team has faced different challenges. But by the
cooperation of all the group members and an advisor the team is now able to reach to
the final result, i.e. all the group members strongly fought these challenge and take the
turn to the front. So now all the group members strongly recommend the department
that for the coming students, it has to provide them with better service than the present
in better hard ware, guaranteed software’s, giving orientations how to proceed,
offering guest to provide them with more experienced work, support morally,
manually, forming good relation with students, giving students description of each
phases and so on. So that it will get what it expects from its students and satisfy with
them.

51
References
(1).”What is uml diagram” http://www.uml-diagrams.org/examples. [Accessed 10
February 2023 2:45:05].
(2). "What is system requirement," Google, 08 December2010. [Online]. Available:
www.google.com.et/. [Accessed 15 February 2023 3:09:21].
(3). the object primer 3rd edition agile model driven development with uml 2.
[Accessed 14 February 2023 4:23:07].
(4). Modern system analysis and design third edition by JEFFERY A.HOFFER,
JOEY F.GEORGE, and JOSEPH S.VALACLCH read to do how to design the use
case diagram and identify use case; actor and symbol. [Accessed 03 March 2023
10:27:35].
(5).”Introduction about ddu” www.ddu.edu.et. [ Accessed 10 January 2023 4:50:10].
(6). "Requirements," 03 April 2015. [Online]. Available: http://www.google.co.uk/.
[Accessed 9 February 2023 8:37:22]. (8)."Non-functional requirement," 02 December
2017. [Online]. Available: www.projectRequerment.com. [Accessed 08 February
2023 9:57:29]

52
Signed Declaration Sheet
I, Yonas Nigussu the undersigned on behalf of the group, declare that this project is
our original work and has not been presented for a degree in any other university, and
that all source of materials used for the project have been duly acknowledged.
Declared by:
Name of Team Leader: _______________________
Signature: __________________________________
Date: ______________________________________
Confirmed by advisor:
Name: _____________________________________
Signature: __________________________________
Date: ______________________________________

53