ISDS 3100 Spring 2012 Idea Name: Hungry Tigers Application Team Name: Team Cuisine March 26, 2012

Transcription

1 ISDS 3100 Spring 2012 Idea Name: Hungry Tigers Application Team Name: Team Cuisine March 26, 2012 Milestone 3 Members: Christopher Boudreaux Stephen M. Chouest Corey Trouard Tyler A. Zimmer 1 P a g e

2 Executive Summary: Team Cuisine s idea is to create a mobile application that will allow users to view any of the different LSU dining hall menus from any smartphone device. As users leave class and head to lunch, currently only one way exists to see the menus of the dining halls. This would be getting online via a web browser. Our application would make it much easier to view the current day s menu and the menu for the rest of the week. Team Cuisine s target audience for the Hungry Tigers application is predominantly the student body. It will be available to faculty for all uses of the application, but visitors to the campus would only be able to use Hungry Tigers for the menu, map, hours of operations and project clean plate purposes. Since everyone today is pressed for time, the Hungry Tigers application would allow users to quickly and easily select where they want to eat. Hungry Tigers will state a level of crowdedness through the student surveys section. The Hungry Tigers application will give user the opportunity to view the menus of the different dining halls. This application would remove the need to find a computer to see the menu of the different dining halls. This would be a great time saver for students with limited time to grab breakfast, lunch or dinner. The Hungry Tiger application would be expanded to other universities in the future. There are always problems that will arise, for the Hungry Tigers application these would include: working with the current information services to provide the most up to date menus, patron count at each hall, maps depicting where the dining halls are located, and nutritional facts on daily menus. The user would click the icon on their mobile device to open the Hungry Tiger application. Once the application opened they would have the choice of locations from a map. The map shows their current location and the location of each dining hall. The users then could tap on the Dining Hall icon to view the menu and hours of operation. 2 P a g e

3 Actor Glossary Term Synonym Description User Faculty/Student/Visitor An individual who uses the application Google Maps Database The database that contains all of the geographical information about dining halls on and off campus. Dining Hall Database The database that contains all of the dining hall information. This information includes: the daily menu, recent student reviews, and hours of operation for each day. Vendor This actor describes the maintenance / update function of the application. It will be in charge of updating the menu on a daily basis. Conversely, hours of operation and any new dining locations will be updated on a case-by-case basis. Vendors are responsible to ensure that vulgar or explicit reviews will be removed from the application in a timely manner. 3 P a g e

4 Use Case Glossary Use-Case Name Use-Case Description Participating Actors and Roles Browsing This use case describes what the User user will see when requesting Google Maps Database geographical and dining hall Dining Hall Database information. This includes the map Vendor of all locations on and off campus, and the current location of the user. The current day s menu, and the hours of operation for each location are included. This use case will describe how the user will submit satisfaction reviews. There are two sections: 1. Student reviews this section describes reviews solely based on a specific dining hall experience, they will be made public for all application users to see and the user will be able to decide which dining hall to attend by reading positive/ negative reviews. This use case will be linked to the Vendor actor so that vulgar or explicit reviews may be removed to protect the integrity of the LSU community. Maintenance This use case describes how the vendor will update the system. The menu at each location will need to be updated daily. Hours of operation and new locations will need to be updated on a caseby-case basis. Vendor 4 P a g e

5 Use Case Diagram Hungry Tigers Application Browsing Dining Halls Google Maps Database Maintain Information User Dining Hall Database Vendor 5 P a g e

6 EVENT RESPONSE LIST Subsystem Actor Event (or Use Case) Trigger Responses User Browsing Open the application The map depicts the locations of Dining Halls and user s current location are shown Shows all reviews written by users as well as reviews to the Managers Vendor Maintenance Open desktop application The system allows vendor to make changes to the nonsecure areas of the application via a desktop application. 6 P a g e

