Software Requirements Specification

SBRA Automation Facility

Aritra Saha Rahul Varma Vipendra Pal Singh

Faculty Housing System

Mayank Kumar Kolipey Abhishek Lokesh Jangid Vijay Suralkar

Hostel Management System

Bhuvnesh Goyal Karanveer Singh Ankit Sharma

Academic Area Management System

Shantanu Srivastava Devanshu Bhimwal Abhishek Gera Asheesh Agrawal Saurabh Saxena

Amenities, Housing and Academic Area Mapping Module

Kasina Abhishek Chirag Sangani Devesh Kumar Singh

Table of Contents 1. Introduction ................................................................................................................................ 1 1.1 Purpose ............................................................................................................................................ 1 1.2 Document Conventions .................................................................... Error! Bookmark not defined. 1.3 Intended Audience and Reading Suggestions................................... Error! Bookmark not defined. 1.4 Project Scope ................................................................................................................................... 1 1.5 References ....................................................................................................................................... 2 2. Overall Description ...................................................................................................................... 2 2.1 Product Perspective ......................................................................................................................... 2 2.2 Product Features.............................................................................................................................. 3 2.3 User Classes and Characteristics ...................................................................................................... 4 2.4 Operating Environment ................................................................................................................... 4 2.4 Design and Implementation Constraints ......................................................................................... 5 2.5 User Documentation ........................................................................................................................ 5 2.6 Assumptions and Dependencies ...................................................................................................... 5 3. System Features .......................................................................................................................... 5 3.1 General use cases............................................................................................................................ 5 3.2 Admin use cases............................................................................................................................... 6 4. External Interface Requirements .................................................................................................. 5 4.1 User Interfaces ................................................................................................................................. 5 4.2 Hardware Interfaces ........................................................................................................................ 5 4.3 Software Interfaces .......................................................................................................................... 5 4.4 Communications Interfaces ............................................................................................................. 6 5. Other Nonfunctional Requirements .............................................................................................. 7 5.1 Performance Requirements ............................................................................................................. 7 5.2 Security Requirements ..................................................................................................................... 7

1. Introduction
1.1 Purpose
This document aims to provide the functional and non-functional requirements for a website, integrated from five modules SBRA Automation System Module, Faculty Housing Module, Hostel Management System Module, Amenities, Housing and Academic Area Mapping Module and Academic Area Management System Module The SBRA Automation System Module aims to provide the functional requirements for the same. It also makes the functionality clear to the end users. It explains the functional features of the database, along with interface details and design constraints. The purpose of Faculty Housing Module is to provide relevant information regarding the real estate features of the residential houses of faculty members at IIT Kanpur Campus. This information will include attributes like: Carpet area of houses, Garden area of houses, No. of rooms in houses, Maintenance Management of houses (with logs of all maintenance), exhaustive search engine for Faculty search with address and other relevant attributes. The amount of information will be accessible to different users with different levels of authentication. The Hostel Management System module provides hostel-information like real-estate information, room allocation details, details about various amenities and facilities like canteen, mess, TV-room etc., employee information, important notifications, complaints submission etc. The Academic Area Management System Module provides details related to automated centralized portal for the management of academic area resources. The system would serve as an information portal and also provide booking facility for the lecture halls and other bookable resources. The purpose of Amenities, Housing and Academic Area Mapping Module is to bring together and automate the information related to real estate entities in the campus such as staff housing, the visitors' hostel, the VH extension including visiting faculty's housing and other general amenities in the campus, like auditorium, SAC, OAT, swimming pool etc. We also intend to accommodate common queries pertaining to availability, etc. The purpose of this module is to provide a detailed mapping of the real estate of the institution's academic area with the departments holding them. The module is not concerned with any estate outside the academic area, though it does take into consideration, the entire area inside it. A search facility will also be provided to the user, through which major locations in the estate can be found. The expected audiences of this document are the students of course CS455, Dr. Sanjeev K Aggarwal and Course TAs.

1.2 Project Scope

1. 2. 3. 4. Provide information in an organized and user friendly web-interface. Significant reduction in the amount of paperwork. Overall reduction in efforts put in by the authorities. Efficient query-handling.

