Ousps SRS

Software Requirements Specification for Online University Selection and Placement System for NEAEA 2021
Software Requirements
Specification
for
ONLINE UNIVERSITY SELECTION AND

PLACEMENT SYSTEM FOR NEAEA
Version 1.0
Prepared by
Group Name: S.C.U.M
Bisrat Abay 1745/10 bisratabay@gmail.com
Fasika Solomon 1750/10 elfineshnfs@gmail.com
Dereje Lemma 1747/10 derejelemmacr7@gmail.com
Solomon Wammi 1769/10 solomonwam@gmail.com
Ammanuel Desalegn 1739/10 amandes21@gmail.com
Advisor: Mr. Gizachew Belayneh (MSc.)
Date: Aug 23, 2021

Contents
List of figures ................................................................................................................................................................ ii
1 Introduction .............................................................................................................................................................1
1.1 Document Purpose .............................................................................................................................................2
1.2 Product Scope ....................................................................................................................................................3
1.3 Intended Audience and Document Overview ....................................................................................................4
1.4 Definitions, Acronyms and Abbreviations .........................................................................................................5
1.5 Document Conventions ......................................................................................................................................5
1.6 References and Acknowledgments ....................................................................................................................6
1.6.1 Acknowledgments ......................................................................................................................................6
1.6.2 Reference ...................................................................................................................................................6
2 Overall Description .................................................................................................................................................7
2.1 Product Overview ..............................................................................................................................................7
2.2 Product Functionality .........................................................................................................................................8
2.3 Design and Implementation Constraints ............................................................................................................8
2.4 Assumptions and Dependencies .........................................................................................................................9
3 Specific Requirements ...........................................................................................................................................10
3.1 External Interface Requirements ......................................................................................................................10
3.1.1 User Interfaces ........................................................................................................................................10
3.1.2 Hardware Interfaces ...............................................................................................................................11
3.1.3 Software Interfaces ..................................................................................................................................11
3.2 Functional Requirements .................................................................................................................................12
3.2.1 F1: Setting (Activation, Deactivation of Registration time and login & Backup and Recovering
Database) ................................................................................................................................................................12
3.2.2 F2: User Management ............................................................................................................................12
3.2.3 F3: Send/Receive Message ......................................................................................................................12
3.2.4 F4: Allow Placement Computation .........................................................................................................12
3.2.5 F5: Add Universities information............................................................................................................13
3.2.6 F6: Submit University preferences ..........................................................................................................13
3.2.7 F7: View placement .................................................................................................................................13
3.2.8 F8: Show selected University ..................................................................................................................13
3.2.9 F9: Registration ......................................................................................................................................13
3.3 Use Case Model ...............................................................................................................................................13
3.3.1 Use case 1: Login ....................................................................................................................................16
3.3.2 Use case 2: Settings.................................................................................................................................17
3.3.3 Use Case 3: Activate Registration Time ..................................................................................................18
3.3.4 Use case 4: Backup database ..................................................................................................................19
3.3.5 Use case 5: Recovering Database ...........................................................................................................19
3.3.6 Use case 6: Activate login .......................................................................................................................20
3.3.7 Use case 7: User Management ................................................................................................................21
3.3.8 User case 8: Create Account ...................................................................................................................23
3.3.9 Use Case 9: Message ..............................................................................................................................24
i
3.3.10 Use case 10: Allow Placement Computation ..........................................................................................25

3.3.11 Use case 11: Add university information ................................................................................................27
3.3.12 Use case 12: Post Exam Schedule ...........................................................................................................28
3.3.13 Use case 13: Notification ........................................................................................................................30
3.3.14 Use case 14: Update Information............................................................................................................31
3.3.15 Use Case 15: Submit Universities information .......................................................................................32
3.3.16 Use Case 16: Student Registration ..........................................................................................................33
3.3.17 Use Case 17: View Placement.................................................................................................................35
3.3.18 Use case 18: Logout ................................................................................................................................35
4 Other Non-functional Requirements ...................................................................................................................37
4.1 Performance Requirements ..............................................................................................................................37
4.2 Availability Requirements ...............................................................................................................................37
4.3 Maintainability Requirements ..........................................................................................................................37
4.4 Safety and Security Requirements ...................................................................................................................37
4.5 Software Quality Attributes .............................................................................................................................38
4.5.1 Usability ..................................................................................................................................................38
4.5.2 Correctness .............................................................................................................................................38
4.5.3 Flexibility ................................................................................................................................................38
4.5.4 Availability ..............................................................................................................................................38
4.5.5 Reliability ................................................................................................................................................38
4.5.6 Adaptability .............................................................................................................................................38
List of figures
Figure 1 General Diagram of OUSPS ................................................................................................................... 7
Figure 2 Sample home page interface ..............................................................................................................11
Figure 3 Use case diagram ................................................................................................................................15
ii
Revisions
Version Primary Author(s) Description of Version Date Completed
1.0 BisratAbay 1st version 8/22/2021

