E-Notice Announcement and Management System SRS

Software Requirements
Specification
for
E-Notice Announcement and

Management System(ENAMS)
Version 1.0
Prepared by:-
Group Name: Scorpio
Name IDNo
1. JEBESA TEMESGEN 1762/10
2. NAFOL ABDISA 1753/10
3. CHALA BORENA 1746/10
4. JILO BEDECHO 1754/10
5. GADISE ALEMAYEHU 1752/10
Advisor: Shambel A.
April ,2021
Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for ENAMS Page i
Table of Contents
Table of Contents ........................................................................................................................... i

Revision History ............................................................................................................................ ii
1. Introduction ............................................................................................................................. 1
1.1 Purpose .........................................................................................................................................1
1.2 Document Conventions ................................................................................................................2
1.3 Intended Audience and Reading Suggestions ..............................................................................2
1.4 Product Scope ..............................................................................................................................3
1.5 References ....................................................................................................................................3
2. Overall Description ................................................................................................................. 4
2.1 Product Perspective ......................................................................................................................4
2.2 Product Functions ........................................................................................................................4
2.3 User Classes and Characteristics .................................................................................................4
2.4 Operating Environment ................................................................................................................5
2.5 Design and Implementation Constraints ......................................................................................5
2.6 User Documentation ....................................................................................................................5
2.7 Assumptions and Dependencies...................................................................................................5
3. External Interface Requirements........................................................................................... 6
3.1 User Interfaces .............................................................................................................................6
3.2 Hardware Interfaces .....................................................................................................................6
3.3 Software Interfaces ......................................................................................................................7
3.4 Communications Interfaces..........................................................................................................7
4. System Features ....................................................................................................................... 7
4.1 Use Case name and Identifiers: Register(U1) .........................................................................7
4.1.1 Description and Priority...........................................................................................................7
4.1.2 Stimulus/Response Sequences .................................................................................................8
4.1.3 Functional Requirements .........................................................................................................8
4.2 Use Case name and Identifiers: Login(U2)..............................................................................8
4.3 Use Case name and Identifiers: edit profile (U3) ....................................................................9
4.4 Use Case name and Identifiers: Post Information (U4) .......................................................10
4.4.1 Description and Priority.........................................................................................................10
4.4.2 Stimulus/Response Sequences ...............................................................................................10
4.4.3 Functional Requirements .......................................................................................................10
4.5 Use Case name and Identifiers: View Information (U5) ......................................................10
4.6 Use Case name and Identifiers: manage account (U6) .........................................................11
4.7 Use Case name and Identifiers: delete information (U7) .....................................................12
Software Requirements Specification for ENAMS Page ii
4.8 Use Case name and Identifiers: Logout (U8) ........................................................................13

