1.

Introduction
1.1 Purpose
According to our research AAU has 33,940 undergraduate students among them college of
natural and computational Science has a total of 4716 students under all programs and
enrolments of which 3376 are male and the remaining 1340 are female students. Likewise more
than 170 academic and supportive staff are working in different departments and offices of the
college.

This document contains a software requirement specification and description for Automated
Security System in Addis Ababa University college of Natural and Computational Science.It
aims at capturing the complete attention to detail requirements of the system. It fully describes
the external behaviour of the identified system and subsystems. In addition to that, non-
functional requirements and other topics worth noting are mentioned.
The system to be developed is intended to help the campus to automate its overall security
system.
The system is designed to operate the database of 4886 users(students and staff).
● Developers: in order to be sure they are developing the right project that fulfills
requirements provided in this document.
● Testers: in order to have an exact list of the features and functions that have to respond
according to requirements and provided diagrams.
● Users: in order to get familiar with the idea of the project and suggest other features that
would make it even more functional.
● Documentation writers: to know what features and in what way they have to explain.
What security technologies are required, how the system will respond to each user’s
action etc.
● Advanced end users, end users/desktop and system administrators: in order to know
exactly what they have to expect from the system, right inputs and outputs and response
in error situations.

1.2 Scope
This document discusses the general specification of the system and nothing beyond that. The
project’s target is to develop an automated security system.The partial and complete
specification of the platform is described in the following sections. In this phase, the
development is restricted to a web based application and device integration.
1.3 Overview
This document is organized in sections for clarity and maintainability, with this section (first
section) as an introduction. The rest are organized as follows:

● Section two: This part explains the general description of this document. This includes
the product perspective, product functions, user characteristics, the general constraints,
assumptions and dependencies.
● Section three: Specific requirements describe the functional and non-functional
requirements. This chapter also describes the use-case model comprehensively, in terms
of how the model is structured into packages and what use cases and actors are in the
model.
● Section four: This part describes the change management process. It shows the process
that will be used to update the SRS, as needed, when project scope or requirements
change.

2. General Description
2.1 Product Perspective
The RMSconsists of a database which contains (user information, GPS coordinates and other
resources), a server along with a backend and frontend software and other infrastructural
resources. The system will have admins to register the students and staff members data.
Including name, Identification number and Biometric data.

2.2 Product Functions

1. Create administrator type: Different types of administrators can be enlisted in the
system.
2. Create administrator: An administrator can be created from an administrator type
registered previously.
3. Signup (student and parents): Parents/Students can sign up to use the platform.
4. Manage students: Parents can manage and monitor their student’s activities on the
platform.

2.3 User Characteristics

2.4 General Constraints

The system must use an internet connection or users will not be able to communicate with the
system.
2.5 Assumptions and Dependencies
● The requirements are met, and clearly defined.
● Users are comfortable sharing their personal information with the system
● Stakeholders can contribute course contents.
● The stakeholders are available for clarification and questions.
● Technology standards for the system do not drastically change.
Dependencies: There are no major dependencies required for this platform.

3. Specific Requirements
3.1 External interface requirements

3.1.1 User Interfaces

3.1.2 Hardware Interfaces

3.1.3 Software interfaces

The system is dependent on browsers. Most of the features require Javascript to be enabled. In
addition to that, third party applications might be used in the development and functioning of the
system. Devops might involve software dependent scripts to be compatible with the server host.

3.1.4 Communication interfaces

Internet connection and browser are required in order for all the functions to be executed. Also
email and SMS might be sent to the users for additional communications.

3.2 Functional Requirements

1. Create administrator Type

Description - A super administrator will be able to create different types of administrators with
specific roles (to be specified by the stakeholders) that will be used when introducing a new
administrator into the system.
- Frequency - Whenever a super admin wants to create a new administrator type.
 - 2. Create administrator
Description - An admin will be able to create a new administrator by specifying their first name,
last name, email, password, phone number and choosing from the administrator type.
- Username
- Password
- Firstname
- Email
- Privilege type
- Phone Number
Frequency - Whenever a super admin wants to create a new administrator.
Use cases - see
3.3 Use cases

3.4 Non-functional requirements

3.4.1 Performance

3.4.2 Reliability

3.4.3 Availability

3.4.4 Maintainability

3.4.5 Portability

3.5 Inverse Requirements

3.6 Design Requirements

3.7 Other Requirements

3.7.1 Training Related Requirements

3.7.2 Packaging Related Requirements

3.7.3 Compliance Related Requirements

4. Change Management process

5. References