FasikaSolomon
DerejeLemma
SolomonWami
AmanuealDesalegn
1 Introduction
Currently in Ethiopia students join University according to their choice and result which
is done manually, which is waste of time and energy, and because of this we are going to
develop a computerized system for the NEAEA to help students to submit their university
preference online. After the exam takes place students will have to choose a university,
which is done recently by manual, but in the proposed system students will choose
Universities with all given information online. In fact, which is not manual and student will
have the ability to view their placement online but in this project, we want to improve it. The
site, which is currently available, is only to see their result and placement. However, we
found it like it’s not user interactive and some of the pages did not work correctly.
Generally, we would like to solve all this problems and aims to provide flexible and
better web based Online University selection and placement system for NEAEA.
1
1.1 Document Purpose

This is Software Requirement Specification (SRS) for Online University Selection and
Placement System (OUSPS). It will explain the purpose and features of the system, the
interfaces of the system, the constraints under which it must operate, and how the system
will react to external stimuli.
This document intended for both stakeholders and developers of the system. In addition,
the purpose of the Software Requirements Specification (SRS) document is to describe the
external behavior of the Ethiopian Online University Selection and Placement System.
Requirements Specification defines and describes the operations, interfaces, performance,
and quality assurance requirements of the Online University Selection and Placement
System.
This document also describes the non-functional requirements such as performance,

usability, Reliability, and so on. It also describes the design constraints that are to be
considered when the system is to be designed, and other factors necessary to provide a
complete and comprehensive description of the requirements for the our system or website.
2
1.2 Product Scope

At present, there are one national exam, which is EHEECE (Ethiopian Higher
Education Entrance Certificate Examination) also, known as Grade 12 national exam. After
students have took the national exam they will be announced and can see their result as
well as their placement through neaea.gov.et/Home/Student web page.
The main activity of NEAEA is to announce and post the date of the exam, their total
exam result out of 700, and student’s university placement as well.
General objectives
The general objective of this project is automating the University Selection and
Placement System in Ethiopia.
Specific objectives
 To minimize paper wastage and information inconsistencies in using paper.
 To make the students information be secured.
 To minimize the time taken to process and maximize the performance of the
system.
 To allow good data management to reuse the recorded data for analysis.
3
1.3 Intended Audience and Document Overview

The intended audience for this document consists of Mr. Gizachew Belayneh (MSc.)
who is our advisor, our developers’ team of this project and the examiner and software
engineering staffs and for anyone who has interest in software engineering.
1.3.1 Document overview
Sequence of reading this document is suggested as top to bottom beginning from the
introduction. The next chapter, the Overall Description section, of this document gives an
overview of the functionality of the product. It describes the informal requirements and is
used to establish a context for the technical requirements specification in the next chapter.
This part starts with product overview that describes the context and origin of product being
specified in this SRS.
The third chapter, Requirements Specification section, of this document is written
primarily for the developers and describes in technical terms the details of the functionality
of the product. In this part, external interface requirement is presented. These include user
interface requirement, hardware interface requirement and software interface requirement.
The four chapters, other Non-Functional requirement, that are not directly obtained by
a single component but obtained as a result of total system functioning are described these
non-functional requirements include performance requirement.
4
1.4 Definitions, Acronyms and Abbreviations

