FACULTY OF SCIENCE

COMPUTER SCIENCE DEPARTMENT

SOFTWARE REQUIREMENTS SPECIFICATIONS (SRS)

PRESENTED BY:

NAME: NCHAGWA JULIUS

REG NO: S13/21422/14

PROJECT TITLE: ONLINE ANDROID SUGGESTION BOX APP

COMPLETION DATE:

PRESENTED TO:

SUPERVISOR:

VERSION 1.0
Table of Content
Table of Contents........................................................................................................ ii
Revision History...................................................................................................... iii

1.INTRODUCTION ................................................................................................................ 4
1.1Purpose ....................................................................................................................... 4
1.2Document Conventions .............................................................................................. 4
1.3Intended Audience and Reading Suggestions ............................................................ 4
1.4Project Scope .............................................................................................................. 4
2.OVERALL DESCRIPTION .................................................................................................... 5
2.1Product Perspective.................................................................................................... 5
2.2Product Features ........................................................................................................ 5
2.3User Problem Statement ............................................................................................ 6
2.4User Objectives ........................................................................................................... 6
2.5Operating Environment .............................................................................................. 6
2.6Design and Implementation Constraints .................................................................... 6
2.7User Documentation .................................................................................................. 6
2.8Assumptions and Dependencies ................................................................................ 6
2.9User Constraints ......................................................................................................... 6
3.SYSTEM FEATURES ........................................................................................................... 7
3.1System Feature 1 ........................................................................................................ 7
3.1.1Description and priority ....................................................................................... 7
3.1.2Stimulus/Response sequences ............................................................................. 7
3.1.3Functional Requirements ..................................................................................... 7
3.1.4Technical issues .................................................................................................. 12
3.1.5Dependencies with other requirements ............................................................ 12
3.2System Feature 2 ...................................................................................................... 12
4.EXTERNAL INTERFACE REQUIREMENTS ......................................................................... 13
4.1User Interfaces ......................................................................................................... 13
4.2 Hardware Interfaces ................................................................................................ 13
4.3 Software Interfaces ................................................................................................. 13
4.4Communication Interfaces ....................................................................................... 13
5.OTHER NON-FUNCTIONAL REQUIREMENTS .................................................................. 14
5.1 Performance Requirements .................................................................................... 14
5.2 Safety Requirements ............................................................................................... 14
5.3 Security Requirements ............................................................................................ 14
5.4 Software Quality Attributes ..................................................................................... 14
5.5 Other Requirements Attributes ............................................................................... 15
6.PRELIMINARY OBJECT-ORIENTED DOMAIN ANALYSIS .................................................. 18
6.1 Interface Relationships ............................................................................................ 18
6.2 User Classes and Attributes ..................................................................................... 18
6.2.1Abstract or Concrete .......................................................................................... 18
6.2.2List of Super Classes ........................................................................................... 18
6.2.3List of Subclasses ................................................................................................ 18
6.2.4Purpose .............................................................................................................. 18
6.2.5Collaborations .................................................................................................... 18
6.2.6Attributes ........................................................................................................... 18
6.2.7Operations.......................................................................................................... 18
6.2.8Constraints ......................................................................................................... 18
7.Preliminary Budget and Schedule .................................................................................. 18
8.Other Requirements ...................................................................................................... 18
8.1 References……………………………………………
8.2 Appendix A: Glossary of definition, Acronyms and abbreviation…………
Appendix B: Analysis Models………………………………………………………………18
Appendic C: Issues List……………………………………………………….. 18
 Revision History
Name Date Reason For Changes Version
Nchagwa julius Initial draft 1.0.0
1. INTRODUCTION
1.1 Purpose

The main purpose of this document is to present a detailed description of the Online Android
Suggestion Box System in specifying the functionality, performance and the interfaces
requirement of the software system. It will explain the purpose and features of the system, the
interfaces of
Online Android Suggestion Box, what the system will do the constraints under which it must
operate and how the system will react to external stimuli.

This document is intended for both the stakeholders and the developers of the system and will be
proposed to the Students and Institutions Employees for its approval. It will also satisfy the
functional, design and performance requirements of the system.

1.2 Document Conventions

