SRS documentation for Android Application BITS NOW - a campus portal for wireless devices to cater the "on-the-move needs" of students and faculty

1. 1
IS C341
(Team Number)
Team Name: OAKS
Software Requirements Specification
Architecture of Campus Portal for Wireless Devices
Shiladitya Mandal
Anand Goyal
Kaustav Ghosh
Omkar Hande
Version: 1.0 Date: 26/01/2013

2. 2
Table of Contents
1. Introduction 4
1.1 Scope 4
1.2 Definitions, Acronyms, and Abbreviations 4
1.3 References 5
1.4 Overview 5
2. The Overall Description 6
2.1 Product Perspective 6
2.1.1 System Interfaces 6
2.1.2 User Interfaces 6
2.1.3 Hardware Interfaces 7
2.1.4 Software Interfaces 7
2.1.5 Communications Interfaces 7
2.1.6 Memory Constraints 8
2.1.7 Operations 8
2.2 Product Functions 9
2.3 User Characteristics 10
2.4 Constraints 10
2.5 Assumptions and Dependencies 11
3. Specific Requirements 13
3.1 External interfaces 13
3.2 Functions 14
3.3 Performance Requirements 15
3.4 Design Constraints 15
3.5 Software System Attributes 15
3.5.1 Reliability 15
3.5.2 Security 15
3.5.3 Maintainability 16
3.5.4 Portability 16
4. Conclusion 17

3. 3
1. Introduction
This SRS describes the software functional and nonfunctional requirements
for release 1.0 of the Campus Portal for Wireless Devices. This document is
intended to be used by the students and faculty of BITS-Pilani Goa and the
members of the project team that will implement and verify the correct
functioning of the system. Unless otherwise noted, all requirements
specified here are high priority and committed for release 1.0.
1.1 Scope
The Campus Portal is developed using university campus as the setting and
the domain for applications developed for the portal for wireless devices.
The portal will focus on real time immediate issues for a student like Class
finding, Faculty finding, Grade calculations, announcements for cancelled
class or deadlines for upcoming project submissions. It will incorporate
features where a student can maintain his time table, schedule and
calendar his examinations and assignment submissions or anything else for
his use. The system, on a wider scale, can also be extended for corporate
offices, where similar issues are faced by the employees.
1.2 Definitions, Acronyms and Abbreviations
SDK Software Development Kit - a set
of software development tools
IDE Integrated Development Environment
- consists of a source code
editor, debugger etc for help
GUI Graphical User Interface – allows user
to interact with electronic devices
using images rather than text
commands
UI User Interface - space where
interaction between humans and
machines occurs
OS Operating Systems
Wi-Fi Wireless Fidelity - allows an electronic

4. 4
device to exchange
data wirelessly (using radio waves)
over a computer network
PHP Personal Home Page - language
designed for Web development to
produce dynamic Web pages
VM Virtual Machine (VM) - a simulation of
a machine (abstract or real)
RAM Random Access Memory – fast and
dynamic memory to store temporary
data
MB/GB Megabyte/Gigabyte – unit of
measuring size of data
MYSQL Standard Query Language - open
source relational database
management system
Apache Web server
phpMyAdmin Free and open source tool written
in PHP intended to handle the
administration of MySQL with the use
of a Web browser
1.3 References
Wireless Java
Programming for
Enterprise
Application
http://books.google.co.in/books?id=6gqsBEbRIYEC&pg=
PT623&lpg=PT623&dq=architecture+for+campus+portal
+for+handheld+devices&source=bl&ots=y0-
uMWppdP&sig=dcOs5_i53mtOWaaNlVvUplIR85A&hl=e
n&sa=X&ei=PmIDUaueDsnIrQeuyIDICA&ved=0CC4Q6AE
wAA
IEEE 1998 IEEE Std 830-1998, IEEE Recommended Practice for
Software Requirements Specifications, ISBN 0-7381-
0332-2.

