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

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

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

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=en&sa=X&ei=PmIDUaueDsnIrQeuyIDICA&ved=0CC4Q6AEwAA

IEEE 1998 IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, ISBN 0-7381-0332-2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.