Client Communication Request

UNFPA
Client Communication System
Application

Business
Requirement
Document

Page Created by:

 Client Communication Request

Table of Contents
1 Executive
Summary..................................................................................
............................................. 4
2 Ownership and
Version....................................................................................
..................................... 5
2.1 Document Ownership
.............................................................................................
...................... 5
2.2 Review & Version
Control ...................................................................................
.......................... 5
3 Overview and
Objective.................................................................................
....................................... 6
4 Background
...............................................................................................
............................................ 7
4.1 About UNFPA
.............................................................................................
................................... 7
4.2 About AccessRH
.............................................................................................
............................... 7
4.3 Business Justification
.............................................................................................
....................... 7
4.4 Product Scope
.............................................................................................
.................................. 7
4.5 Process Stakeholders
.............................................................................................
....................... 8
4.6 Resources and References
.............................................................................................
............... 8

Page Created by:

 Client Communication Request
4.7 Definitions and
Acronyms...............................................................................
.............................. 9
5 Assumptions, Dependencies and
Constraints................................................................................
.....11
5.1 Existing Software and Standards
.............................................................................................
...11
5.2 Existing ITC
Infrastructure...........................................................................
................................11
5.3 Existing communication between UNFPA PSB and the
client (Third Party Client, Country Office and the Vendor)
.............................................................................................
......................................... 12
6 Proposed System Overview
...............................................................................................
................. 13
6.2 Architecture
Description.............................................................................
................................13
7 Functional Business
Requirements ...........................................................................
.......................... 15
7.1 General Requirements
.............................................................................................
................... 15
7.2 User Interface
.............................................................................................
................................19
7.3 Feature Functionalities
.............................................................................................
..................22
8 Non-Functional
Requirements...........................................................................
................................. 26
8.1 Modular Software
.............................................................................................
..........................26

Page Created by:

 Client Communication Request
8.2 Data Access Layer Library
.............................................................................................
.............. 26
8.3 Graphic User Interface
.............................................................................................
................... 26
8.4
Reporting...............................................................................
...................................................... 26
8.5 Security and Integrity Controls
.............................................................................................
...... 27
8.6 Access/Availability
.............................................................................................
......................... 27
8.7 User Documentation, Training and
Configuration...................................................................... 28
8.8 Software Quality
.............................................................................................
............................28

Page Created by:

 Client Communication Request

8.9 Project
Documentation........................................................................
....................................... 28
Appendix A: Existing high level Procurement Business Process
and Data Flow ................................. 29

Page Created by:

 Client Communication Request

1 Executive Summary
Client Communication System forms an integral part of UNFPA’s
procurement cycle to ensure that its
Clients either Country Office or Third Party Customers (AccessRH
Clients) are kept well informed on the
status of an order from when the customer requests a quotation to
when the order is delivered at port
of
destinatio
n.
Currently, when a client wishes to contact UNFPA regarding an
order and request information, such request is done via email
exchange or telephone. The email and telephone communications
received from clients about an order are archived in SuperOffice
from a UNFPA PSB perspective. For the client (i.e. Country Office
and Third Party Client) they do not have a source where all
communications are stored apart from email system. The same
applies to communications with the Vendor.
Country Offices, AccessRH Third Party Clients and UNFPA Vendors
currently make use of telephones and email systems to exchange
communicate with PSB.
The above method of communication has led to a number of
challenges as highlighted in section 4.3 page 7 (Business
Justification) of this document.
In order to resolve the highlighted challenges and bring about
a more effective way to manage communication across
UNFPA’s Clients, a java web application called “Client
Communication Request System” will need to be developed and
integrated with three other applications (Request For Quotation
application, Pro Forma Storage and Management and Order
Tracking application). These applications will eventually be
integrated with the current myAccessRH.org website.
The Client Communication Request System will be used by the
client (i.e. Third Party Client and Country Offices) to communicate
with PSB about their order at any stage from submitting the
request for quotation to receipt of their order at the port of
destination. It can be thought of as a ticketing system which allows
for general back and forth communications, as well as questions
and answers. Importantly, it will archive all communications for later
retrieval.

Page Created by:

 Client Communication Request

2 Ownership and Version

2.1 Document Ownership