AGM: - All Group Member
GUI: - Graphical User Interface.
HTTP: - Hyper Text Transfer Protocol.
ICT: - Information and Communication Technology
ID: - Identification card.
IEEE --- Institute of Electronics and Electrical Engineering Standard
NEAEA: - National Educational Assessment and Examination Agency.
OUSPS: - Online University Selection and Placement System.
PHP: - Hypertext Preprocessor
SQL: - Structured Query Language regarding database.
TCP: - Internet Protocol Version
UI: - User Interface
UML: - Unified Modeling Language.
1.5 Document Conventions

In this documentation, all texts including topics and subtopics are written in Arial font
style. All texts with font size 12, topics with font size 14, and chapters with font size 16.
Chapters and Subtopics are written in bold (This document follows the IEEE formatting
requirements).
5
1.6 References and Acknowledgments

1.6.1 Acknowledgments
First and foremost, we would like to thank God Almighty for giving us the strength,
hope, ability and opportunity to undertake this documentation. Furthermore, we would
also like to acknowledge with much appreciation the crucial role of our Advisor Mr.
Gizachew Belayneh (MSc.). In addition, we would like to express our deepest
appreciation to all who help us to finish our project documentation writing successfully.
1.6.2 Reference
[1] “WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems
Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapters 8” [offline]
[2] “www.google/object oriented system analysis and design.com” [Online]
[3] “www.wikipedia.com” [Online]
[4] Lecture slides
6
2 Overall Description
2.1 Product Overview

OUSPS is a self-contained web-based system that performs placement computation
as well as let’s the students to submit their university preference in an orderly manner. The
system which we are going to develop is new for the NEAEA because there is no a
computerized system for the organization before.
The general diagram that illustrate the process of Online University Selection and
Placement System is:
USER OUSPS
WEB SERVER
DATABASE
Figure 1 General Diagram of OUSPS
7
2.2 Product Functionality

The system to be developed will give easy and fast way to students to submit their
University preference and see their University placement online.
The major product functionalities are:

 Allow the students to get further information about the Universities (distance
from capital city, intake capacity, given program)
 Allow the students to submit their University preference in order manner.
 Allow the schools to feed their students personal information.
 Notifying the placement by computing according to the criteria.
2.3 Design and Implementation Constraints

Some of the constraints during the development of our project;
 Time limitation: the time to build our project is not enough to include more
functionality to the system
 Hardware limitation
 Lack of electric power
 Lack of internet connection
 Unrest in our campus
 Operating language
8
2.4 Assumptions and Dependencies

 It is assumed that any users has an internet access and can do online manipulations.
The performance of depends on the quality and speed of the internet connection.
 The user should know English language.
 One assumption about the product is that it will always be used when server is
accessible only. If there is no any connection between server and clients, the system
is not Accessible.
 The user must have a user account on the system to use the system.
9
3 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
This is how the user will interact and access the system, and the goal of the user
interface design is to make the user’s interaction as simple as possible, in terms of
accomplishing user’s goal. Generally, UI is used to connect end users with the system.
The system composed of multiple graphical user interfaces. Some of them are as follows:
 Home – this interface displays new feeds and other related information about the
agency like Mission, and goal of the agency.
 Login – this interface is where the users login.
 Register – this interface is where the students get registered into a system.
 Profile – this user interface is presented when the user wants to update the profile
information
1. Home interface: This form contains some links, which lead it to the concerned page,
and if the user has an account, he/she will directly go to concerned page by entering
their E-mail address and password.
10
Figure 2 Sample home page interface
3.1.2 Hardware Interfaces
Hardware interface of our system are clients and servers. Clients are each and every
computer that have browser to connect to the system.
Server is the computer that has a database for our system and performs the
registration of the user/student, receive petition of students, show their university
placement to the students, and store all the information’s.
3.1.3 Software Interfaces

The software interface of our system is DB of the system and operating system that
is essential for the system to operate within the hardware interface. The database of the
system is created by XAMPP server. The operating system used is windows operating
system 10.
11
3.2 Functional Requirements

Functional requirements describe the interactions between the system and its
environment. The environment includes the user and any other external system with which
the system interacts. Generally, functional requirements are expressed in the form system
must do (requirement).
3.2.1 F1: Setting (Activation, Deactivation of Registration time and login &
Backup and Recovering Database)
The administrator can recovers the database that we already have if any failure
occurs to prevent any faults or lose of information from database. The registration and login
time will be activated or deactivate by putting specified date of time that how much the
registration and login time should last.
3.2.2 F2: User Management

