Al-Borj_QA_FDD_v0.02

Functional Design Document (FDD)
Version 0.02
May 19, 2014
Quality Assurance Enhancements
Al-Borj

Al-Borj
Al-Borj_QA_FDD_v0.02
Document Revision History
Version # Author/Editor Date Notes/Changes
0.02 Chris Pittman 23/4/2014 Initial draft based on design meeting
Note: Version numbers less than 1.0 denote drafts while version numbers of 1.0 and higher denote final
documents and subsequent revisions to them.

Al-Borj
Functional Design Document - Client Acceptance
Client: Wissam El-Khatib
Project: Quality Assurance Enhancement
Prepared By: Chris Pittman, Business Analyst
Date: 01 May 2014
The enclosed document presented for acceptance is the Functional Design Document v0.01.
An electronic copy of the FDD document for the Al-Borj TRIRIGA implementation is provided. Please print,
sign, and date two copies. Please retain one copy of the signed document for Al-Borj records and return the
other signed copy to the Business Analyst.
Al-Borj must accept this document prior to moving onto the Configuration phase of the Al-Borj
implementation.
Accepted by: ______________________________________Date:__________________________
Rejected by: ______________________________________Date:__________________________
Reason for Rejection:
Comments:

Al-Borj
TABLE OF CONTENTS
1 Introduction .................................................................................1
1.1 Purpose ...............................................................................................................1
1.2 Audience .............................................................................................................1
1.3 Additional References/Resources................................................................................1
1.4 Glossary of Project Terms.........................................................................................1
1.5 Project Team ........................................................................................................1
1.6 Project Assumptions ...............................................................................................2
1.6.1 Dependencies.............................................................................................2
1.6.2 General ....................................................................................................2
1.7 Project Responsibilities............................................................................................2
2 Outstanding Items & Decision Log .......................................................3
3 Overview of Changes.......................................................................4
3.1 Background ..........................................................................................................4
4 High Level Business Requirements ......................................................5
4.1 Scope..................................................................................................................5
4.1.1 Tasks .......................................................................................................5
4.1.2 Classification..............................................................................................5
4.1.3 Portals......................................................................................................5
4.1.4 Reports.....................................................................................................5
4.1.5 Notifications ..............................................................................................5
4.1.6 Security ....................................................................................................5
4.2 Business Requirements Traceability Matrix....................................................................6
5 Process Requirements .....................................................................7
5.1 Quality Assurance Enhancement: Overview ...................................................................8
5.1.1 Overview ..................................................................................................9
6 Functional Design Requirements ...................................................... 12
6.1 General ............................................................................................................. 12
6.2 Roles ................................................................................................................ 12
6.3 Work Order Form ................................................................................................. 13
6.3.1 QA Tab (NEW)........................................................................................... 13
6.4 QA Rating Class Form (NEW) .................................................................................... 14
6.4.1 General Tab ............................................................................................. 14
7 Reports ..................................................................................... 16
7.1 General ............................................................................................................. 16
7.2 QA Ratings by Work Order ...................................................................................... 16
7.3 QA Ratings by Service Manager................................................................................. 16
8 Integrations ................................................................................ 19
8.1 Maximo Integration ............................................................................................... 19
9 Portals ...................................................................................... 20
9.1 Portals .............................................................................................................. 20
9.1.1 QA Specialist Portal (NEW) ........................................................................... 20
9.2 New Portal Sections .............................................................................................. 20
9.2.1 Closed Work Orders.................................................................................... 20
10 Configuration Requirements............................................................ 22
10.1 List and Classification Modifications .......................................................................... 22
10.1.1 Classification: QA Rating.............................................................................. 22
10.2 Notifications ....................................................................................................... 22
10.2.1 Notification Requirements ........................................................................... 22
10.3 Internationalization .............................................................................................. 22
10.3.1 Language Requirements .............................................................................. 22
10.3.2 Currency and Measurement Conversion Requirements ......................................... 22
11 Security..................................................................................... 23
11.1 Role Base Security ................................................................................................ 23
11.1.1 Existing Security Group to New Group ............................................................. 23
11.1.2 Security Matrix ......................................................................................... 23