5. An online system for booking various types of resources with complete transparency

1.3 References
1. www.iitk.ac.in/sbra 2. We will be heavily referring to the existing modules and online portals developed at IITK to avoid redundancy and mistakes which were done in the past. These portals will include library automation, office automation, CC automation, Real Estate office etc. 3. http://mcis.jsu.edu/studio/SRSSample.doc 4. http://www.cse.msu.edu/~chengb/RE-491/Papers/SRSExample-webapp.doc

2. Overall Description
2.1 Product Perspective
SBRA automation system is a content management system in which all the information about the residents and room allocations in SBRA is maintained. The data is stored in a database engine which can be modified by the administrator and queried by the user. The service may be accessed using a standard web browser like Internet Explorer or Google Chrome. The Faculty Housing has precise data about the real estate information about the faculty housing. Such type of centralized information system is of extreme importance and relevance to several authorities at the IITK campus. The Hostel Management System will be completely web-based, linking to the server residing in IIT Kanpur through a standard web-browser. An Internet connection is necessary to access the system. The system will be information based i.e. there is no provision of booking/reservation of services/facilities. The only exception is the feature of complaint submission. The information management will be done using database management system. A web interface will also be provided to an admin to edit the contents of the databases. The Academic Area Management aims to replace the existing information and booking system at IIT Kanpur. Currently there is no centralized information system in the campus. Any details about the resources need to be procured from the respective managements. The booking is also done manually at different offices for different resources. As such, there is a need for an automated and centralized system for the same. Amenities, Housing and Academic Area Mapping Module intends to get all possible estates which can be automated and maintained as such under a single roof. It will also focus on the academic area and map it with the departments.

2.2 Product Features

The main feature 'SBRA automation system has that it allows the user to search for the information related to the SBRA like finding the Apartment number of a particular person or finding the number of vacancies in the SBRA. It also allows the admin to update the database and keep it up to date. The main features of Faculty Housing Management System are: 1. Exhaustive search engine for faculty- This functionality will help to search a faculty with their current housing address with very less information at hand, and thus facilitate better search engine. 2. Faculty Housing Info management- This functionality will increase the amount of precise and relevant information available about faculty housing. 3. Land area/Carpet area/Dimensions of rooms/Garden area- This information might be extremely crucial to the maintenance department and room allocation committee. 4. Maintenance Management System- This functionality will be useful to the people of the maintenance department. The Academic Area Management System allows one to navigate through academic area at room level granularity. Apart from this the system has a feature using which one can view the room occupancy and other details. It also provide interface to view availability of the room and book the same. It will also provide architectural details like floor-area, constructional area and other. The Amenities, Housing and Academic Area Mapping Module will consist of a detailed and exhaustive database covering all important features of the target estates. Users can view, add, delete or modify information according to the permissions allotted to them. Furthermore, activities pertaining to a specific building, for instance, booking of rooms in VH, allotment of houses in Staff housing can be integrated too. The module also consists of simple colour-coding of the academic area because most of the estates are held by individual departments. However for estates held by multiple departments, such as the faculty building, we shall provide a door-by-door view of the estate for better representation. The features of Hostel Management System are: 1. Search students on the basis of various attributes 2. Room allocation 3. Projecting when a particular room will become empty and how many rooms will be empty on a particular date. 4. A search interface for IP address information will also be incorporated. 5. The contact details of Hostel Wardens, HEC and office. 6. Notifications of all hostels 7. The real estate information of each hall. 8. The map of the hostel will be available along with a section of page depicting notifications related to hostel. 9. There will be link to the content representing the recreational facilities in the hostel. 10. Search facility related to the hostel staff. There will be four search parameters Type of job, Designation of the person, Wing allotment and phone number of the concerned person. 11. Information regarding various shops in the hostel area. 12. Miscellaneous information - timings of mess, canteen, shops and computer room and office hours of hostel.

13. An interface for students to submit complaints regarding the hostel facilities. The user can authenticate himself/herself using his/her CC credentials. On authentication, the user will be presented with a form, where he/she can enter his/her name, roll no, etc, and his/her complaint.

2.3 User Classes and Characteristics