The Administrator should be able to manage the users registered to the system, so
the administrator can add users (i.e the agency), activate/deactivate students’ registration
time and login, and Backup and Recover database.
3.2.3 F3: Send/Receive Message

The administrator can send/receive message to/from agency director and the agency
director send/receive message to/from students and their school, in this case each users
(actors) has a choices to select to whom for sending a message.
- If the message is concerned to the students the agency director send it to the
students.
- If the message is concerned to the agency director the administrator send it to the
agency director.
- If the message is concerned to the IT technician the agency send it to IT
technician.
3.2.4 F4: Allow Placement Computation
Here also the agency director is responsible to allow the system to start placement
computation.
12
3.2.5 F5: Add Universities information

The agency is responsible to feed the details of all Universities (Distance from capital
city, intake capacity, list of given programs).
3.2.6 F6: Submit University preferences

Students must be registered to system before they submit for University preferences.
Here students see all available Universities and some information about the university and
lets them to submit for universities preference as their needs.
3.2.7 F7: View placement

The student must login to system to see his/her placement. After login to system, they
can see where he/ she is placed through the website.
3.2.8 F8: Show selected University

The students can see their University placement according to their entrance result
and their choice.
3.2.9 F9: Registration

To use the system students should first register and need to have their own account
in order to use the system. The students should provide their username, registration ID
number, E-mail, answer for some security questions (i.e incase if they forgot their password)
and password. Any user after registered to the system they should provide their username
/or E-mail and password in order to login.
3.3 Use Case Model

In the use case diagram given below, we have displayed how our users interact with
the system to accomplish their goals and responsibilities. Here in our diagram we have 4
actors (Administrator, the agency, IT technician, and Students), 3 of which are the main
users (Administrator, Agency director, and Students). In every use case mentioned in the
diagram, the actions of the users are described, and how these use cases are related to one
another is represented by the help of arrows. In our Use case diagram all functionalities of
the system are displayed.
13
The actors of our system are as follow:
o Administrator
o The Agency
o Students
o IT Technician
The following are list of Use Cases:
o Setting (Activation, Deactivation of Registration time and login, change user account
type & Backup and recovering Database)
o User Management
o Create Account
o Send/Receive Message
o Allow Placement Computation
o Add Universities information
o Post Exam Schedule
o Notification
o Update Information’s
o Submit University Preferences
o View University Placement
o Registration
o Login
o Logout
The following Use Case diagram on the other hand shows how the Agency director,
Administrator, Students, and IT technician interact with the proposed system.
14
Figure 3 Use case diagram
15
3.3.1 Use case 1: Login
Use case Login

UC ID UC1
Author AGM
Purpose Let users to access the system
Requirements Traceability The system lets users to login
Priority High
Pre-Conditions User is not logged into a system. User has
previously enrolled in system.
Post-Conditions User is logged in to system
Actors Agency director, Administrator, Students,
and IT technician
Flow of event 1. The user open the website using the
URL
2. The user clicks login link
3. The system displays the login page
4. The user Insert username and
password.
5. The user clicks on login button
6. The system authenticates the user.
7. The system will display the home
page of the system.
Alternative Flow of event 6.1 Unregistered user cannot login.
Exceptions 8. If the user does not enter username
or password, the system informs the
user to enter the required fields.
9. If the username or password is
invalid, the system will respond
“Invalid username or Password”.
16
3.3.2 Use case 2: Settings
Use case Settings
UC ID UC2
Author AGM
Purpose Let’s administrator to making any change,

and recover database of a system.
Requirements Traceability The system shall allow administrator to
store a backup file and to recover later
Priority High
Pre-conditions Login to the Administrator main task page
Post conditions The Administrator can manage users

account and make any change to a system
Actors Administrator
Includes UC1
Extends UC3,UC4,UC5,UC6
Flow of Events 1. The admin login to his/her account

2. The admin click on settings page
3. The admin can remove,
activate/deactivate registration
time and login, change user
account type, and can store a
backup file and recover database
Alternative Flow of Event 4. Unrecognized user can’t make any

change
Exceptions 5. If the administrator tries to change

the account type of his/her own
account displays error message of
17
“Can’t change your own account

type!”
3.3.3 Use Case 3: Activate Registration Time
Use case Activate registration time
UC ID UC3
Author AGM
Purpose To let the students get registered in a