5. General Functional Requirements ....................................................................................... 13
6. Other Nonfunctional Requirements .................................................................................... 14
6.1 Performance Requirements ........................................................................................................14
6.2 Safety Requirements ..................................................................................................................14
6.3 Security Requirements ...............................................................................................................14
6.4 Software Quality Attributes .......................................................................................................14
6.4.1 Maintainability Requirements ...............................................................................................14
6.4.2 Portability Requirements .......................................................................................................15
6.4.3 Compatibility Requirements ..................................................................................................15
6.5 Business Rules ...........................................................................................................................15
Appendix A: Glossary ................................................................................................................. 16
Appendix C: To Be Determined List ......................................................................................... 16
Revision History
Name Date Reason For Changes Version
Initial 09-26/04/2021 Initial Draft of SRS 1.0
Software Requirements Specification for ENAMS Page 1
1. Introduction
Now days, in many parts of the world Mobile devices are dominant and, beyond the future it is
anticipated that mobile internet utilization will exceed desktop utilization world-wide. In this project, we
need to develop an integrated system on E-Notice Announcement and Management System.
The E-Notice Announcement and Management System will provide an interface on the university official
Integrated system in which Students can access information and interact with other members of their
respective class. It can implement with the collaboration of Information and Communication Technology
directorate office (ICT) and Collage of Computing and Informatics (CCI) Know it is managed and
administered by ICT Teaching and learning technology unit.
1.1 Purpose
The purpose of this document is to present a detailed integrated system E-Notice Announcement and
Management System. It will explain the different functional as well as non-functional requirements of the
system, the interfaces of the system, what the system will do or how the system will interact with the
external users, the constraints under which it will operate. This Software Requirement Specification
document will provide a clear understanding of what is expected by the client in the proposed E-Notice
Announcement and Management Integrated system. This will give a clear idea on how the software
should be developed by the development team for the end users. This SRS will provide a solid base or
foundation for the project. From this SRS and the testers can create test plans and various test case
documents.
The main goal of the project is to design an important system for managing the advertisement activities.
The new proposed system will operate efficiently by eliminating all the time-consuming issues and
provides a better and much enhanced service to the Students as well as the management and staff. The
proposed software is multi-platform software such that it will work in all the operating systems and most
of the browsers.
1.2 Document Conventions
This document was organized in accordance with the Software Requirements Specification template of
the IEEE. The bold words is to emphisize more about them.
Heading: Font Size: 16
Font Style: Bold
Font: Times New Roman
Sub Heading: Font Size: 14
Font Style: Bold
Font: Times New Roman
Content: Font Size: 12
Font: Times New Roman.
Paragraph line spacing 1.5
1.3 Intended Audience and Reading Suggestions
This document is the software requirement specifications as agreed by users, developers and owners. The
SRS has important information for users, system owners, designers, maintenance team and system testers
as well as documentation team. The SRS provides different information that will be vital for different
groups of readers.
System Users: concerned in Functional and non-functional requirements, GUI requirements
Used to review if the interface, functional and non-functional requirements are the one they desire and
recommend change if necessary.
System Owners: concerned in Project cost, functional and non-functional requirements
Used to specify developments tools to be used, check if all their requirements are included.
Designers: concerned in Use cases, functional and non-functional requirements, assumptions and
dependencies, design constraints Used to revise the use case as necessary, check the achievability of
requirements, and tools proposed to be used.
Testing Team: concerned in Functional and non-functional requirements used to During black box
testing the testes checks if the system does what it was intended to do. For this check-up for functional
requirements are important
Maintenance Team: Use case, functional and non-functional requirements used to if the system fails
during maintenance the maintenance team needs to revise the initial functionality the system was
intended to do.
1.4 Product Scope
The software to be produced is an Integrated System known as E-Notice Announcement and

Management System which will help the Students of all Haramaya university communities such as clubs,
unions, forums, student, teacher and administrator. The core part of the project is to give information
online. There are three types of the end users for this E-Notice Announcement and Management System
the first ones are the Student who uses the system for the to address news purposes. The other end users
are the manager and the admin who are given separate authentication to the E-Notice Announcement and
Management System.
The system E-Notice Announcement and Management System is used to give new information. The user
can give and receive news or information through online or through phone or in web. The Student needs
to enter their personal details. An email containing the confirmation details will be sent to the Student’s
email address or message to mobile. The staff members of the Haramaya University like, clubs, unions,
forum, students, teacher and administrator need to enter the Student details by logging to employee
modules with corresponding authorization.
1.5 References
➢ SRS Template given by the teacher.

➢ www internet.
➢ Copyright © 1999 by Karl E. Wiegers.
2. Overall Description
2.1 Product Perspective
Even though the product which is going to be implemented is a new product it can be used as enhancing
solution for an existing system. This system explained in this document is the first version. This system
will replace the existing manual system of Haramaya University Advertisement. The systems are
interacting with students, teacher, clubs, forums and administrator. Student can view information posted
by manager and admin can control overall system.
2.2 Product Functions
The key functionality of this system can be abstracted as follows.
✓ The Student can be register to system

✓ Enable Student to have information easily since the system online advertisements instead of
paper.
✓ To help the manager easily distributes (uploads) any related information and advertisement.
✓ The Administer can control overall services proved by the system.
2.3 User Classes and Characteristics
E-Notice Announcement and Management System to the following user classes:-

The end user who plays an important role in the proper function of the application must be familiar with
Android Mobiles. The users, when they use the application, they should know how enable network
connection.
Primary User – It defines student and staff.
Developer – The role of a developer is to maintain the application. It is assumed that the developer is
adept in HTML, PHP, XML and Android.
Data Clerk- Is an IT literate and a person with detail system component knowledge and experience. Has
access to preparing news, notices and advertisement to the system.
System Admin – This is a programmer and a person with detail system knowledge and experience. Has
access to control database and server.
2.4 Operating Environment