This document has been broken down into subsection and in which each section covers the three
fundamental parts that are in the application, the database, portal and feedback.

This document follows MLA Format. Bold-faced text has been used to emphasize section
and sub-section headings.
Highlighting is to point out words in the glossary and italicized text is used to label and
recognize diagrams.

1.3 Intended Audience and Reading Suggestions

The intended users of this system are all major stallholders which include project owner, students
and employees.
Also lectures and anyone evaluation the project. This project is intended for a learning institution
that has employees and students. It’s implemented under the guidelines of the lecturer

1.4 Project Scope

The Online Android Suggestion Box Application offers various operations like giving out

your suggestions about a particular matter, giving Ideas, Proper Channeling of complain and also

provides feedback to the raised complains ideas and suggestions in good time. It also provides

reward to the best idea that one might come up with. These services are all grouped together and

conveniently run on specifically for your android device. All the operation can be achieved and

performed when the internet is available. The Admin registers users to start using the system.

The system also contains a relational database containing a list of Ideas, Complains, and

Feedback
2. Overall Description

This section will give an overview of the whole application. The Android Application will be
explained in its context to show how the user interacts with other systems and introduce the basic
functionality of it. It will also describe what type of stakeholders that will use the Application
and what functionality is available for each type. At last, the constraints and assumptions for the
system will be presented.

2.1 Product Perspective

1. To provide a means for the student to directly issue what is affecting them
2. To provide an efficient feedback to the delivered complain so as to improve the
3. To improve efficiency delivery of ideas by both students and employees to their relevant
organization’s
4. To provide synchronized and centralized suggestion box system
5. To provide immediate storage and retrieval of data and information

2.2 Product Features

Class of Use Cases Use Cases Description

Use cases related to system Log of Admin Log admin to the system
authorization of system Change password of the admin Change login password of the
administrator admin of the system
Use cases related to Register the student by himself Store personal, contact and
registration of Register the student by system medical details of the donor
students/employees admin Store personal, contact and
medical details of donor
Use cases related to Login of student Log donor to the system
authorization of student Change password of student Change login password of the
donor of the system
Use cases related to change the Change contact details of the d Change personal and contact
registration details of student student details of student
himself
Change contact details by Change personal and contact
system admin details of student
2.3 User Problem Statement
Students for a long time have had issues of not being had and lack of proper channeling of
complain which results to catastrophic consequences including strikes and lack of goodwill.
But through the Android Online Suggestion and Complain Management system will not only
cater for student well-being’s but also improves the organization/institutional management and
growth
My Application seeks to provide a reliable forum where students/employee will be able to give
out there complain and ideas to help in growth of either learning institution’s or their place of
work
2.4 User Objectives

2.5 Operating Environment

While Online Suggestion and Idea Management Application users may be distributed worldwide,
each installation will have all of its component devices available locally and users are required to
have an Android platform system.

Due to the limited battery-life of mobile devices, Android Suggestion Box may consider power
use as a design factor. This is a low priority extension to the Application.

In addition, due to existence of much different type of Android devices Online Android
Suggestion will follow the compatibility guide line that Google provided on Development.
My Application operates within the Java-based

2.6 Design and Implementation Constraints

1. The Application must run on an Android platform operating system.
2. The Application must be conserving the battery life.
3. The system must be able to operate on many different type of Android devices.
4. The software must also use the language supported by the android development environment,
5. Java plus the android SDK
6. Security – System is consisting of the features to keep the privacy of every donor. Any donor
can't see any detail of any other donor.
2.7 User Documentation
 Software documentation – A complete document about the software will be given to Android
Admin for future maintenance of the system.
 Operation manual – A user manual is provided to the system administrator with some simple
explanations about the system and its features.
 Description for installing and running of the Application

2.8 Assumptions and Dependencies

1. At this stage of the project, Online Suggestion And Idea Management System will not support
 operating systems other than.
a) Internet access is required for each Android device. An assumption is that the android device
maintains internet access throughout the entire session.
b) The system database will be accessible in real time
c) The user doesn't submit any false details to the system
2.9 User Constraints
The project uses Android Platform. Generally, Android applications are written in Java.
There may be future which may result in compatibility issues in the future.

3. System Features