Introduction
Al-Borj
Al-Borj_QA_FDD_v0.02 1
1 INTRODUCTION
1.1 Purpose
This Functional Design Document is intended to define in detail the application customizations and configurations
required to the base TRIRIGA product to accommodate the requirements of the project. It is designed to provide a
blueprint to guide the work necessary for construction and testing. The final details needed for construction shall
be included in the Technical Design Document (if applicable). This document is being created as a result of a gap
analysis performed and is intended to document the functionality that deviates from the base product. This
document and content overrides the content/requirements/and decisions made in the BPA/GAP document. Not all
base application functionality is explicitly described. In the case where screen shots are provided, they are meant
to be a guide only. Textual descriptions always override screen shots provided.
1.2 Audience
The intended audience for the Functional Design Document is comprised of end users, business analysts and
business process owners involved with the business functions that are the subject of the engagement. It will also
be used by members of the project team who will be responsible for further defining requirements and developing
the solution.
1.3 Additional References/Resources
This Document references the following other documents:
Date Document Name
(Filename)
Definition
1.4 Glossary of Project Terms
Term Definition
1.5 Project Team
Company Title/Position Name Phone Email
Al-
Mutawer
Assad Nassreddine
+966-56-111-
9222
anassreddine@almutawer.
com
Al-Borj Wissam El-Khatib welkhatib@alborj-sa.com
Al-Borj IT Manager Tracy Jefferson
+966-54-135-
4168
tjefferson@alborj-sa.com
Al-Borj
TRIRIGA System
Administrator
Mani Sanjeevi
+966-55-151-
9256
mani_s@alborj-sa.com
Al-Borj Business Analyst Chris Pittman
+966-54-439-
8844
cpittman@alborj-sa.com

Introduction
Al-Borj
1.6 Project Assumptions
This section explains key assumptions being made by Al-Borj in order for work to progress and complete within the
estimated time frames. Items used for planning that are considered true are called project assumptions. Time,
scope or cost of this project may be impacted if an assumption turns out to be false, or if Al-Borj defines
additional requirements outside the context of this project (i.e. enhancements or other projects).
1.6.1 Dependencies
The following Projects and/or development efforts that are currently in progress have a direct impact on the
requirements that are within the scope of this project.
a. Integration with Saudi Services Maximo.
1.6.2 General
a.
1.7 Project Responsibilities
The internal team is responsible for the creation and implementation of the Quality Assurance Enhancement.

Outstanding Items & Decision Log
Al-Borj
2 OUTSTANDING ITEMS & DECISION LOG
This section is intended to identify any remaining items to be determined either by Al-Borj. The intended purpose
is to allow both parties a tracking mechanism post exploration phase and allow for the approval of this document
with the outstanding items remaining below.
Responsible Party Issue/Question Decision Status Decision
Made

Al-Borj
3 OVERVIEW OF CHANGES
This section provides an overview of applicable terms to the project.
3.1 Background
Al-Borj requires a Quality Assurance tab for the team to make notes and if necessary Re-Open a work order if they
do not think it passes the specifications of the job. The tab will only be available for the QA team to work with. If
a closed work order is re-opened it will impact the integration.

Al-Borj
4 HIGH LEVEL BUSINESS REQUIREMENTS
4.1 Scope
4.1.1 Tasks
 Work Order has to be modified with a QA tab.
 QA needs the ability to re-open Closed work orders.
4.1.2 Classification
 A new classification needs to be created.
4.1.3 Portals
 Portal section needs to be available to show closed work orders.
 Portal needed for QA Specialists.
4.1.4 Reports
 A report shall exist that lists work orders rated for date range.
 A report shall analyze QA ratings by Service Manager.
4.1.5 Notifications
 Notification required on Closed status of work order.
4.1.6 Security
 A new security group for the QA team is required.

