Embed Size (px)
Citation preview
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.
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.
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
Find Parking SpotActors: 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.
Post Towing/Ticketing AlertActors: 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
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
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
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
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.
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.
Add/Modify/Delete AccountActors: 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
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.
Add/Modify/Delete Parking InformationActors: 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 displayedIncludes: Location, Lot name, Lot ID, Lot type, etc.Business Rules: Only an administrator or parking service worker can add, modify, or delete parking informationSpecial Requirements: Must have a valid username and password
Add/Modify/Delete Class InformationActors: AdministratorDescription: This use case defines the actions that an administrator will take in order to add, modify or delete class information.Trigger: AdministratorPre-conditions: Administrator is currently signed into accountPost-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 endsAlternative 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
Post AlertsActors: 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
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
Add/Modify/Delete/View ScheduleActors: 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
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
Data Flow Diagram
ERD Diagram
Questions
The End