➢ Android based mobile phones and Iphones.
2.5 Design and Implementation Constraints
Design Constraints:
1. Security: The files in which the information regarding securities and portfolios should be secured
against malicious deformations.
2. Fault Tolerance: - Data should not become corrupted in case of system crash or power failure.
✓ Language requirements: software must be multilingual, including the following languages:

English, Amharic, Afaan Oromo and etc.
✓ hardware and software failures
✓ shortage of internet access
✓ shortage of consultancy service
✓ shortage of power access
✓ Central Server should be on-line round the clock
2.6 User Documentation
For user documentation and information, we described in External Interface Requirements.
2.7 Assumptions and Dependencies
✓ The project should be completed within specified time period including Planning,
Designing, Development, Testing and Deployment.
✓ We are assuming that the user should have some basic knowledge of computer.
✓ The project should be completed within specified budget.
✓ All the Entry and Exit criteria of all the stages should be met.
✓ The product should be user-friendly, reliable and should maintain the industry standards
without compromising the quality.
✓ there is internet connection in order to use this application
✓ The user has at least one ID number of those Haramaya University which are going to be
included in this system.
✓ The user must be registered at least in one club or department.
✓ Hardware and software installation: It is assumed that all the needed software and hardware be
Installed and are ready to do the jobs needed.
3. External Interface Requirements
3.1 User Interfaces
The user interface should be easy to understand and use by the end user, so that he or she can choose the
operation he wants to do without any confusions. The format on the screen should describe the operations
that can be done using the proposed system.
The proposed system has the integrated system.
➢ the Integrated system

✓ the GUI of the Integrated system must be responsive in order to have ease of access while
accessing remotely
✓ the Integrated system must have attractive loading page which can enhance the work sprit of
the user and also which inform about the system for the visitors
✓ the Integrated system shall have special login interface for the administrator of the website
✓ the Integrated system shall have attractive and easily manageable interface after login
✓ the Integrated system shall protect any wrong entry of the user
✓ the Integrated system shall interact with the server as fast as possible
✓ The proposed system requires server to store information
3.2 Hardware Interfaces
The hardware interface specifies the logical characteristics of each interface between the SW and
hardware on which the SW run.
➢ Computer (Laptop) with a connection: For developing software
➢ Compact Disk: To back up the software documentation
➢ Flash Disk: For transferring files

➢ 800 GB hard disk (HDD), 512 memories (RAM), 3.2 GHz processor, Server, Printer
3.3 Software Interfaces
The software interfaces specify the SWE and hardware on which the SWE can run, so in this system we
have used: -
✓ Android Studio: -software to design the proposed system. It is a multi-language

integrated development environment (IDE) comprised a base workspace.
✓ API services
✓ MySQL
✓ Notepad
✓ Microsoft Office 2019: For writing system documentation
✓ Internet: To search additional information about system development
3.4 Communications Interfaces
Users can connect their mobile to internet. The communication architecture must follow the client-server
model. Once connected to the server, users can easily view any information. Users can easily update their
information when connected to the server. The update should not take any longer than 10 minutes.
4. System Features
4.1 Use Case name and Identifiers: Register(U1)
4.1.1 Description and Priority
The Student who is registered to the system must be included to the Student list and when the web admin
wants to check Student detail the detail which is inserted by the admin must be displayed. The system
completes its tasks successfully.
Actor:- Student
Priority:- This requirement is high priority.
4.1.2 Stimulus/Response Sequences
Basic flow
1. The system displays the home page.

2. Click Register Button
3. Enters personal information
4. Click Sign up Button
5. Use Case Ends
Exception: - the user may insert wrong data format in the field provided
4.1.3 Functional Requirements
➢ To add Students in the system in order to enable the Student use this system.
➢ Register Information about the Student
➢ The system will notify the user while the user commits error.
4.2 Use Case name and Identifiers: Login(U2)
The system must be loaded successfully. The Student must be register after that the login page is
displayed in order to continue to the system.
Actor:- Student, Manager and Admin
Priority:- This requirement is high priority, because the Student can’t get services his/her system
Basic flow

2. Click Login button
3. Insert required information (like: username, password)
4. Click login button
5. Use Case Ends
Exception: - If the user inserts invalid username and password the system must display error
message and ask the user to re-enter the fields again
➢ To permit the use to access the system

