Skip to content

Release 1.0 Requirements

Scott McCulloch edited this page Dec 11, 2017 · 3 revisions

Phase 1 Requirements

The deliverables for this project are a mobile and web application.

Availability

[1.39] For every unit a person is associated with availability can be recorded for the following types:

  • [1.3] Immediate Response (15mins)
  • [1.4] Non-Response (tree job 1-2 hours)
  • [1.5] OOAA Deployments

[1.2] Availability can be recorded as a day of the week or specific times of the day (e.g. 5p-10p).

[1.38] If availability is not recorded, a person is considered available.

[1.29] Recurring availability can be repeated and applied to all futures dates (e.g. Mon-Thurs 5-10p).

[1.30] At any time, a pattern of availability may be overridden for a single day without breaking the ongoing pattern.

[1.7] Availability (future) can be edited at any time.

[1.47] Users may optionally record notes against any availability.

[1.54] A user may mark themselves as unavailable until a specified date (maximum 1 year).

[1.60] Ability to search for a specific date or date range to view availability.

Web Only

[1.8] The solution shall display availability information via visual means (e.g. dashboard functionality)

[1.25] The solution shall allow specified users to view member availability by member

[1.26] They solution shall allow users to view member availability by date (time, day, week, month, year)

[1.33] The solution shall allow specified members to report on non-availability of members

[1.34] The solution shall allow users to send reminders to members to enter their availability

[1.43] The solution shall allow specified users to enter in availability on behalf of other users

[1.52] All users can view availability/capability/currency of all members within Beacon

[1.53] When viewing availability of an entire unit the list of unit members should appear in alphabetical order - ideally the user logging in would be at the top of the list

[1.55] Member lists should include the SAP ID and the Member Name

[1.56] Search functionality throughout should allow member searches by member firstname, member surname or SAP ID (or a combination)

[1.59] Users should be able to create patterns that can be used at a State, Region, LGA or unit level

[1.62] Availability should initially show the logged in member's own availability (ie as a landing page) but then allow the option to view all members within their unit (or the units they have access to )

Events (Jobs)

[9.4] The solution shall allow users (available and unavailable) to respond to events regarding their attendance with a 'yes' or 'no'.

[9.6] The solution shall notify the requesting user when a member has responded 'yes' 'or 'no' to a job.

[9.7] The solution shall allow authorised users to view a list of users who have responded 'yes' and 'no' to a job.

[9.8] The solution shall allow authorised users to see updates to the list of users responding yes to a job in real time.

[9.9] The solution shall allow users who have responded yes to a job, to see other users who have also responded yes to that job.

[9.10] The solution shall allow all unit users, to see updates to the list of users responding yes to a job, in real time

[9.12] The solution shall allow authorised users to create teams from those users who have responded yes to a job.

[9.15] The solution shall allow authorised users to notify users who responded yes to a job, that they are not required.

[9.19] The solution shall allow users to change their initial yes/no response.

Mobile Only

[9.21] Mobile device users should receive notifications regardless of whether or not the user is logged into the app

[9.22] Allow users to select whether they will meet at the unit headquarters or at the job location

Web Only

[1.6] The solution shall allow users to utilise member availability information/data to create teams for deployment.

Person

[2.2] App should receive it's person details from SAP (via Beacon API)

[3.2] App shall display rolled up capabilities by their corresponding codes. e.g. RCR = Road Crash Rescue, GLR = General Land Rescue.

Security

Mobile Only

[1.40] User shall only have to login once (until they nominate to log out)

Web Only

[1.51] The solution shall allow specified users to amend the user access of other users e.g. Admin level access

Settings

[1.18] Users can specify whether or not they receive requests regardless of their current availability status

[1.37] The default time increments for availability can be configured in settings (e.g. 15min, 30min, 1hr, 3hr, 6hr, 12hr, 24hr). The default is 1hr (assumed).

Mobile Only

[9.20] The solution shall allow users to enable/disable geo location tracking in their settings. When enabled this will then show their location and ETA in relation to a job once they have responded yes to a job until they are either stooddown from a team or the team is stooddown or the job is complete.

General

[1.50] On time sensitive screens (availability, job details), data should be real time (refreshed automatically when changes are made).

[1.68] Ability to credit contributors of the app.

[1.71] App should show about information (version number, support information, etc).

Mobile Only

[1.73] If a mobile device has no connectivity allow the user to update the app offline (and changes load automatically once connectivity is restored)

Web Only

[1.57] Able to select all units within a region or LGA for messaging/reporting/screen filtering

[1.58] Able to select all members within a unit for messaging/reporting/screen filtering

[1.61] Map view should be able to select state level (default) and then drill down to region or unit levels and see overall member available numbers.

[1.63] Users will be able to message particular members filtered by one or more (or combination of) Regions, LGAs, Units, availability type on a particular date or date range (past, current and/or future), capabilities, member name, team (within unit).

[1.64] Generate a .csv file detailing member availability and/or member capability that can be printed or emailed using the functionality of the app that the data is opened in or using outlook to email.

[3.9] The solution shall allow users to view a members list of capabilities, when selecting their name.

[3.12] The solution shall allow specified users to run reports on members and capabilities (.xls/.csv data extraction – specific report types to be determined)

[3.16] Users will be able to view all members by capability type at either a State, Region or Unit level and in the form of a list on screen, a report and visually on a map


Phase 2 Requirements

Deployment Groups

[7.16] The solution shall allow authorised users to send notifications to members about to be deployed including all deployment information: i.e. deployment dates (start, finish, and travel dates), times, location (where they’re being deployed to – region and unit if applicable), role, accommodation details etc

Job

[9.11] The solution shall allow authorised users to send further notifications to users, or groups of users, of their choosing who have responded 'yes' to a job

[9.17] When a user responds yes to a job, the solution shall calculate an eta to unit and eta to job location based on their actual location.

[9.18] The solution shall allow users to change the eta for when they will arrive at the job when the meeting point is different to the unit address, or they are not at their home address.

Person

[1.72] Display each member’s immunisation status on the Member Availability App. High level indication only as there are privacy restrictions stopping the display of the detail status of each member’s immunisation record.

General

[1.69] Points/Stats/% - User Profile eg # logins, availability %, jobs accepted etc etc