User-case related to System Authorization

Use case 1: Login Admin
Primary actor: System administrator
Pre-condition: Internet connection should be available
Main Scenario:
a) Login into the Online Android Suggestion Box App
b) Admin initiates the command to start the app
c) System is shown all the features of the system
d) Click login administrator button
e) The system asking for the username and password
f) The admin provides username and password
g) System does authentication
h) Main application relevant to admin is displayed

Alternative Scenario:
d) Authorization fails
 A message is given to the admin that the provided password is wrong
 Allow the admin to re-enter the password, three-chances will be given

Use Case 2: Change the login password of admin

Primary actor: System administrator
Pre-condition: Internet connection should be available. Admin logged in
Main Scenario:
a) Admin selects command to change password
b) The system is asked to type the current password, new password and again confirm new
password.
c) Admin provides the current password, new password and confirm password
d) System does authentication
e) New password is stored in the system
Alternative Scenario:
d) i. Authorization fails
 A message is shown that the provided current password is wrong
 Allow the admin to re-enter the current password, three-chances will be given
d) ii. New password doesn't match with the confirm new password
 A message is shown to the admin that the provided new password doesn't match with the
current password
 Allow the admin to re-enter the new password and confirm new password
Use case related to registration of student/employee
Use Case 3: Register the student/employee by himself
Primary actor: Student
Pre-condition: Internet connection should be available
Main Scenario:
a) Log into the Online Suggestion Box Application
b) System is shown all the features of the system
c) The authorities doesn't approve the registration of the user
 Details are not stored in the database
 Send a message to that person about the rejection of the application. Ask him to
register again

Use Case 5: Login of the donor

Primary actor: Donor
Pre-Condition: Internet Connection should be available
Main Scenario:
a) Log into the official blood bank app
b) System is shown all the features of the system
c) Select the login of donor command
d) The system asking for username and password
e) Donor provides the username and password
f) System does authentication
g) Relevant application relevant to donor is displayed
Alternative Scenario
f) Authorization fails
 Message is given to the user that the provided password is wrong
 Allow the admin to re-enter the password, three-chances will be given

Use Case 5: Change login password of student

Primary actor: Student
Pre-Condition: Internet condition should be available. Student logged-in
a) Student selects command to change password
b) The system is asked to type the current password, new password and confirm new
password
c) Student provides the current password, new password and confirm new password
d) System does authentication
e) New password is stored in the system
Alternative Scenario:
d) Authorization fails
 A message is given to the Student that the provided current password is wrong
 Allow Student to re-enter password, five-chances will be given
e) New password does not match with confirm new password
  Allow the Student to re-enter the password and confirm new password

Use cases related to registration of donor details

Use Case 6: Change personal contact by Student himself
Primary actor: Student
Pre-Condition: Internet connection should be available, Student logged-in
Main Scenario:
a) Student initiates the command to edit profile details
b) The system provides the filled application of the exact Student
c) Student changes personal and contact details and finishes
d) System does authentication
e) New details will replace the past details and store in the system
 4. EXTERNAL INTERFACE REQUIREMENTS

4.1 User Interfaces

There are two major actors in the system. The system provides some advance features to the
system admin and the user. If the system admin logs in, the system interface provides some main
command buttons to the admin.
 Change login password
 Print statements
 View Suggestion from database
 Send feedback
 View Ideas
If the donor logs in, the system will provide another different interface with different commands
 Change login password
 Edit personal, contact details
 Contribute Ideas
 Give suggestions
4.2 Hardware Interfaces
This will be an android application, and as such will be designed to interface with the hardware
present on the android phone. In theory the application will be able to run by other devices
that can emulate the Android but this will not be a consideration during design. There are
three physical buttons on the phone. The options button will be used specifically in multiple
instances to bring up menus, such as bringing up the ability to add an idea during the idea
generation phase.
As this is a mobile device, it will be using android network to connect to the internet which will
allow communicating with database servers. This means that it will be using the
infrastructure, be it wireless communication points or physical lines of the network in-order
to perform properly.
There will have to be some sort of error checking for if the network is down or inaccessible.
4.3 Software Interfaces
Android application
4.4 Communication Interfaces
HTTP protocol will be used to facilitate communication between the client and the server
 5. OTHER NON-FUNCTIONAL REQUIREMENTS