This document is owned and will be endorsed by UNFPA
AccessRH IT Team (Copenhagen) for the
development of Client Communication Request System Java web
Application which will eventually be
used by Country Offices, Third Party Clients, PSB and PSB Vendors.

2.2 Review & Version Control

Version # Date Modified by Signed off by Description of
Modification

V1.0. Ehime Enahoro IT Team 1st Draft

V2.0. Ehime Enahoro IT

PSBTeam and
Team 2
nd
Draft
Lead

V3.0. Ehime Enahoro IT Team, Lead

Team PSB 3
rd
Draft
and Campbell
Bright

V4.0. Ehime Enahoro IT Team, Lead

Team PSB Final Sign Off
and Campbell
Bright

Initial document sign-off by the document owners will result in

version 1.0. Future sign-off will always
be whole numbers (version 2.0, 3.0, etc.). Any significant
process changes will result in a change of
version number as well. For example, should a new sub-process
be added after initial sign-off, this
would result in draft version 1.1. Once this change is signed off
by the document owner, the document
shall become version 2.0.

Page Created by:

 Client Communication Request

3 Overview and Objective

The purpose of this document is to provide detailed requirements
from which design proposals can be
developed. It contains details of requirements in the following
areas:

High level business requirements

Functional requirements
Nonfunctional requirements

Throughout the document individual paragraphs have been

categorized as follows:

M Paragraphs marked "M" in the margin represent mandatory

requirements which must be met by
D Paragraphs marked "D" in the margin represent desirable
requirements which should be met by

Page Created by:

 Client Communication Request

4 Background

4.1 About UNFPA

For the sake of brevity, information about UNFPA is not
reproduced here. Details can be found on the
corporate website, www.unfpa.org.

4.2 About AccessRH

For the sake of brevity, information about AccessRH is not
reproduced here. Details can be found in the
project management documents found on the Copenhagen
corporate intranet at M:\Procurement\26.
Access RH\0. Project products\ARH M. Management products\3.
Products\.

4.3 Business Justification

Based on the scenario highlighted within the executive
summary, the current methods applied by
UNFPA to enable clients communicate with PSB has
brought about a few challenges such as:

1. Inadequate data security on the client side

2. Duplication of work
3. Time wasted sifting through emails to capture the right
correspondence about an order
4. Missing data issues due to possible email deletions
5. Inadequate audit trail on communications regarding an order
6. Lack of systems in place to store information from a client’s
perspective hence communication
data retrieval is often slow as the client would have to search
through various email exchanges
to arrive at the required information etc.

4.4 Product Scope

4.4.1 Scope Includes
- The development of technical documents such as the
Business Requirement Document,
development of System Design Document, Test Case
Documents, Test Case Execution Document
and any other document which will enable the development,
testing and deployment of the
Client Communication Request Application.
- This product will involve the actual development of
the Client Communication Request
Application developed in JAVA.
Page Created by:
 Client Communication Request
- The application will be developed as a Web application with
its own URL
- The product will be developed together with S.438 (Pro-
forma Storage and Management), S.440
(Client Order Tracking Application) and S.448 (Request for
Quotation Module).
- It will involve the integration of the Client
Communication Request Application and the
myAccessRH.org Website.
- It will involve product testing and deployment to the business
- It will also involve change management associated with
deploying the product to the business.

Page Created by:

 Client Communication Request

4.4.2 Scope Excludes

- Changes to User authentication, as this will be managed
by the web portal software LifeRay.
- Changes to existing Database Schemas.

4.5 Process Stakeholders

The stakeholders that are involved in this application include:
AccessRH IT Team: Primarily responsible is to facilitate the entire
process involved in the development of the application to the
specifications outlined in this document and also provide
product review throughout the development process.
PSB Procurement Staff: They will form as informants, reviewers
and testers throughout the requirement gathering stage and
the software development cycle. Hence will be involved in
functionality related decisions.
UNFPA MIS (New York): Responsible for managing the servers upon
which the application will be hosted. Will also provide support
with application deployment, interfacing to other systems, and
ongoing system administration.
Recruited Software Development Consultant: This consultant will hand the
actual software development work to ensure that the product
is build and integrated to meet user expectations.
Third Party Customers: The third Party Client will fall into five
categories which are MOH, NGO, UNDP, Other UN agencies
and they are considered the main users of this application
hence will contribute towards requirement gathering.
Country Office: All UNFPA Country Offices will be considered users
of this application hence will contribute towards requirement
gathering.

