Toby Muresianu (tmuresia) Specifications: Facility Finder 2/9/06 1. Description of project A campus-wide room-management solution with a web-based front end providing access to a database of all the rooms on campus, which can be easily searched or browsed according to various criteria (capacity, location, necessary facilities of the room,availability on a certain date/time). It will also display the appropriate contact person for reserving the room. Administrators will be able to long on and enter information regarding times the rooms are booked and available, and when room reservations are made the appropriate departments (e.g. media services, campus security) are notified automatically. The back end will facilitate construction of the database by allowing batch scanning of room photographs as well as information entry. 2. Component Design Access Page - Brown Password Management System | Web GUI | Database connector - Notification Sender | Oracle Database | Data Entry connector - Scanner | Data Entry GUI - Brown Password Management System 3. Annotations Access Page - a standard brown AuthID login page, which checks the credentials of regular users and administrators who want to access Database Connector and decides whether to admit them and what level of access to grant them. Brown Password Management System - the Brown-run system which verifies the credentials entered in the access page. Web GUI - the online interface to the database. User enters the criteria for the room he wants, and the interface passes it along to the database connector and displays the results appropriately. Database Connector - Middleware between the GUI and the database. Takes simple requests from the GUI and deals with accessing the database to retrieve or write information. Notification Sender - handles sending email to all of the parties who need to be notified about room registration (information contained in the database). Oracle Database - Already existant in a preliminary form, the data structure which will contain all of the room information and photographs and the capability of searching through them. Data Entry Connector - middleware between the data entry gui (offline) and the oracle database for adding photos and new and old room information to the database, and communicate with the scanner to pass batches of photographs from the physical device to the database. Data entry GUI - The interface to the user seeking to update room information (other than scheduling) in the database. 4. UI Diagrams GUI (to front end user) ____________________________________ | | | |Room Options |Photo of Current | | | rooom | | | | | | | | |_________________| |scroll box of rooms | | |meeting above criteria |booking info| | | | | | | | | | ------------------------------------- GUI (to back end user) _________________________ | | |Room info | | | | | | | | | |list of photos uploaded| | | | | |scan photo button | | | ------------------------- 5. Annotations to diagrams. 1. if possible given performance limitations, the list of the rooms meeting the criteria entered by the user should update automatically when the user enters more information. 2. Calendar info should include week and month views. The person should be able to see if a room is being used, but not whom it is being used by, according to people currently employed booking rooms. 3. A thumbnail photo should accompany every room in the list, followed by a few extras should the user click on that room for a closer look. 4. Color of interface not important, but gray or black would probably work best. 6. Non-functional requirements Performance - It should be possible to find a set of rooms that fulfill basic needs within 5 seconds after the information is entered. When updating, changes should be able to be made and reflected within 10 seconds. Scanning photos for input should only take 5 seconds longer than the scan itself. Reliability - information should not be cached, it should always accurately reflect the database. The system should be able to handle several dozen people accessing it and several people updating it at the same time, and continue to give accurate information in an amount of time in line with the perf specifications. Security - The system should always ask for credentials, and log out after 30 minutes of inactivity. People with administrator priveleges should only have them in the areas in which they need to work; regular users should never be able to change information in the database. Regular users should not be able to see the names of groups which may have reserved a room at a particular point, only that it has been booked. Documentation - All features of use and maintenance of the system, including database functions that could change in later versions of oracle software, should be documented in such a way that computer science students with no prior knowledge of the package are able to update it with a minimum of studying. Users should be able to use a how-to-guide, and an explanation of how to use the back end should be provided, as should a description of how the software is different from older programs currently being used. ease of use - regular users should be able to find what they are looking for without consulting a manual, and administrators should be able to begin using the system after 10 minutes of training. testing - needs to be detailed in a subsequent specifications document, but should include testing with many users, security testing, and invalid data testing. Dummy classes should be made for each actual class to test all of its functionality and ensure that future updates preserve this. compatibility - the database should be accessible on pc, mac, and linux, and pictures should be able to be uploaded from a windows pc. 7. Updated Requirements P1 = most important p10 = not important Password Protected access to the database via Brown AuthID logins. (2) A web based front end for users that allows searching and browsing of rooms based on various criteria and availability. (2) An addition to the web based front end accesible by administrators allowing them to enter reservations. (3). Capability of hosting up to six dozen consecutive users (4). 8. Potential issues -interfacing with a scanner, particularly on linux, may be complicated. Will have to look into generic drivers, pre-written interfaces. -managing data transfer over the internet may be tough and needs to be adequately encrypted. -authentication should take place quickly, and we must be granted access to the mechanism for checking by the university.