VMS-homework

Created .net mvc with idividual user account setup CIS 4327 – IS Senior Project I Pre-Semester Team Project Assignment

Due on August 22nd (First day of the class)

Submission will be GitHub Repository or other appropriate means of sharing source code base.

Volunteer Management System Introduction The Volunteer Management System (VMS) is a web based application that allows a nonprofit organization to collect volunteers’ information, track their participation in activities, and produce reports on their contributions made. The purpose of this document is to define the high-level requirements and features of a portion (only administrative features) of the Volunteer Management System (VMS).

This document describe two use case specifications relevant to administrative features of the VMS. Use case specification provide detailed description of high level requirements of a feature. Requirements are described as interaction between user and the system as a series of user actions and system events. We will learn more about use cases in the fall semester.

Details of Manage Volunteer Profile Information and Manage Opportunities use cases are provided in this document. Read the user interactions and system actions described in the use cases to gain an understanding on the administrative feature needs of the VMS. Work as a team to develop administrative features of the VMS. Use the web development platform (ASP.NET or PHP) selected as a team to develop these features. Make decisions as a team to develop these two features. You are allowed to make necessary assumptions on missing information about the requirements and the VMS.

Objectives and Expectations of the Pre-Semester Assignment The objectives of the assignment are two-fold. First, is to provide you sample set of requirements that is much closer to what you will face in the senior project class for practicing your web development programming skills. In fact, below given two use case specifications were taken from one of the previous senior project student submissions. Second, is to provide you opportunity to self-assess your individual as well as team capabilities to develop a working software. Mentors will use the code base to assess your team capabilities as well.

As it was mentioned in my earlier communications, in the senior project course, you will be learn about the software development lifecycle processes. Web development programming skills are pre-requisite for the course. As the class involves real world project and with real commitments, pre-requisite skills are going to be important for delivering working and useful product to your client. Therefore, it is very important you practice and improve programming skills in the remaining few weeks before the fall semester starts.

I don’t expect your solution to be perfect, but demonstrate team’s capability. Try to put in at minimum 5 to 10 hrs per week as a team to make progress on this assignment. Do your best to communicate, divide up work, and work as a team (as much as possible). Use Case 1: Manage Volunteer Profile Information Brief Description This use case shows the steps involved when an administrator manages the profile information of volunteers.

1. Basic Flow of Events 1.1. Administrator logs on The use case begins when an administrator enters the following user credentials: -Username -Password The system stores this information in the session so that the administrator only can see information appropriate to them. 1.2. System displays administrator page System displays a selection of actions to perform. The following actions relevant to this use case are displayed: Manage Volunteers and Manage Opportunities. 1.3. Administrator chooses Manage Volunteers option Administrator selects the option of going to the area where he/she can manage the volunteers. 1.4. System displays summary view of volunteers based on the default filter System shows a list of the volunteers along with possible actions the administrator can take for each of them. The relevant actions are the following:

a. Change Volunteer Filter b. Search Volunteers c. View Volunteer Opportunity Matches d. Edit Volunteer e. Add New Volunteer

The volunteers which are displayed at this step are shown based on the system’s default filter of criteria for which categories of volunteers show up. 1.5. Administrator Chooses Option to Change Volunteer Filter The administrator selects the option to Change Volunteer Filter. 1.6. System Displays List of Filters The list of filters includes the following: a. Approved/Pending Approval (volunteers in both approval statuses are included) b. Approved c. Pending Approval d. Disapproved e. Inactive f. All

1.7. The administrator chooses the particular filter to use. 1.8. The system displays an updated list of the volunteers based on the administrator’s choice. 1.9. Use Case Ends The use case ends.