5.1 Performance Requirements
The primary performance requirement is the speed of the network. While there should not be that
much information flowing across during a brainstorming session, if the time limit of the session
is short, the user needs to be able to see other ideas and input their own in a reasonable amount
of time in-order to participate in the exercise.
5.2 Safety Requirements
There are no safety requirements with this application, other than any normal hazards of a mobile
device. The only hazard is a user using the device when they should not be such as while driving.
5.3 Security Requirements
5.4 Software Quality Attributes
a) Reliability
The software will meet all of the functional requirements without any unexpected
behavior. At no time should the gauge output display incorrect or outdated
information without alerting the user to potential errors.
b) Availability
The software will be available at all times on the user’s Android device, as long as
the device is in proper working order. The functionality of the software will depend
on any external services such as internet access that are required. If those services
are unavailable, the user should be alerted.
c) Security
The software should never disclose any personal information of users, and should
collect no personal information from its own users.
d) Maintainability
The software should be written clearly and concisely. The code will be well
documented. Particular care will be taken to design the software modularly to
ensure that maintenance is easy.
e) Portability
This software will be designed to run on any Android operating system version 2.3
or higher. The software will be forward compatible for all currently released Android
operating system versions (up to 4.2)
f) The primary attribute of this application will be usability given the large amounts of data
and information that will be presented on such a small screen as well as users ability to
input data into the device in a reasonable manner that should not be that much difficult than
if they were on a bigger screen like a computer.
g) As usability is hard to quantify, substantial user testing will be needed and feedback
gathered in-order to determine if the application can generally considered usable.
h) Because this application will be on a phone, portability is also important. We don't want it to
take up so much space or be too slow causing the user not to be able to fit it on the device.
Interoperability is something that is not specifically important at least at the beginning.
i) The android device is being used because of its popularity and the ability for the code to-be
open source. This in contrast to other phones like iphone which would not allow for open
source application development and this would go against goals of overall project.
However, in the future, the ability to use this on other phones that support the goals of the
project would be nice, but that is outside the scope of this project

6. Other Nonfunctional Requirements

5.1 Performance Requirements

The requirements in this section provide a detailed specification of the user interaction
with the software and measurements placed on the system performance.

5.1.1 Response time

The system is interactive and the delays involved are less. So in every action-
response of the system, there are no immediate delays. In case of opening
windows forms, of popping error messages and saving the settings or sessions
there is delay much below 2 seconds, in case of opening databases, sorting
questions and evaluation there are no delays and the operation is performed in less
than 2 seconds for opening, sorting, computing, posting > 95% of the files. Also
when connecting to the server the delay is based editing on the distance of the
system and the configuration in the system so there is high probability that there
will be or not a successful connection in less than 20 seconds for sake of good
communication.

5.1.2 Capacity
The maximum number of request made at a time is limited only the number of
nodes to give back the request, hence there is no upper limit inherent of operation
in the system.
Higher storage space means more user and bigger workspace per user so higher the
storage, better the performance.
The system can be able to carry a lot of data since the storage capacity provided to
the system is large enough.

5.2 Safety Requirements

In the Plant Information and Diagnosis System, safety has been given first priority. The
transmission of data between the system is secure form the server to the web application
without any changes made or data modified in the transmission process.

5.3 Security Requirements

Since all the data will be transferred on the web, system should also use an encryption and
decryption mechanism only intended user can decode the data and work on the data.
Since execution will also be done in the machine in the server side, user should be restricted in
terms of user rights. User should only access the web application and should not access to any
other workspace. Also rights of the admin user should be restricted so that user can not harm to
system kind of data he inserts into the system.
Another security concern in the Plant Information and Diagnosis System is for users
account hence proper mechanism is used to avoid easy access of login information since
the passwords are hashed.

5.4 Other Quality Attributes

5.4.1 Availability
The system will be available to the users at all times. They will not be restricted in
accessing various information in the system. Amy time one needs to use it, he/she
should just visit the site
In the system, when the internet has been lost or gets disrupted while operations
are ongoing, the system is able to send information again for verification.