5. 5
1.4 Overview
This document has been prepared in accordance with the IEEE standard
830-1998, IEEE Recommended Practice for Software Requirements
Specifications [ISBN 0-7381-0332-2]. The document is divided into 4
sections. Section 1 introduces the application. Section 2 provides
information with customer point of view such as Product Perspective,
Product functions, User Characteristics, Constraints, Assumptions and
dependencies and specific requirement. Section 3 focuses more on detailed
technical aspects of the application, basically for developers. This includes
External Interfaces, Functions, Performance Requirements, Logical
Database Requirements, Design Constraints, Software system attributes
and Organizing Specific Requirements. The final Section will be the
conclusions.

6. 6
2. The Overall Description
The product described in this document is campus portal for wireless
devices. This section describes all general factors of the product and its
requirements. It does not state specific requirements. Instead, it provides a
background for those requirements, which are described in section 3.
2.1 Product Perspective
This software is self-contained. The application which will be developed will
not be part of any existing system. But, it is not independent. It will require
access (read and write) to the central database of BITS Pilani Goa Campus -
all information about students, faculty, and courses offered. Existing web
based portals and the new architecture will function separately, but will
share the same database.
2.1.1. System Interfaces
The proposed architecture will be implemented using Android SDK (v20.0.2)
for Java. The Java SDK used is version 1.6.
The IDE used for development is Eclipse 3.7.2(Indigo Service Release 2).
ArgoUML v0.34 has been used for the use case diagram in section 2.
2.1.2. User Interfaces
The front end is designed for wireless devices run on Android OS. It is a GUI
interface, with buttons, check boxes, lists, etc. to navigate through the
application. Outside the applications normal UI, reminders and updates will
be conveyed to user via notifications in the status bar.
The user interface will be optimized for easier usage. Checkboxes and radio
buttons will be used to reduce text input from user, which is cumbersome
in portable devices, especially small touch screens. Also, scroll bars will be
used to minimize display errors, and provide easy navigation for all screen
sizes.

7. 7
2.1.3. Hardware Interfaces
2.1.3.1 Client Side:
Wireless devices with Wi-Fi connectivity above can use the application.
There is no restriction on screen size or any other hardware specifications.
2.1.3.2 Server Side:
The PHP scripts will be hosted on a remote server in the LAN, and will
connect to a MySQL server on the same machine. The web server (Apache)
will be listening on the standard port 80.
2.1.4. Software Interfaces
2.1.4.1 Client Side:
The application is designed for the Android platform. Any wireless device
running on Android OS v2.2 and above can use the application.
2.1.4.2 Server Side:
An Apache web server will accept all requests from the client. A
development database will be hosted locally (MySQL) and the production
database is hosted centrally (MySQL).
Apache server: Version 2.2.22 –
required to host a HTTP web server
MySQL server: Version 5.5.24 –
required to host MySQL database server
PHP: Version 5.3.13 –
required to communicate with database
2.1.5. Communication Interfaces
The software will access the Wi-Fi network to access a local server
(Apache). HTTP protocol will be used to communicate with the server. (RFC
2616 or HTTP/1.1)

8. 8
2.1.6. Memory Constraints
Most Android devices (OS version 2.2 and above) have memory in the
range of 150MB to 1GB RAM. Design footprint should not exceed 100MB.
2.1.7. Operations
2.1.7.1 Modes of operation: The user can either be a student or a faculty.
2.1.7.2 Periods of interactive/unattended operation: When the user’s
device is unlocked and the application is on the forefront of other
applications, it is in interactive mode. There will be a background service
running all the time which analyzes when to provide notifications to user,
and will poll for new updates from the web server.
2.1.7.3 Data security: Username and password provided to application is
not sent as plaint text. Password is encrypted before sending
authentication request to server.
2.1.7.4 Backup and recovery: Procedures for data backup and recovery are
already in place. Since we are using an existing database, the application
need not worry about data backup or recovery.

