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

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

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 IDE Software Development Kit - a set of software development tools Integrated Development Environment - consists of a source code editor, debugger etc for help Graphical User Interface allows user to interact with electronic devices using images rather than text commands User Interface - space where interaction between humans and machines occurs Operating Systems Wireless Fidelity - allows an electronic

GUI

UI

OS Wi-Fi

4 device to exchange data wirelessly (using radio waves) over a computer network Personal Home Page - language designed for Web development to produce dynamic Web pages Virtual Machine (VM) - a simulation of a machine (abstract or real) Random Access Memory fast and dynamic memory to store temporary data Megabyte/Gigabyte unit of measuring size of data Standard Query Language - open source relational database management system Web server Free and open source tool written in PHP intended to handle the administration of MySQL with the use of a Web browser

PHP

VM RAM

MB/GB MYSQL

Apache phpMyAdmin

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=y0uMWppdP&sig=dcOs5_i53mtOWaaNlVvUplIR85A&hl=e n&sa=X&ei=PmIDUaueDsnIrQeuyIDICA&ved=0CC4Q6AE wAA IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, ISBN 0-73810332-2.

IEEE 1998

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.

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.

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)

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 users 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.

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 webbased 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 arent 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.