1. The general user who intends to find out information about people residing in SBRA or wants to enquire about the room allocation, vacancy etc. 2. The administrator whose primary goal is to keep the database up-to-date. 3. General user for searching information of faculty information etc., for maintenance complaints of both hostels and faculty housing. 4. The Maintenance Dept. for managing complaints and maintenance logs etc. 5. General user who desires to search students on the basis of various attributes 6. IIT Kanpur authorities who intend to check on room allocation 7. IIT Kanpur authorities intending to know when a particular room will become empty and how many rooms will be empty on a particular date. 8. Students who intend to search for IP address information will also be incorporated. 9. General users who intend to know the contact details of Hostel Wardens, HEC and office. 10. Hall residents - Notifications of all hostels 11. IIT Kanpur maintenance and other authorities intending to know about the real estate information of each hall. 12. General user who intends to use the map of the hostel will be available along with a section of page depicting notifications related to hostel. 13. Hostel residents who intend to know about the recreational facilities in the hostel. 14. IIT Kanpur authorities and hostel residents who intend to search the hostel staff. 15. General user who need the information regarding various shops in the hostel area. 16. Miscellaneous information intended for hostel residents like timings of mess, canteen, shops and computer room and office hours of hostel. 17. Hostel residents can submit complaints regarding the hostel facilities. 18. The project would be used by the campus community for getting information related to the academic area resources and booking facility. 19. It would also be used by the administrators for granting or denying booking requests, modifying existing information in the system, and for allocation of resources to various departments. 20. Users with permissions to access as well as modify the map data like colour-codes, tags, or inclusion of a newly constructed building, etc. and users with permissions only to access but not modify the map. However users of both the classes can make use of the sub-modules like that of tag-search.

2.4 Operating Environment

The operating environment is as follows: 1. System will be deployed on a central server which would have a HTTP Server and a Database Server. 2. Users would use the system through a HTTP browser that permits cookies to be stored.

3. The HTTP Server used would be Apache on Linux. 4. The database server used would by MySql.

2.5 Design and Implementation Constraints

The server should have sufficient resources (CPU, RAM, and Disk Space) to service the required number of users. 1. 2 GHz 1 GB RAM PC 2. Open source platforms are used and so there may be some performance and support issues as opposed to proprietary components that integrate well if they are all from the same vendor. 3. The system would be available only in English 4. The system would have a lightweight web interface to enable quick loading over low bandwidth connections. 5. The administrator is responsible for maintain the database 6. The administrator is also responsible for maintaining the physical security of the system. 7. Remote security will have to be ensured by the system itself 8. The module is based entirely on data provided by the institute. So the accuracy of the module depends entirely on the accuracy of the data provided during the construction of the module.

2.6 User Documentation

The User Interface would be very simplistic and self explanatory. This would eradicate the need for user documentation for the general user whose primary goal would be to query the database. A documentation manual would be provided to the system admin but here again the simplistic nature of the User Interface would avoid significant dependency on the documentation.

2.7 Assumptions and Dependencies

For full working of the system the computers that the users use to connect to the system should be able to access the server on which the system is deployed. 1. The server should remain powered on as far as possible and in case of a power failure, there should be indefinite power back up or a controlled shutdown should be performed. 2. The browsers used to access the system should support cookies.

3. System Features
SBRA Automation System 3.1 General use cases
Login In this case user will be asked to provide login information to access the database, if the login information is correct then user is taken to navigate window else user will again taken to login page.

Logout A logout link (probably in the right hand top corner of the navigation page) Navigate Window After successful login user is taken to this navigate window. This further contains the function which user can use. Search The primary feature as far as the user is concerned. This would allow him to query on the database on the basis of several parameters like Department, Apartment Number, Programme enrolled in, etc.

3.2 Admin use cases

Login In this case admin will be asked to provide login information to access the database, if the login information is correct then user is taken to navigate window else user will again taken to login page. Logout A corresponding logout functionality for the admin to log him out of the system Update Will allow the admin to modify the database and keep it up to date. Search Search will be enabled for the admin as well so that he may find out with much ease information like the number of vacancies currently in the SBRA.

