Unifi Functional Requirements Mapping
Functional
The following list is a set of known and determined Functional Requirements.
info
These are based on the assumptions provided in the [[Security System Brief]] briefing.
| Req | Description | Category | Response | Fit |
|---|---|---|---|---|
| FR1 | User Authentication to Access Control: The system should allow users to authenticate themselves using various methods (e.g., cards, PINs, biometrics as well as using Mobile phones etc). These must be linked to a backend Identity Service (FR8). | Must | Using the Unifi G2 Pro Access Reader, pin code, NFC, phones can be used in the access request process. | Part |
| FR2 | Door Control: The system should be able to control the doors, including locking and unlocking them. | Must | The Unifi access control system can control up to 8 doors in the proposed configuration. | Comply |
| FR3 | Access Granting: The system should grant access to authorised personnel upon successful authentication. | Must | The system has a Unifi Access application that controls the door latches to open the door on successful authentication. | Comply |
| FR4 | Access Denial: The system should deny access to unauthorised personnel. | Must | The system uses policy based access control and schedules to prevent access based on user/policy/time etc. | Comply |
| FR5 | Auditing and Logging: The system should maintain a record of all access attempts, grants, and denials. Should provide a full event log made available to other systems. | Must | The system provides both SYSLOG and API based access to logs. Also the system has event driven webhooks linked to Slack or 3rd party platforms on certain actions. | Comply |
| FR6 | User Management: The system should allow administrators to manage user accounts, including adding, editing, and deleting users. | Must | The system maintains a local copy of AD provided users, and groups that are used in policies to determine enforcement of policies. External users can also be added as needed for contractors and visitors as required. | Comply |
| FR7 | Role-Based Access Control (RBAC): The system should support RBAC to ensure that users only have access to authorised areas. | Must | Access to systems and functions are controlled via RBAC policies - this can be used to limit permissions for management of the various elements of the system. e.g. Access to video, access / network etc. | Comply |
| FR8 | Integration with Other Systems: The system should be able to integrate with other security systems, such as CCTV and alarm systems. | Should | The system can leverage webhooks and API's to integrate with other systems. Integrations such as using a 3rd party compatible card is also possible. | Comply |
| FR8 | Integration with Identity Systems: The system must be able to integrate with organisational identity systems to ensure compliance for onboarding or off-boarding of staff. | Must | The system can be integrated with Entra/O365/Google and LDAP as required to populate usernames and permissions. | Comply |
| FR10 | Alerts and Notifications: The system should send alerts and notifications to administrators in case of unauthorised access attempts or system failures. | Should | Webhooks can be used to provide notifications on actions customisable events. This can also include apps such as slack. | Comply |
| FR11 | Scalability: The system should be able to scale to accommodate growing user bases and increasing security requirements. | Must | The system can accomodate eight doors with the current design, additional doors can be added either as a single additional door, or as another 8 door unit. There is no limit to the users or devices under management. If additional network storage of video files, this can be archived to a NAS or SAMBA file store as needed. | Comply |
| FR12 | Door Lock Types: The system should have the ability to operate different types of door locks, from magnets to latches. | Must | The system can operate both magnetic latches or magnetic door strikers as needed. | Comply |
| FR13 | Policy Based: In addition to RBAC, the system must be able to assign permissions to users based on an assigned policy either system or identity defined. | Must | Full RBAC control is available and can be deployed against policy or individual user. | Comply |
| FR14 | Time of Day Controls: The system must be able to deal with Time of Day / Week scheduling to ensure proper control over out of hours access. | Must | A built in scheduler is included in the system for ToD controls used with policy. | Comply |
| FR15 | Emergency Access: The system must allow for proper emergency access controls with local regulation - including fire evacuation and power failure modes. | Must | The system has an emergency mode that can be triggered to allow access to buildings / rooms as required. | Comply |
| FR16 | Fail Safe: The service must fail to a known state in the event of an emergency - known state being either fail open, or fail secure. Fail secure is the preferred state. | Must | The system has the option for fail safe or fail open as required. This is a policy setting. | Comply |
| FR17 | Door Bell: The service must provide the ability to notify staff inside the building when people are at the reception desk. | Must | The G2 Pro access scanners have a camera and doorbell function - this can be used to notify staff via the monitors or via Webhook notifications as needed. The system can also be integrated with 3rd party systems via API in the future. | Comply |
| FR18 | Package Drop: The service should allow a package drop secure drop box for packages or courier letters enabling the secure housing of items. | Should | Given the system is designed to secure access to areas such as doors etc - i required, a package drop off area could be used to securely drop off packages - this could be a door, a locked box etc with either a latch or magnetic door control. Access to this could be via a smart card SE provide, a PIN code or something else. If the courier has a compatible access card, this could be added. | Comply |
| FR19 | Package Drop Notifications: The service should notify staff either via e-mail or other means that a package has been delivered, and the drop box opened. | Should | Push notifications could be programmed to lets staff know of a new package. Webhooks could be used to send notifications to Slack etc. Recordings of the package being delivered could also be included to show proof of delivery / access. | Comply |
| FR20 | Package Drop Camera: The system should link the drop off of the package with a camera image / video for evidence of delivery. | Should | As above. | Comply |
| FR21 | Enhanced Detection: The system could be able to deal with new use cases such as motion detection, sound detection and/or water detection to safeguard the property and alert support teams to corner case detection. | Could | AI processing can be enabled in cameras to detect, noise, motion, person, vehicle animal etc. These can be used to trigger alarms should unauthorised motion occur. | Comply |
| FR22 | Logging Externally: The system must be able to export logs and events to SIEM using syslog or compatible exporters. | Must | Syslog and event logging is possible for all events and system access. | Comply |
| FR23 | API Capability: The system should allow secure API access to common functions to enable external automation or orchestration activities to occur. | Should | Limited API is available for access control - however this is a key area for development. | Comply |
| Video Cameras | ||||
| FR24 | Cameras: The system should integrate with cameras to record both the public areas, but also secure areas such as Comms rooms or internal secure areas. A seperate Functional and Non Functional set of requirements would be defined for this should this be a consideration. | Should | Cameras can be deployed to areas of interest, including areas that are locked off (comms rooms and records areas) for safety. | Comply |
| FR25 | Integrated Door Viewer: The solution should allow staff internal to the secure office location to see who is at reception or who is looking to gain entry. This is to protect staff from potential dangers from uninvited guests. | Should | It is recommended to install a door viewer to protect staff going to the reception area to answer a door entry request. | Comply |
| Smart Building Features | ||||
| FR26 | Digital Signage: The system could allow management and control over digital signage in the entrance / reception area that can be used to advertise or advise on | Could | If required, a module can be added behind any HDMI TV or screen to display corporate media or data. | Comply |
| FR27 | Digital Motion Sensors: The system could introduce motion sensors to act as a secondary alarm system detecting motion and activating cameras or alerting security personnel when motion is detected when all staff have left. | Could | Cameras or dedicated PoE powered devices can serve as motion detectors and detections be sent via e-mail or Webhooks. | Comply |
| FR28 | Digital Water Sensors: The system could extend the monitoring of water ingress areas such as kitchens and communications rooms to provide a safeguard against leaks or other undesirable water issues. | Could | As above. | Comply |
| FR29 | Digital Audio: The system could be integrated with digital audio to provide background music or emergency communication to staff. This is important given the removal of physical handset broadcast features from the environment. | Could | The system can be used to manage and power external speakers for streaming media or emergency announcements. | Comply |
| FR30 | EV Charging: With the event of Electric Vehicles, the need to provide staff and guests access to a managed EV charging solution would be a benefit. Any security and access control system should allow expansion to IoT devices and 3rd party systems. | Could | This is possible with a supported EV charger. | Comply |
| FR31 | Staff Presence Detection: The system could be extended to automatically record a site staff register which in the event of an emergency, provide managers or staff fire teams a list of who is onsite. | Could | An automation could be triggered on the event of an emergency being declared to automatically email / webhook logs or onsite staff to a 3rd party or external screen. | Comply |
| FR32 | Video Recording: The system should be able to record and retain video recordings for a defined period of time. These would be used for incident investigation, and proof of package delivery etc. | Should | Network Video Recording (NVR) is available in the solution - this can be deployed in a RAID configuration and stored locally within the office space. | Comply |
| FR33 | Video Recording Policy: All recordings must be managed by a Policy around retention and storage location. | Must | The system would provide policy based control over duration and retention. There is also an archive function to ensure that no recordings are lost, or maintained for a longer timeframe. | Comply |
| FR34 | Access to Video Recordings: Any video recording must use defined access control (RBAC - FR7) to view or delete any recording on the system. | Must | Access is maintained by the UDM appliance. Each application being: Network, Protect, Access and Identity are managed via RBAC permissions. | Comply |
| FR35 | Access to Portals and Management: All access to systems and services must be limited to system defined applications and policy access control. | Must | As above. | Comply |