2. Alternative Flows 2.1. Search Volunteers
3. The administrator chooses Search Volunteers option the basic flow step 1.4 (System Displays Administrator Page).
4. The administrator specifies the volunteer to search for.
5. The system displays list of volunteers matching the search criteria.
6. The use case ends. 2.2. Volunteer Not Found
7. This alternative flow starts after step 1 of alternative flow 2.1 (Administrator Specifies Volunteer to Search For), when no volunteer matching the search criteria is found by the system
8. System shows a message informing the administrator that no volunteers matched the search criteria.
9. The use case ends. 2.3. View Opportunity Matches
10. The administrator performs at the Basic Flow and Alternative Flow 2.1 (Search Volunteers) as needed to navigate to a list that includes the volunteer for which he/she wants to perform the action.
11. The administrator chooses the View Volunteer Opportunity Matches option to see which opportunities the system has matched with the volunteer.
12. The system displays the list of opportunities it has matched with the volunteer.
13. The use case ends. 2.4. Edit Volunteer Profile
14. Administrator performs the Basic Flow and Alternative Flow 2.1 (Search Volunteers) as needed to navigate to a list that includes the volunteer for which he/she wants to perform the action.
15. Administrator selects the Edit Volunteer option.
16. System displays the volunteer’s information to the administrator in a format that can be edited. This information is as follows: a. First Name b. Last Name c. Username d. Password e. Centers where the volunteer prefers to work f. Skills/Interests g. Availability times h. Address i. Home/work/cell phone numbers j. Email k. Educational Background l. Current Licenses m. Emergency Contact Name n. Emergency Contact Home/Work Phone o. Emergency Contact Email p. Emergency Contact Address q. Whether there is a copy of volunteer’s drivers license on file r. Whether there is a copy of volunteer’s social security card on file s. Volunteer’s Approval Status
17. Administrator makes changes to the volunteer’s information as needed.
18. Administrator selects option to update the volunteer’s information by saving his/her changes.
19. System ensures that the updated information is valid.
20. If the information is valid, the system saves the updated information.
21. System removes the page showing the volunteer’s information and goes back to where the administrator was before he/she selected the Edit Volunteer option.
22. The use case ends. 2.5. Add a New Volunteer
23. The administrator performs the Basic Flow and Alternative Flow 2.1 (Search Volunteers) as needed to navigate to a list that includes the volunteer for which he/she wants to perform the action.
24. The administrator selects the Add New Volunteer option.
25. System displays a section in which the administrator can enter various aspects of volunteer information. Information includes: a. First Name b. Last Name c. Username d. Password e. Centers where the volunteer prefers to work f. Skills/Interests g. Availability times h. Address i. Home/work/cell phone numbers j. Email k. Educational Background l. Current Licenses m. Emergency Contact Name n. Emergency Contact Home/Work Phone o. Emergency Contact Email p. Emergency Contact Address q. Whether there is a copy of volunteer’s drivers license on file r. Whether there is a copy of volunteer’s social security card on file s. Volunteer’s Approval Status
26. Administrator adds the volunteer data.
27. Administrator selects option to create the new volunteer by saving his/her changes.
28. System ensures that the information is valid.
29. If the information is valid, the system creates the new volunteer.
30. System removes the page showing the volunteer’s information and goes back to where the administrator was before he/she selected the option to create the new volunteer.
31. The use case ends. 2.6. Handle Cancelled Add Volunteer Action If, at any step, the administrator selects the option to cancel the addition of the new volunteer:
32. The system clears any changes made by the administrator and does not save them.
33. The system removes the page for adding the new volunteer and goes back to where the administrator was before he/she selected the option to create the new volunteer.
34. The use case ends. 2.7. Handle Cancelled Edit Volunteer Action If, at any step, the administrator selects the option to cancel the action of editing the volunteer’s profile:
35. The system clears any changes made by the administrator and does not save them.
36. The system removes the page for editing the volunteer’s profile and goes back to where the administrator was before he/she selected the option to edit the volunteer information.
37. The use case ends. 2.8. Unauthenticated Administrator If, at basic flow step 1.1 (Administrator Logs On), the system finds that the login credentials the administrator has provided are invalid:
38. The system refuses to log the administrator into the system.
39. The system displays a message to the administrator indicating that his/her credentials were not valid, along with the option to re-enter them.
40. Process resumes at step 1.1 (Administrator Logs On). 2.9. Invalid Volunteer Data Input If, at any step, the system finds that the administrator has provided invalid volunteer data input:
41. The system refuses to save the added/updated volunteer information.
42. The system displays an indication to the administrator that he/she has entered invalid information.
43. Process goes back to step where invalid data was entered and continues from there. 2.10. Quit Session
44. At any point, the user decides to quit the session unexpectedly.
45. The system discards any unsaved changes the user has made.
46. The use case ends.

Use Case 2: Manage Opportunities

1. Basic Flow 1.1. Administrator logs on The use case begins when an administrator enters the following user credentials: -Username -Password

s The system stores this information in the session so that the administrator only can see information appropriate to them. 1.2. System displays administrator page System displays a selection of actions to perform. The following actions relevant to this use case are displayed: Manage Opportunities. 1.3. Administrator chooses Manage Opportunities option Administrator selects the option of going to the area where administrator can manage opportunities. 1.4. System displays summary view of opportunities based on the default filter System shows a list of the opportunities along with possible actions the administrator can perform:

a. Change Opportunity Filter b. Search Opportunity Tc. View Volunteer Opportunity Matches d. Edit Opportunity e. Add New Opportunity f. Delete Opportunity

The opportunities that are displayed at this step are shown based on the system’s default filter of criteria. 1.5. Administrator Chooses Option to Change Filter The administrator selects the option to change current opportunity filter. 1.6. System Displays List of Filters The list of filters includes the following: a. Most Recent (60 days) b. By Center

1.7. The administrator chooses the particular filter to use. 1.8. The system displays an updated list of the opportunities based on the administrator’s choice. 1.9. Use Case Ends The use case ends.

2. Alternative Flow 2.1. Search Opportunities
3. The administrator chooses Search Opportunities option after the end of step 1.4 of the Basic Flow.
4. The administrator types in keyword or name of opportunity.
5. The system updates the opportunities that are displayed to only include those that match the search criteria.
6. The use case ends. 2.2. Opportunity Not Found
7. This alternative flow starts after step 1 of the 2.1 alternative flow (Search Opportunities).
8. The system updates the opportunities that are displayed to include no opportunities, since none were found that matched the administrator’s criteria.
9. System shows a message informing the administrator that no opportunities matched the search criteria.
10. The use case ends. 2.3. View Opportunity Matches
11. The administrator performs the Alternative Flow 2.1 (Search Opportunities) as needed to navigate to a list that includes the opportunities for which he/she wants to perform the action.
12. The administrator chooses the View Volunteer Opportunity Matches option to see which volunteer the system has matched with the opportunity.
13. The system displays the list of volunteers it has matched with the opportunity.
14. The use case ends. 2.4. Change Opportunity Filer
15. The administrator performs 1.4 of basic flow.
16. Choose different filter option.
17. System display refreshes corresponding to selected option. 2.5. Edit Opportunity
18. Selects edit from table next to opportunity.
19. System display window to edit information. 2.6. Administrator edits opportunity fails Edit failure can occur for mistyped information this can happen after alternative flow 2.5. User is asked to reenter information. 2.7. Add New Opportunity
20. Selects to add new opportunity.
21. System display window to add information. 2.8. Delete Opportunity
22. Selects delete from table next to opportunity.
23. Data on page refreshes to correspond.

General system notes System must be designed in an easily-usable manner and must handle errors or wrong inputs appropriately!

Testing discord