specified time limit
Requirements Traceability -
Priority High
Pre-conditions Login to the administrator main task page
Post conditions The registration time will be active
Includes -
Extends UC2

2. The admin click on settings active
registration time button in menu
bar
3. The registration time will be
activated
Alternative Flow of Event 4. Unrecognized admin can’t make

any change
Exceptions -
18
3.3.4 Use case 4: Backup database
Use case Backup database
UC ID UC4
Author AGM
Purpose To store a backup file of the whole system
Requirements Traceability The system shall allow the administrator to

sore a backup file
Priority High
Pre-conditions Assuming any failure could happen to the

system
Post conditions All database file stored
Extends UC2
Includes -
Flow of Events 1. The administrator select setting link

from menu bar
2. Clicks on backup
3. The system stores a backup file
Alternative flow of events 1. Unregistered user cannot neither

backup or recover
Exceptions -
3.3.5 Use case 5: Recovering Database
Use case Recovering Database
UC ID UC5
19
Author AGM
Purpose To recovery the database if failure occurs

to the system.
Requirements Traceability The system shall allow the administrator to

recover DB
Priority High
Pre-conditions Any failure or lose of data from database
Post conditions Errors or lose of data are fixed and the

system kept healthy
Includes -
Extends UC2
Flow of Events 4. The administrator select setting link

from menu bar
5. The system check whether there is
a backup file stored or not
6. The system recovers the database
data
Alternative flow of events 2. Unregistered user cannot neither

backup or recover
Exceptions 7. If there is no backup file stored the

system response with a message
“No back up file found!”
3.3.6 Use case 6: Activate login
Use case Activate login
20
UC ID UC6
Author AGM
Purpose To let users to login into a system
Priority High
Pre-conditions Login to the administrator main task page
Post conditions The login state will be activated
Includes -
Extends UC2

2. The admin gets all user account of
the system
3. The admin click on
active/deactivate link
4. The login state will be active or de-
active
Alternative Flow of Event 5. Unrecognized admin can’t make

any change
Exceptions -
3.3.7 Use case 7: User Management
Use case User Management

UC ID UC7
Author AGM
21
Purpose The administrator is responsible for the

entire situation regarding students and
agency account removing and the like
issues.
Requirements Traceability The system shall let administrators to
manage users who are registered in the
system
Priority High
Pre-conditions The administrator clicks on the admin page
and the following basic course of actions
are followed.
Post conditions Agency, students, and IT
technician/school account is either
created or removed if all the necessary
forms are filled, otherwise the system
response error message.
Extends -
Includes UC1
Flow of Event 1. The Administrator first login to
his/her account
2. The admin click on user
management page
3. Admin can manage any users in a
system
Alternative Flow of event 4. Unauthorized admin can’t manage
user
Exception 5. If the administrator try to delete his
own account, the system response
22
with error message “Can’t delete

the account\!”
3.3.8 User case 8: Create Account
Use case Create account

UC ID UC8
Author AGM
Purpose To create an account for the agency and
for each preparatory schools
Requirements Traceability The system shall allow admin to create a
user account for the agency and for school
Priority High
Pre-conditions A valid E-mail address
Post conditions The users get registered to the system
Actors Administrator, agency director, IT
technician
Extends -
Includes UC1
Flow of Event 6. The users first login to his/her
account
7. The user click on create account
page
8. The user fill all the required field
9. The account will be created
Alternative Flow of event 10. Unauthorized user can’t create
account
Exception 11. If the user tries to create account
using the same E-mail address for
different account, the system
23
displays error message “The E-mail

address exist!”
3.3.9 Use Case 9: Message
Use case Send/Receive Message
UC ID UC9
Author AGM
Purpose Let students to send their petition directly

to the agency, and agency directory to
communicate with administrators.
Requirements Traceability The system shall let users to send/receive

message through the system.
Priority Medium
Pre-conditions Users should have to select to whom

he/she wants to send a message (i.e
student, director or administrator).
Post conditions The message will sent to intended users
Actors Administrator, Agency director, Student
Includes UC1
Flow of Event 1. The user first login to their account

2. The users click on send message
page
3. The users write the message
4. The users selects to whom to send
the message
24
5. The message will send to intended