5.4.2 Usability
The system is easy to handle and navigate in the most expected way with no
delays. The system program reacts accordingly and transverses quickly between
its states. The interaction between the user and the system provides a smooth and
easy way to access information.
5.4.3 Resource Utilization
The system will be able to utilize all devices and resources used to host it
effectively. Since the system will be light weighted, it will require a small storage
 space to host the system. It also will not require a small space in the CPU to carry
out execution.

5.4.4 Maintainability
The system will be easy to maintain since the admin will have the privilege to
update the data in the system every moment need arises.

5.4.5 Portability
Our system is portable and can run on different platform, browsers and all internet
devices. The system is lightweight to ensure that it run on every device with slow
internet connections. Portability also means running in different platform without
much effort. To achieve this in our project
5.4.6 Serviceability
Since the dream of any software developers is good service delivery to their users,
I have ensured that serviced delivery to the users is given the very first priority.
The system will be able to offer adequate, efficient, accurate services to users.
Access for information will be available always to every user of the system.

6. Preliminary Object-Oriented Domain Analysis

These are objects that must be modeled within the application to satisfy its requirements.
It provides a structural view of the requirements.

6.1 Inheritance relationship

In our my application some classes will inherit attributes of another class for them to
carry out operation effectively.
We will have different classes in our system; -
a. Class Admin
We will have different classes inheriting the methods/attributes of class admin as
show;
 ADMIN
Username: String
Password: String
View()
Feedback()

Student

Add()
View()
AdminLogin Update()

login()

b. Class Idea
This is the class will contain all the attributes of the class. Some classes will depend
on the class by inheriting some features from the class.
6.2 User classes and Characteristics
6.2.1 Abstract or Concrete
Indicate if the class is abstract or concrete
In the system, the abstract classes are;
 Admin class
 Idea class
 Complain class
 Database class

The concrete classes are:

 Login class
 Feedback class

6.2.2 List of Super Classes

The super classes in our application are those that do major functions/important
tacks. Without these classes our system cannot execute major functions in the
systems.
In our system, the major/super classes are:
 Database connection classes
This class that will help the developer to connect to the database. The class
will contain the database name, driver and url to connect to the database.
 User class
This is a class that contains the user details. The user details are the data
the admin user login details. The class also has methods that will allow the
user to login to the system.
The figure below shows the class, attributes and methods; -
admin
username; String
password: String
 login()

 Idea class
This is the class that will contain the attributes of a given class. It also
contains some of the methods showing the operations one can perform.

plant
Type;
Category:
Diagnose()

 Complain class
This is the class that will contain the signs and symptoms of various
diseases of various crops.

Diseases
Symptoms;
Signs;

6.2.3 List of subclasses

This are classes that inherit attributes and method of the super classes. This
classes can’t do better without inheriting the attributes of super classes. Some of
the sub classes in the system are;
 Login
This is a sub class of the user class that allow the user to login to the
system.

login
username
 password

 Diagnosis
This a sub class that will help the users to be able to diagnose their crops
for diseases and pests.
6.2.4 Purpose
These classes in the system will help both the developers, stakeholders, users and
all those interacting with the system to carry out various activities. These
activities are; -
 The classes will help in the development process. This will help the
developer to ensure that all the attributes in the system are captured.
 The database class will help in connecting with the database.
 The classes also help the developing team to ensure that every event is
given enough time and all the data needed is provided to ensure effective
services.
 Other classes the users to carry out various activities in the system like
diagnosis, search and also carry out various tasks.
 These classes also will help the users to data gathering so as to gather the
most effective, important information.

6.2.5 Collaborations
In this system, different classes must collaborate to finish up some operation in
the system. In the Plant Diagnosis and Information System, many of the classes
must work together to carry up various activities.
Example; -
 For a user to login into the system, he must interact with the log in class in
the backend of the system. For the login class to work properly, it need to
collaborate with the user class that contain the user’s login details.
  The class manage data must also collaborate with other classes like the
admin class, the database connection class to allow the user to log in into
the system for him/her to carry out effective operations in the system.
 The class diagnosis also should collaborate with other class. For effective