High Level Business Requirements
Al-Borj
4.2 Business Requirements Traceability Matrix
# Business
Requirement
Requirement Description Module/BO Config
Required
Notes FDD
Reference
1 N/A The QA requires the ability to optionally perform and
document a QA inspection of work that was performed
where the work order has been closed by a service
manager.
triTask/sbgWork
Task
Yes 5.1
2 N/A Ability to re-open work orders that are already closed
required.
triTask/sbgWork
Task
Yes 6.3
3 N/A Require a QA tab that is only available for the Quality
Assurance team.
triTask/sbgWork
Task
Yes 6.3
4 N/A Need a portal for QA Specialist Portals Yes 9.1.1
5 N/A Need a portal section to show all closed work orders. Portals Yes 9.2.1
6 N/A Need to create a new classification. Classification Yes 6.4, 10.1.1
7 N/A A report shall analyze QA ratings by Service Manager. Reports Yes 7.3
8 N/A A report shall exist that lists work orders rated for
date range.
Reports Yes 7.2
9 N/A Need a notification that informs the QA group when a
work order is Closed.
Notifications Yes 10.2.1

Process Requirements
Al-Borj
5 PROCESS REQUIREMENTS
This section details the customizations required to the configured TRIRIGA workflow functionality. This section focuses on data flow and action requirements
as they pertain to the business process requirements defined to date. The textual description of the process diagrams always overrides the diagrams provided.
This is done so that the text explicitly states the requirements of the new system, and the screenshots provide the reader a graphical representation of the
requirements. At the time of development, the layout or basic design may alter to accommodate the defined requirements within the TRIRIGA workflow
engine capabilities.
Note that in the process verbiage items and diagram are to be highlighted in blue.

Al-Borj
5.1 Quality Assurance Enhancement: Overview

Al-Borj
5.1.1 Overview
The Quality Assurance Enhancement is a planned set of changes to add the quality assurance team into the work order process. The process will add a tab
specifically for the use of the quality assurance team. There are impacts to the work order form, notifications, the Maximo integration, and to the existing
process for completion and closure of work orders.
5.1.1.1 Details (Step by Step)
Step by Step Process Analysis Config
Req?