user
Alternative flow of Event 6. Unregistered user cannot send a

message.
Exception 7. If the user do not select to whom to

send the message and click on
send button, it display an error
message “Select to whom to send
message”
8. If the user do not write, the
message and clicks on send button,
display error message of “write the
message, Please!”
3.3.10 Use case 10: Allow Placement Computation
Use case Allow Placement Computation

UC ID UC10
Author AGM
Purpose To select university for each students
according to their result
Requirements Traceability The system shall allow to compute for
university placement
Priority High
Pre-conditions The student should be registered into the
system
Post conditions For each students who fulfill the criteria,
the institution will be selected
Actors Agency
25
Extends -
Includes UC1
Flow of Event 1. The agency director first login to
his/her account
2. The director click on compute
placement button
3. Get all Universities total intake
capacity
4. Add 12 point only for all Natural
female students
5. Add 10 point only for all Social male
students
6. Add 22 point only for all Social
female students
male students from a developing
regions and pastoralist areas
students from a developing regions
and pastoralist areas
female students from a developing
female students from a developing
male students who are disabled
students who are disabled
26

female students who are disabled
female students who are disabled
15. Using a Sequential sorting
algorithm sorts all students in
decreasing order according to their
total result
16. Decide the cut-off point according
to the total university intake
capacity
17. Start placing each students to
university according to their choice
until the university intake capacity
maximized
18. If the intake capacity fills up go to
students next university preference
Alternative Flow of event 19. Unauthorized director can’t
compute for placement
Exception -
3.3.11 Use case 11: Add university information
Use case Add Universities Information
UC ID UC11
Author AGM
Purpose The director responsible for adding,

deleting and update any kind of
information about Universities.
27
Requirements Traceability The system shall allow the agency to add

all universities and related information’s
Priority High
Pre-conditions Login into the agency director page
Post conditions The agency director can add, update or

delete universities information’s.
Actors Agency Director
Includes UC1
Flow of Events 1. The agency director first login to

his/her account
2. The agency director click on add
universities information page
3. The director can add University
name, distance from capital city,
intake capacity, given programs
Alternative flow of Event 4. Unauthorized user can’t add any

information
Exceptions 5. If the director add the same

university name displays an error
message of “University name
duplicated!”
3.3.12 Use case 12: Post Exam Schedule
Use case Post exam schedule

UC ID UC12
Author AGM
28
Purpose To notify the students when the exam will

be
Requirements Traceability The system shall allow the students to
know when the exam is
Priority High
Pre-conditions -
Post conditions The exam schedule will be posted
Actors Agency
Extends -
Includes UC1
Flow of Event 1. The agency director login to his/her
account
2. The director click on post exam
schedule button on menu bar
3. The system displays the exam
schedule form page
4. The director write the START and
END date of the exam
5. The director clicks on post button
6. The schedule will be posted
Alternative Flow of event 7. Unauthorized agency director can’t
make exam schedule
Exception 8. If the agency tries to schedule the
exam with the same number of
date, the system will display an
error message.
9. If the agency try to schedule the
exam with different academic year,
the system also displays error
message
29
3.3.13 Use case 13: Notification
Use case Notification
UC ID UC13
Author AGM
Purpose To let the students get a notification about

exam schedule and other necessary
information’s
Requirements Traceability The system shall allow the agency to post
notifications
Priority Medium
Pre-conditions Write the notification subject and content to

be posted
Post conditions The agency post notification to all users of
the system at once
Actors Agency director
Includes UC1
Extends -
Flow of Events 1. The director login to his/her

account
2. The director click on notification
button on menu bar
3. The system response the
notification page, which contain a
form to be filled
30
4. The agency write the notification

type, and content and click on post
button
5. The notification will be posted
Alternative Flow of Event 6. Unrecognized agency can’t post a

notification
Exceptions 7. If the agency tries to post the

notification with no content or
subject the system response with
an error message
3.3.14 Use case 14: Update Information
Use case Update information
UC ID UC14
Author AGM
Purpose To update some users information
Requirements Traceability The system shall allow the users to update

some information
Priority Medium
Pre-conditions Login to the user main task page
Post conditions The information will be updated
Actors The agency, IT technician
Includes UC1
Extends -
Flow of Events 6. The user first login to their account
31
7. The user gets the information to