➢ The system must display appropriate error and warning message for the user.
➢ If the actor is a student, he/she must have a student id and be a student in one of the departments
and club.
➢ If the actor is manager, he/she must have manager,’ id.
➢ If the actor is administrator, he/she must have administrator,’ id.
4.3 Use Case name and Identifiers: edit profile (U3)
The Student, Manager and Admin must be successfully logged in to the system then they can successfully
edit their profile.
Actors: Admin, Student, Manager.
Basic flow

2. login to the system
3. click update profile button
4. change the previous profile with the current profile
5. click save button
6. Use Case Ends
Exception: - the user may insert wrong data format in the field provided.
➢ Updating the Student accounts if there is user to edit profile.

➢ The user edit profile must be updated.
4.4 Use Case name and Identifiers: Post Information (U4)
The manager must be successfully logged in to the system then they can post the information.
Information successfully posted. The system completes its tasks successfully.
Actors: Manager
Basic flow

2. manger login to the system
3. click post button to insert the detail information
4. fill all information regarding the notice to be posted
5. click post button
Exception: - if all informations are not filled notify the manger to completely fill all the
information required.
➢ To enable manager to post information

➢ Information that able to post
4.5 Use Case name and Identifiers: View Information (U5)
The Student Select which type of information wants. The Student must be successfully logged in to the
system and information must be in the systemStudent can view information successfully. The system
completes its tasks successfully.

Actors: Student
Basic flow

2. Register to the system
4. click view button to insert the detail information
5. select from Department, club, forum and association
➢ To enable Student to view information

➢ Select which type of information Student wants
4.6 Use Case name and Identifiers: manage account (U6)
First Student and manager have an account. Admin can manage the account successfully.The system
completes its tasks successfully. First Student and manager have an account.
Actors: Admin
Basic flow

2. Register to the system
4. click manage account button to manage all account select from manager and Student.
➢ To enable admin how to manage the account.

➢ The system will notify the user while the user commits error
4.7 Use Case name and Identifiers: delete information (U7)
The manager must successfully logged in to the system. The Student must be successfully logged in to
the system and information must be in the system. Manager can delete information successfully.
Actors: Manager
Basic flow
1. Go to the interface which is provided for manager only

2. Click on “information” menu
3. Click on “Delete” link which is intended to the information to be deleted
4. Confirm the confirmation dialog by clicking ‘yes’ button.
➢ enable manager to delete information.

➢ The system must give understandable message to the manager that he is going to delete the
information from the system.
4.8 Use Case name and Identifiers: Logout (U8)
The user must be successfully logged in to the system. The permission of accessing that account must be
blocked until he/she logged in back again.
Actors: Admin, manager, Student
Basic flow
1. Click on logout button.
➢ To disable the permission of accessing the account or the system
5. General Functional Requirements

Functional Requirements are those that refer to the functionality of the system, i.e. what services it will
provide to the user. Statements of services the system should provide how the system should react to
particular inputs and how the system should behave in particular situations.
REQ-1: Enable Student to register.

REQ-2: Enable the Student, manager, administrator to login and logout.
REQ-3: Enable the Student and manager to view and update his/her profile.
REQ-4: Enable the Student to view information.
REQ-5: Enable the manager to post, edit and delete advertisement.
REQ-6: Enable the administrator to manage Account.
6. Other Nonfunctional Requirements

