1 / 25

Team ELL System Requirements

Team ELL System Requirements. Ladakeysha Thomas Elizabeth Waldo LaWanda Warren Brandon Williams. Use Cases. Login. Actors: All users Description: This use case defines the actions that an all users will perform to login to the system.

kairos
Download Presentation

Team ELL System Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Team ELL System Requirements Ladakeysha Thomas Elizabeth Waldo LaWanda Warren Brandon Williams

  2. Use Cases

  3. Login Actors: All users Description: This use case defines the actions that an all users will perform to login to the system. Trigger: All users except Visitors Pre-conditions: User is in the database. Post-conditions: User will gain access Normal Flow: 1. The system prompts user for login information (username and password). 2. User inputs login information. 3. System saves and verifies user 4. User is logged in. 5. Normal Flow ends. Alternative Flows: 1. User inputs the wrong login information. 2. System will deny that user access. 3. Alternate flow ends. Exceptions: Includes: Username and password Business Rules: All user can login Special Requirements: Must have a valid username and password Assumptions: User is in the database.

  4. View/Receive Alerts • Actors: All Users • Description: This use case defines the actions that a user will perform to receive and view alerts (i.e. Safety, “Dey Towing”, etc.) • Trigger: All Users • Pre-conditions: User is currently signed into system • Post-conditions: A user will be able to receive alerts • Normal Flow: 1. System displays the types of alerts a user can sign up to receive • 2. User selects the types of alerts he would like to receive • 3. System prompts user for delivery type (email or phone number(for text messages)) • 4. User inputs required information • 5. System saves the alert type and delivery format • 6. Normal flow ends • Alternative Flows: 1. System receives new alert • 2. User must click message button • 3. System displays alerts for the items student signed up for • 4. Alternate flow ends • Alternative Flows: 1. User can cancel any input into system. • 2. Alternate flow ends. • Exceptions: The correct event is displayed • Includes: Name, date, location, etc. of event • Business Rules: A user can receive alerts for different actions (i.e. Safety, “Dey Towing”) • Special Requirements: Must have a valid username and password • Assumptions: All users have access to this information

  5. Find Parking Spot • Actors: All Users • Description: This use case defines the actions that a user will perform to find a parking spot/lot on campus • Trigger: All User • Pre-conditions: User is currently signed into system • Post-conditions: A user will be able to find a parking spot/lot on campus • Normal Flow: 1. System displays parking lots on campus • 2. User selects parking lot • 3. System shows parking lot status (i.e. 100% full, 50%, 25%, etc.) • 4. System displays directions to parking lot based on user’s current location • 5. Normal flow ends • Alternate Flows: 1. System finds user’s current location • 2. System displays parking lots close to user’s location • 3. User selects parking lot • 4. System displays lot status • 5. User confirms the lot it would like directions to • 6. System displays directions to lot • 7. Normal flow ends • Alternate Flows: 1. Student can cancel any input into system. • 2. Alternate flow ends. • Exceptions: The correct parking lot will be displayed • Includes: Parking lot status and location • Business Rules: A student can receive find parking spots/lots on campus • Special Requirements: Must have a valid username and password • Assumptions: All users have access to this information.

  6. Post Towing/Ticketing Alert • Actors: All users • Description: This use case defines the actions that a user would take to post a towing or ticketing alert. • Trigger: Any user • Pre-conditions: User is currently signed into account • Post-conditions: Users will be able to post and view towing alerts • Users will be able to post and view ticketing alerts • Normal Flow: 1. System prompts for type of alert; towing or ticketing. • 2. User chooses towing • 3. System presents a list of current parking lot • 4. User selects the parking lot that he would like to update with towing alert • 5. System prompts user for details of the alert • 6. User enters the details of alert and selects save • 7. System saves updated towing alert • 8. User can now see new towing alert • 9. Normal flow ends • Alternative Flows: 1. System prompts for type of alert: towing or ticketing. • 2. User chooses ticketing • 3. System prompts for location and model and make of car • 4. User types response • 5. System prompts user to save • 6. User selects save • 7. Alert is saved and displayed • 8. Alternate flow ends • Alternative Flows: 1. User cancels any changes made to parking lot statuses • 2. Alternate flow ends • Exceptions: The correct parking lot is displayed were towing and ticketing is happening • Includes: Parking lot name and location • Business Rules: Parking information can be viewed by users • Special Requirements: Must have a valid username and password to access system • Assumptions: All users have access to this information

  7. Search Events • Actors: All Users • Description: This use case defines the actions that a User will perform to search for events. • Trigger: All Users • Pre-conditions: User is currently signed into account • Post-conditions: A user will be able to search and view events in the system • Normal Flow: 1. The user searches for an event based on name, date, time, or can display all • 2. System displays events matching query • 3. User can select an event to view additional details • 4. Normal flow ends • Alternative Flows: 1. User cancels input • 2. Alternate flow ends. • Exceptions: The correct events are displayed. • Includes: Events • Business Rules: Any student can search for events. • Special Requirements: Must have a valid username and password • Assumptions: All users have access to this information

  8. View Map of Campus Actors: All Users Description: This use case defines the actions that a user will perform view a map of campus Trigger: All Users Pre-conditions: User is currently signed into system Post-conditions: A user will be able view a map of campus Normal Flow: 1. The system prompts user current location 2. User will input current coordinates or location 3. System will return a map of campus based on coordinates or location from step 2 4. User will be able to see map of campus 5. Normal flow ends Alternative Flows: 1. User can cancel any input into system. 2. Alternate flow ends. Exceptions: Correct map of campus will be displayed Includes: Building descriptions, landmarks specific to FAMU Business Rules: A map of the campus will be displayed to users Special Requirements: Must have a valid username and password Assumptions: Will show map of campus

  9. Search for Location • Actors: All Users • Description: This use case defines the actions that an user will perform to search for building location, landmark, etc. and display on map • Trigger: All Users • Pre-conditions: User is currently signed into account • Post-conditions: An user will be able to view the locations of buildings, landmarks and display on map • Normal Flow: 1. System prompts user for building name, landmark, etc. • 2. User enters a response. • 3. System displays a map of building, landmark entered in step 2 • 4. Normal flow ends • Alternative Flows: 1. Administrator can cancel any input. • 2. Alternate flow ends. • Exceptions: The correct accounts are displayed. • Includes: Map of building, landmark is displayed • Business Rules: All users can search for building locations and landmarks • Special Requirements: Must have a valid username and password • Assumptions: All users will have access to this information

  10. Get Directions • Actors: All Users • Description: This use case defines the actions that a user will perform to receive directions to buildings or other campus locations. • Trigger: All User • Pre-conditions: User is currently signed into system • Post-conditions: A user will be able to receive directions to locations • Normal Flow: 1. The system prompts user with a list of locations on campus for the user to pick from • 2. User selects location he/she would like to receive directions to • 3. The system will return directions for the location selected (by text or map) • 4. Normal flow ends • Alternative Flows: 1. User can cancel any input into system. • 2. Alternate flow ends. • Exceptions: Correct directions for buildings will be returned • Includes: Building location for campus • Business Rules: A user will receive directions to campus locations • Special Requirements: Must have a valid username and password • Assumptions: All users have access to this information.

  11. Parked • Actors: All Users • Description: This use case defines the actions that a user will perform to input parking locations. • Trigger: All Users • Pre-conditions: User is currently signed into system • Post-conditions: A user will be able to input parking location • Normal Flow: 1. System prompts user parking lot location or name • 2. User inputs parking location or name • 3. System asks user if illegally parked • 4. User inputs (yes or no) • 5. System saves inputted information • 6. Normal flow ends • Alternative Flows: 1. User can cancel any input into system. • 2. Alternate flow ends. • Exceptions: Correct directions for buildings will be returned • Includes: Building location for campus • Business Rules: A user will receive directions to campus locations • Special Requirements: Must have a valid username and password • Assumptions: All users have access to this information.

  12. Actors: Administrator Description: This use case defines the actions that an administrator will take in order to add, modify or delete an account Trigger: Administrator Pre-conditions: Administrator is currently signed into account Post-conditions: System will be updated. Normal Flow: 1. The system prompts the administrator if he/she would like to add, modify, or delete class information 2. Administrator: clicks add 3. System prompts for name, ID number, date of birth, and address 4. The administrator responses 5. System prompts the administrator to save 6. Information is saved 7. Normal flow ends Alternative Flows: 1. Administrator chooses modify. 2. System prompts for user’s name and ID number 3. Administrator types response 4. Account information is displayed 5. Administrator edits the information 6. System prompts administrator to save. 7. Information is saved. 8. Alternate flow ends. Alternative Flows: 1. Administrator chooses delete. 2. System prompts for user’s name and ID number 3. Administrator types response 4. Account is displayed. 5. Administrator selects delete 6. Alternate flow ends. Alternative Flows: 1. Administrator can cancel any input. 2. Alternate flow ends. Exceptions: The correct account information is displayed. Includes: Name, ID number, etc. Business Rules: Only the administrator can add/modify/delete account. Special Requirements: Must have a valid username and password Add/Modify/Delete Account

  13. Search Accounts Actors: Administrator Description: This use case defines the actions that an administrator will perform to search for accounts in the system. Trigger: Administrator Pre-conditions: Administrator is currently signed into account Post-conditions: An administrator will be able to view the accounts of users in the system. Normal Flow: 1. System prompts user for name, type, date joined, or ID number of user. 2. User enters a response. 3. System displays a list of results. 4. User is able to choose from list of results. 5. System displays specifics of the account chosen by the administrator. Alternative Flows: 1. Administrator can cancel any input. 2. Alternate flow ends. Exceptions: The correct accounts are displayed. Includes: Name, type of account, date joined, and ID number are displayed. Business Rules: Only the administrator can search accounts. Special Requirements: Must have a valid username and password Assumptions: The administrator is the only one with access to this information.

  14. Actors: Administrator, Parking Service Worker • Description: This use case defines the actions that an administrator will take in order to add, modify or delete parking • Trigger: All Users • Pre-conditions: User is currently signed into account • Post-conditions: System will be updated. • Normal Flow: 1. The system prompts the user if he/she would like to add, modify, or delete parking information • 2. User clicks add • 3. System prompts for Location, Lot name, Lot ID, Lot type, etc. • 4. User inputs prompted information • 5. System prompts for user to save • 6. Information is saved • 7. Normal flow ends • Alternative Flows: 1. User chooses modify. • 2. System prompts for Location, Lot name, Lot ID, Lot type • 3. User inputs response • 4. P:arking information is displayed • 5. User edits parking information • 6. System prompts user to save. • 7. Information is saved. • 8. Alternate flow ends. • Alternative Flows: 1. User chooses delete. • 2. System prompts for Location, Lot ID, Lot name, Lot type • 3. User inputs response • 4. Parking information is displayed. • 5. User selects delete • 6. Alternate flow ends. • Alternative Flows: 1. User can cancel any input. • 2. Alternate flow ends. • Exceptions: The correct parking information is displayed • Includes: Location, Lot name, Lot ID, Lot type, etc. • Business Rules: Only an administrator or parking service worker can add, modify, or delete parking information • Special Requirements: Must have a valid username and password Add/Modify/Delete Parking Information

  15. Add/Modify/Delete Class Information Actors: Administrator Description: This use case defines the actions that an administrator will take in order to add, modify or delete class information. Trigger: Administrator Pre-conditions: Administrator is currently signed into account Post-conditions: System will be updated. Normal Flow: 1. The system prompts administrator for name and ID number 2. Administrator types response 3. System prompts the administrator if he/she would like to add, modify, or delete class information 4. The administrator clicks add 5. Administrator types information 6. System prompts administrator to save 7. Information is saved 8. Normal flow ends Alternative Flows: 1. System prompts administrator for name and ID number 2. Administrator types response 3. Administrator chooses modify. 4. Account information is displayed 5. Administrator edits the information 6. System prompts administrator to save. 7. Information is saved. 8. Alternate flow ends. Alternative Flows: 1. System prompts administrator for name and ID number 2. Administrator types response. 3. Administrator chooses delete. 4. Account is displayed. 5. Administrator selects delete 6. Alternate flow ends. Alternative Flows: 1. Administrator can cancel any input. 2. Alternate flow ends. Exceptions: The correct account information is displayed. Includes: Name, ID number, etc. Business Rules: Only the administrator can add/modify/delete class information. Special Requirements: Must have a valid username and password

  16. Post Alerts • Actors: Public Safety Official • Description: This use case defines the actions that a user would take to post alerts. • Trigger: Public Safety Official • Pre-conditions: User is currently signed into account • Post-conditions: Users will be able to post alerts • Normal Flow: 1. System prompts for type of alert (traffic, security, maintenance, etc.). • 2. User chooses which type of alert • 3. System prompts user for details of the alert • 4. User inputs required information for selected alert type • 5. System saves updated alert • 6. User can now see new alert • 7. Normal flow ends • Alternative Flows: 1. User can cancel any input. • 2. Alternate flow ends. • Exceptions: Alerts will be displayed for users • Includes: Predefined alerts for safety, traffic, security, etc. • Business Rules: Alerts can be viewed by users • Special Requirements: Must have a valid username and password to access system • Assumptions: All users will have access to this information

  17. Add/Modify/Delete/Post Event • Actors: Moderator • Description: This use case defines the actions that a user will perform to add, modify, delete, post an event • Trigger: Moderator • Pre-conditions: User is currently signed into system • Post-conditions: Events will be approved • Normal Flow: 1. The system prompts the user if he/she would like to add, modify, delete or post an event • 2. User will select to add/modify/delete/post a event • 3. System will prompt (or display if modify is selected) for event information(name, date, time, length) • 4. User will input event information or modify current event • 5. System will update event list • 6. User can view event • 7. Normal flow ends • Alternative Flows: 1. User can cancel any input into system • 2. Alternate flow ends. • Exceptions: Event will be displayed for user • Includes: Name, date, time, length, etc. of events • Business Rules: A user will be able to add/modify/delete/post an event • Special Requirements: Must have a valid username and password • Assumptions: The moderator is the only one who can add/modify/delete/post an event

  18. Add/Modify/Delete/View Schedule Actors: Student, Faculty Description: This use case defines the actions that a user will perform to add/modify/view/delete their schedule. Trigger: User Pre-conditions: 1. User is currently signed into system Post-conditions: 1. A user will be able to add/modify/view/delete their schedule Normal Flow: 1. System will prompt user to add in their schedule 2. User enters class information (days, starting and ending times, building, etc.) 3. System accepts input from user and displays it back 4. User verifies the data and selects save 5. System saves user input 6. Normal flow ends Alternative Flows: 1. System displays user’s schedule 2. User selects modify and makes changes to schedule 3. System accepts input and display back to user 4. User verifies changes and selects save 5. System saves user input 6. Alternate flow ends Alternate Flows: 1. System will prompt student for daily or weekly view of schedule 2. User makes selection of either daily or weekly view 3. System accepts input from user and displays day(s), hours, classes and buildings. 4. User can now view schedule. 5. Alternate flow ends Alternate Flows: 1. System displays user schedule 2. User selects to delete schedule 3. System prompts user to verify the delete 4. User verifies 5. System deletes schedule 6. Alternate flow ends Alternative Flows: 1. User can cancel any changes they made to the system. 2. Alternate flow ends. Exceptions: Correct class schedule is displayed for user Includes: Room building and room number for classes Business Rules: A user schedule can be added, viewed, modified or deleted Special Requirements: Must have a valid username and password

  19. Take Me to Next Class • Actors: Student, Faculty • Description: This use case defines the actions that a user will perform to receive directions (textual or map) to their next class • Trigger: Any User / Student • Pre-conditions: User is currently signed into system • Post-conditions: A user will be able to receive directions to their next class • Normal Flow: 1. The system prompts user for selection of next class • 2. The user will input selection • 3. System will ask for text or map or both directions • 4. User will make selection • 5. The system will return the user’s next class with directions to it • 6. Normal flow ends • Alternative Flows: 1. User can cancel any input into system • 2. Alternate flow ends. • Exceptions: Correct class schedule will be displayed for user • Includes: User’s schedule • Business Rules: A user will be able to receive directions to their next class • Special Requirements: Must have a valid username and password • Assumptions: All users will have access to this information

  20. Data Flow Diagram

  21. ERD Diagram

  22. Questions

  23. The End

More Related