Faculty Housing Module

3.2.1 Faculty Information Search Engine

Description and Priority A user can get details like name, designation, address, email-id, department etc. by using a search engine with a list of search criteria like name, designation (professor, assistant professor etc.), house number etc. Priority: High Stimulus/Response Sequences 1. User navigates to the search page 2. User selects the search criteria and fills the search query 3. User submits the form 4. Server checks for an empty or invalid form.

5. If the form is valid, server queries the faculty information table of the database and presents user with search results. Functional Requirements REQ-1: REQ-2: user is provided with comprehensive list of search criteria like name, department, designation, house number, email-id, pf-number and gender. on choosing the search criteria, user gets either a space to write the query like in case of name, email-id OR a list of options to choose from like in case of choosing department, user gets a list of all departments to choose from. (In case of an empty search query, it is taken as default and all the results in the table will be output) in case of invalid form the user is prompted about the invalid input before submitting. Only a valid search form is processed. Faculty Information Management

ERR-1:

3.2.2

Description and Priority Interface for an admin to add a new entry, edit an existing entry and delete an existing entry from the faculty information database. Priority: Medium Stimulus/Response Sequences 1. An admin navigates to the faculty information management page 2. Admin chooses whether to add, edit or delete. 3. If add was chosen, admin is presented with an empty details-form. 4. admin submits the form 5. server checks for empty fields 6. If the form is valid, server queries the faculty information table of the database and creates a new entry. 7. If edit or delete was chosen, admin now sees the faculty information search page. Admin selects the faculty to be edited or deleted. 8. If edit was chosen, admin is presented with a details-form containing the existing information for the selected faculty. 9. After updating the details, admin submits the form. 10. Server checks for empty fields. 11. If the form is valid, server queries the database and updates the corresponding entry in the faculty information table. 12. If delete was chosen, admin is prompted to confirm deletion. 13. On confirmation of deletion, server queries the database and deletes the corresponding entry in the faculty information table. 14. On successful execution of either of add, edit or delete operations, admin gets a success message.

Functional Requirements REQ-1: REQ-2: REQ-3: REQ-4: REQ-5: ERR-1: ERR-2: ERR-3: on choosing to add, admin gets an empty form to fill details of the faculty and a submit button. on submitting a filled form, server creates a new entry in faculty information table of the database using details from the submitted form. on choosing edit, admin gets a form with all details filled with the existing data and an update button. on submitting a filled form, server updates the existing information with new information from the form in the faculty information table. on choosing delete, admin gets a confirmation dialog. On selecting YES, server deletes the entry for the selected faculty from the faculty information table. in case of submitting a form with an empty field, user is prompted to fill all the fields before hitting submit; only a fully filled form is accepted and processed by server. if connection is terminated before a form is submitted, the fields are cleared, no changes are done to the database and server moves to wait state. if connection is terminated after a form is submitted, the database is modifies accordingly. Server proceeds normally to add, update or delete a database entry. House Information System

3.2.3

Description and Priority Interface to get detailed information about a faculty house. Priority: High Stimulus/Response Sequences 1. user navigates to housing information page 2. User selects the house-type (type III, type IV) from drop-down lists and clicks submit. 3. Server queries the housing information table of the database and presents user with details like land area, carpet area, floors etc. for the selected house type. Functional Requirements REQ-1: REQ-2: a list of house-types is present. on choosing the house type and clicking submit server displays all the details like land area, carpet area, floors, occupation status, number of rooms and dimensions of rooms for that house type from the housing information table of database. if user clicks on submit before selecting the house type, he/she is prompted to first select the type and then submit. User stays on the page to do so. if connection is terminated before the form is submitted, the fields are cleared and server moves to wait state. if connection is terminated after form is submitted, server returns to wait state.

ERR-1: ERR-2: ERR-3:

3.2.4

Maintenance Management System