Non-functional requirement means necessities of the new system that not directly related to the
functionality of the new system. In our case, the nonfunctional requirements are listed as follows:
6.1 Performance Requirements
Response time: The response time for each Activity is very low, since latest version is applied.
➢ Example transaction involves retrieving message sent from one emulator to the other in
average: 300 milliseconds, maximum: 2 seconds.
Services: The system should give information about services that users have been used every month. So
users can use system
6.2 Safety Requirements
The system must keep copy of every day work as back up. This should be done every day and kept in
Compat disks.
6.3 Security Requirements
Security becomes crucial issue in the proposed system. A user must login to the system with user name
and password. The system should allow login to only authorized users. Users that have previously created
account through user name (E-Mail) and password.
The database server should be updated for latest update of anti-virus every morning. The system must
also employ user authentication features of the system by setting user name and password.
6.4 Software Quality Attributes
6.4.1 Maintainability Requirements
The system will develop using object-oriented software development technique that makes the software
highly maintainable. If there are any additional requirements the system is flexible to change. The code
should be well documented so that developers and other programmers can easily make changes and
enable the future evolution of the application.
The system shall be maintained from the back up data in case the system is affected by some problematic
data. The system shall be maintained from back up data in case the system is affected by problematic
data.
6.4.2 Portability Requirements
✓ The application should work on any operating system window or Unix.
✓ Ability to move the software to different smart phones.
6.4.3 Compatibility Requirements
✓ Our application shall be accessible by any computer brand.
✓ independency of hardware platforms
6.5 Business Rules
➢ The eligible students are required to fill in the in the space provided in the form.
➢ It is expected that a student does not add any ambiguous or fraudulent information in his/her infor
mation.
➢ The subsection documents all required data design constraints.
Appendix A: Glossary
Acronyms/Abbreviations Definition
ENAMS E-Notice Announcement and Management System

IEEE Institute of Electrical and Electronics Engineering Standards
GUI Graphical User Interface, the part of the application that the user sees and interacts
with.
XML Extensible Markup Language is a simple, very flexible text format which is designed
to carry data, not to display data.
PHP Personal home page
HTML HyperText Markup Language
Admin System administrator
RAM Random Access Memory
ICT Information and Communication Technology
HU Haramaya University
CCI Collage of Computing and Informatics
SWE Software
UML Unified Modeling Language
Appendix C: To Be Determined List

This appendix documents the following major TBDs:
➢ Add appropriate information:
• Admin
• Manager
➢ Remove unnecessary GUI information.
➢ Manager
➢ Do not allow Student to post any information.
➢ Student can only look up the notice

E-Notice Announcement and Management System SRS

Uploaded by

Copyright:

Available Formats

E-Notice Announcement and Management System SRS

Uploaded by

Document Information

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

E-Notice Announcement and Management System SRS

Uploaded by

Copyright:

Available Formats

Software Requirements

E-Notice Announcement and

Table of Contents ........................................................................................................................... i

4.8 Use Case name and Identifiers: Logout (U8) ........................................................................13

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Product Scope

The software to be produced is an Integrated System known as E-Notice Announcement and

➢ SRS Template given by the teacher.

2.1 Product Perspective

2.2 Product Functions

The key functionality of this system can be abstracted as follows.

✓ The Student can be register to system

2.3 User Classes and Characteristics

E-Notice Announcement and Management System to the following user classes:-

2.4 Operating Environment

2.5 Design and Implementation Constraints

✓ Language requirements: software must be multilingual, including the following languages:

2.6 User Documentation

For user documentation and information, we described in External Interface Requirements.

2.7 Assumptions and Dependencies

3. External Interface Requirements

3.1 User Interfaces

➢ the Integrated system

3.2 Hardware Interfaces

➢ Flash Disk: For transferring files

3.3 Software Interfaces

✓ Android Studio: -software to design the proposed system. It is a multi-language

✓ Microsoft Office 2019: For writing system documentation

✓ Internet: To search additional information about system development

3.4 Communications Interfaces

4.1 Use Case name and Identifiers: Register(U1)

4.1.1 Description and Priority

4.1.2 Stimulus/Response Sequences

1. The system displays the home page.

4.1.3 Functional Requirements

4.2 Use Case name and Identifiers: Login(U2)

4.2.1 Description and Priority

4.2.2 Stimulus/Response Sequences

1. The system displays the home page.

4.2.3 Functional Requirements

➢ To permit the use to access the system

4.3 Use Case name and Identifiers: edit profile (U3)

4.3.1 Description and Priority

4.3.2 Stimulus/Response Sequences

1. The system displays the home page.

4.3.3 Functional Requirements

➢ Updating the Student accounts if there is user to edit profile.

4.4 Use Case name and Identifiers: Post Information (U4)

4.4.1 Description and Priority

4.4.2 Stimulus/Response Sequences

1. The system displays the home page.

4.4.3 Functional Requirements

➢ To enable manager to post information

4.5 Use Case name and Identifiers: View Information (U5)

4.5.1 Description and Priority

Priority:- This requirement is high priority.

4.5.2 Stimulus/Response Sequences

1. The system displays the home page.

4.5.3 Functional Requirements