FUJ00119562
FUJ00119562
ICL Pathway Ref: CR/FSP/003
DSS/POCL Functional Specification Version: 6.0
Date: 26/7/96
1. ABOUT THIS DOCUMENT
1.1 PURPOSE
Schedule B7 (Authorities’ Agreement), paragraph 2.2, required that Pathway
would supply BA/POCL with a Functional Specification (FS) within one week
of execution of the contract, 15 May 1996, for agreement by a target date of 30
June 1996. Version 3 was published on 22 May and extensively reviewed by
all parties. Version 4 was published on 14 June and was further reviewed as
planned. Version 5 was published 26 June and received final approvals on 30
June, thus fulfilling the terms of the contract.
The fundamental purpose of this process is to establish an early level of
agreement between Pathway and the Authorities concerning a more detailed
level of specification of functionality of the services to be supplied, and by
association, the underlying products from which such services are derived,
such that service and product development activities can be undertaken with
expedition and a high degree of confidence.
Schedule B7 paragraph 2.2 provides that changes to the FS definition
subsequent to agreement will be subject to a process of agreed change control.
The purpose of such change control is to facilitate necessary and agreed
change in a scrutinised and orderly manner, and is neither to prevent such
change nor implicitly vary any party’s obligations under the contracts.
1.2 STRUCTURE AND SCOPE
[R951, R927, R928, R932, R973]
This FS is organised in a manner which anticipates the Service Architecture
Design Document (SADD), which is required according to Clause 401.1 in the
Authorities’ Agreement. This FS is developed under change control from its
initial form such that it becomes the SADD itself when satisfactorily complete
and detailed and that it is maintained thereafter as the SADD. In this manner
there will be a complete description and unbroken audit trail of changes
proposed and changes agreed. It is anticipated that the first version of the
SADD to correspond with the start of Operational Trial will be achieved in
September 1996 and will reach a “steady state” state in June 1997.
Figure 1-1 on the following page shows the structure required of the SADD
according to the terms of the initial agreements.
Printed: [ DATE \I]} COMMERCIAL-IN-CONFIDENCE
C:\FS6\PFISCT1.DOC Page 1
FUJ00119562
FUJ00119562
ICL Pathway Ref: CR/FSP/003
DSS/POCL Functional Specification Version: 6.0
Date: 26/7/96
‘Servive Architecture Design Document
AMO 1.1, ROZE ROS] (BI (DSS)NB3(POCL)]
I
Figure 1-1: Required structure of the Service Architecture Design Document
The scope of the SADD, and hence the target scope of this document, is
therefore the Steady State Service Definition of the Pathway Service as a
whole, divided principally into the two Steady State Service Definitions
applicable to the two Contracting Authorities but with certain topics which are
logically for description at the Pathway Service level.
At early levels of revision of the FS only those parts necessary for the
immediate purpose will be populated. Over time it is anticipated that material
from the body of the document will be abstracted to appropriate appendices.
Sections 2.1 and 2.2 form a concise description of the Service Architecture.
Detailed procedures will be discussed and agreed between DSS, POCL and
Pathway and will form part of the procedures documentation.
Printed: [ DATE \I]} COMMERCIAL-IN-CONFIDENCE
C:\FS6\PFISCT1.DOC Page 2
FUJ00119562
FUJ00119562
ICL Pathway Ref: CR/FSP/003
DSS/POCL Functional Specification Version: 6.0
Date: 26/7/96
1.2.1 CONTRACTUAL BASIS OF STRUCTURE
Where appropriate, the defining clause for an element is shown; for example,
A401.1, D405.2 or P405.4, denoting respectively the Authorities’, DSS or
POCL Agreement clause in question. Similarly the schedules associated with
each element are identified in brackets, in italics where they are to be
produced. Requirements and, in due course, Solutions are denoted by Rnnn
and Snnn respectively, for example, R951.
The Card Management and Payment Authorisation Services embrace a number
of second order services, for example, the BPS Management Information
Service. These are grouped as common service elements within the DSS
Service Architecture.
1.2.2 PFI SERVICE LEVEL COMPONENTS
It is in the nature of the total service solution that the end-to-end aspects of the
Benefit Payment Service (BPS) are specified at the top level of Service
Architecture. The Card Management and Payment Authorisation Services
(CMS, PAS), together with several supporting services, are defined within the
DSS Service Architecture, while the Benefit Encashment Service (BES) forms
part of the POCL Service Architecture.
In addition, certain aspects of the security architecture are for specification at
the top level of the Pathway Service Architecture.
In order to assist understanding of the operation of the services, this document
provides information about the products on which they are expected to be
based. These underlying systems may be implemented differently from the
manner described as a result of the parties meeting their obligations under the
agreements.
Printed: [ DATE \I]} COMMERCIAL-IN-CONFIDENCE
C:\FS6\PFISCT1.DOC Page 3