Description and Priority Interface for a faculty to lodge complaints like electricity problems etc. and also for a maintenance person to check for complaints. It also provides the complete maintenance history or Log for a house. Priority: High Stimulus/Response Sequences 1. Faculty navigates to maintenance page. Server presents him/her with a complaint-form. 2. After filling the form faculty submits it. Server checks form empty fields. 3. If the form is valid, a new entry is created in the complaints table of the database. 4. In case of a maintenance person say MP, MP navigates to the maintenance page. Server presents him/her with a list of complaints. 5. MP selects and views a complaint. The complaint also contains the housing details. 6. MP selects to view the maintenance history and is presented with a page to select a particular house 7. On selecting the house number and submitting, server queries the complaints table of the database and displays complete list of past maintenance work. Functional Requirements REQ-1: a faculty can access the complaints page. The page contains a form to describe the complaint and provide house number. On submitting the form, a new entry is created in the complaints table of database. a maintenance person say MP, can access the complaint list page and maintenance history page of a house. the complaint-list page shows a list of unresolved complaints. The list contains a brief description of the complaint. On selecting a complaint, MP sees the full complaint with complete housing information. Server displays the housing information using the house number that the faculty provided while lodging the complaint. Maintenance page gives MP options to select a particular house like in Housing Information System; a list of house-types and a list of corresponding house numbers. On selecting a house number and clicking on submit server displays the complete history of maintenance work done on that house from the complaints table. In case of a user submitting a form with an empty field, a prompt is displayed to fill all fields before submitting and user stays on the page. if connection is terminated before a form is submitted, the fields are cleared and server moves to wait state. if connection is terminated after form is submitted, server returns to wait state.

REQ-2: REQ-3:

REQ-4:

ERR-1: ERR-2: ERR-3:

Hostel Management System

Students/Room Search The user visits the homepage. For this use case to be initiated the user must be connected to the Internet and on the Hostel Management homepage. 1. 2. 3. 4. 5. The user selects the Search link. The server returns the search form. The user fills in the form. The user clicks submit. The server returns the required information.

Accessing hostel information The User navigates to the site for a specific hostel. For this use case to be initiated the user must be connected to the Internet and on the homepage of the system. 1. 2. 3. 4. User clicks on the area tab and he is navigated to the page in which all areas are displayed categorically. On the Map link, user will find a detailed map of the hostel. On the notification frame of the page, all the latest notifications and events will be displayed On clicking the recreation link, the user will reach the page depicting information related to the recreational facilities available in the hostel which can include reading room, TV room, table tennis room, other sports facilities etc.

Search facility for hostel staff The user has to fill in some of the fields and click on 'Submit' button For this use case to be initiated, the user must be connected to the Internet and connected to the particular server residing inside IIT Kanpur. 1. The user connects to the particular web server inside IIT Kanpur. 2. The user fills in the specific parameters and clicks on the 'Submit' button. 3. The query handler goes through the database to show the appropriate results. Information about various shops inside a hostel The user wants to see the information about shop(s) in a particular hall. For this use case to be initiated the user must be connected to the Internet and connected to this particular server inside IIT Kanpur. 1. The user clicks on the hall button (each hall will have a button on the homepage).

2. After going on the page of that hall, the user will click on the 'Shops' button on that page. 3. The user will get the information. Miscellaneous The link titled miscellaneous will provide with information regarding timings of miscellaneous parts of hostel. For this use case to be initiated the Alum must be connected to the Internet and on the mainpage of hostel. 1. The user chooses to click on the link titled miscellaneous. 2. The user is navigated to a page which displays information about the timings of the mess, canteen, shops, office etc. Complaint submission The user visits the complaints submission page For this use case to be initiated the user must be connected to the Internet and on the complaints submission page. 1. 2. 3. 4. 5. 6. The user logs in using his CC credentials. The user is presented with a form on successful login. The user fills up his name, roll no and room no. The user fills up his compaint in a text area. The user clicks on submit. The complaint is added in the database, and a notification is sent to the warden/hall office.

Academic Area Management System

Navigational System The aim of this system is to allow user to navigate through the academic area. It will be a high priority feature. Stimulus/Response Sequences Initially the map of whole academic area will be presented displaying the various building in it. The user then can click on the building whose detail map he/she wishes. It will zoom in/open up the map of that building and on similar line the map till floor level details can be viewed. One can then click on the resource to view its complete details. Functional Requirements To be developed

