Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Campus portal for wireless devices srs


Published on

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

Published in: Education
  • hi there am conducting a research on how to come up with a captive portal for my business dealing in internet provision to my customers and businesses around my premises if you got material regarding your research please forward them to me
    Are you sure you want to  Yes  No
    Your message goes here

Campus portal for wireless devices srs

  1. 1. 1IS C341(Team Number)Team Name: OAKSSoftware Requirements SpecificationArchitecture of Campus Portal for Wireless DevicesShiladitya MandalAnand GoyalKaustav GhoshOmkar HandeVersion: 1.0 Date: 26/01/2013
  2. 2. 2Table of Contents1. Introduction 41.1 Scope 41.2 Definitions, Acronyms, and Abbreviations 41.3 References 51.4 Overview 52. The Overall Description 62.1 Product Perspective 62.1.1 System Interfaces 62.1.2 User Interfaces 62.1.3 Hardware Interfaces 72.1.4 Software Interfaces 72.1.5 Communications Interfaces 72.1.6 Memory Constraints 82.1.7 Operations 82.2 Product Functions 92.3 User Characteristics 102.4 Constraints 102.5 Assumptions and Dependencies 113. Specific Requirements 133.1 External interfaces 133.2 Functions 143.3 Performance Requirements 153.4 Design Constraints 153.5 Software System Attributes 153.5.1 Reliability 153.5.2 Security 153.5.3 Maintainability 163.5.4 Portability 164. Conclusion 17
  3. 3. 31. IntroductionThis SRS describes the software functional and nonfunctional requirementsfor release 1.0 of the Campus Portal for Wireless Devices. This document isintended to be used by the students and faculty of BITS-Pilani Goa and themembers of the project team that will implement and verify the correctfunctioning of the system. Unless otherwise noted, all requirementsspecified here are high priority and committed for release ScopeThe Campus Portal is developed using university campus as the setting andthe domain for applications developed for the portal for wireless devices.The portal will focus on real time immediate issues for a student like Classfinding, Faculty finding, Grade calculations, announcements for cancelledclass or deadlines for upcoming project submissions. It will incorporatefeatures where a student can maintain his time table, schedule andcalendar his examinations and assignment submissions or anything else forhis use. The system, on a wider scale, can also be extended for corporateoffices, where similar issues are faced by the employees.1.2 Definitions, Acronyms and AbbreviationsSDK Software Development Kit - a setof software development toolsIDE Integrated Development Environment- consists of a source codeeditor, debugger etc for helpGUI Graphical User Interface – allows userto interact with electronic devicesusing images rather than textcommandsUI User Interface - space whereinteraction between humans andmachines occursOS Operating SystemsWi-Fi Wireless Fidelity - allows an electronic
  4. 4. 4device to exchangedata wirelessly (using radio waves)over a computer networkPHP Personal Home Page - languagedesigned for Web development toproduce dynamic Web pagesVM Virtual Machine (VM) - a simulation ofa machine (abstract or real)RAM Random Access Memory – fast anddynamic memory to store temporarydataMB/GB Megabyte/Gigabyte – unit ofmeasuring size of dataMYSQL Standard Query Language - opensource relational databasemanagement systemApache Web serverphpMyAdmin Free and open source tool writtenin PHP intended to handle theadministration of MySQL with the useof a Web browser1.3 ReferencesWireless JavaProgramming forEnterpriseApplication 1998 IEEE Std 830-1998, IEEE Recommended Practice forSoftware Requirements Specifications, ISBN 0-7381-0332-2.
  5. 5. 51.4 OverviewThis document has been prepared in accordance with the IEEE standard830-1998, IEEE Recommended Practice for Software RequirementsSpecifications [ISBN 0-7381-0332-2]. The document is divided into 4sections. Section 1 introduces the application. Section 2 providesinformation with customer point of view such as Product Perspective,Product functions, User Characteristics, Constraints, Assumptions anddependencies and specific requirement. Section 3 focuses more on detailedtechnical aspects of the application, basically for developers. This includesExternal Interfaces, Functions, Performance Requirements, LogicalDatabase Requirements, Design Constraints, Software system attributesand Organizing Specific Requirements. The final Section will be theconclusions.
  6. 6. 62. The Overall DescriptionThe product described in this document is campus portal for wirelessdevices. This section describes all general factors of the product and itsrequirements. It does not state specific requirements. Instead, it provides abackground for those requirements, which are described in section 3.2.1 Product PerspectiveThis software is self-contained. The application which will be developed willnot be part of any existing system. But, it is not independent. It will requireaccess (read and write) to the central database of BITS Pilani Goa Campus -all information about students, faculty, and courses offered. Existing webbased portals and the new architecture will function separately, but willshare the same database.2.1.1. System InterfacesThe 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 User InterfacesThe front end is designed for wireless devices run on Android OS. It is a GUIinterface, with buttons, check boxes, lists, etc. to navigate through theapplication. Outside the applications normal UI, reminders and updates willbe conveyed to user via notifications in the status bar.The user interface will be optimized for easier usage. Checkboxes and radiobuttons will be used to reduce text input from user, which is cumbersomein portable devices, especially small touch screens. Also, scroll bars will beused to minimize display errors, and provide easy navigation for all screensizes.
  7. 7. 72.1.3. Hardware Interfaces2.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. Server Side:The PHP scripts will be hosted on a remote server in the LAN, and willconnect to a MySQL server on the same machine. The web server (Apache)will be listening on the standard port Software Interfaces2.1.4.1 Client Side:The application is designed for the Android platform. Any wireless devicerunning on Android OS v2.2 and above can use the application. Server Side:An Apache web server will accept all requests from the client. Adevelopment database will be hosted locally (MySQL) and the productiondatabase is hosted centrally (MySQL).Apache server: Version 2.2.22 –required to host a HTTP web serverMySQL server: Version 5.5.24 –required to host MySQL database serverPHP: Version 5.3.13 –required to communicate with database2.1.5. Communication InterfacesThe software will access the Wi-Fi network to access a local server(Apache). HTTP protocol will be used to communicate with the server. (RFC2616 or HTTP/1.1)
  8. 8. 82.1.6. Memory ConstraintsMost Android devices (OS version 2.2 and above) have memory in therange of 150MB to 1GB RAM. Design footprint should not exceed 100MB.2.1.7. Operations2.1.7.1 Modes of operation: The user can either be a student or a faculty. Periods of interactive/unattended operation: When the user’sdevice is unlocked and the application is on the forefront of otherapplications, it is in interactive mode. There will be a background servicerunning all the time which analyzes when to provide notifications to user,and will poll for new updates from the web server. Data security: Username and password provided to application isnot sent as plaint text. Password is encrypted before sendingauthentication request to server. Backup and recovery: Procedures for data backup and recovery arealready in place. Since we are using an existing database, the applicationneed not worry about data backup or recovery.
  9. 9. 92.2 Product FunctionsThis section outlines all the main features of Campus Portal.Figure 1: Rough use case diagram of requirements2.2.1 Student Role: Add/Remove courses to schedule:Every student, after login, must select which courses he is registeredin/attending informally. To get updates and reminders about classes, onemust select that course. Choose mess option:Whenever mess option opens, student is notified. Henceforth, mess optioncan be selected from mobile/web interface(SWD)2.2.2 Faculty Role:Faculty need not add courses manually. When they login, they canautomatically 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 attendingclasses for the course. Cancel classes:
  10. 10. 10Cancelling a class is just a button click. It will be instantly informed tostudents 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 hisstatus 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 details2.2.4 Administrator Role Message broadcast by administrator:Administrators can send any instant urgent broadcast message to allusers/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 semester2.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 inthe schedule starts (feature can be turned on/off)
  11. 11. 112.3 User characteristicsUser Groups: Student/Faculty/Administrator2.3.1 Student Educational level: High Experience with technology: Medium-High Domain experience: High2.3.2 Faculty Educational level: High Experience with technology: Low-Medium Domain experience: High2.3.3 Administrator Educational level: High Experience with technology: High Domain Experience: Medium2.4 ConstraintsThe 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 theanimation/graphics, the lesser the probability of crashing (because of lowRAM). Also, it must be mde sure that the network thread does not infinitywait for response for server.
  12. 12. 122.4.3 Safety and security:Password provided by user must not be sent in plaintext format to the webserver – encryption (MD5) must be done before transmission to avoidintruders. 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 alower version, reliability is not guaranteed. The correct functioning of the system will partly be dependent on thecorrectness of the data stored and managed as part of the existing web-based system. Also, the server crashing (or down for maintenance) will make theapplication temporarily unavailable.
  13. 13. 133. Specific RequirementsThe following section describes the requirements in detail. This section is meantfor the designers and developers of the system.3.1 External InterfacesInterfaces: Wireless Device & Remote Server3.1.1 Wireless device Name of the product: Wireless device supporting Android v2.2 andabove Description of purpose: Get input from the user via touch/text inputand display output on the device screen, and send request tobackend server. Source of input or destination of output: input taken from Touchscreen/Keypad and request sent to application backend. Valid range, accuracy and/or tolerance: Range and accuracy dependsupon the Wi-Fi signal strength. Relationships to other inputs/outputs: Inputs given to the remoteserver 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 orencrypted(password) Command formats: user need not type commands. Entire applicationis GUI based3.1.2 Remote server Name of the product: Remote server Description of purpose: Get input from the application front end andprocess the input request and generate corresponding results. Source of input or destination of output: Application front end on thewireless device.
  14. 14. 14 Valid range, accuracy and/or tolerance: Range and accuracy dependsupon the Wi-Fi signal strength and uptime of the server Relationships to other inputs/outputs: Inputs taken from theapplication front end and output to the same device. Data formats: Data will be processed and accessed from MySQLserver.Command formats: Database will be accesed through PHPscripts.3.2 FunctionsFunctional requirements define the fundamental actions that must takeplace in the software in accepting and processing the inputs and inprocessing and generating the outputs3.2.1 User authentication1. User enters username and password2. The username and encrypted password is sent to the remote backendserver3. User is authenticated4. Authentication details is relayed back to the application front end.5. Limit on password and username length to prevent overflow ofinformation3.2.2 Addition of new course to the schedule of a student1. User will select a course to add to the schedule2. Request sent to the backend server3. Availability of class timings in the existing schedule.4. In case of clashes the course is not added5. Allotment of the selected course if no clashes.3.2.3 Chosing mess option1. User selects his mess option
  15. 15. 152. Request sent to the mess database server3. Acknowledgement of mess allocation3.2.4 Cancellation of class(By professor)1. Professor cancels a particular class2. All students registered for the course get a notifications.3.2.5 Setting chamber consultancy avaibility1. Professor either sets his availability as present/not present2. Students can view this availability of the professor.3.2.6 . View list of Registered students in a course1. Professor requests for viewing list of registered students2. Check whether the Professor Is an instructor for the course3.2.7 Auto silent mode(Background service)1. Background service is running which turns the device into silent mode ifthe student or faculty has a class during that time slot.2. User can turn this feature on/off.3.3 Performance Requirements3.3.1 Supporting simultaneous Users The campus currently has around 2500 users including students andprofessors/teachers. The existing backend database server has its implementation forhandling simultaneous data modification/access requests. Performance of the system will depend upon the processing powerof the existing database server.
  16. 16. 163.3.1 Amount and type of information to be handled Database will be stored in MySQL tables asnd communication will bedone 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, thedeveloper must add scrollbars in every Activity.3.5 Software System AttributesThe following section describes the non-functional requirements or qualityattributes of the system.3.5.1 Reliability Reliability of the system partly depends on the backend databaseserver. While the database server is up and there is good Wi-Ficonnectivity to the server, the application will work perfectly. In caseof database server being down, there is no guarantee that theapplication will work.3.5.2 Security Each user (student or faculty) has a unique ID (possibly BITS mail) andpassword to login into the portal. An user cannot change details ofother users.
  17. 17. 17 Users can make certain personal information as hidden to public orhidden to only students. E.g, a student can make his contactinformation available only to professors/only students. While adding courses to the “timetable”, system produces warningon clash of timings with an existing course opted by the user. When password is sent to the database, we make use of MD5hashing encryption to prevent intruders from accessing plaintextpasswords.3.5.3 MaintainabilitySince the system has a modular design, it is easy to add new modules forany new requirements in future versions.3.5.4 PortabilityThis software application is packaged into a “.apk” file, which is a standardfile 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. 184. ConclusionsIn this document we have introduced the application and its generalfeatures available for the end users who are the students and faculty. Italso gives detailed technical aspects and requirements of the applicationfor the developers. The application focuses on the immediate needs of bothstudents and faculty while they aren’t in their respective rooms likeclassroom, faculty chamber, upcoming tests and timetable, checkingwhether is faculty in chamber or not and features such as quick messagingand notifications are present.The application has intense usage and with minor modifications, it use canbe extended to various ecosystems like corporate, banks, multinationals,and various other management and technical sectors.