4.6 Resources and References

4.6.1 References
The reference documents below were used to prepare this
requirement document and may be used as a
reference point to ensure the desired products (i.e. Client
Communication Application) is well developed
to expectation.

Title Author Date Comments Areas

affected
ARH.S. 448 Ehime Enahoro September
Request for 2011
Quotation
ARH.S. 444 Ehime Enahoro February 2012
Customer
Service
Standardisation
ARH.S. 427 Atif Ashaq August 2011
Website –
How to Order
ARH.S. 439 Kevin Mayer December
Pro-Forma 2011

Page Created by:

 Client Communication Request

Invoice
Management
Product
Description.
ARH.S. 440 Atif an Kev December 2011
Tracking Mayer
Product
Description.

4.7 Definitions and Acronyms

The following terms and acronyms are used throughout this
document.

DMS Division of Management Services (to which PSB belongs)

PSB Procurement Services Branch (of the United Nations
UNFPA RH Population Fund)
United Nations Population Fund
Reproductive Health Order
OTS Tracking System AccessRH
Request For Proposal
ARH RFP Request For Quotation
Application Programming Interface
RFQ API UNFPA’s ERP Systems called PeopleSoft
(UNFPA) Country Office
ATLAS CO
Database
Ministry of Health
DB MOH
Non Governmental Organisation
NGO RT Regional Team

Graphical User Interface

GUI Lightweight Directory Access Protocol
LDAP
Data Access Layer
DAL
Order Tracking System
OTS

Page Created by:

 Client Communication Request
SO SuperOffice
Request For Quotation
RFQ

Page Created by:

 Client Communication Request

5 Assumptions, Dependencies and Constraints

5.1 Existing Software and Standards

UNFPA’s MIS has a number of standard environments which
should be used for custom developed
software.

5.1.1 Operating Systems

- Preferred: Linux Ubuntu (RedHat)
- Supported: Solaris 10
- Supported: Windows 2008 R2

5.1.2 Databases
- Preferred: MySQL
- Highly supported: Informix
- Supported: Oracle

5.1.3 Application Environments

- Latest stable versions used as required.
- WWW Server: Apache
- Application Server: Tomcat (via Apache JServ Protocol)

5.1.4 Application Development

- Java (JDK6) with struts framework
- Front end / web GUI: JQuery
- Object Relational Modeling: Hibernate
- Authentication & Identity Management: LDAP / SSO

5.1.5 Development Tools:

- Version Control: Subversion
- IDE: Netbeans

5.1.6 Portal Software

- Liferay Version 6

5.1.7 Other Applications

UNFPA is heavily reliant on a number of software packages.
Custom developed software should not
replicate functionality which can be accomplished within the
existing packages. Any custom developed
software should, if possible, interface with existing software in
order to minimize replication of work
required by users. Existing applications include:

- Atlas (PeopleSoft 8.9): The ERP used by UNFPA

- SuperOffice: CRM tool used by UNFPA for document
management

5.2 Existing ITC Infrastructure

Page Created by:

 Client Communication Request
As this project falls within Procurement Services Branch, the
application shall fit within and utilise
existing UNFPA ITC resources where possible. It should be hosted
within UNFPAs server environment in
New York which is a virtualised environment running on clustered
physical servers. Management and

Page Created by:

 Client Communication Request

system administration of the servers is handled by the MIS staff

in New York, and application level
management shall be handled by PSB staff in Copenhagen.

5.3 Existing communication between UNFPA PSB and the client (Third Party Client,
Country Office and the Vendor)
Currently PSB clients (Country Office, Third Party Client and PSB
Vendor) communicate with UNFPA via
telephone and email when making enquiry about an order.
When PSB receives or sends a
communication, the PSB buyer uploads / archives these
communications via outlook to SuperOffice,
where such communication is stored against a project name for
future reference. This mechanism is
only available for the PSB buyers hence this has led a number of
issues as highlighted within section 4.3
page 7 (Business Justification) of this document.

Page Created by:

 Client Communication Request

6 Proposed System Overview

6.1 Proposed Architecture

Oracle Database Informix Database

Schema Schema