Information System The aim of this system is to allow user to query for information including room-capacity, floor-area, department, occupants. It will be a high priority feature. Stimulus/Response Sequences User can search for the desired information by combination of various parameters A simple query builder type of interface will be provided and output will be a list corresponding to the query. If time permits we will be displaying the result on a map. Functional Requirements To be developed Booking System The aim of this system is to allow a interface which will allow user to view room availability and book the same. It will be a high priority feature. Stimulus/Response Sequences The interface will provide user with parameters like capacity, time-availability and location Using these one can issue a query and list of room would be displayed. User can then make request for the rooms which he/she desire. IT will send a notification to corresponding administrator on whose approval, corresponding changes will be made to database and client will be notified back. Apart from this, user can also view the pending requests. Functional Requirements To be developed

Amenities, Housing and Academic Area Mapping Module

Filtered Search
The details of the staff housing, both regular and visiting can be found out through altered search consisting of filters like house number, employee name, employee id, etc. This is a high priority feature. Stimulus - Response When there is a match in the database with the filters specified, the corresponding entry will be displayed. In any other case, the user will be redirected to modify his search criteria. Functional Requirements To be developed

Availability and Booking

The status of various amenities and housing facilities, which can be booked will be dynamically updated. In case of any vacancy, details regarding how to book them will be provided to the user. This is a high priority feature. Stimulus - Response The status of any request made by the user will be displayed along with the status details for the entire week alongside it. Functional Requirements To be developed

Static Data Access

Various details regarding the estates which are expected not to change for a relatively long period of time come under the umbrella of static data. Stimulus - Response There is not much of a stimulus-response interaction here, as the data displayed is always the same. Functional Requirements To be developed

Tag Search
The major areas in the map will be tagged prior to the deployment of the module. The search sub-module will allow the users to search for the location of any tag if searched for, on the map. This is a high priority feature for the module. Stimulus Response The location on the map will be centered and highlighted on the map in case there is a matching tag found. In case there is no matching tag found, a tag request can be sent to the administrators. The search submodule will allow the users to search for the location of any tag if searched for, on the map. The users with access to modify the map data can add, delete or modify the tags at any time. Functional Requirements To be developed

External Interface Requirements

4.1 User Interfaces
The user interface of this system will be web based. Login page This is the main page which the user will see when entered into the interface for the database. Navigation page After successful login the user will b navigated to this page. This page will contain:

Search database This page will give user a category wise search. Some of the categories could be Department, Gender, Apartment Number, Program enrolled into, etc. Logout It will logout the user from the system. The GUI which we are planning to use might typically have Text fields, buttons, drop down boxes, tick boxes, radio buttons etc. and frames of other features and links to other features. So that all the features can be accessed from the main page. The output and error messages will be displayed in the same page below the features. The user interface consists of web based portal, designed for viewing in web browsers. It will be made through HTML, CSS, and PHP. Scripts like Flash and Java Script will also be used. As long as any browser is supported in an environment, there will be no other hardware requirements

4.2 Hardware Interfaces

A computer with connection to the internet.

4.3 Software Interfaces

Server side For server side we need: Apache Web Server For hosting the entire system apache server will be used. PHP For handling the data from the user to update database, PHP will be used as a scripting language. MySQL Database Engine For maintaing the database MySQL will be used as a database engine, it will store all the tables. Client side For client side a HTML web browser with JavaScript support is needed like Internet Explorer, Firefox.

4.4 Communications Interfaces

1. HTTP could be used to communicate between the server hosting the application and the client browser. 2. The HTTP connection would be unencrypted since the data is not that sensitive and to ensure scalability by avoiding the overhead of SSL connections.

4. Other Nonfunctional Requirements

5.1 Performance Requirements
1. The server should have a fast CPU, hard disk, and RAM (e.g. 2Ghz, GB RAM) 2. The system should provide quick response time (80% of the pages should load in less than three seconds). 3. The system should be able to serve at least 100 users simultaneously.

5.2 Security Requirements

1. Only people having a valid IIT-K Computer Center login should be able to access the system. 2. Users should not be able to update the database. 3. Users must not be able to obtain private information like contact number, age ,etc from the system database.