diagnosis, the class should collaborate with other classes like the plant
class. This class contain the type of plant, category of the plant and for a
user to carry out effective diagnosis the class should collaborate with the
plant class.
 The pests class also should collaborate with the diagnosis class to ensure
that the diagnosis process for which pest is completed.

6.2.6 Attributes
Different classes in the system has different attributes. Some of them are; -
 Class Admin
The class admin has attributes. They are; -
i. Username
ii. Password
 Class plant
This is the class that contain the plant details and information.
i. Plant type
ii. Plant category
 Login class
This is a class that allow the user to login. The attributes are; -
i. Username
ii. Password
 Diseases
It has the following attributes; -
i. Symptoms
ii. Signs
 Database class
This is a class that helps in database connection. They have; -
 i. username
ii. url
iii. password of the database

6.2.7 Operations
Different classes carry our different operation.
Some of the operations are; -
Admin class- this is a class that contain the user information
Database class – this is the class that will help the developer to create a
connection to the database.
Idea class – this is the class that contain the ideas given out and details
Suggestion class – this class will allow the forwarding of complain/suggestions
Login class- this is the class that allow the admin user to log in to the system.

6.2.8 Constraints
In the system, we have some general state of some class.
Example, the admin class is a class that will allow interaction between only the
admin of the system. The admin is the person who is going interact with the
viewing suggestions and handling ideas.
Also the login is only restricted to the user whose details have been stored in the
database since the system will only allow the users in the database to login.

1. Preliminary Budget and Schedule

7.1 Budget
The development of the system will not cost a lot of cash;
The following shows my expenditure.
Work Cost
Collecting related information 300/=
Printing and Binding 400/=
Total 700/=

7.2 Schedule
 The development of the system will take quite some time so as to come up with an
effective system. Below is how I have planned to spend my time in the project.

Duration activity Jan Feb March April April May June July
2018 2018 2018 2018 2018 2018 2018 2018
Problem definition
Feasibility study and analysis
Requirement analysis
System design
Coding
Compiling and Testing
System Integration
User documentation
Testing and Debugging
Presentation

2. Other Requirements
Database Requirements
The system has been developed using MYSQL database. MySQL is efficient since it can
allow easy insertion, modifying and also easy access of data form the database. Database
is where we store our login details, data about various plants and any kind of data that
will be associated with the system.

8.1 References
a) SRS sample provided by Dr. Gikaru.
b) Android, MySQL and Apache by Julie C. Meloni, Pearson Education.
c) Fundamentals of database systems by Ramez Elmasri and Shamkant B.Navathe
d) https://krazytech.com/projects/SoftwareRequirementsSpecificationdocumentwith
example

8.2. Appendix A: Glossary of definitions, Acronyms and abbreviations.

Admin - this is a user who has privileges to add, modify, change, delete and
update data in the system.
User - this is all other user of the system.
 Web application – this is the side of the site that is accessible to the other user
who is not supposed to login into the system.
Web portal - this is the side of the website that is accessed by the admin. To
access the site, one is supposed to login into the system.

6.2 User Classes and Characteristics

7. Preliminary Budget and Schedule

7.1 Budget
The development of the system will not cost a lot of cash;
The following shows my expenditure.
Work Cost
Collecting related information 300/=
Printing and Binding 400/=
Total 700/=

7.2 Schedule
The development of the system will take quite some time so as to come up with an
effective system. Below is how I have planned to spend my time in the project.
8. Other Requirements
Database Requirements
The system has been developed using MYSQL database. MySQL is efficient since it can
allow easy insertion, modifying and also easy access of data form the database. Database
is where we store our login details, data about various plants and any kind of data that
will be associated with the system.

8.1 References
SRS sample provided by Dr. Gikaru.
Fundamentals of database systems by Ramez Elmasri and Shamkant B.Navathe
https://krazytech.com/projects/SoftwareRequirementsSpecificationdocumentwithexample
Android, Mysql and Apache by Julie C. Meloni, Pearson Education.

8.2. Appendix A: Glossary of definitions, Acronyms and abbreviations.

Android – an operating system designed for mobile devices (i.e. cell phones,
tablet computers) by Google, Inc.
Android device – any device running Android. In this document, synonymous to
“smart phone running Android.”
.