ATLAS - PeopleSoft Application

Client Communication System – Java
Application

Email
Management MyS
QL
System (MS Datab
ase
Outlook etc)

6.2 Architecture Description

The Client Communication System will utilize both Informix
DBase and MySQL database (i.e.
database also utilized by other applications such as RFQ, Pro
Forma Invoice application, Client Order
Tracking Application) in order to ensure that data can be entered
and stored as well as displayed on
all required screens. Within the infrastructure, the Informix
database is a read only database while
MySQL database will enable the application to both read and
write to the database. To ensure this,
the current Informix and MySQL Database will be updated /
modified to accommodate the Client
Communication Request
Application.
Alternatively and also recommended, the Oracle database
currently utilized by Atlas may be used in place of the MySQL
database highlighted above. Though both databases (i.e.
Oracle and My SQL may be considered similar in many affects,
MySQL has a better data storage concept). The use of exiting
Oracle database may be preferred putting in context:
1. Licensing implications

Page Created by:

 Client Communication Request
2. The need to have a standardized IT Infrastructure
hence helping to avoid silo
databases within the Infrastructure.
3. Database Security (Database authentication and
Privileges)
4. Schema Migration

Page Created by:

 Client Communication Request

6.3 Expected Business Benefits

After the successful implementation and testing of Client
Communication System Application which will
be integrated to the AccessRH.org website, the following
would be considered expected business
benefits:

1. Improved data security on the client side

2. Eliminates duplication of work on the clients side
3. Eliminates issues of missing data issues due to possible
email deletions
4. Ensures adequate audit trail on communications regarding an
order
5. Time wasted sifting through emails to capture the right
correspondence about an order
6. Ensures a well structured mechanism in place to store
information from a client’s perspective
hence improving communication data retrieval.
7. Provides effective management of communication across
all user groups (PSB, Third Party
Clients, UNFPA Vendor and Country Office).
8. The right email goes to the right staff during the
procurement cycle providing accountability and
responsibility.

Page Created by:

 Client Communication Request

7 Functional Business Requirements

7.1 General Requirements