9. 9
2.2 Product Functions
This section outlines all the main features of Campus Portal.
Figure 1: Rough use case diagram of requirements
2.2.1 Student Role:
 Add/Remove courses to schedule:
Every student, after login, must select which courses he is registered
in/attending informally. To get updates and reminders about classes, one
must select that course.
 Choose mess option:
Whenever mess option opens, student is notified. Henceforth, mess option
can be selected from mobile/web interface(SWD)
2.2.2 Faculty Role:
Faculty need not add courses manually. When they login, they can
automatically see the courses they are registered with.
 View list of students registered for their courses:
Professors who are registered to courses, can see list of students attending
classes for the course.
 Cancel classes:

10. 10
Cancelling a class is just a button click. It will be instantly informed to
students via notifications.
 Quick messages:
Professors can send instant messages to students of a course.
 Set chamber consultancy availability:
When professors are available for chamber consultancy, he can set his
status to available, else busy/offline.
2.2.3 Common Roles for Student/Faculty
 Miscellaneous contacts – SWD, ARC, MedC, cab service, etc.
 View course/faculty/student pages
 Edit personal details
2.2.4 Administrator Role
 Message broadcast by administrator:
Administrators can send any instant urgent broadcast message to all
users/only students/only faculty
 Reset password for users
 Register courses for faculty:
It is the job of the admin to register courses for faculty every semester
2.2.4 Background Services
 Reminder/alarm 10 minutes before class starts
 Auto Silent mode during classes:
The wireless device will automatically turn to silent mode once a class in
the schedule starts (feature can be turned on/off)

11. 11
2.3 User characteristics
User Groups: Student/Faculty/Administrator
2.3.1 Student
 Educational level: High
 Experience with technology: Medium-High
 Domain experience: High
2.3.2 Faculty
 Educational level: High
 Experience with technology: Low-Medium
 Domain experience: High
2.3.3 Administrator
 Educational level: High
 Experience with technology: High
 Domain Experience: Medium
2.4 Constraints
The following are constraints for developers.
2.4.1 Parallel operation:
UI must not be blocked when network operation is taking place. Hence,
threading must be done to parallelize network operation and UI.
2.4.2 Reliability:
To make sure application does not crash, two things must be looked at -
network operation and graphics/animation. The lesser the
animation/graphics, the lesser the probability of crashing (because of low
RAM). Also, it must be mde sure that the network thread does not infinity
wait for response for server.

12. 12
2.4.3 Safety and security:
Password provided by user must not be sent in plaintext format to the web
server – encryption (MD5) must be done before transmission to avoid
intruders. Also, session information must be deleted if user has logged out.
2.5 Assumptions and Dependencies
 It is assumed that user has Android OS v2.2 or above installed. If user has a
lower version, reliability is not guaranteed.
 The correct functioning of the system will partly be dependent on the
correctness of the data stored and managed as part of the existing web-
based system.
 Also, the server crashing (or down for maintenance) will make the
application temporarily unavailable.

13. 13
3. Specific Requirements
The following section describes the requirements in detail. This section is meant
for the designers and developers of the system.
3.1 External Interfaces
Interfaces: Wireless Device & Remote Server
3.1.1 Wireless device
 Name of the product: Wireless device supporting Android v2.2 and
above
 Description of purpose: Get input from the user via touch/text input
and display output on the device screen, and send request to
backend server.
 Source of input or destination of output: input taken from Touch
screen/Keypad and request sent to application backend.
 Valid range, accuracy and/or tolerance: Range and accuracy depends
upon the Wi-Fi signal strength.
 Relationships to other inputs/outputs: Inputs given to the remote
server hosting web and database server.
 No restriction on screen sizes
 Window formats: vertical/horizontal orientation
 Data formats: data will be sent to server in either plain text or
encrypted(password)
 Command formats: user need not type commands. Entire application
is GUI based
3.1.2 Remote server
 Name of the product: Remote server
 Description of purpose: Get input from the application front end and
process the input request and generate corresponding results.
 Source of input or destination of output: Application front end on the
