In addition to the pre-loaded staff records in the Staff Management module volunteers may arrive to the event and desire to help in the response. The Volunteer Management module will allow for on-the-fly registration of volunteers throughout the affected area.

Note on contribution: Please feel free to fill out sections of the specification as this project is a collaborative effort; however, if you feel your ideas could be in conflict to previous ideas or you want to change sections already fleshed out please use the discuss tab first and find consensus with others working on this module or section.

In the current functionality of Mayon all persons actively assisting in the response effort are considered “Staff”. Information on these individuals is pre-loaded into the system before an event is deployed; however, the back end is designed to support on-site registration of volunteers. These individuals would be used to fill in open roles available at or near the site they are registering at; or, in the event of long term response without restricted movement of people and resources, they could be deployed to affected areas in need of volunteers.

A few concepts in the current functionality of Mayon are relevant to the Volunteer Management module; specifically the functions of a “Scenario”, an “Event”, and the “Staff Pool”. Because Mayon focuses on preparedness and the deployment of response plans, the Emergency Management user creates “Scenarios”. Scenarios are response plans; and during the creation of a scenario the user sets Staff Deployment Rules, meaning they say what type of staff from which organization will be deployed should that scenario be activated. When the Scenario becomes an “Event”, or a specific instance of response, the Staff Deployment Rules are used to create a “Staff Pool” from all available staff who fit into the rules set in the Scenario. This staff pool is then distributed to the facilities that need them for the active event.

The volunteer management module will allow for volunteers to be registered as active additions to the staff pool without being counted as long-term members of the “Staff” list. They will be assigned to facility resources and shifts within those facility resources as long as they remain active as long as they are available or as long as the event is still active. After the resolution of the active event their information will be retained for security and auditing purposed; however, they will not be considered long-term staff available for future staff pool creation.

A major hurricane is about to strike in Costa Rica and citizens in San Jose have been asked to seek out shelters in their neighborhoods to wait out the high winds and potential flooding. Mayon has distributed municipal staff throughout the shelter system to ensure shelters can open; however there are only enough staff in the system to meet the basic requirements and people being sheltered in San Jose Public School 3 have asked how they can help.

The staff member assigned to manage records of who is being sheltered in San Jose Public School 3 takes the information of the “clients” (shelterees) of who would like to volunteer and registers them in Mayon as volunteers. Because is is not safe to travel during the hurricane the staff member registering these volunteers assigns them to work directly in San Jose Public School 3 so they are not deployed elsewhere.

Mayon now knows there are additional persons working in San Jose Public School 3. In the event that more municipal Staff respond as being available they will be deployed where they are needed instead of to the shelter that has volunteers.

The hurricane has now passed San Jose and the sheltering system saved many lives; however the devastation to public and private property is immense. Public employees are doing there best to clean up, and some local groups have formed to clean there own neighborhoods; yet when they are done they still want to help so the city of San Jose has set up a volunteer co-ordination station in the McEnery Convention Center.

At the Convention Center, walk-in volunteers are asked for their basic contact information by a staff member who is registering their information in Mayon but leaving there location unassigned. Mayon assigns the volunteer to shelters or centers that are still open in the system and the volunteer is told where to report to help. San Jose has arranged for a busing system for volunteers and off they go to assist in the response.

Bonus: a bit of extra credit for the developer who wants to get ahead of themselves.

Its been two years since the major hurricane that tore through San Jose and another hurricane is on it's way. Last time Felipe volunteered at his local shelter. This time he reports early to the McEnery Convention Center since he knows they will have Mayon running and they will need extra help. Felipe is asked by the Volunteer Coordinator if he's volunteered before and when he says yes the Coordinator searches the past volunteer records for his information. She finds Felipe, verifies that Felipe's contact information is the same, and he is deployed to help in the response without having to register again.

Note: This 'bonus' is a bonus because volunteers are event-specific and not kept in the staff pool. This Bonus use case is that the “old” volunteer record from a past event could be flagged to be re-activated for the current event response.

<What shouldn't this piece do?>

• “Client” tracking is a planned functionality for Mayon; however, it's not yet been implemented in the core code. Ultimately, the volunteer management piece of Mayon will allow clients to be converted into volunteers. This conversion piece can't be built until client management is built; however, volunteer management is such an important part of staff deployment that it may be too important to put off until client management has been completed.

<What screens should the user see? How should the work flow through the module? Good to include some sketches or pictures.>

• Staff Management
• Event Management

The technical specifications are drawn directly from and written to satisfy user stories and workflow documents.

Interfaces need to be created to handle later use in client to volunteer registration, proper business objects with record permanence

record permanence is needed for volunteer business objects

Note on contribution: Please feel free to fill out sections of the specification as this project is a collaborative effort; however, if you feel your ideas could be in conflict to previous ideas or you want to change sections already fleshed out please use the discuss tab first and find consensus with others working on this module or section.