7 Use Case Narratives Hungry Tigers Application Author (s): Date: 3/26/12 Version: USE CASE NAME: PRIMARY BUSINESS ACTOR: OTHER PARTICIPATING ACTORS: OTHER INTERESTED STAKEHOLDERS: DESCRIPTION: Browsing User Google Maps Database Dining Hall Database Vendor This use case describes what the user will see when requesting geographical and dining hall information. This includes the map of all locations on and off campus, and the current location of the user. The current day s menu and the hours of operation for each location are included. This use case is initiated when the application is launched PRE-CONDITION: TRIGGER: TYPICAL COURSE Actor Action System Response OF EVENTS: Step 1: User selects application from a smartphone Step 4: User selects a dining hall from the map. Step 7: User closes the application. Step 2: System connects to Google map server and Dining hall server Step 3: System launches a map of all dining hall locations on campus. The current location of the user is displayed. Step 6: System responds by displaying the information for the specified dining hall. This includes: current day s menu, hours of operation, and reviews. ALTERNATE COURSES: CONCLUSION: POST-CONDITION: BUSINESS RULES IMPLEMENTATION CONTRAINTS AND Optional Step 6 (1): User selects the write a review button from the current page. Optional Step 6 (3): User submits a review. Optional Step 7 (1): User selects a back button when on page from step 6. Alt. Step 1: Vendor deletes a vulgar review. Optional Step 6 (2): System launches a page with a blank template for the user to write a review on. Optional Step 6 (4): System responds by displaying a confirmation message. Review Received Optional Step 6 (5): System reloads page from step 6 with user review now showing in the reviews section. Optional Step 7 (2): System returns user to step 2. Alt Step 2: System erases vulgar review from the Dining hall database. This use case concludes when the user closes the application. 7 P a g e

8 SPECIFICATIONS ASSUMPTIONS: OPEN ISSUES: 8 P a g e

9 Hungry Tigers Application Author (s): Date: 3/26/12 Version: USE CASE NAME: PRIMARY BUSINESS ACTOR: OTHER PARTICIPATING ACTORS: OTHER INTERESTED STAKEHOLDERS: DESCRIPTION: Maintenance Vendor Dining Hall Database User Check application on daily basis to aid their decisions on where to dine This use case describes how the vendor will update the system. The menu at each location will need to be updated daily. Hours of operation and new locations will need to be updated on a case-by-case basis. This use case is initiated when a vendor wishes to update the provided content PRE-CONDITION: TRIGGER: TYPICAL COURSE Actor Action System Response OF EVENTS: Step 1: Vendor signs into Dining Hall Step 2: Dining hall system displays server options for uploading menus / news Step 3: Vendor uploads the menu for the day Step 4: Vendor has option of entering a Step 5: Dining hall database is news update for any specific location or as updated with new information a general update for all dining halls ALTERNATE COURSES: Step 6: Vendor checks his mobile app to ensure use case was a success CONCLUSION: POST-CONDITION: BUSINESS RULES IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS ASSUMPTIONS: OPEN ISSUES: This use case concludes when the vendor is certain the system is displaying the correct updated information. 9 P a g e

10 Screen Shots 10 P a g e

11 User Confirmation Message Review Menu and Hours of Operation Choose Dining Hall Map Open Application Vendor Edit Reviews Reviews 0 Hungry Tigers Application Map Map Request Google Map Database Menus and Hours of Operation Information Request Dining Hall Database 11 P a g e

12 Appendix A: Functional Requirements Process Oriented: 1) Dining Hall Information a) The system must allow users to submit personal reviews on the quality, taste, etc. of the food on the menu each day. b) The system must display nutritional facts about each menu item each day. 2) Geographical Information a) The system must display a map which showcases each place to eat on campus. b) The system must display all off-campus places where Tiger Cash is accepted. Information Oriented: 1) Menu of all locations on campus a) The system must include real-time menu information for the current day for each location. b) The system must include real-time review information from student reviews on daily menu. 2) Schedule for hours of operation a) The system must retain a map of on-campus dining locations. b) The system must include the hours of operation for all dining locations on campus 12 P a g e

13 Appendix B: Non-Functional Requirements 1) Operational: a) System shall be compatible with IOs devices and android smart phones. b) System shall allow content updates to be pushed to the app. c) System will allow for frequent software updates. d) System should be usable regardless of location as long as Internet access is available. e) System should be usable on same days dining halls are open or meal transfers are enabled. f) System should allow unexpected closure notices to stand out and grab attention immediately. 2) Performance: a) System should load reasonably fast, such that users don't get frustrated and rely on the preexisting website instead. b) System should occupy a reasonably sized memory footprint. c) Inter-app navigation should be crisp and responsive. d) System needs to be able to withstand high traffic during mid-day lunch rushes. 3) Security: a) System should prevent users from changing source material aside from reviews. 4) Cultural and Political: a) System should be LSU themed. (color scheme, pictures of LSU athletics, phrasing, etc.) b) System should be politically neutral aside from being pro LSU. c) System should be navigable by anybody regardless of their ability to read English. d) System should be usable by anyone regardless of status with the university (students, faculty, and visitors.) 13 P a g e