wireless device.

14. 14
 Valid range, accuracy and/or tolerance: Range and accuracy depends
upon the Wi-Fi signal strength and uptime of the server
 Relationships to other inputs/outputs: Inputs taken from the
application front end and output to the same device.
 Data formats: Data will be processed and accessed from MySQL
server.Command formats: Database will be accesed through PHP
scripts.
3.2 Functions
Functional requirements define the fundamental actions that must take
place in the software in accepting and processing the inputs and in
processing and generating the outputs
3.2.1 User authentication
1. User enters username and password
2. The username and encrypted password is sent to the remote backend
server
3. User is authenticated
4. Authentication details is relayed back to the application front end.
5. Limit on password and username length to prevent overflow of
information
3.2.2 Addition of new course to the schedule of a student
1. User will select a course to add to the schedule
2. Request sent to the backend server
3. Availability of class timings in the existing schedule.
4. In case of clashes the course is not added
5. Allotment of the selected course if no clashes.
3.2.3 Chosing mess option
1. User selects his mess option

15. 15
2. Request sent to the mess database server
3. Acknowledgement of mess allocation
3.2.4 Cancellation of class(By professor)
1. Professor cancels a particular class
2. All students registered for the course get a notifications.
3.2.5 Setting chamber consultancy avaibility
1. Professor either sets his availability as present/not present
2. Students can view this availability of the professor.
3.2.6 . View list of Registered students in a course
1. Professor requests for viewing list of registered students
2. Check whether the Professor Is an instructor for the course
3.2.7 Auto silent mode(Background service)
1. Background service is running which turns the device into silent mode if
the student or faculty has a class during that time slot.
2. User can turn this feature on/off.
3.3 Performance Requirements
3.3.1 Supporting simultaneous Users
 The campus currently has around 2500 users including students and
professors/teachers.
 The existing backend database server has it's implementation for
handling simultaneous data modification/access requests.
 Performance of the system will depend upon the processing power
of the existing database server.

16. 16
3.3.1 Amount and type of information to be handled
 Database will be stored in MySQL tables asnd communication will be
done in the form of encrypted/plain text.
 Amount of information sent/received depends upon the request.
3.4 Design Constraints
 There is no restriction on the screen size of devices. Hence, the
developer must add scrollbars in every Activity.
3.5 Software System Attributes
The following section describes the non-functional requirements or quality
attributes of the system.
3.5.1 Reliability
 Reliability of the system partly depends on the backend database
server. While the database server is up and there is good Wi-Fi
connectivity to the server, the application will work perfectly. In case
of database server being down, there is no guarantee that the
application will work.
3.5.2 Security
 Each user (student or faculty) has a unique ID (possibly BITS mail) and
password to login into the portal. An user cannot change details of
other users.

17. 17
 Users can make certain personal information as hidden to public or
hidden to only students. E.g, a student can make his contact
information available only to professors/only students.
 While adding courses to the “timetable”, system produces warning
on clash of timings with an existing course opted by the user.
 When password is sent to the database, we make use of MD5
hashing encryption to prevent intruders from accessing plaintext
passwords.
3.5.3 Maintainability
Since the system has a modular design, it is easy to add new modules for
any new requirements in future versions.
3.5.4 Portability
This software application is packaged into a “.apk” file, which is a standard
file format that runs on any device running Android operating system. So,
any new user who wants to use the application just needs one file.

18. 18
4. Conclusions
In this document we have introduced the application and its general
features available for the end users who are the students and faculty. It
also gives detailed technical aspects and requirements of the application
for the developers. The application focuses on the immediate needs of both
students and faculty while they aren’t in their respective rooms like
classroom, faculty chamber, upcoming tests and timetable, checking
whether is faculty in chamber or not and features such as quick messaging
and notifications are present.
The application has intense usage and with minor modifications, it use can
be extended to various ecosystems like corporate, banks, multinationals,
and various other management and technical sectors.