make a change
8. The user makes a change and
click on update button
9. The information will be updated
Alternative Flow of Event 10. Unrecognized user can’t make an

update
Exceptions -
3.3.15 Use Case 15: Submit Universities information
Use case Submit University Preference
UC ID UC15
Author AGM
Purpose To let the students to submit their

university preference in an order manner
Requirements Traceability The system shall allow students to submit
their choice of institute
Priority High
Pre-conditions Student must select university preference

orderly
Post conditions Students submit their universities choice.
Actors Students
Includes UC1
Flow of Events 1. First the students login into their

account
32
2. The students click on submit

university preference page
3. The submit their choice in an order
manner
4. The students submit their
preference
Alternative flow of events 5. Students without account and login

into a system cant submit
university preference
Exceptions 6. If the students do not submit their

preference in and orderly manner
response with error message
“University preference order
duplicated!”
3.3.16 Use Case 16: Student Registration
Use case Student registration
UC ID UC16
Author AGM
Purpose The students will be registered for the

predefined year
Requirements Traceability The system shall allow students to register
into a system.
Priority High
Pre-conditions Students should have to be registered,

before they submit for university
33
preference and see their placement,

through their school account.
Post conditions The student gets registered to the system
Actors Students
Includes UC1
Flow of Events 1. The student need to contact the IT

technician first
2. The account will be created for
each student through their school
account
3. The students have account in the
system
Alternative flow of events 4. The students not contact with IT

technician will not get registered
Exceptions 5. If any information is missed during

registration time display the
system response with an error
message “Please fill the required
information!”
6. If the student registration ID exists
display and error message,
“Registration ID found exist!”
7. If the student E-mail address exists
display error message of “Email
account exist!”
34
3.3.17 Use Case 17: View Placement
Use case View Placement
UC ID UC17
Author AGM
Purpose To let the students to see where they are

placed
Requirements Traceability The system shall allow let students view
the university name where they placed
Priority High
Pre-conditions The student must login to their account to

see his/her placement
Post conditions The students can see where they are
placed
Actors Students
Includes UC1
Flow of Events 1. The student opens the system

2. The student login to a system
3. The clicks on view placement page
4. The students can see where they are
placed
Alternative flow of events 5. Unregistered students cannot login
and view placement
3.3.18 Use case 18: Logout
Use case Log out

UC ID U18
Author AGM
35
Purpose To logout from the system

Priority Medium
Pre-Conditions User is logged in to the system
Post-Conditions User is logged out of the system
Actors Agency director, Administrator, Student,
and IT technician
Extends UC1
Flow of Events 1. The user first needs to login to a
system
2. The user clicks on logout button
3. The user logout from the system
Alternative Flow of event -
Exception -
36
4 Other Non-functional Requirements
4.1 Performance Requirements

 The system shall send out confirmation message after it receives a successful
student’s registration submitted form within 5 seconds.
 The login information shall be verified within five seconds.
 The system is expected to serve large number concurrent request.
4.2 Availability Requirements
 The system should be available at all times by keeping the online servers up and
running for 24/7.
4.3 Maintainability Requirements
 The application should be easy to extend. The code should be written in a way that
it favors implementation of new functions, in order for future functions to be
implemented easily to the application.
 All PHP pages used by the OUSPS web site will be centrally located within the file
structure so that any update will affect all areas where the modified code is called.
4.4 Safety and Security Requirements
 Passwords must be a minimum of eight characters and must contain one to seven
digits.
 All exchanges from client to server involving private data shall occur using the highest
available level of secure connection (e.g., https).
- Users Password Security: All the passwords that are generated or

accepted must be stored in database in an encrypted form.
- Students Create Account Security: The security of creating account
for the students in the system. If a student’s want to create an account
and during registration time if username and/or E-mail address exists,
then the students notified to enter other username.
37
- Director login securely: If a director tries to log in to a system with a

non-existing account, then the director should be notified about login
failure.
- Administrator login securely: If administrator tries to login to system
with a non-existing account, then the administrator should not be
logged in and should be notified about a login failure.
- Student login Security: If students tries to login to system with a non-
existing account, then students should not be logged in and should be
notified about a login failure.
- Communication Security: Security of the communication between
the system and server.
4.5 Software Quality Attributes

