Upload
dangdiep
View
213
Download
0
Embed Size (px)
Citation preview
FUNCTIONAL REQUIREMENTS DOCUMENT
GENERIC CHILD HELPLINE SYSTEM
5th April, 2018.
1 Table of Contents
2 Table of Figures................................................................................................................3
Acronyms...............................................................................................................................4
1 Introduction:-..................................................................................................................5
2 Non Functional Requirements........................................................................................62.1 Work plan.............................................................................................................................62.2 Technical Support Terms.......................................................................................................7
2.2.1 Hours of Operation..............................................................................................................72.2.2 Incident and Problem Management....................................................................................72.2.3 Matrices Definitions.............................................................................................................72.2.4 Support during 6 Month Warranty Period...........................................................................82.2.5 Priority Levels and Response Time.......................................................................................8
2.3 Handling of Code Repository and Testing Procedures..........................................................102.4 Project management...........................................................................................................112.5 Hardware Requirements.....................................................................................................122.6 Data Security.......................................................................................................................132.7 Data Confidentiality, Integrity and Availability....................................................................14
3 Functional Requirements & Features..............................................................................163.1 Modes of Communication...................................................................................................16
3.1.1 Walk – In Cases: -..............................................................................................................163.1.2 Web-Online Form..............................................................................................................193.1.3 Web-Chat: -.......................................................................................................................223.1.4 Social Media: -..................................................................................................................253.1.5 SMS:-................................................................................................................................263.1.6 Calls: -...............................................................................................................................293.1.7 Field Worker – Mobile Compatible Application: -............................................................32
4 Case Management Form:-...............................................................................................344.1 Case Capture work flow.......................................................................................................34
5 Quality Analysis (QA) Module: -......................................................................................435.1 Monitoring Form: -..............................................................................................................435.2 Quality Analysis Procedure: -...............................................................................................44
6 Escalated Cases / Referral / Follow up Cases:-.................................................................466.1 Case Escalation / Referral Procedure...................................................................................47
7 Reporting Module: -........................................................................................................487.1 Pivot Reports.....................................................................................................................517.2 Comprehensive Reports.....................................................................................................527.3 Reports Automation: -.......................................................................................................52
8 Dashboards: -.................................................................................................................53
1 | P a g e Functional Requirement Document
8.1 Resources Presence Status:.................................................................................................538.2 Counselor Login Page: -.......................................................................................................548.3 Administrator Dashboard: -.................................................................................................568.4 Supervisor Dashboard: -......................................................................................................57
9 Integration: -...................................................................................................................589.1 Proposed CPIMS / DCIMS and 116 data flow: -...............................................................58
10 FRD Signoff: -...............................................................................................................60
11 APPENDICES................................................................................................................6211.1 Appendix 1: Securing Application Services on Public Networks............................................6211.2 Appendix 2: Principles and Standards: Confidentiality
2 | P a g e Functional Requirement Document
2 Table of FiguresFigure 1: Walk in Form...................................................................................................................7
Figure 2: Walk in Form filled..........................................................................................................7
Figure 3: Walk in Form New Case..................................................................................................8
Figure 4: Walk in Form Existing Case............................................................................................9
Figure 5: Walk in Form Case Status................................................................................................9
Figure 6: Email Repository Summary...........................................................................................10
Figure 7: Web Online details.........................................................................................................11
Figure 8: Existing Case Found…………………………………………………………………...12
Figure 10: Chat Search Cases found..............................................................................................14
Figure 9: Chat Case Form..............................................................................................................14
Figure 10: Chat Cases Found.........................................................................................................16
Figure 11: SMS Summary Repository...........................................................................................16
Figure 14: New Case Creation Form.............................................................................................21
Figure 19: Client Details................................................................................................................27
Figure 20: Perpetrator Details........................................................................................................28
Figure 23: Case Action..................................................................................................................31
Figure 24: Call Monitoring Procedure...........................................................................................33
Figure 28: Communication management report............................................................................38
Figure 30: Pivot report...................................................................................................................40
Figure 32: Activity Dashboard......................................................................................................42
Figure 31: Counsellor Login Status...............................................................................................43
Figure 33: Counsellor Case Dashboard.........................................................................................44
Figure 34: Administrator Dashboard.............................................................................................45
Figure 35: Supervisor Dashboard..................................................................................................46
Figure 36: Current 116 and CPIMS Flow......................................................................................47
Figure 38: Proposed 116 and CPIMS integration..........................................................................48
Figure 39: Operational Flow of integrated System........................................................................50
3 | P a g e Functional Requirement Document
This FRD has been prepared by BITZ ITC
Acronyms
ODK Open Data Kit
API Application Programming Interface
ESA East and Southern Africa
ESAR East and Southern Africa Region
ESARO East and Southern Africa Regional Office
CO Country Office
SDG Sustainable Development Goals
VANE Violence, Abuse, Neglect, and Exploitation
VAC Violence Against Children
VAWG Violence Against Women and Girls
CMS Case Management System
CPIMS Children Protection Information Management System
DCIMS District Child Information Management System
IEBC Independent Electoral and Boundaries Commission
CRM Contact Management System
SMS Short messaging Service
FRD Functional Requirement Document
MNO Mobile Network Operator
SysAdmin Systems Administrator
TAT Turn Around Time
PRSP Premium Rate Service Provider
ITU International Telecommunication Union
BITZ ITC Bitz IT Consulting Ltd
PRSP Premium Rate Service Provider
4 | P a g e Functional Requirement Document
1 Introduction:-
Child Helpline International is a collective impact organization working to defend the rights of children and youth worldwide. The network consists of 181 member organizations operating in 147 countries around the world (December 2017). Since its founding in 2003, it has supported the creation of new child helplines and strengthened the network by sharing what has been learned from the best of them, with all of them.
Child Helpline International has partnered with UNICEF’s Eastern and Southern Africa Regional Office (ESARO) to support child helplines in the Eastern and Southern Africa (ESA) region. This collaboration aims to improve call response mechanisms, case management and referral of cases.
In the last 2-3 years UNICEF ESARO in its role of technical support and coordination realized that a number of Child Helplines in the region are faced with similar challenges. ESARO in collaboration with COs’, assessed the various Helplines used within these 3 countries and identified similarities in processes and platforms, estimating that there is a 60-80 percent overlap. It is proposed that under the technical guidance of ESARO, a modular and replicable generic Helpline system is developed and thereafter customized for Kenya, Tanzania and Uganda for their own country specific context. The core components of the Helpline platform, common across nearly all countries is referred to as the Generic Helpline System. Some of these common features will include Case Registration, Case Management, escalation and follow-up procedures.
This FRD therefore captures the functional and non-functional requirements to develop the Generic Helpline.
5 | P a g e Functional Requirement Document
2 Non Functional Requirements
2.1 Work planThe system will be developed in 2 phases. Phase 1 which will take about 3 months will involve development of the core system. This can be used to capture cases, Escalate, Refer and Follow up cases for faster resolution. Phase 2 will involve development of the other additional functionalities such as CHAT, Mobile App, SMS and social media. Below is the Work Plan.
Phase Time Start EndRelease One(This is the Core System development stage)
Inception Phase (Project requirements gathering)
2 Week Week 1
Week 2
FRD preparation 6 Weeks Week 3
Week 8
Core System Design 2 Week Week 1 Week 2Coding Phase 8 Weeks Week 3 Week 10Testing &Transition Phase 3 Weeks Week 11 Week 13
Customization and Deployment
Customization to Specific Country and deployment to the 3 countries (2 weeks for each country)
10 Weeks Week 14 Week 23
Sub-total Core system Development and Deployment in the 3 countries
23 Weeks April, 2018 August, 2018
Release Two(Integrated Services & Features)
1. SMS2. Chat integration3. Mobile App4. Tele-working 5. External Web
Interface
4 Weeks Week 24 Week 27
Testing and deployment
Testing system and deployment to the 3 countries
4 Weeks Week 28 Week 31
Documentation and Training Facilitation
Source Code preparations Documentations and handover
2 Weeks Week 32 Week 33
Sub-total Release two Development, Deployment and Handover
10 Weeks August, 2018
October, 2018
Guarantee Period Free 6 Months Support
24 Weeks August, 2018
January, 2019
6 | P a g e Functional Requirement Document
SLA Support and Maintenance
2 Years February, 2019
January, 2021
2.2 Technical Support Terms2.2.1Hours of OperationThe company will ensure the availability of support staff from Monday to Friday from 8am-6pm(GMT+8).Any requests for the support outside these hours or the weekends or public holidays will be requested by UNICEF or partners to the Vendor in writing and agreed at least 48 hours prior the need.
2.2.2 Incident and Problem ManagementThe core idea of incident management is quick workable resolution of outage or performance degradation of any features, modules, or the system in its entirety.
For critical incidents and multiple incidents of similar nature, the root cause of the problem will need to be identified. Solutions or workarounds will be tested and applied.
As part of the expected SLA, a tiered software support services model will be employed to provide an effective way to manage support services. If change is needed the request will be channeled to UNICEF through the Ministry or the Child Helpline. UNICEF will in turn consult with the Vendor and agree on cost and timing of the change request to be effected.
2.2.3Matrices DefinitionsThe engagement mode for support and maintenance anticipates all level 1 technical support to be provided by the Ministry or the Child Helpline in house technical team. End users shall contact them with issues. End users will communicate with the internal IT team either through Phone, face to face, Email or internal CHAT system which will be integrated to the Child Helpline System. The point of contact shall attempt to resolve the issue. If successful the issue will be closed at that point. If not successful the point of contact will submit the issue using the issue tracking/ticketing system as shall be provided by the Vendor. At the same time the issue will be flagged to the UNICEF technical support and The Vendor technical team. Once inside the ticketing system the issue will be followed to closure while all parties will receive progress updates until closure. At this point the Vendor will have the responsibility to resolve the issue and to provide the necessary updates.
Critical or high issues will be logged into the ticketing system and automatically assigned to the Vendor support team. Immediately the point of contact at the Ministry or the Child Helpline shall be required to call the Vendor according to the escalation plan / matrix below and at the same time inform the UNICEF technical team.
7 | P a g e Functional Requirement Document
The triage process and prioritization assignment to each issue shall be managed by the Ministry or the Child Helpline.
A. Critical (Response On call)
A complete interruption causing the system (or critical piece of functionality) to be inaccessible. The Ministry or Child Helpline IT point of contact has no possible workaround to resolve the issue.
B. High (Response 3 Hours)
Critical functionality degraded or rendered unusable, causing severe impact on service availability for a significant portion of users. A temporary workaround exists but is not an acceptable longer term solution.
C. Medium Response (1 business day)
Issue affects no-critical functionality, or impacts a smaller number of users. A workaround is available.
D. Low (Response 2 business days)
Issue distracts users from their work in the system, but does not impact functionality or data. A workaround exists.The triage process and the prioritization assignment to each issue shall be managed by the Ministry and reviewed with the Vendor support team.
2.2.4Support during 6 Month Warranty Period
Unlimited access to the Vendor’s ticketing system as described on the priority levels and response time section below.
Unlimited technical support via email, CHAT, Skype and calls Intense training of the internal IT team at the Ministry or Child Helpline Vendor to send a technical resource once a week. This will be mostly a troubleshooting
session, pre-emptive support, applying of fixes and training sessions.
2.2.5Priority Levels and Response Time
Whenever Ministry or Child Helpline logs an incident to the Vendor’s ticketing system, they will add a prioritization to the incident. The prioritization will determine the response time for incidents. Incidents will primarily be reported through a ticketing system developed by the Vendor. Other communication channels such as phone, CHAT, Skype and email will be used as well, depending on the urgency and priority level of the incident. This response will be maintained during the specified hours of operation. The table below lists the four priority levels and the corresponding response times.
8 | P a g e Functional Requirement Document
Summary of Priority Levels and Response Times
Incidence
Description Work Around Action Response Time
Critical Complete interruption System Inaccessible
No work around exists
Log in to the ticketing system.Call VendorInform UNICEF
On-Call
High Critical functionality degraded rendered unusableSevere impact on service availability
Work Around exists but only as temporary solution.
Log in to the ticketing system.Call VendorInform UNICEF if exceeds the 3 hours resolution response time.
3 Hours
Medium Non CriticalAffects small number of users
Work Around available
Log into the ticketing systemInform Vendor
1 Business Day
Low Does not affect functionalityDistracts Users
Work Around available
Log into the ticketing systemInform Vendor
2 Business Days
Response times means that the Vendor will acknowledge receipt of the ticket and begin researching a solution to the issue within the allotted time. For the critical and High priority issues once a solution has been discovered the Vendor will be required to deploy it soonest possible while keeping the Ministry, Child Helpline and UNICEF updated on the progress. For the Medium to low incidences the Vendor will work directly with the IT point of contact at the Ministry or Child helpline to implement the changes required. For Medium to low incidences it is expected that the solution can be effected remotely for example through team viewer with the assistance of the internal IT team at the Ministry or at the Child Helpline.
Level 2 and Level 3 researching and troubleshooting of issues may include contacting third party partners. Time spent contacting and troubleshooting with third party partners shall be deducted from the selected allotted time for support and maintenance.
As indicated above, all issues including critical and high issues will be submitted via an online ticketing system. Critical and high issues will be followed by a call to the Ministry and UNICEF designated focal points to ensure prompt attention. Other channels that may be used to alert the Vendor of the critical and high issues entered in the ticketing system include instant messaging, email or Skype.
9 | P a g e Functional Requirement Document
The Vendor will be responsible for providing a primary contact number, as well as secondary numbers in case the primary contact number is unreachable. They will also provide links to other platforms where support will be available to the client.
2.3 Handling of Code Repository and Testing Procedures
The Vendor shall maintain a current production codebase with a central repository using Github and a test environment as similar as possible to the production environment. They will have one test environment setup at their offices and another one on cloud that will be available to the stakeholders. The Vendor shall maintain and update a roadmap for feature enhancements in consultation with the Ministry or the Child Helpline and UNICEF. Once an issue is reported or a new functionality is developed, the developer shall follow established software development practices, including:
Checking out the necessary code from the repository Investigating and preparing the software fix on their local machine Performing sufficient unit and regression-testing to be satisfied that the fix has not
unintentionally impacted a different area of the system. Merging the code back into the codebase Deploying the codebase to the Test environment Working with the stakeholders to perform final acceptance testing Upon sign-off and consultation with the stakeholders, moving the fix to production
The above high-level image illustrates the staging to delivery process.
10 | P a g e Functional Requirement Document
All development and testing work will be done on development and testing environments respectively. The production platform will only be patched once the patch has been tested on a testing/staging platform. The Ministry or Child Helpline and UNICEF should be informed of all patches and/or alterations applied to the production system. The following steps and procedures will be observed.
A. Open source Source code licensed under the free and open-source AGPL license (Affero General
Public License v3) with UNICEF a sole copyright holder of the AGPL license. All code must be uploaded to an agreed repository on GitHub.
B. Test coverage Automated testing of overall system, including provision of unit tests for all source code
that can be run on the integration build server. Near total test coverage for all code is required.
C. Performance and scalability Repeatable testing of system performance to ensure scalability, including automated
detailed performance measurement of all software modules under stress-test conditions.
D. Check – in Procedure Check-in early check-in frequent is the model developers will adapt. On Github vendor
will adopt subversion (SVN) where developers should have a branch for the code in progress. Commits to that will not break the main build, which is in the trunk. This will also enable one to revert back to the last checkpoint. When the code is finished the branch will be merged into a local copy of the trunk. If it compiles, runs passes tests then the trunk is committed.
E. Agile development The software development process shall include regular check-ins to re-assess progress,
check priorities and adapt specific implementation details. Publicity visible roadmap and development priorities
However, all the above features to be implemented within the agreed timeframe. Trello Software development Project Management tool will be used
2.4 Project management
As defined in the RASCI matrix in the scope, the overall contract will be managed by UNICEF ESARO, with supervisor as the Regional ICT Chief Kenya, Tanzania and Uganda customized work, training, and deployments will be managed by Child Protection Section with technical
11 | P a g e Functional Requirement Document
support of the CO ICT/T4D teams. Coordination of the Vendor work across the country offices will be done by ESARO under the leadership of the regional ICT Chief.
2.5 Hardware Requirements
Type of Hardware Description / Specifications Country and Number of Units Required
Applications & DataDL 380 Gen9 Server ProLiant DL380 Gen9/2SFF HP/2P Rack (2U)/1 x
E52620v3(6 core, 2.4 GHz, 15MB, 85W)/1 x HP 16GB 2Rx4 /3 x HP 300GB 6G SAS 10K 2.5/P440ar 2G + batt / DVD-RW/4x1Gb (331i)/4xHP Fans/2x500W HP/Easy Rail Kit + CMA/3-3-3 Part No:K8P42A HP DL380 Gen9 E5-2620v3 Kit HP 16GB 2Rx4 PC4-2133P-R Kit HP 300GB 6G SAS 10K rpm SFF (2.5-inch)
Uganda (1)Zanzibar (1)
1 TB SAS 10K rpm SFF (2.5-inch)
Replacement of Hard Disks on the Cisco Server Kenya (2)
NAS External Disk Seagate Business 2-Bay 8TB Network Attached NAS Storage for Backing up Voice recordings and Application Data
Uganda (2)Tanzania (2)Zanzibar (1)Kenya (2)
Connectivity / TelecomsOption 1 and Most desirable SIP otherwise E1
If the Child Helpline has E1 connectivity or if they wish to arrange with the Telecom providers to set up an E1 link
Zanzibar (SIP / E1)Kenya (Migrate to SIP if possible otherwise remain on E1)
MyPBX with GSM Modules
Provision for about 8 Sim Cards Uganda (1)Kenya (1)Tanzania (1)Zanzibar (1)
Routing / SecurityRouter Cisco 2900 SeriesSwitch Cisco Switch 24-Port (CISCO SF2024 Small Business 24
Port )Firewall – Cisco SA 5512 ASA5512-SSD120-K9 Cisco ASA 5500 Series Firewall Uganda (1)
12 | P a g e Functional Requirement Document
Series Edition Bundle If we go the cloud option for hosting a good firewall is paramount and the Cisco ASA 5510 series is a good bet. Cyberoam too offers good security and could be a cheaper option
Kenya (1)Zanzibar (1)
Server Cabinet (If country does not have one)
Toten 42U Server Cabinet with Mesh Door W600 x D1000 x H2055mm Full Vented Top Frame with Rear Cable Entrance or equivalent
Zanzibar (1)Kenya (1)
Server room UPS APC Smart-UPS RT 5000VA 230V - Warranty 3 years Repair or Replace (Excluding Battery) and 2 year for batteryCall Center
Good Desktop Computers for the Call Center
Recommended i5/i7 2.4 Ghz, 8GB RAM Windows 7 (SP1) or Windows 8.1 (Desktop Mode)
If Child helpline chooses to reduce cost No need for these desktops to be installed with Licensed Windows OS as can be installed with Open Source OS such as Ubuntu which is free
Kenya would like a replacement of desktops (20)
Headsets – Plantronics Creative headsets/headphones with mic Kenya (20)Hosting
Hosting – Main Application
Good Internet between Call Center preferably FiberThis is especially because of the integration between government systems with Child Helpline system needed constant online synchronization.
Zanzibar connection needs to be upgraded
2.6 Data Security
Please note that UNICEF has provided part of their Data Security policy appended as Appendix 1.
Security is essential for Child Helpline information systems, and involves among other things, network security, computer security, Internet security and software security. The Ministry and Child Helpline IT teams’ capacity will be enhanced so as to avoid breaching of the Child Helplines security by enforcing the following practices.
Protection
• The helplines to install a fully licensed virus scanner able to detect malware, worms and viruses that infiltrate the systems through the Internet, unsecure networks and infected removable media such as flash disks.
• They are to ensure constant updates to virus scanners and computer software to counter the latest network threats and viruses.
13 | P a g e Functional Requirement Document
• Enable and continuously monitor built-in computer firewalls to shield the operating systems from viruses and network threat.
• Train and support qualified system administrators at the Ministries and the Child Helplines to control all computer systems and network equipment.
• Perform regular system monitoring and reporting to identify security gaps before they become issues.
Perform regular backups
• The Child Helplines can come to a sudden halt when the computer systems crash. The Helplines can incur considerable losses and other serious implications including data loss. The IT teams at the Helplines will be supported to come up with the right backup strategy which will ensure that they have a data restore point in such situations. Having a good server and other external storage mechanisms such as a hard drive can aid in data backup. Recommendations have been given below on hardware requirements for each country. Setting up automatic backups at regular intervals is the best way to deal with data problems.
It is also proposed to have an offsite backup stored on a server or NAS in a different location. This would ensure that incase even the infrastructure at the Child Helpline was to go down for one reason or the other restoration data would still be available from a different location. The Child Helpline would be advised to configure a VPN connecting other branches to connect to the Main Helpline center thereby allowing for online offsite backup scheduled to run on a pre-configured schedule.
Perform Software and System Maintenance Regularly
• Regular maintenance practices such as disk defragmentation and software updates ensure that computers run efficiently. Schedule a monthly or weekly defragmentation process to keep all files in a single working unit. When you have a genuine operating system, you can set automatic updates to allow the operating system get essential updates fixes from the manufacturer.
• IT system maintenance for servers and databases is also necessary for keeping IT systems up-to-date and secure. An AMC will be entered into between UNICEF and the Vendor for a period of 2 years (See Appendix 3). During this period the IT teams at the Child Helpline will be trained to build their capacity to handle support issues. The Vendor’s support will be downscaled until handover of the support function to the internal IT teams.
Genuine Essential Software
• Today, many people fall prey to cheap and readily available “free” software that may not be secure for use in a business environment. Such software has many security loopholes that may expose the company’s data to hacking, identity theft and virus attacks. It is important for any given business to adopt safe, industry standard and approved software to run on its computers.
• We will also assist the IT Teams to determine programs that draw huge amounts of bandwidth from the Helplines computers and get rid of them before disaster strikes.
14 | P a g e Functional Requirement Document
2.7 Data Confidentiality, Integrity and Availability
Child Helpline International members recognize the right of all young people, children and families to services that are professional, individualized, confidential, culturally sensitive and timely. Confidentiality refers to protecting information from being accessed by unauthorized parties.
Given the sensitive nature of conversations and possible intervention outcomes, confidentiality is a serious matter for child helplines around the world. Confidentiality is also one of the reasons why children feel they can trust the child helpline with their difficult matters.
Members of Child Helpline International believe that services designed for children should respect the child’s right to privacy and ensure confidentiality
It may impede on a child’s right to confidentially and privacy if a child helpline is able to automatically locate a caller without their express permission and informed consent. It may also be a barrier to help if a child is scared they will be identified or called.
During the generic FRD discussions at UNICEF offices the issue of confidentiality for those Child Helplines planning on having call back services was raised. The need to adhere to Child Helpline International confidentiality standards should be adhered to. Please see Appendix 2 for more information on the Child Helpline International confidentiality standards.
15 | P a g e Functional Requirement Document
3 Functional Requirements & Features
3.1 Modes of Communication
The registration of cases, Case Management, escalation and Follow-up will be done through the various communication modes listed below:
3.1.1 Walk – In Cases: -
This feature is for all the Clients or the reporters who have access to the counselling center and can walk-in into the premises and report the case.
When selected there will be no other calls or other mode of communication for any cases directed to the counsellor.
The timer for the case handled will be triggered, which will eventually be used for statistics for the individual counsellor.
Once the entire case form is filled and the status of the case is updated, the timer for the case will stop and will indicate counsellor as available for the next case
The counsellor needs to make himself / herself available to take more cases via Calls, SMS, Web- Chat, E-Mails, Social Media, Walk-ins, etc
Features of Walk-In case: -
1) During Walk-in, the client or reporter can be reporting the case for the 1st time or might be following up on a previous case which has already been registered. Kindly note that the walk-in form will be used for the following unstructured communications:
a. Chatb. Emailsc. SMSd. Social Media
16 | P a g e Functional Requirement Document
2) To have this checked, below will be the features given to the counsellor.
Figure 1: Walk in Form
3) When any of the above details Name, Phone no. or case id are submitted, the system will search in the data base for any of the matching details and then populates the form.
Figure 2: Walk in Form filled
17 | P a g e Functional Requirement Document
Name: Text BoxPhone Nos: Text BoxCase Id: Text BoxAge Text BoxSex Drop DownLocation Text Box
Name: PeterPhone Nos: 12345678Case Id: Text BoxAge 10Sex MCounty Kisii
Submit
4) If no records are found, the system will indicate NO MATCHING RECORDS, click on NEW to create a new form.
Once the New Case button is clicked, a new case form pops up and the details are filled accordingly.
*The case form details are mentioned at a later stage.
3.1.1.1 For existing Case:
Click on Submit button:
18 | P a g e Functional Requirement Document
Name: PeterPhone Nos: 12345678Case Id: Text Box
NO RECORDS FOUND
Click NEW to create a NEW Case
NEW Case
Name: PeterPhone Nos: 12345678Case Id: Text Box
Figure 3: Walk in Form New Case
Figure 4: Walk in Form Existing Case
The system will search for the particulars in the data base and fetch the details matching in a tabular column.
The counsellor can click on the hyper link on the Case Id and can view the case details. The case form with all the details for that case will be displayed. There will be an update / edit button below the case form The counsellor can update the case form with the relevant information All changes made will have an audit trail, which indicates the information update/ edited,
date, time and the login details of the counsellor The data base gets updated with the latest date and time for records purpose All forms will have an auto save and edit button below There will be a BACK button for the information to be viewed / edited/ updated on the
previous pages The auto generated case id nos will remain the same as created earlier. Every heading will have a filter to sort the records
3.1.2 Web-Online Form
These Web Online form will be structured meaning that all fields will be pre-defined with Mandatory fields properly defined for the online client. This will ensure that data received from a Web Online report will be usable in the Case Management system to easily create a case. The form will have “I am not a robot”/”captcha” test for protecting against malicious bot attack on the web server. Development team to setup up SSL in the web service. This will enable user to access the site over htts: allowing secure transmission of data between client browser and server. A verification mechanism will also be setup for the online submission. This mechanism could take the form of sending a verification email or generating an immediate phone call or SMS to the user asking a verification response. This will assure the counsellor updating cases of dealing with authentic clients and eliminate or reduce bot attacks
19 | P a g e Functional Requirement Document
3 results found for the match Click here to GO BACK
Sl No
Name Phone Nos Case ID Type of case Date (Last update)
Case Status
1 Peter 12345678 9845200 Abuse 20/02/2016 Escalated2 Peter 12345678 0213411 General enquiry 09/12/2015 Closed3 Peter 12345678 0123422 Trafficking 01/11/2015 Closed
Figure 5: Walk in Form Case Status
The counsellor will use the methodology of assigning the cases to themselves and acting upon them.
The client will fill the case form online and click the submit button. The mandatory fields required to be filled online and the format of information will be
provided by the Ministry and the Child Helplines in each country. Case nos will automatically get assigned and any updates / progress on the case will be
notified via E-Mail / SMS to the person who has raised the case on line. Any modifications to the case form will have an audit trail left behind. A clear guideline details will be mentioned to the person which will guide them on how to
fill the form and raising their concern When selected, there will no calls or any other mode of communication for any cases
directed to the counsellor. The timer for the case handled will be triggered, which will eventually be used for statistics
for the individual counsellor for number of cases handled via E-Mails. The case management system will be integrated with the Domain to send and receive E-
Mails accordingly for a specified E-Mail id Allow anonymous reporting to allows key cases to be reported without any fear Once the entire case form is filled and the status of the case is updated, the timer for the case
will stop and will indicate counsellor as available for the next case The counsellor needs to make himself / herself available to receive more cases via Calls,
SMS, Web- Chat, Walk-ins or Social Media
Features of a Web Online Case: -
When clicked on Web Online, there will be a Web Online repository which will indicate the following:
Total No. of Web Online Cases Received for the day. It will take the counsellor to all the Web Online Cases received for the day in the common
bucket
20 | P a g e Functional Requirement Document
Click here to GO BACK
Total No. of Web Online Cases Received for the day
Total Nos of Web Online Cases assigned to my Queue
Total Nos of Web Online Cases Actioned for the day
Total Nos of Web Online Cases Escalated for the day
Total Nos of Web Online Cases Pending for the day
Total Nos of Web Online Cases Closed for the day
50 10 7 3 5 2
Figure 6: Email Repository Summary
The counsellor can select the Web Online case and assign to Himself / herself to action it accordingly
Cases will be listed on a First in First out (FIFO) basis. For all unassigned Cases, the counsellors can click on check box and assign the case to
themselves to act on it. All other Web Online cases assigned to other counsellors will be greyed out and cannot be
assigned or viewed until the case is closed or escalated Once the case has been taken by the counsellor, the status will indicate WORK IN
PROGRESS
To check if it’s an existing case follow up or new case.
The system will automatically search the Case ID or E-Mail id from the data base and indicate if there are any cases pertaining to the same Web Online Case or it’s a first time.
1) To have this checked, key details will be given to the counsellor to do a search. Please refer to figure 1.
2) When any of the above details are fed into the database and the submit button clicked, the system will search for any of the matching details and publish the data.
3) If no records are found, the system will indicate NO MATCHING RECORDS, click on NEW to create a new form. Please refer to figure 3.
4) Once the New Case button is clicked, a new case form pops up and the details are filled accordingly.
21 | P a g e Functional Requirement Document
Click here to GO BACK
Case ID E-Mail ID Category Date Web Online Case Received on
Assigned Action Status
9845200 [email protected] Complaint 15/02/2017 Unassigned -0213411 [email protected] Abuse 21/01/2017 Mariam Closed0123422 [email protected] Child
treatment31/12/2016 Tony Escalated
9845201 [email protected] Enquiry 29/12/2016 Mariam Closed0213414 [email protected] Trafficking 29/12/2016 Gary Work in
ProgressFigure 7: Web Online details
For Existing Case:
The system will search for the particulars in the database and fetch the details matching in a tabular column.
1) Response by the Counsellor will be done by the Domain id or SMS.2) The counsellor can click on the hyper link on the Case Id and can view the case details.3) The case form with all the details will be displayed4) There will be an update / edit button below the case form5) The counsellor can update the case form with the relevant information6) All changes made will have an audit trail, which indicates the information update/ edited,
date, time and the login details of the counsellor 7) The data base will be updated with the latest date and time for records purpose8) All forms will have auto save and edit button below9) There will be a BACK button for the information to be viewed / edited/ updated on the
previous pages All of the above information will be formulated in the form of reports10) The auto generated case id nos will remain the same as created earlier. 11) Every heading will have a filter to sort the records
3.1.3 Web-Chat: -
This feature is for all the Clients or the reporters who have access to Internet and would like to report a case through the Child Helpline web portal through the chat facility to a counsellor.
22 | P a g e Functional Requirement Document
2 results found for the match Click here to GO BACK
Sl No
Name Case ID E-Mail ID Type of case Date Case Status
1 Jack 7865201 [email protected] Trafficking 07/01/2017 Escalated2 Jack 1413409 [email protected] Abuse 09/12/2015 Closed
Figure 8: Existing case found
When selected, there will be no calls or other modes of communication directed to the particular counsellor.
There can be an option for a notification received when Clients or the reporters want to chat. When accepted the chat, automatically the system will change status for no call mode and
continue with the activity. Once the status of the case is closed, the system will prompt if the counsellor wants to go
back to calls, if not they will continue with offline support mode. The case management system should be integrated with the Web page of the child Helpline The timer for the case handled will be triggered, which will eventually be used for statistics
for the individual counsellor for nos of cases handled via Web- Chat. Once the entire case form is filled and the status of the case updated, the timer for the case
will stop and will indicate the counsellor as available for the next case The counsellor needs to make himself / herself available to take more cases via Calls, SMS,
Walk-ins web-chat, Social Media, Web-online etc. Refer to walk-in form in figure 1.
Features of Web-Chat case: -
1) The case management system is integrated with the Web portal via API2) When notification pops up indicating the Web Chat, the available counselor has the
option to accept the chat or decline it. 3) The system will identify from the chat id, if it’s a first time chatting or a regular chat. 4) For a new CHAT case the counsellor will create it using a Walk-in Form from within
the system. 5) The oldest chat unattended will feature first on top6) If the counselor is chatting, the status of the counselor on the dashboard will change
to chatting and the timer will start till the chat is completed with the case form been completed and updated
To check if it’s an existing case follow up or new case.
The system will automatically search the Web Name id of the chatter from the data base and indicate if there are any cases pertaining to the same Web name id or it’s a first time.
Also the counsellor can search by the following criteria for Web Name, the client or reporter can be reporting the case for the 1st time or might be following up on a previous case which has already been registered
To have this checked, the below will be the features given to the counsellor.
23 | P a g e Functional Requirement Document
Figure 9: Chat / Case Search Form
When any of the above details are fed into the database such as Name or Web Chat name or Phone nos or case id and clicked on submit button, the system will search in the data bases for any of the matching details and publish the reports
5) If no records are found, the system will indicate NO MATCHING RECORDS, click on NEW to create a new form. Please refer to figure 3.
6) Once the New Case button is clicked, a new case form pops up and the details are filled accordingly.
For Existing Case:
24 | P a g e Functional Requirement Document
Click here to GO BACK
Name: Text BoxWeb Chat Name Text BoxCase Id: Text BoxPhone Nos: Text Box
2 results found for the match Click here to GO BACK
Sl No
Name Web- Chat Name
Case ID Type of case Date Case Status
1 Nicholas Nike987 5966000 CPIMS 22/08/2016 Closed2 Nicholas Nike987 7321769 Abuse 01/12/2016 Closed
Figure 10: Chat Search Cases found
The system will search for the particulars in the data base and fetch the details matching in a tabular column.
1) The response for the chat will be done from the Web Browser and all the trail chats will be recorded
2) The counsellor can click on the hyper link on the Case Id and can view the case details.3) The case form with all the details will be displayed4) There will be an update / edit button below the case form5) The counsellor can update the case form with the relevant information6) All changes made will have an audit trail, which indicates the information update/ edited,
date, time and the login details of the counsellor 7) The data base get updated with the latest date and time for records purpose8) All forms will have auto save and edit button below9) There will be a BACK button for the information to be viewed / edited/ updated on the
previous pages All of the above information will be formulated in the form of reports10) The auto generated case id nos will remain the same as created earlier. 11) Every heading will have a filter to sort the records
3.1.4 Social Media: -
Face Book, Twitter
These features are for all the Clients or the reporters who have access to Internet and would like to raise a complaint through the Child Helpline Facebook page or Twitter account.
The entire process for the Social media will be the same as the Web Chat process and methodology.
All modes of communication will have a search engine.
Refer to walk-in form in figure 1.
25 | P a g e Functional Requirement Document
3.1.5 SMS:-
This feature is for all the Clients or the reporters who have access to the phones and who wish to send an SMS to 116 for the Child Helpline. UNICEF will provide our technical team with their SMS send / receive platform which will support structured reporting via SMS. The counsellor will be able to get / probe for key information from the reporter via SMS
When selected, there will be no calls or other mode of communication directed to the particular counsellor.
The case management system should be integrated with the SMS Gateway to receive and send SMS accordingly from a specified 116 short code. (Mostly through a PRSP but may vary from country to country)
The timer for the case being handled will be triggered, which will eventually be used for statistics for the individual counsellor for number of cases handled via SMS.
There will be an option to reply to SMS through the case management system to acknowledge the SMS received and seeking for more details.
Once the entire case form is filled and the status of the case is updated, the timer for the case will stop and will indicate as available for the next case
The counsellor needs to make himself / herself available to take more cases via Calls, SMS, Web- Chat, Walk-ins, Social Media, E-Mails, etc.
26 | P a g e Functional Requirement Document
Features of SMS case: -
When clicked on SMS, there will be a SMS repository which will indicate the following
When clicked on the hyper link of Total Nos of SMS Cases Received for the day. It will take the counsellor to all the SMS received for the day in the common bucket The counsellor can select the SMS and assign to Himself / herself to action it accordingly The latest SMS will get featured on top For all unassigned SMS, the counsellors can click on check box and assign the SMS case to
themselves to action it. All SMS assigned to other counsellor will be greyed out and cannot be assigned or viewed
until the case is closed or escalated
Once the case has been taken by the counsellor, the status will indicate WORK IN PROGRESS
27 | P a g e Functional Requirement Document
Click here to GO BACK
Total Nos of SMS Cases Received for the day
Total Nos of SMS cases assigned to my Queue
Total Nos of SMS cases Actioned for the day
Total Nos of SMS cases Escalated for the day
Total Nos of SMS cases Pending for the day
Total Nos of SMS cases Closed for the day
10 6 3 1 5 2
Click here to GO BACK
Sl No
Sender No. Body / Contentof SMS
Date SMS Received on
Assigned Action Status
Click To Assign
Respond to SMS
1 0722987650 General Information 10/01/2017 Unassigned -2 0713654321 Sexual Abuse 08/01/2017 Unassigned - -3 0763409062 Abduction 07/12/2016 Unassigned - -
4 0733414523 Mental Health 07/12/2016 Mariam Closed Replied5 0720055067 Trafficking 06/12/2016 Gary Work in
ProgressReplied
Figure 11: SMS Summary Repository
Figure 12: SMS Details
The timer for the case handled will be triggered, which will eventually be used as stats for the individual counsellor.
Once the entire case form is filled and the status of the case updated, the timer for the case will stop and will indicate as available for the next case
The counsellor needs to make himself / herself available to take more cases via Calls, SMS, Web- Chat, E-Mails, Social Media, Walk-ins, etc
Refer to walk-in form in figure 1.
SMS case details: -
For SMS, the client or reporter can be reporting the case for the 1st time or might be following up on a previous case which has already been registered
To have this checked key information will be provided to the counsellor. Please refer to figure 1.
When any of these details are fed in the database such as the Name, Phone no or case id and submitted, the system will search in the data base for any of the matching details and display the data.
If no records are found, the system will indicate NO MATCHING RECORDS, click on NEW to create a new case. Please refer to figure 3.
Once the New Case button is clicked, a new case form pops up and the details are filled. Please refer to figure 4.
For Existing Case:
The system will search for the particulars in the data base and fetch the details matching in a tabular column.
28 | P a g e Functional Requirement Document
Figure 8: SMS Search Results with no existing case
Figure 13: Case search status form
3 results found for the match Click here to GO BACK
Sl No
Name Phone Nos Case ID Type of case Date Case Status
1 Peter 12345678 9845200 Abuse 20/02/2016 Escalated2 Peter 12345678 0213411 General enquiry 09/12/2015 Closed3 Peter 12345678 0123422 Health 01/11/2015 Closed
The counsellor can click on the hyper link on the Case Id and can view the case details. The case form with all the details will be displayed There will be an update / edit button below the case form The counsellor can update the case form with the relevant information All changes made will have an audit trail, which indicates the information update/ edited,
date, time and the login details of the counsellor The data base get updated with the latest date and time for records purpose All forms will have auto save and edit button below There will be a BACK button for the information to be viewed / edited/ updated on the
previous pages All of the above information will be formulated in the form of reports The auto generated case id no will remain the same as created earlier. Every heading will have a filter to sort the records
3.1.6 Calls: -
The system will allow incoming calls from a reporter or a client who is reporting a case. There will be provision for a toll free phone numbers (hotline) that will cater for the Child Helpline. Calls can be transferred within the call center while at the same time the supervisor can be able to budge into an ongoing call to listen in or give some inputs to both parties.
It has been noted that some counsellors receive more calls than others. This is probably because they do not make themselves available by clicking the available button. This can be resolved by putting a wrap up timer that the supervisor can change.
IVR – Interactive Voice response
A welcome message with greetings with information about the child helpline will be played. However it was agreed that information playing on the IVR will be provided by Ministry in conjunction with the particular Child Helpline.
Language preference (Selection) and skill set routing Hold music or general information played when all counselors are busy on calls Voice mail for a call back if the call has not gone through to any of the counselors
Call landing on the counselor’s desk:-
When the call lands at the counselor’s desk, the number from which the call is coming through gets displayed
29 | P a g e Functional Requirement Document
If the call is from a number which is not in the data base, a new case form will be popped up If the number has been registered in the database, all the data pertaining to this number will
get displayed The counselor will have an option to select the existing case as a follow up. There will be an
edit/update button for the counselor to update the information. In case it’s a New case, a unique case id for the case gets generated which will be generated
in the form for sequential numbering As and when the details in the form gets filled, there will be an auto save functionality which
will be saving the information There will be a back button for the counsellor to come back to see the previous information
Features of a Call Case: -
Critical information in the form of call summary will get displayed in the right hand side of every case form for reference.
If the call gets disconnected, there will be an option for disposing the case form by indicating incomplete form due to call disconnect.
Once the conversation begins, the counselor will be able to identify if the call is Genuine or a Prank call, Blank Call or Foreign Language
The counsellor will be able to tick the option to proceed with the call Once this information is stored into the database, in future any call coming from the same
number will have an indication if the call is BLANK, PRANK or Foreign Language (More details on PRANK calls mentioned later) Once the entire form is completed with all relevant information, the call will be closed with
appropriate dispositions. When counsellor is allocated to calls queue there will be no other modes of communication
such as SMS or Email available to the counsellor. The case management system will be integrated with the Call Center Management system to
receive and make calls through toll free short code number (116) The timer for the case handled will be triggered, which will eventually be used for statistics
for the individual counsellor for the number of cases handled via calls. Once the entire case form is filled and the status of the case updated, the timer for the case
will stop and will indicate counsellor as available to receive the next case call. The counsellor needs to make himself / herself available to take more cases via Calls, SMS,
Web- Chat, Walk-ins, Social Media, E-Mails, etc. In the contacts field it is important to capture the nearest Landmark whether it’s a hospital,
school etc.
New Case: -
A new case form will pop up with a unique case number assigned to it.
30 | P a g e Functional Requirement Document
Case No: 1234456
For existing case / repeat nos:
The system will search for the particulars in the data base and fetch the details matching in a tabular column.
The counsellor can click on the hyper link on the Case Id and can view the case details.
The case form with all the details will be displayed There will be an update / edit button below the case form The counsellor can update the case form with the relevant information All changes made will have an audit trail, which indicates the information update/
edited, date, time and the login details of the counsellor The data base gets updated with the latest date and time for records purpose All forms will have auto save capability and edit button below There will be a BACK button for the information to be viewed / edited/ updated on
the previous pages
31 | P a g e Functional Requirement Document
Click here to GO BACK
Name Text BoxAge Calendar / Text Box / Date RangeSex Drop DownLanguage Drop DownLocation Drop DownNearest landmark Text Box
Create New Case
3 results found for the match Click here to GO BACK
Sl No
Name Phone Nos Case ID Type of case Date Case Status
1 Dan 12345678 9845200 Abuse 20/02/2016 Escalated2 Dan 12345678 0213411 General
enquiry09/12/2015 Closed
3 Dan 12345678 0123422 Trafficking 01/11/2015 Closed
Figure 14: New Case creation form
Figure 15: Case Status form
All of the above information will be formulated in the form of reports The auto generated case id number will remain the same as created earlier. Every heading will have a filter to sort the records
3.1.7 Field Worker – Mobile Compatible Application: -
The system will be mobile compatible. This means the application will be accessible on mobile devices. Users log-in using their credentials on the mobile device. They will be able to receive cases assigned / escalated to them for follow-up. They will also be able to register cases just as if they were accessing the system at the call center.
The Case forms will be the same as mentioned in all the processes with the same functionalities.
Offline capability will be inbuilt in the application hence once the phone is connected with internet, the entire data will be transferred to the server and will get featured in the case repository.
There will be confidentiality maintained as the phone will transfer the information once connected to the server.
Through an ODK API to enable offline data synching once device is connected to internet. Once the information is transferred to the server, the case id will get generated as per the
sequential order of the cases that have been created for all modes of communication. For other external departments, Web logins will be created with access right to what is
essential for them to view and update accordingly. All of the above shall have detailed audit trails with foot prints of date and time. Field worker once logged in, will be able to view the dashboard of how many cases have
been assigned to them, how many they have created, what is the TAT for the cases to be resolved, Etc.
32 | P a g e Functional Requirement Document
Sl No
Counselor Name
Case ID Assigned Date Assigned to
Type OF case
Criticality TAT Action
1 Elizabeth 9876542 03/08/2016 Michael Child Abuse
High Priority 5 hrs Update
2 Susan 2673849 10/08/2016 Michael CPIMS High Priority 1 day Update3 Kimani 9754207 14/08/2016 Michael CPIMS Medium
Priority2 days Update
4 Brian 1573642 19/08/2016 Michael CPIMS Medium Priority
6 hrs Update
5 Jacky 6254782 23/08/2016 Michael Child Abuse
Low Priority 2 days Closed
Figure 9: Field Worker case status
My Cases Created:
4 Case Management Form:-3
4.1 Case Capture work flow
It has been noted that government child protection information systems have a case record sheet in place with defined fields. The technical team together with Ministry and Child helplines will work together to verify existing fields are matching with the government system fields for easier data exchange between the 2 systems.
It was agreed that standards need to be developed to guide those registering cases on important information to capture from the reporter.
To maintain confidentiality it was suggested that Case information on progress should not be given to follow up reporters either by mail or any other means.
33 | P a g e Functional Requirement Document
Sl No
Counselor Name
Case ID Case Created Date
Assigned to
Type OF case
Criticality TAT Status
1 Michael 6738293 10/12/2016 Michael Child Abuse
High Priority 2 hrs Pending
2 Michael 4357485 17/12/2016 Michael CPIMS High Priority 5 hrs Closed3 Michael 9282632 17/12/2016 Michael CPIMS Medium
Priority1 days Pending
4 Michael 5283746 21/12/2016 Michael CPIMS Medium Priority
3 hrs Update
5 Michael 2163858 26/12/2016 Michael Child Abuse
Low Priority 8 hrs Closed
Create New Case
Figure 10: Create a new case
In the Child Helpline system there are 7 broadly classified tabs for the information to be captured.
A. Case Reporter DetailsB. Case CategoryC. Other Client DetailsD. Perpetrator DetailsE. Case NarrativeF. Services OfferedG. Case Action
Depending on the case status if the client is a first time Reporter the counselor will click on Create New case otherwise if the client or is a repeat Reporter/ Client the form will populate accordingly.
34 | P a g e Functional Requirement Document
Case Capture Workflow
35 | P a g e Functional Requirement Document
Create New Case
End
Case Actions
Services OfferedGet Case Narrative
Case Update
Get Client Details
Select Case Category
Follow Up
With Perpetrator
Get perpetrator details
List/Search & select Case under Reporter
Reporter is Client
Get Reporter Details
Additional client details
Reporter Exists
Start
No
Yes
No
Yes
No
Yes
No
Yes
Figure 16: Case capture flow
We would like to note that the fields to be captured as well as questions to be asked during case registration process will be aligned to the Child helpline and THE MINISTRY during the development process.
Case Reporter’s Details: -
36 | P a g e Functional Requirement Document
Fields To be Captured Actions Capturing FeaturesWhat is your Name If the reporter wants to keep this
discreet choose YES then all other Name details will be grayed out
Drop Down if Name Discreet and Text Box to capture Name details if Name not Dicreet
Sex Male (M)Female (F)
Drop Down – To select
Language Spoken EnglishKiswahiliOther
Drop Down – List of Langauges
Age Adult, Child Text Box - AgeDrop Down - Age BracketCalendar – Exact Date of Birth
Location / Address CountySub-CountyWard
Drop Down for Location selection
Nearest Landmark HospitalPolice StationSchool
Text Box
Profession Profession of the reporter Drop DownNationality Default Kenyan Drop DownNational ID Number Identification Text Box Email ID Required for Web-chats Text Box
Save and Proceed
Figure 17: Case reporters details
Case Reporter’s details Continued: -
A) Other Client Details: -
37 | P a g e Functional Requirement Document
Save and Proceed
Fields To be Captured Actions Capturing FeaturesCase Category
1) Trafficking2) Abduction3) Physical Abuse
4) Refer 5) Escalate6) Information & Enquiry7) Follow up
Drop Down – Radio button to choose multiple option
1) Refer to HospitalPoliceOther Authorities
Drop Down – List of
2) Escalate SupervisorCase ManagerOther Senior
Drop Down – List of Seniors to escalate to
3) Information & Enquiry Close Drop Down – List of Information & Enquiry. (Other – Text Box)
4) Follow up History with case id Search Button – Case id nos or other details
Are you the Client If Yes, all the details of the reporter will be replicated as Client details. If No, Client details need to be captured.
Yes or No – Radio Button
YES If Yes, all the details of the reporter will be replicated as Client details.
NO If No, Client details need to be captured.
1) What is your relationship with the client
List of all relations Drop down
2) Client Name Text Box3) Sex Male/ female / Unclear Drop Box4) Language Spoken Drop down & Text Box for others
Age Must be asked if Major or Minor 1) Text Box – for age2) Drop Down – For age Bracket3) Calendar – For exact DOB
Profession: Text BoxDo you have the same address as the client?
If Yes, all the details of the reporter address will be replicated as Client details. If No, capture Client’s address
Yes or No – Radio Button
NO If No, Client’s address details need to be captured.
Location / Address CountySub-CountyWard
Drop Down for Location selection
Nearest Landmark HospitalPolice StationSchool
Text Box
Figure 18: Case form
38 | P a g e Functional Requirement Document
Figure 19: Client Details
Fields To be Captured Actions Capturing FeaturesIs the Client Disabled Yes Or No Drop Down - If Yes, comment
box to capture the details of disability
What is the client HIV/AIDS status?
Positive / Negative / Unknown Drop Down
What is the client's household type?
Single HeadedSingle ParentBoth ParentGrand ParentsGuardianOthersUnknown
Drop Down – For Others a text Box
How many children are in the household?
Text Box
How many adults are in the household? Text Box
What is the occupation of the household head?
Small Scale BusinessLarge Scale BusinessPublic ServantCasual LaborerNGO WorkersOthers Drop Down
Is the client attending school?
If Yes, all the details of the School will be required. If No, last level of education is required Yes or No – Radio Button
YESWhat is the name of the school? Text Box
What is the school type?
Public BoardingPrivate BoardingPublic DayPrivate DayNone Drop Down
What class is the client?
Primary, SecondaryTertiary – In details Drop Down
How is the client's school attendance?
Consistent,Inconsistent Unknown Drop Down
Save and Proceed
Perpetrator Details: -
Logic – If in previous Category there is no Abuse, this part will not get featured. Its only when Abuse is selected that abuse will these details pop up
Fields To be Captured Actions Capturing FeaturesIs the client abused? Yes / No / Maybe
If Yes or Maybe, further details are required If No, just indicates Save & Proceed. Add button – For Perpetrator details for further if the counselling leads to this stage
Drop Down
Add Button
If Selected YES or Maybe Abuse Category will get populatedAbuse Category Abduction
AbandonmentPhysical AbuseSexual exploitation and abuseDefilementTraffickingetc
Drop Down
39 | P a g e Functional Requirement Document
Figure 20: Perpetrator Details
Name Text Box
Relationship
FatherMotherBrotherSisterUncleAuntNephewNieceTeacherNeighborUnknown Drop Down & Text Box
Age Age or Age Range Text Box
If Adult – Marital Status
MarriedSingleDivorcedCohabitingWidowedUnknown Drop Down & Text Box
Contact details Text BoxDoes the perpetrator share household with client? YES or NO Drop BoxIs there any additional details on perpetrator? More information Text Box
40 | P a g e Functional Requirement Document
Figure 21: Perpetrator Details
Services Offered: -
41 | P a g e Functional Requirement Document
Fields To be Captured Actions Capturing FeaturesSelect service offered 1. Counselling
2. Appropriate Referrals3. Awareness4. Psychological Support5. Educational Support6. Directed to Telecom Support7. Report to Police8. Medical Support9. Legal Support10. Basic Need Support11. Resettlement12. Others
Drop Down
1. Counselling Counselling categoryAbuse & ViolencePeer RelationshipPovertyPsychological healthBehavior ProblemDiscriminationFamily RelationshipLegal IssuesGender Based Violence
Drop Down
2. Appropriate Referrals Refer to Box - (Need the list)Action CentersShelter For victimSupport GroupSocial WorkerHospital / ClinicEtc
Text Box – With Reference no to be mentioned
Save and Proceed
Add Perpetrator if required
Figure 22: Services Offered
Case Action: -
42 | P a g e Functional Requirement Document
Fields To be Captured Actions Capturing FeaturesAction 1. Escalate
2. Pending3. Closed
Drop Down
Consent Box If Escalated – Consent box will get populated for sharing the information to external department
Tick box
1. Escalate Escalate to Whom?A) SupervisorB) Call Center Manager
Drop Down
A) Supervisor- Supervisor List Name the Supervisor Drop Down or Text Box
B) Call Center Manager – Supervisor List
Call Center Manager List Drop Down or Text Box
2. Referral 1. Police2. Other Authority
Drop Down
3. Closed Submit and Close
Submit & Close
Consent – This case shall be referred to external department for resolution.
The details have been authorized to be shared.
Figure 23: Case Action
5 Quality Analysis (QA) Module: -
All the voice calls handled by the counselor will have 100% recordings. A monitoring form needs to be tailor made and designed for the center.
To analyse the cases the supervisor listens to the calls in the system and evaluates and validates if the case details are okay and then does QA based on counsellor interaction.
There is a provision of a Quality monitoring sheet which will be focusing on the entire calls with respect to soft skills, counselling knowledge, updating the system, etc.
The QC will have the option of following the activities on the calls:
a) Barge into the call – without the counselor being aware of it
b) Snoop into the call – While listening to the call, the QC person can prompt the counselor for any information without the client being able to listen.
c) Confer – Where the Supervisor or QC person, Counselor and the client are able to have a conversation
4
5.1 Monitoring Form: -
It will have the following broadly classified headings
1) Opening / Greeting of the call2) Listening skills 3) Acknowledgment4) System Check 5) Resolution / Counselling provided6) Hold Procedures7) Updating System appropriately8) Closing the call
All of the above shall have detailed parameters for which a specified score shall be assigned. Depending on the score the overall QC percentage shall be calculated.
*Elaborate details of the monitoring sheet needs to be provided by the counsellors
43 | P a g e Functional Requirement Document
5.2 Quality Analysis Procedure: -
Supervisor or QC person when they click on the QC tab, all the calls get displayed which have been attempted
The QC can search for a particular call with any search criteria mentioned above in Blue The headings can be filtered accordingly The details will be as displayed, Name, case id, date of call, Time of call, Duration of call,
Status of call, whether the call has been Qc’ed or not, Acceptance by the counselor, scoring of the call and Evaluate call
If the QC wants to listen to the call, the hyper link CLICK should be pressed The monitoring form will pop up with all the relevant details of the call getting auto filled Subsequently the call recordings will pop up and the QC can listen to the call and score on
the monitoring sheet Once done, the monitoring sheet will be submitted to the counsellor. The counsellor will receive notification of the QC sheet, he/she will click and view the
scoring along with the comments mentioned by the QC The counselor can Accept or Reject the monitoring sheet by mentioning his/her comments
44 | P a g e Functional Requirement Document
Sl No
Counselor Name
Case ID Date of call Time of Call
Duration of call
Status of Call
Qc’ed Call (Done/Pending)
Accepted Scored call - %
Evaluate Call
1 Jacky 9876542 03/08/2016 11:33:00 00:04:54 Closed Done Yes 83% -2 Kimani 2673849 10/08/2016 12:00:10 00:10:12 Escalated Pending - - Click3 Brian 9754207 14/08/2016 14:12:57 00:07:03 Pending Pending - - Click4 Susan 1573642 19/08/2016 14:49:00 00:11:44 Escalated Pending - - Click5 Elizabeth 6254782 23/08/2016 18:03:40 00:06:20 Closed Done Yes 57% -
Search & Filter
Figure 24: Call Monitoring Procedure
If Rejected, the QA form goes to the QC to have a discussion and ensure there is acceptance from both the parties
If accepted, the table will get updated with the status and the scores All the monitoring sheets will be available for further reference in a PDF format A quality dashboard will be maintained and used for analysis purpose Live calls also can be monitored and scored on a new monitoring sheet, which eventually
gets updated on the system
N.B. It is noted that the same procedure as above will be applied by the Call center Manager as they QC the supervisors. Parameters used to QC the supervisors will be agreed upon with the stakeholders but could be such as number of calls listened to, number of QC forms rated etc.
45 | P a g e Functional Requirement Document
6 Escalated Cases / Referral / Follow up Cases:-
An escalated case is a case escalated to the supervisor in the call center.
A referral is a case forwarded to other departments / Social Workers / field worker / Police / Hospitals etc.
The Supervisor or Counselors can monitor the dashboard of all the cases to ensure appropriate action is being taken for closure of cases. This will focus more on the cases which have been escalated.
For E.G – TAT table for Escalated
Every case which is assigned with Priority will be defined with TAT (Turn Around Time) which will be defined by the department heads. Depending on the type of case, if the cases is not to be acted upon or updated within the specified time, it will give an alert to the concerned manager / Supervisor.
46 | P a g e Functional Requirement Document
Position High Priority Medium Priority Low Priority After TAT- EscalationTeam Leader 3 hours 7 hours 15 hours SupervisorSupervisor 4 hours 10 hours 18 hours Call Center ManagerCall Center Manager 6 hours 12 hours 20 hours ManagerManager 8 hours 16 hours 24 hours Director
Figure 25: Escalation
6.1 Case Escalation / Referral Procedure
When a Supervisor or Counselor click on the Escalated / Follow up, all cases get displayed which have been escalated
The table will showcase the details of all the case, to whom it was escalated and when Depending on the TAT the Status of the case will change its color. Red being that its crossed
the TAT while Blue means it still has time for updates Once the PENDING link is clicked, the case form will open up, for which the counselor or
the concerned authority can update the status or can have an extension on the closure date and time.
The Supervisor can search for a particular case with any search criteria mentioned above in Blue
The headings can be filtered accordingly with the ascending order or descending order Any changes made to the case form will have an audit trail with date and time stamp
47 | P a g e Functional Requirement Document
Sl No
Counselor Name
Case ID Date of call Time of Call
Status of Call
Escalated To Dept
Escalated To Person
TAT Status
1 Elizabeth 9876542 03/08/2016 11:33:00 Escalated Team leader Karen High Priority
5 hrs Pending
2 Susan 2673849 10/08/2016 12:00:10 Escalated Supervisor Adrian High Priority
1 day Pending
3 Kimani 9754207 14/08/2016 14:12:57 Escalated Call Center Manager
Michael Medium Priority
2 days
Pending
4 Brian 1573642 19/08/2016 14:49:00 Escalated Manager Claire Medium Priority
6 hrs Pending
5 Jacky 6254782 23/08/2016 18:03:40 Escalated Supervisor Tabitha Low Priority
2 days
Pending
Figure 26: Case Status
Search & Filter
7 Reporting Module: -
All activities done on the case management system will result into reports which are used by the supervisors, management and others to analyze the trends be proactive and take corrective measures to mitigate situations.
There shall be 2 main line of reports.
A) Case Management Reports B) Call Management Reports
A) Case Management Reports will consists of all the information have been captured through the case form utilized. A broadly classified reports as follows: -
*All of the above will have filter and search option to get the exact data with the proper date range.
48 | P a g e Functional Requirement Document
Sl Nos
Reports Calls Walk-in SMS Web Chat
Web Portal
Case /Field Worker
Other Dept
Social Media
Mobile App
1 Nos of cases Created
2 Nos of cases Closed
3 Nos of cases Pending
4 Nos of cases Escalated
5 Nos of casesRetrieved
6 Nos of cases missed TAT
7 Nos of cases with High Priority
8 Nos of cases with Medium Priority
9 Nos of cases with Low Priority
Figure 27: Case report
B) Call Management Reports will consist of all the information captured through the calls. A broadly classified reports as follows: -
49 | P a g e Functional Requirement Document
Sl Nos Reports Calls Walk-in
SMS Web Chat
Web Portal
Case /Field Worker
Other Dept
Social Media
Mobile App
1 Total Inbound calls
2 Answered calls
3 Missed calls
4 Voice mails
5 Abandon Calls
7 Total Prank Calls
8 Total Blank Calls
Figure 28: Call Management Report
*All of the above will have filter and search option to get the exact data with the proper date range.
50 | P a g e Functional Requirement Document
9 Total Foreign languageCalls
10 Caller Hung up
11 Average Talk time
12 Average Wait time
13 Average Walk-in time
14 Login duration
15 Average Walk-in time
16 Average E-Mail Handling time
17 Average Chat Time
18 Average SMS Handling time
Figure 29: Communication management report
5
6
7Reporting Capabilities
There are two types of reports available to the end user.
Pivot Reports Comprehensive Reports
7.1 Pivot Reports
Wide selection of reports can be extracted .The X-Axis drop down list is matched with the Y-Axis drop down list and date range is also selected, then one clicks the Generate Report tab.
This gives a permeation & combination of the type of reports required and the different data required.
Figure 30: Pivot Report
51 | P a g e Functional Requirement Document
7.2 Comprehensive Reports
These are the main types of reports that have the category reports when you click on them. These include:
Call Reports Case Reports Counsellor Reports Service Reports Performance Reports
The comprehensive reports can be generated in PDF format while the Pivot reports can be generated in both excel and PDF formats. To print comprehensive reports click Export Data tab and click on the PDF icon.
7.3 Reports Automation: -
Reports will be automated to be sent by end of a certain period to the important stake holders
Reports will be sent on a periodic bases like, daily, weekly, fortnightly, monthly and quarterly
Reports needs to be extracted and utilized for analysis purposes. Where needed with graphical representation.
Reports shall be available on the Web which can be available to only authorized personnel which also can be downloaded in the respective formats
*The formats for the reports needs to be provided by the different stakeholders.
52 | P a g e Functional Requirement Document
8 Dashboards: -
Wall Display Visual Dashboard: Summary dashboard to provide rich-graphics representation of real-time status of the Call Center that includes Call and Cases Statistics captured on big screen
Real Time reports of calls coming in and the cases that have been handled shall be displayed as a Wall Board on the screen
Dashboard for Public: This dashboard will provide aggregate data to a publicly-available web interface that can be viewed and consumed by Online communities.
Access right shall be provided a read only and download of the reports to anyone outside the vicinity.
Figure 31: Activity Dashboard
8.1 Resources Presence Status:
This feature will show the supervisor the status of all counsellors and their current status.
Presence Status
This indicates the number of counsellors assigned to the respective queues
Nos of counsellors Logged into the queue Nos of counsellors available
53 | P a g e Functional Requirement Document
Activities Assigned Logged in Available Busy Break / Training
Offline Names
Calls Inbound 10 8 4 3 1 2Calls Outbound
5 4 1 2 1 1
Walk in 3 3 0 3 0 0Online Chat 3 2 1 1 0 1Online form on the website
3 3 1 1 1 0
SMS 1 1 1 0 0 0Social media messenger
2 1 0 1 0 1
Nos of counselors busy on activities Nos of counselors on Break Nos of counselors Offline Names of all the counselors for the assigned queue When the supervisor clicks on each queue, it will pop up the names along with the
duration they have been on that status.
The Supervisor / Admin has the option to assign any new counsellor to the queue, reassign them to another queue or remove them from the assigned queue. (Create, Edit, Remove Users, Accounts, Admin configurations, etc.)
8.2 Counselor Login Page: -
Once the Counselor logs into their system, the login status and dashboard along with Cases and calls/other activities will be displayed for that day.
54 | P a g e Functional Requirement Document
Login Peter
Available BusyIdle
Reports
Login Hours
Dash Board for the day
No of calls Answered
No of calls Missed
No of Outbound calls
Incomplete calls
Avg Talk Time
Avg E-Mail Handling time
Avg Walk in time
Avg Chat Time
Avg Time on Social Media
QC
Figure 32: Counselor Login Status
Once the counselor logs into the page, he/ she will be able to see the stats for the day It will indicate to which queue they have been logged in It will gives a timer as to how long they have been available to take calls, idle time and busy
time Depending on the queue assigned, it will give the stats in Average time for handling the cases It will showcase the call statistics showing how many calls have been Answered, missed calls
and incomplete calls It will indicate the login hours for each counsellor for the day Clicking on each link will provide the details QC scoring for the day, when clicked it will provide all the QA details Clicking the Reports tab, will take him to all the reports against his/her login credentials
Councilor Cases
This will indicate all the status of cases against each communication channel for that particular counsellor.
Counselor can click on any particular tab and all the relevant case details will get displayed.
55 | P a g e Functional Requirement Document
Activities Total Nos of cases
Total cases closed
Total cases Pending
Total cases Escalated
Voice Mail Follow ups
Calls 10 6 3 1 2 0Walk-in 4 1 1 1 0 1SMS 5 3 0 2 0 0Chats 2 2 0 0 0 0Web Portal Login 1 1 0 0 0 0Social Media 2 1 1 0 0 0
Figure 33: Counselor Case Dashboard
8.3 Administrator Dashboard: -
The Administrator is the overall system user. He or she will have access to the entire system and control rights.
Once logged in, the Administrator will be able to view the following content as per the day:
Figure 34: Administrator Dashboard
In addition to the above mentioned features, the Administrator will be able to manage other system features like SIP management, reports and system users.
56 | P a g e Functional Requirement Document
View Agents Status
Assign User Rights
Manage Escalations / Refreeals
Assign User Roles View Case Statistics
Instant Access to other Dashboards
Create User
Edit User Rights
Delete User
8.4 Supervisor Dashboard: -
Once the Supervisor logs into his/her account. Will be able to view the following dashboard logged in for the day
Clicked on the Calls tabs it will display all the consolidated calls for all the counselors
Clicking on Cases will display all the cases created by all the counsellors with various mode of communication
Clicking on QC, will display the option to monitor the calls, QC for the site and QC dashboard
Field workers – it will display all the stats where the case workers/ Field workers have raised a case, updates on escalated cases and the status for other departments
My Queue – will display any cases assigned to the supervisor, any cases he/she is handling etc.
The supervisor will have control on retrieving cases from any assigned person and assigning to a different person for closures
Supervisor will have access for all the reports and can extract the reports as per the requirements along with date frequency
*All of the above will have consolidated stats from the counselor dashboard
57 | P a g e Functional Requirement Document
Calls
Counsellor Status (Idle, Busy, Available)
QC
My Queue
Cases
Dashboard
Figure 35: Supervisor Dashboard
9 Integration: -
Different countries will have different integration requirements. For example Kenya through the DCS requires that the integration be done to the CPIMS. This will mean that the Child helpline system will need to greatly align its Case categories to those used by the CPIMS. Same case will apply to the locations where CPIMS uses locations as per the IEBC. Tanzania has an almost similar requirement in that they require that the Child Helpline System be integrated to the DCIMS which is developed by the UDSM. Uganda’s integration requirement is not fully determined, however they have indicated that the government currently is carrying out an initiative to centralize government systems hence in the future this may be defined into a concrete requirement.
We have noted that at present the Child Helpline Systems and the government systems are disconnected and therefore holistic top-level reporting becomes a tedious exercise for the respective Ministries or government departments.
The following is an indicative workflow and the steps to achieve an integrated case flow between the Child Helpline 116 and the government case management system whether it is DCIMS or CPIMS.
6
9.1 Proposed CPIMS / DCIMS and 116 data flow: -
58 | P a g e Functional Requirement Document
Reporting events register
Calls SMSWeb ChatsSocial Media
Outlets
Child Helpline Database
CPIMS / DCIMS Case Monitoring
Social Welfare Desk – Walk-in
Figure 11 Current Child Line 116 and CPIMS flow
The main details of the flow are as follows:
Cases are currently sent from helpline 116 to the social welfare officers through Calls, SMS and Emails
No standardized methodology of follow-up on cases from the county, sub county and district welfare offices
There are no standard case categories between Child help line 116 and government children departments.
No standardized reporting Difficult to establish the incidences of children receiving support from both helpline 116 and
social workers. Difficult to track children who contacted 116 through individual institutional treatments
plans and interventions
The proposed integration will seek to:
Provide an interface to 116 on case management milestones including interventions and case closure
Provide functionality where helpline can push/pull cases between Child Helpline systems and government case management systems.
Each case shall have a unique case serial number used for tracking the status of that case.
59 | P a g e Functional Requirement Document
10FRD Signoff: -
Functional Requirement Description Signoff
Child Helpline
Project Name: New Child Helpline System Project Consultant: Bitz IT Consulting Ltd
Start Date: December, 2017 Completion Date: February, 2018Project Duration: 3 Months Sponsor: UNICEF
Project Goal: Enhancing and upgrading the Child abuse case management system. Integration features like walk-in, E-mails, Chat, SMS and social media to the system. A sustainable system which will be robust, sustainable and tailor made system which acts like plug-in play with few customizations.Project Deliverables:
Review the existing systems and gathering inputs from all the relevant stakeholders for child help lines
Pull out common features from the 3 specific FRD’s Prepare detailed Functional Requirements Gathering with module by module working
methodology Planning for a future system with all the functionality along with different modes of
communications. Collect all relevant feedback from the stakeholders and create a high level blue print of the
system Prepare functional requirement document (FRD) using system experienced System Architect,
from the blue print. Document the FRD in detailed technical document for developers to use during development
phase Present the final findings with the FRD to all the stake holders for final approval which will
determine the scope of the second phase.
Client Name: UNICEF ESARO Consultants: Bitz IT Consulting LTD
Address: Gigiri, Nairobi - KenyaContact: Sean Blaschke
Address: Nairobi, KenyaContact: James Nganga
60 | P a g e Functional Requirement Document
Email: [email protected] Email: [email protected]
By signing this document, I acknowledge that I have received stated deliverables to the agreed quality levels.
UNICEF ESARO : Contact: Email:
Signature:
Date:
Bitz IT Consulting LtdContact: James NgangaEmail: [email protected]
Signature:
Date: 05/04/2018
Remarks:
61 | P a g e Functional Requirement Document
11APPENDICES
11.1 Appendix 1: Securing Application Services on Public Networks
Information involved in application services passing over public networks will be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification. This would include: The level of confidence each party requires in each other’s claimed identity, e.g. through authentication.
Authorization processes associated with who may approve contents of, issue or sign key transactional documents.
Ensuring that communicating partners are fully informed of their authorizations for provision or use of the service.
Determining and meeting requirements for confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation of contracts, e.g. associated with tendering and contract processes.
The level of trust required in the integrity of key documents. The protection requirements of any confidential information. The confidentiality and integrity of any order transactions, payment information, and
delivery address details and confirmation of receipts. The degree of verification appropriate to verify payment information supplied by a
customer. Selecting the most appropriate settlement form of payment to guard against fraud. The level of protection required to maintain the confidentiality and integrity of order
information. Avoidance of loss or duplication of transaction information. Liability associated with any fraudulent transactions. Insurance requirements.
Control of Operational Software - Acquisition and Development The acquisition and development of operational software will follow these guidelines:
Software will be tested before usage. An audit log of all updates will be documented and tracked on Github. Vendor or partner-supplied software will be maintained at the level supported by the
supplier. Physical or logical access may be given to suppliers exclusively for support purposes,
with tight controls implemented and enforced, and with management approval. Supplier’s activities will be monitored and logged.
Development environment will follow production system patch management practices, requiring a maintenance window, during which all applicable patches may be applied, after testing. The maintenance procedure may be made more frequent, for instance, for a critical security gap or a threat already taking place.
62 | P a g e Functional Requirement Document
Critical patches will be installed as soon as possible. If the patch is critical, and active threats have not yet been witnessed, patch installation can be postponed until the following scheduled maintenance window depending on the business risk.
With the exception of critical vulnerabilities to a threat already in circulation, no patch installation will be completed without testing. In the event of critical vulnerabilities with a threat in circulation, the installation will be completed at once, but a testing procedure will still be completed afterward.
Applications will be developed in a manner that they can be configured to perform with the minimum system authority necessary.
Before a new system goes into production, it will undergo a system approval progression that will include QA review. When applicable (Class I and non-qualified systems) specific security tests such as credentialed and non-credentialed assessments and confirmation and validation of final product security controls against “original” requirements.
Control of Operational Software - Use of Development Tools
Development and system maintenance will only implement administrative tools, compilers, version management software, and so on, from trusted sources (e.g., vendors with which UNICEF has a current relationship). Use of development tools is authorized on systems designated for development / testing only and may not be used on a production system. Tools or utilities attained from untrusted sources will first be validated and proven to be fit and secure before being used for development or production purposes. During this validation phase, systems will be carefully monitored to make sure that no unexpected activity is occurring.
Developmental Testing Information Leakage / Security Vulnerabilities: Information Systems will be tested periodically to identify any potential for accidental or covert information leakage or security vulnerabilities. The following shall be considered to limit the risk of information leakage, e.g. through the use and exploitation of covert channels:
Scanning of outbound media and communications for confidential or hidden information. Masking and modulating system and communications behavior to reduce the likelihood
of a third party being able to deduce information from such behavior. Making use of systems and software that considered to be of high integrity. Regular monitoring of personnel and system activities, where permitted under existing
legislation or regulation and monitoring resource usage in computer systems.
Protection of System Test Data
Test data will not contain any sensitive or classified information, to prevent disclosure to unauthorized developers and testers.
Any production data to be used for testing purposes will be anonymized (sanitized), and it will not be possible to recreate the production data from the anonymized data.
The anonymized data cannot contain any information like keys or pointers that could be used to access the original data.
63 | P a g e Functional Requirement Document
All test data, even though it is scrubbed clean of low-level data, collectively will not reveal any high-level information or hints about high-level information.
Even though sanitized test data is not supposed to give an intruder any hints about the production data, it will still be safeguarded and handled. ICTD/STANDARD/2018/007 P a g e 6 of 9
The test data used for each test will be tracked in the repository and be referenced in the issue tracking system.
Change Management Any changes to … systems or software will be agreed upon between … key stakeholders / … owner of the concerned system and, if applicable, any third parties involved. Before changes can be made, the following steps will be followed:
The ICT operations, or organizational unit with intent to implement any change, will describe the change and the anticipated scenario, supported by the applicable documentation.
The implications for security (in terms of confidentiality, integrity, and availability) will be evaluated using a preliminary impact analysis.
The change will be tested before being applied. After changes are made, a technical review will be conducted to determine if new risks
have been introduced by the change or existing risks factors have been altered. In emergency situations, this procedure can be overridden and documentation provided
retrospectively.
System Review and Acceptance All proposals for new systems will include a security plan that describes how the system satisfies the security requirements provided in this document and any other applicable security standard definitions.
Electronic Messaging Information involved in electronic messaging will be appropriately protected. Security considerations for electronic messaging shall include the following:
Protecting messages from unauthorized access, modification or denial of service. Ensuring correct addressing and transportation of the message. General reliability and availability of the service. Legal considerations, for example requirements for electronic signatures. Obtaining approval prior to using external public services such as instant messaging or
file sharing. Stronger levels of authentication controlling access from publicly accessible networks.
64 | P a g e Functional Requirement Document