Al-Borj
5.1.1.1.1 Process begins. No
5.1.1.1.2 Work Order is created. No
5.1.1.1.3 Work Order is Activated. No
5.1.1.1.4 Service Manager monitors work order as it progresses, and may
need to cancel it. Has the Work Order been canceled in TRIRIGA?
If no, proceed to 5.1.1.1.3
No
5.1.1.1.5 The Work Order is set to Canceled in TRIRIGA. Yes
5.1.1.1.6 Was the Work Order Canceled in MAXIMO? If yes, proceed to
5.1.1.1.22 otherwise proceed to 5.1.1.1.9.
N/A
5.1.1.1.7 Work Order is sent to MAXIMO via the integration. (NOTE: this
occurs in parallel to the monitoring and potential for cancelation
mentioned in 5.1.1.1.4.
Yes
5.1.1.1.8 Has the work order been canceled in MAXIMO? If no, proceed to
5.1.1.1.11
N/A
5.1.1.1.9 Sets the Work Order to Canceled in Maximo. Yes
5.1.1.1.10 Is the Work Order Canceled in TRIRIGA? If no, proceed to
5.1.1.1.5 If yes, proceed to 5.1.1.1.22.
N/A
5.1.1.1.11 The work order is completed in MAXIMO. No
5.1.1.1.12 The TRIRIGA integration sets the Work Order to Completed. Yes
5.1.1.1.13 Has the completion been confirmed by a service manager? If yes,
proceed to 5.1.1.1.17
N/A
5.1.1.1.14 The Work Order is Re-Opened. No
5.1.1.1.15 The Work Order is set back to Active state in TRIRIGA. No
5.1.1.1.16 The Work Order is set back to Active status in MAXIMO via the
integration. Proceed back to 5.1.1.1.11.
Yes
5.1.1.1.17 The Work Order is set to Closed in TRIRIGA. No
5.1.1.1.18 The Work Order is set to Closed in MAXIMO via the integration. Yes
5.1.1.1.19 QA is notified on their portal. Yes
5.1.1.1.20 Will QA do an inspection? If no, proceed to 5.1.1.1.23 N/A
5.1.1.1.21 QA fills in QA tab on the work order with results of their
inspection.
Yes

Al-Borj
5.1.1.1.22 Is QA going to Re-Open the Work Order? If yes, proceed to
5.1.1.1.15
N/A
5.1.1.1.23 Process Ends. No

Al-Borj
6 FUNCTIONAL DESIGN REQUIREMENTS
This section details the customizations required to the TRIRIGA base product functionality. This section focuses on functional requirements as they pertain to
screen layout, data capture, and available functionality to the end user. The text provided in this section always overrides the screen shots provided. This is
done so that the text explicitly states the requirements of the new system, and the screenshots provide a baseline for the textual requirements. At the time
of Construction, the layout or basic design may be altered to accommodate the defined requirements, or new requirements added at that time.
6.1 General
This section details any general or overarching requirements that may affect the overall system.
Key Modifications
6.1.1.1.1 Adding a new tab to the already configured work order form.
6.1.1.1.2 Creating a new classification strictly for the QA team.
6.2 Roles
This section details the specific roles to be created within the system. Each of these roles will have a business process purpose, security requirements, and
portal requirements. Also please review the Role Setup Matrix later in this document.
Business
Functional
Role
Description General Security Requirements Existing/New
Home Page
(Specify)
Existing/New
Security Group
(Specify)
QA
Specialist
Same rights as an Al-Borj Service
Manager but with additional
access to the new QA tab.
sbgHome – QA
Specialist
sbgQASpecialist

Al-Borj
6.3 Work Order Form
6.3.1 QA Tab (NEW)
TRIRIGA Object Details
Module:
Business Object:
Tab:
triTask
sbgWorkTask
QA
Key Modifications
General
6.3.1.1.1
Section: Observations
6.3.1.1.2 Rating – This is a locator to the new QA Rating classification. Field name should be sbgQARatingCL.
6.3.1.1.3 QA Notes – This is a memo field with a maximum length of 900 characters. Field name should be sbgQANotesTX
State Considerations
6.3.1.1.4 This tab is an exception to the rule of read only that is normal for the Closed state. Note that the rest of the form is to remain in a read
only state.
Validation Considerations
6.3.1.1.5 N/A
Additional Considerations
6.3.1.1.6 The QA tab is only visible to the QA Specialist group.
6.3.1.1.7 The Re-Open action is to be available on this tab.

Al-Borj
6.4 QA Rating Class Form (NEW)
6.4.1 General Tab
TRIRIGA Object Details
Module:
Business Object:
Tab:
Classifications
sbgQARating
General
Key Modifications
General
6.4.1.1.1 Please note the example above came from the existing classification called “triContractType” which has the same information as required
for the new one.
Section: General
6.4.1.1.2 Please maintain the functionality from the above sample.
Section: Details

Al-Borj
Section: Classification Notes
State Considerations
6.4.1.1.5 N/A
Validation Considerations
6.4.1.1.6 N/A
Additional Considerations
6.4.1.1.7 N/A

Al-Borj
7 REPORTS
The following reporting requirements have been identified for the project. Some modifications have been made so that the requirements adhere to the
TRIRIGA platform capabilities and most efficient usability. Some reports are associated with a Portal view, but all reports can be generated from the Report
Manager.
7.1 General
Req. # Report Criteria Requirement Detail
7.1.1.1.1
7.2 QA Ratings by Work Order
This is a query listing work orders with their QA Rating.
Task ID Task Name Rating QA Notes Request Class Building Floor Work Location Actual End Closed Date Closed By Status
triIdTX triNameTX sbgQARatingCL sbgQANotesTX triMatrixRequestClassCL triNameTX triNameTX triNameTX triActualEndDT sbgAutoCloseDT triStatusCL
7.2.1.1.1 Group By None
7.2.1.1.2 Static Filter Status <> retired; QARating <> null
7.2.1.1.3 Runtime Filter Closed Date/Time >= User entered value and Closed Date/Time <= User entered value;
Closed By
7.2.1.1.4 Sort Order Work Order Number
7.2.1.1.5 Portal View None
7.2.1.1.6 Totals None
7.2.1.1.7 Other N/A
7.3 QA Ratings by Service Manager
This is a query showing QA Rating by Service Managers in a specified period of time.

Al-Borj

Al-Borj
7.3.1.1.1 Group By Service Manager; Rating
7.3.1.1.2 Static Filter Status <> retired; QARating <> null
7.3.1.1.3 Runtime Filter Closed Date/Time >= User entered value and Closed Date/Time <= User entered value
7.3.1.1.4 Sort Order Service Manager; Rating
7.3.1.1.5 Portal View None
7.3.1.1.6 Totals None
7.3.1.1.7 Other N/A

Al-Borj
8 INTEGRATIONS
There are two initial integrations in the system: Microsoft Dynamics AX and a connection to the Maximo implementation at Saudi Services. This FDD only
impacts the integration to Maximo.
8.1 Maximo Integration
The original scope of the Maximo integration ends once a work order is closed. This new functionality will cause a work order in a closed state to be re-opened
and back in an active state so there may be an impact to the integration.

Al-Borj
9 PORTALS
The portals represented in this chapter are intended to be the initial ones for review and testing. The final layout is likely to change.
9.1 Portals
9.1.1 QA Specialist Portal (NEW)
9.2 New Portal Sections
9.2.1 Closed Work Orders
Only display records where the work orders are set to Closed.

Al-Borj
Req No Field Notes
9.2.1.1.1 Task ID
9.2.1.1.2 Task Name
9.2.1.1.3 Rating
9.2.1.1.4 QA Notes
9.2.1.1.5 Request Class
9.2.1.1.6 Building
9.2.1.1.7 Floor
9.2.1.1.8 Work Location
9.2.1.1.9 Actual End
9.2.1.1.10 Closed Date
9.2.1.1.11 Closed By

Al-Borj
10 CONFIGURATION REQUIREMENTS
10.1List and Classification Modifications
10.1.1 Classification: QA Rating
 TBD
10.2Notifications
This section defines the Notifications required in the system to notify different roles about functional areas. These requirements are for any changes to
existing notification or to address new notification requirements
10.2.1 Notification Requirements
Req. # Notification Name Linked BO Linked Form Notify on
State
Notification Content Persons/Roles Groups
10.2.1.1.1 Work Task-Closed triTask sbgWorkTask Closed Work Task Closure N/A QA Specialist
10.3Internationalization
10.3.1 Language Requirements
The following language requirements have been identified for this implementation:
10.3.1.1.1 English shall be the only supported language.
10.3.1.1.2 Arabic should be available in the future.
10.3.2 Currency and Measurement Conversion Requirements
The following currency and measurement requirements have been identified for this implementation:
10.3.2.1.1 Support for Saudi Riyals, US Dollars, and Euros is required.

Security
Al-Borj
11 SECURITY
Below is the security configuration. Note that unless otherwise specified, the System, Audit Actions, Workflow, Includes tabs are all not visible.
11.1Role Base Security
11.1.1 Existing Security Group to New Group
Take the existing Al-Borj Service Manager security group and copy it to a new group called Al-Borj QA Team. In the new group, make sure the users can access
the new functionality described in this document. The security matrix below indicates new access.
11.1.2 Security Matrix
ACCESS KEY
R - Read (Read)
U - Update (Read, Update)
C - Create (Read, Update, Create)
D - Delete (Read, Update, Create, Delete)
X – Full Access
NONE - No Access
sbgQualityAssurance
Module BO Tab/Section
triTask sbgWorkOrder QA* C
Classification QA Rating General R
 This tab must be accessible even when a record is in a read only, closed state.

Al-Borj_QA_FDD_v0.02

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Similar to Al-Borj_QA_FDD_v0.02

Similar to Al-Borj_QA_FDD_v0.02 (20)

Al-Borj_QA_FDD_v0.02