4.5.1 Usability
The placement website design shall allow deployment on both Windows and UNIX
(Linux) servers. The design should support Windows Server, and UNIX.
4.5.2 Correctness
The system provides correct response to the correct request, which is
made by the client.
4.5.3 Flexibility
The system is flexible for all users when they enter the correct login information.
4.5.4 Availability
The system is available for the user as long as there is an internet connection.
4.5.5 Reliability
The data or information which is retrieved from the system is accurate (required) in
deserved time.
4.5.6 Adaptability
The system interface that will develop is attractive and easily understand to the
users, which reflect the adaptability of the system.
38
Appendix A – Data Dictionary
Name of object Description
Malfunction fail to function normally
Menu a list of commands or facilities, especially

one displayed on the screen
User The OUSPS system clients
IT technician One that teaches ICT
Student One that learn in schools
UID Unique id number given for students
24/7 24hrs of the day, and 7 days of the week
39
Appendix B - Group Log

Group Meetings:
- We have been meeting each other 2 hours per day for two weeks. When we have
been meeting together as a group we share and compile what all researched alone.
- By the time of our meeting, we share the reality we got about any information about
how the NEAEA currently works.
No Name Id Email Responsibility

1. 1Bisrat Abay 1745/10 bisratabaya123@gmail.com Team leader
2. 2Fasika Solomon 1750/10 elfineshnfs@gmail.com Project manager
3. 3Dereje Lemma 1747/10 derejecr@gmail.com Project designer
4. 4Amanueal Desalegn 1737/10 amandes@gmail.com Project analysis
5. Solomon Wami 1779/10 Solomonwami3@gmail.com Data gather and problem

identifier
40

Ousps SRS

Uploaded by

Copyright:

Available Formats

Ousps SRS

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ousps SRS

Uploaded by

Copyright:

Available Formats

Software Requirements Specification for Online University Selection and Placement System for NEAEA 2021

ONLINE UNIVERSITY SELECTION AND

Group Name: S.C.U.M

Bisrat Abay 1745/10 bisratabay@gmail.com

Fasika Solomon 1750/10 elfineshnfs@gmail.com

Dereje Lemma 1747/10 derejelemmacr7@gmail.com

Solomon Wammi 1769/10 solomonwam@gmail.com

Ammanuel Desalegn 1739/10 amandes21@gmail.com

Advisor: Mr. Gizachew Belayneh (MSc.)

Date: Aug 23, 2021

3.3.10 Use case 10: Allow Placement Computation ..........................................................................................25

1.0 BisratAbay 1st version 8/22/2021

1.1 Document Purpose

This document also describes the non-functional requirements such as performance,

1.2 Product Scope

1.3 Intended Audience and Document Overview

1.4 Definitions, Acronyms and Abbreviations

GUI: - Graphical User Interface.

HTTP: - Hyper Text Transfer Protocol.

ICT: - Information and Communication Technology

ID: - Identification card.

IEEE --- Institute of Electronics and Electrical Engineering Standard

NEAEA: - National Educational Assessment and Examination Agency.

OUSPS: - Online University Selection and Placement System.

PHP: - Hypertext Preprocessor

SQL: - Structured Query Language regarding database.

TCP: - Internet Protocol Version

UI: - User Interface

UML: - Unified Modeling Language.

1.5 Document Conventions

1.6 References and Acknowledgments

2.1 Product Overview

Figure 1 General Diagram of OUSPS

2.2 Product Functionality

The major product functionalities are:

 Allow the students to submit their University preference in order manner.

 Allow the schools to feed their students personal information.

 Notifying the placement by computing according to the criteria.

2.3 Design and Implementation Constraints

2.4 Assumptions and Dependencies

3.1 External Interface Requirements

3.1.1 User Interfaces

Figure 2 Sample home page interface

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.2 Functional Requirements

3.2.2 F2: User Management

3.2.3 F3: Send/Receive Message

3.2.5 F5: Add Universities information

3.2.6 F6: Submit University preferences

3.2.7 F7: View placement

3.2.8 F8: Show selected University

3.2.9 F9: Registration

3.3 Use Case Model

The actors of our system are as follow:

Figure 3 Use case diagram

3.3.1 Use case 1: Login

Use case Login