7.1.1 System
Requirement Requirement M/D
No: s
1. The Client Communication Application will be M
developed as a Java based rich
web application functional only from within the
MyAccessRH.org website. i.e.
2. The application will also be integrated with M
other applications such as the
Client Order Tracking Application, Pro-forma
Storage and Management
3. The application will utilize both Informix and M
MySQL database associated with
the myaccessRH.org website. (Please note that
4. The Client Communication application will M
provide required data real Time
online such that data sent or received will
reflect immediately and will be
5. User authentication and management will be M
handled by the Liferay platform
6. When a communication / message are sent for D
the first time by the client, the
application will generate a Ticket Number which
will help identify and tie all
communications / messages of the
same thread together.
For example when a client initiates the first
communication / message about an order at the
RFQ stage, a unique Ticket Number is generated,
on the back end the Ticket Number will be tied to
/ associated with the RFQ number. Also, should
the client send a message at the Pro Forma
Invoice Stage, the Pro forma Invoice Number
will tie into the RFQ number hence both the Pro
Forma Invoice Number and the RFQ Number
will link to the Ticket Number (which will be the
number visible to the users hence the Ticket
7. Each Client question / message should be ‘tagged M
/ related’ to a Unique Ticket
Number which will be associated to related
Requisition Numbers, Request For
Quotation Numbers, Pro Forma Invoice Numbers,
Purchase Order Numbers,
Purchase Order Line Numbers or Schedule Line
8. When the user receives a message / M
communication, it should automatically
assign such email to its associated reference
number i.e. Requisition Number,

Page Created by:

 Client Communication Request

Please note that:

One ‘Request For Quote Number’ may give rise
to more than one
‘Pro-Forma Invoice Number’.
One ‘Pro-forma Invoice Number’ may give rise
to more than one
‘Purchase Order Number’.
One ‘Purchase Order Number’ may give rise to
more than one
9. User (CO, Vendors or Third Party Client) should be M
able to ask questions of PSB
at any point during and throughout the procurement
life cycle about an order,
10. The application developed in Java will be M
to enable communication exchange between
application and MS Outlook conveniently (this is
very vital) to ensure limited
impact to the way PSB buyer manages their
11. The application will be developed to enable the M
storage of messages and
12. The User should be able to view all previous M
messages sent and received, and
13. The Client Communication Request application will M
enable the user to keep
track of all communications (both inbound and
outbound communications /
messages requests) associated with any single order
14. The application will enable the Client to send and M
receive communications
from ‘Request For Quotation’ / When a Requisition
is raised stage to when the
15. The application will allow simultaneous access by M
multiple users (i.e. with the
capacity to withstand approximately 200 users
16. The application accessi vi use authentica usin an M
authentication
17. mechanism.
The application will pass all tests cases approved by M
mandatory user requirements as laid out in
document.
18. The functionality to update ‘User Profile’ shall M
be accessible via the ‘My
Account’ Page. i.e. a single update to the ‘User
Profile’ within ‘My Account’
shall update all ‘User Profile’ associated with the
Order Management System
19. The application will be developed to M
accommodate future upgrades and

Page 16 Created by: Ehime

Enahoro
 Client Communication Request

customization should the need arise.

20. The application shall run on Apache Tomcat 6. M
21. The application shall utilize JavaServer Faces 2. M
22. The User Interface will be integrated with the M
myAccessRH.org website and
23. The product will capture phone calls and M
communication done outside of this
system (separate emails, faxes, etc.). This will
ensure that, for a specific
customer order, a complete history of all types
of communication will be
24. The application will have the ability to maintain M
25. contact
The lists.
application should have a simple way to M
forward as an email to another

7.1.2 User Group

User authentication and management takes place outside of this
application. However, the application
will have access to information regarding the group the user falls
into. In other words, the username and
user group of the currently logged in user shall be available via a
third party API call.

Requirement Requirements M/D

No:
26. The application shall be developed with the following M
user groups in mind:
Group 1 - Third Party Clients
This group will have the ability to create,
send, receive and view
messages.
This user group will have the capacity to send
messages to PSB and receive messages /
communications from PSB (i.e. from PSB
Outlook email system), Country Office and
the Vendor.

Group 2 – PSB
This group will have the ability to create,
send, receive and view
messages.
But will have the capacity to also receive
and send responses back to the
corresponding user using Outlook. Hence
ensuring the PSB user maintains a single
source for communication though also
having access to the Client Communication
Request Application.

Group 3 - Country Office

This group will have the ability to create,
send, receive and view
messages.
Page Created by:
Client Communication Request
Country Office via the application will have
the capacity to send

Page Created by:

 Client Communication Request

Third Party Client and PSB messages /

communications and receive messages /
communications from the Vendor.

Group 4 - UNFPA Vendors

This group will have the ability to create, send,
receive and view
messages.

The Vendor will have the capacity to send and

receive messages /
communications to and from PSB,

Send to Country Offices and Third Party Client.

7.1.3 System Configuration Setting

The User Interface page and the downloadable files contain a large
amount of information. Depending
on which type of user group are logged in, different fields should
be displayed hence the administrator
should have the capacity to configure which data fields should be
displayed for each user group.

Requirement Requirements M/D

No:
27. The system administrator shall be able to specify M
(via a configuration file or
otherwise) which fields / information are displayed
28. The application Interface will consist of data fields M
specified by the business.

7.1.4 Data Access Layer Library

The data access layer of the application to be used will be the
existing DAL currently in use by other
product catalogue application which is integrated to the
myAccessRH.org website. The DAL will be a
reusable Java library such that other future applications to use the
products database may utilise this
library. The library shall provide complete, read only access to
the database in an object/relational
model type system.

Requirement Requirements M/D

No:
29. The data access layer of the application shall be M
provided in a self contained Java

Page Created by:

 Client Communication Request
30. The data access layer of the application shall provide M
a pluggable API which can
31. The API of the data access layer of the application M
shall be documented fully

Page Created by:

 Client Communication Request

7.2 User Interface

7.2.1 All Pages

Requirement Requirements M/D
No:
32. The application will possess active menu and user M
33. friendly navigation.
Within all pages in the application, with a single M
mouse click, the user shall be
Access the ‘Help’ functionality (please refer
34. 6.2.4and
The look ‘help’ section)
feel of the User interface will be in M
line with myAccessRH.org

7.2.2 Home Pages

Requirement Requirement M/D
No: s
35. When the User logs into myAccessRH.org M
authentication mechanism, the application should
determine access privilege
levels for the various user groups as
mentioned in 6.1.2 No 1 to ensure
36. When the user logs into the myAccessRH.org M
portal, the User Interface will be
accessible via a click of the ‘My Account’ tab (These
module will be managed
and made possible by the Website User
37. The application will list / sort all messages based M
on dates as a defaults. The user
- By Client Name (Message Sender).
- By Ticket Number (Automatically generated
when a message is first
initiated by the client).
- By Reference Numbers (eg. Request For
Quote Number, Pro forma
Invoice Number, Purchase Order Number and
38. Purchase Order
The application Linegive the user (PSB) the
will also M
ability to assign Status to a
39. The application will enable the User (in this case M
CO, Third Party Client and
Vendor) to view the status (Open or Closed) of the
40. Once the User clicks the ‘Message’ button, the M
specified by the business will be displayed on the
User Interface (UI) based on
the User Group Profile.
Data fields:

Page Created by:

 Client Communication Request

Group 1 - Third Party Clients

Group 2 – PSB Buyer and Team Leads
Group 3 - Country Office
Group 4 - UNFPA Vendors
Group 5 - Administrator

7.2.3 Message Pages

Requirement Requirement M/D
No: s
41.a All User Interface irrespective of User Groups M
will have the following defaults
fields names on the message page:
From: This will be a static text representing the
41.b To: This will be an input text representing the M
recipients email address. (i.e.
41.c Date: This will represent the date the message M
was received by using the
41.d Time: This will be a static text and will represent the M
actual time the message
41.e Subject: This will be an Input text representing the M
41.f Telephone:
subject line.
The sender’s contact number. The M
contact number will be the
number as it appears in SuperOffice. Where none
exist within the SuperOffice,
41.g Message Content: the application will have a content M
body consisting of a
specified MIME (Multimedia Internet Mail Extensions)
type and a block of storage
41.h Priority: This will be the priority level with which a M
message is delivered. The
application will have a forced response
functionality:
- High Importance
41.i Ticket Number: The Ticket Number is the number
associated with a message thread i.e. The Ticket M
Number will be the number which uniquely
binds all
associated messages and their reference numbers
(Request for Quote Number, Pro forma Invoice
Number, Purchase Order Number, Purchase
Order Line Number or Schedule Line) together.

42. The application will enable the sender to create a M

new message as and when
43. All new message sent or received at any point M
in time will stack above the
previous messages within the Inbox in a queue.
44. The application will have a drop down M
button consisting of message
functionalities such as:

Page Created by:

 Client Communication Request

- Mark
- Mark All
- Unmark
- Mark as read
- Mark as Unread
- ‘Forward’ to contact (should display pop up
messages to enter email
45. The application will be able to tag each message M
sent or received to an
associated Requisition Number, Request for Quote
Number, Pro-Forma Invoice
Number, Purchase Order Number, Purchase Order line
Please Note:
One Request For Quote Number may give rise to
more than one Pro-
former Invoice Number.
One Pro-former Invoice Number may give rise to
more than one
Purchase Order Number.
One Purchase Order Number may give rise to
more than one PO Line
46. The application will have a hyperlink functionality to D
enable the download of
Number, Pro-Forma Invoice Number and
functionality will be associated with Order Tracking
Application).
Please note that this functionality will no longer exist
if the Ticket Number as a superset is.

47. Request for Quotation: A click will enable the M

download of the confirmed
‘Request For Quotation’ Document. This will be
accessible by the Third Party
Please note that this functionality will no longer exist
if the Ticket Number as a superset is.

48. Pro-Forma Invoice Number: A click will enable the M

download of the Confirmed
Pro-Forma Invoice document. This will be accessible
by the Third Party Client,
Please note that this functionality will no longer exist
if the Ticket Number as a superset is.

49. Purchase Order Number: A click will enable the down M

load of the PO document
which the PSB Buyer has used in placing an order
with the Vendor. This will only
Please note that this functionality will no longer exist
if the Ticket Number as a superset is.

50. The application will have a ‘Reset’ button which M

will be used to reset the new

Page 21 Created by: Ehime

Enahoro
 Client Communication Request

message page to enable the user re enter required

information on the User
51. Delete: Message deletion will not be supported M
for all users except for the
52. Search functionality: The application will give the M
user the capacity to search

7.2.4 Help Pages

Requirement Requirements M/D
No:
53. Each of the Client Communication Request M
Application pages will have the
54. It should have a ‘HELP’ button which once basi M
information on how to use the Client
55. Communication
Within Request
the ‘HELP’ page, theapplication.
user should have access to M
static text which tells the
user how to use the Client Communication Request
Application. It should also

7.3 Feature Functionalities

7.3.1 Message Notification/ Alert Functionality
Requirement Requirement M/D
No: s
56. A message tab should highlight green on the Users M
side (Group 1, 3 and 4) when
a new message is received successfully on the PSB
Interface. This will indicate to
57. When the User (Group 1, 3 and 4) of the M
application receives a new message, an
email alert should be sent to the User’s specified
58. New messages sent from the application or M
received by the application should
59. The Tab called ‘Message’ (Message Module) within ‘My M
Account’, should display
60. The application will send a notification to the PSB M
buyer via Outlook email if PSB

Page Created by:

 Client Communication Request

7.3.2 Message Delivery Functionality

Requirement Requirements M/D
No:
61. The application should be provided with dynamic M
capabilities such that each
time a new user is added to the system, he or she will
start to receive as soon as
possible the appropriate messages i.e. In general if
the UNFPA buyer sends out a
the new user should still receive the message
application and also via email notifications.

This requirement will hold only if a generic email

contact is not used for an entire clients’
organization (i.e. a single email contact used by
all with the business)

62. The application will be such that when the User M

sends a message from the
application to a recipient (i.e. PSB User), the
message will be received on the
recipients (i.e. PSB User) side of the client
communication application and also in
full message via Outlook and in return if the
recipient (i.e. PSB User) sends a

7.3.3 Message Threading Functionality

Requirement Requirements M/D
No:
63. The application should be developed to model simple M
message threading
functionality. This means chains / history of messages
that are replies to each
other. For example, If message ‘B’ is a reply to some
other message called
message ‘A’, then message ‘B’ should be able to

7.3.4 Message Follow Up Functionality

Requirement Requirement M/D
No: s
64. The application should enable the sender of a M
message setup a follow up /
reminder functionality such that when the sender

Page Created by:

 Client Communication Request

7.3.5 Internal Note Functionality

Requirement Requirements M/D
No:
65. The application should give the user the ability to M
write internal notes to the
message for self or staff use. Please refer to 6.1.1

7.3.6 Draft Functionality

Requirement Requirements M/D
No:
66. The application should enable the user to have M
message draft functionality such
that messages / communications can be saved as
draft copy when a user creates
67. The application must be able to store only one M
version of the draft message.

7.3.7 Document Attachment Functionality

Requirement Requirements M/D
No:
68. The application will have the capacity to upload and M
attach files (Word, Excel,
PDF and Picture formats) to any message. Each
attachment can only be attached

7.3.8 Auto – Acknowledgment Functionality

Requirement Requirements M/D
No:
69. The application should enable the user to generate M
auto – acknowledgement
messages. This is to let the User know that their

7.3.9 Load Balance Functionality

Requirement Requirement M/D
No: s
70. The application will enable load balancing based on M
set criteria such as:
1. Amount of unanswered requests
2. Amount of unclosed Communications etc
I.e. the application should be such that when the
PSB buyer’s message box contains unread
messages relating to orders of up to 10 (or
predetermined by the Team Lead or
administrator), the application should
automatically pass subsequent messages to an
assigned contact specified by the Team Lead or

Page Created by:

 Client Communication Request

administrator.
71. Irrespective of the amount of messages received the M
application should also give
the user the ability to assign the communication /

7.3.10 Intelligent Messaging Assignment Functionality

Requirement Requirements M/D
No:
72. The application will have intelligent messaging M
assignment functionality to
ensure that each message received by PSB is
correctly routed to the associated
country region PSB buyers for example if a message
/ communication is received

7.3.11 SLA and Escalation Functionality

Requirement Requirement M/D
No: s
73. The applications should have the capacity to set M
SLA on time and day at which to

Page Created by:

 Client Communication Request

8 Non-Functional Requirements
8.1 Modular Software
Requirement Requirements M/D
No:
74. The application shall utilize the Modular-View- M
Controller (MVC) model (View,

8.2 Data Access Layer Library

Requirement Requirements M/D
No:
75. For the sake of brevity and to avoid duplication of M
data across applications to be
built and integrated with the myAccessRH.org

8.3 Graphic User Interface

Requirement Requirements M/D
No:
76. The application shall utilize a pluggable language M
pack system to allow for
77. A default English language pack for the User Interface M
78. shall
All be provided
styling in the UI shall be done through CSS IDs M
and classes, with style
definitions stored in files separate to the HTML

8.4 Reporting
The reporting functionality will enable the user to generate
report which will ensure performance
management associated with client communications with AccessRH.

Requirements M/D
Requirement
No:
79. The application should be able to run a report M
which will indicate when each
communication request from Third Party
Customer, Country Office, UNFPA
Vendors was responded to by the PSB user. This
80. The application should be able to generate a D
report to enable the user to
81. It should generate a report to determine the M
average time for PSB Team to
82. The application will enable the generation of M
report to indicate how many

Page Created by:

 Client Communication Request

etc about an order with PSB i.e. overall total by

83. order,
The by Buyer and
application by Team.
should enable the generation of a M
report to show how many
84. The application will enable the generation of reports D
to indicate total number of
replies made to PSB clients (i.e. Country Office,
85. It will generate the percentage of all replies that D
were sent inside the chosen
service level (i.e. 2 days) which is associated with
86. It will generate the number of days replies that were D
sent within the chosen SLA.
Time will be measured from when the original
87. The application should send a report to the user if M
communication sent by the

8.5 Security and Integrity Controls

Requirement Requirements M/D
No:
88. The application will have a control user access level M
based on the user group e.g.
Message comes in about an order, it should ID the
89. Security is one of the most important features of the M
Client Communication
System. All email expectation over a network by the
application must be
encrypted. Since access from outside the UNFPA

8.6 Access/Availability
Requirement Requirement M/D
No: s
90. The Application must be available at all times to its M
users. All messages sent or
received via the application must eventually be
stored in the associated
database. Users expect and should receive software
91. The application should be executable / accessible M
from at least the following
- Internet explorer
- Monzilla Firefox
- Google Chrome
- Safari
92. The application shall be accessible via the M
1. Windows 2000
2. Windows XP

Page Created by:

 Client Communication Request

3. Windows Vista
4. Windows 7
MacOS X and higher
93. Application should be accessible via mobile devices M
such as Ipads, Laptops and

8.7 User Documentation, Training and Configuration

Requirement Requirements M/D
No:
94. The application shall contain a downloadable PDF M
document within the ‘HELP’
95. All application an privile sha b configur b th Lifer M
administrator
user.

8.8 Software Quality

Requirement Requirements M/D
No:
96. The GUI of the application shall apply the same M
screen resolution as the other

8.9 Project Documentation

Requirement Requirement M/D
No: s
97. All project documentation related to this project M
will be stored on PSB M drive

Page Created by:

 Client Communication Request

Appendix A: Existing high level Procurement Business Process and

Data Flow

C: Regular
email
communica
tion
exchange. UNFPA PSB
Communications 3: RFQ: Quotation
Request
* All communications
AccessRH (email and telephone
Website
http:// * Receive quote from
www.myacces currently archived in
srh.org
Websi AccessRH Client.
te. Super Office.
* Get quote from
Supplier if order is not
available in Inventory.

1: RFQ Down 2: Downloaded

load RFQ form
request

3: Completed RFQ Form via email

5: Approved Pro-forma
6:
I n vo i c e
Acces
sRH
Client Signed confirmed C: Regular
s Pro-forma Invoic email
communica
e tion
exchange.
7: Payment to
UNFPA
UNFPA 4: Get PSB
Quote
from vendor
Inventory
for order
placed
(Order,
Frieght,
special
printing)

9: Email

notification for
order shipped and Legend
shipping documents
Legend
SymSubtitle
Co Descri
bol unt Acce
ption
10: Order Shipped ssR
1 H
Clie
UNFPA PSB Vendor / nt
Pre-qualified Supplier 1 Invent

1 ory
Suppli

Figure 01: Story Board for exiting Third Party Procurement Model.

Page Created by: