FUJ00234921 - Schedule B6.1 HNG-X Business Requirements Version 15.0

Evidence on official site

FUJ00234921
FUJ00234921

CONFIDENTIAL

SCHEDULE B6.1

HNG-X BUSINESS REQUIREMENTS

Version History

ite mment

1.0 31/08/06 Agreed version at date of signature of CCN1200

11 26/09/06 Minor corrections by PO

1.2 11/10/06 Further minor corrections from FS

1.3 19/01/07 Further minor changes

2.0 25/01/07 Baseline copy of 1.3

6.0 16/06/09 Moving all schedules to V6.0 as agreed with Fujitsu

6.1 24/12/09 Applying changes as per CCN 1268

6.2 31/03/10 Applying changes as per CCN1276a

7.0 10/05/10 Moving all schedules to V7.0 as agreed with Fujitsu.

8.0 21/02/12 Moving all schedules to v8.0 in accordance with
CCN1294d

9.0 13/01/14 Moving all Schedules to v9 in accordance with
CCN1349

10.0 10/09/15 Moving all Schedules to v10 in accordance with
CCN1506

11.0 31/03/16 Moving all schedules to V11.0 in accordance with
CCN1604

12.0 03/07/17 Moving all schedules to V12.0

13.0 Updating as per CCN1617a and moving all Schedules
to v13.0

14.0 20/12/2021 Updating as per CCN1648b and moving all Schedules
to v14.0

75.0 72/04/23 Updating as per CCN1727.

Schedule B6.1 Version 15.0
Page 1 of 39
CONFIDENTIAL
SCHEDULE B6.1
HNG-X BUSINESS REQUIREMENTS
1. INTRODUCTION
1.4 This Schedule B6.1 sets out the HNG-X Requirements (or processes to be followed to

24

2.2

3.1

create HNG-X Requirements) for the HNG-X System, the solution to which will be
developed and documented in accordance with Schedule B6.2.

This Schedule B6.1 also envisages that the Parties may introduce changes to the live
Horizon system and that such changes may or may not impact on the Requirements
Definition Process.

THE THREE BASELINES

There are three baselines relevant to the definition of HNG-X Requirements and their
realisation in the development of the HNG-X System:

2.1.1. the “Applicable Horizon Baseline”: the baseline that consists of the Horizon
Applications and the Horizon Service Infrastructure up to and including Release
S92 together with those changes delivered (or to be delivered) after Release S92
which have been agreed in accordance with the Change Contro! Procedure and
which are, as at the date of signature of CCN1200, listed in Annex 13 to this
Schedule (as that baseline may be amended in accordance with the provisions of
this Schedule);

2.1.2 the "Requirements Baseline”: the baseline described more fully in paragraph 4
that represents Post Office’s requirements for the HNG-X System as set out in
this Schedule and agreed in accordance with the Requirements Definition
Process (as that baseline may be amended or re-issued in accordance with the
provisions of this Schedule); and

2.1.3 the “Solution Baseline": the baseline that consists of the HNG-X System as at
the HNG-X Initial Acceptance Date (as that HNG-X System may be modified to
rectify any HNG-X Acceptance Incidents).

For the purpose of the Parties resolving any dispute concerning the Applicable Horizon
Baseline or any part of the Applicable Horizon Baseline (including, without limitation, a
dispute as to the Existing Functionality), the Parties shall refer to the Horizon system that
is in live operation as at the date of the dispute in question and shall (a) exclude the effects
of changes that have only been applied as described in paragraph 3.1 of this Schedule,
and (b) include the effect of changes described in paragraph 3.2 of this Schedule to the
extent they have not been implemented.

THE APPLICABLE HORIZON BASELINE

Changes to the live Horizon system that are requested after the date of signature of
CCN1200 and that introduce changes or functions that are not intended to be replicated
in, or to have any effect upon, the HNG-X System, will be dealt with in accordance with

Schedule B6.1 Version 15.0
Page 2 of 39

FUJ00234921

FUJ00234921
CONFIDENTIAL

3.2

41

the Change Control Procedure or through Work Orders but shall be ignored in determining
the Applicable Horizon Baseline.

Changes to the live Horizon system that are requested after the date of signature of
CCN1200 and that are intended to introduce changes or functions that will be replicated
in, or otherwise affect, the HNG-X System, will be dealt with in accordance with the
Change Control Procedure or through Work Orders. The Change Control Procedure or
the Work Ordering Procedure (as the case may be) will be used to assess the effect of
the changes or new functions on the live Horizon system and (so far as possible at the
time of agreeing the change) on the Requirements Baseline and the changes and new
functions will be taken into account in determining the Applicable Horizon Baseline (and
will be recorded by the Parties in a control log initially formed from the information in
Annex 13 to this Schedule).

THE REQUIREMENTS BASELINE
Requirements Areas

4.1.1 The Requirements Baseline will be composed of HNG-X Requirements covering
each of the following:

(a) the Functional Requirements;

(b) ‘System Capacity and Performance Requirements' which, as at the date
of signature of CCN1200, are referred to in Annex 3 to this Schedule;

(c) ‘User Interface Requirements’ as described in paragraph 4.3;

(d) ‘Training Requirements’ which, as at the date of signature of CCN1200,
are referred to in Annex 4 to this Schedule;

(e) ‘Operational and Support Service Requirements' which, as at the date
of signature of CCN1200, are referred to in Annex 5 to this Schedule;

(f) ‘Migration and Implementation Requirements' which, as at the date of
signature of CCN1200, are referred to in Annex 6 to this Schedule;

(g) ‘Design and Architecture Requirements’ which, as at the date of
signature of CCN1200, are referred to in Annex 7 to this Schedule;

(h) ‘Security Requirements’ which, as at the date of signature of CCN1200,
are referred to in Annex 8 to this Schedule;

(i) ‘Development Requirements’ which, as at the date of signature of
CCN1200, are referred to in Annex 9 to this Schedule; and

() ‘Testing Requirements' which, as at the date of signature of CCN1200,
are referred to in Annex 10 to this Schedule.

Schedule B6.1 Version 15.0
Page 3 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

Notwithstanding any other provision of this Agreement (including this Schedule),
where any HNG-X Requirement set out or referred to in Annexes 3 to 10 of this
Schedule is inconsistent with an HNG-X Assumption which is (a) related to that
HNG-X Requirement and (b) set out or referred to in the same Annex or in Annex
12, the HNG-X Assumption shall prevail only to the extent of that inconsistency
such that the HNG-X Requirement shall be modified so as to avoid that
inconsistency (such modification to be dealt with under the HNG-X Programme
Requirements Change Control Process).

Notwithstanding any other provision of this Agreement (including this Schedule),
where the application of the Requirements Definition Process or the application
of the Business Equivalence Principles would produce an HNG-X Requirement
that is inconsistent with the HNG-X Assumption set out in Annex 12, the HNG-X
Assumption shall prevail only to the extent of that inconsistency such that the
HNG-X Requirement shall be modified so as to avoid that inconsistency (such
modification to be dealt with under the HNG-X Programme Requirements Change
Control Process).

HNG-X Requirements will be maintained in the HNG-X Requirements Catalogue
and issued formally to Fujitsu Services at agreed points throughout Project HNG-
X, including at the date of signature of CCN1200, at the end of the Requirements
Stage, and at the end of either or both of HNG-X Requirements Assurance and
HNG-X Solution Assurance (if these result in amendments to the HNG-X
Requirements).

4.2 Functional Requirements

4.2.1

4.2.2

The Functional Requirements will be generated by following the Functional
Requirements Definition Process. When generating the Functional Requirements
in accordance with the Functional Requirements Definition Process, the Parties
shall at all times observe and apply the following principles ("Business
Equivalence Principles"):

(a) other than the Agreed Changes and the Allowed Changes, the Business
Capabilities and Support Facilities will provide such functionality as
results from applying the guidelines in Annex 1 to the Existing
Functionality; and

(b) for the avoidance of doubt, other than the Agreed Changes and the
Allowed Changes, the Business Capabilities and Support Facilities will
not be required to provide any functionality that does not result from
applying the guidelines in Annex 1 to the Existing Functionality.

Agreed Changes

(a) The Agreed Changes are agreed as exclusions from, additions to, and
changes in the Existing Functionality that are to be applied in generating
the Functional Requirements in accordance with the Functional
Requirements Definition Process. Agreed Changes are exceptions to

Schedule B6.1 Version 15.0

Page 4 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

4.2.3

the Business Equivalence Principles and cannot themselves be
changed by the application of the Business Equivalence Principles.

Any specific functional characteristics of Existing Functionality that have
been changed as a direct consequence of applying an Agreed Change
are no longer subject to the Business Equivalence Principles.

The effect that an Agreed Change has on the Existing Functionality shall
be limited to the direct consequence of applying that Agreed Change to
the relevant aspect or aspects of the Existing Functionality.

One of the Agreed Changes is the introduction of Postal Services. The
Parties will develop HNG-X Requirements for Postal Services in
accordance with the Postal Services Definition Process.

Allowed Changes

The “Allowed Changes" are changes to aspects of Existing Functionality in
respect of which the following conditions are fulfilled:

(a)

(c)

(e)

either:

(i) the aspect of the Existing Functionality is now assessed by Post
Office as creating operational or procedural problems or
inefficiencies within a Branch; or

(ii) the aspect of the Existing Functionality was previously agreed to
be implemented within certain limitations or constraints and these
limitations or constraints are not present in, or relevant to, the
Solution Architecture or other solution artefact; and

the effect of applying the requested change is assessed by Fujitsu
Services, acting reasonably and in good faith, as having an acceptable
cost/ risk / resources impact on Project HNG-X; and

the effect of any such change is to make the manner in which Users
utilise an element of Existing Functionality more efficient without
introducing any completely new functionality into the Existing
Functionality; and

the required change is notified in writing by Post Office to Fujitsu
Services before the end of the Requirements Stage or as part of HNG-

X Requirements Assurance; and

the change has not already been assessed as being an Agreed Change.

An Allowed Change shall be dealt with in accordance with the HNG-X Programme
Requirements Change Control Process.

Schedule B6.1 Version 15.0

Page 5 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

43 Requirements of the HNG-X User Interface

4.3.1

4.3.2

4.3.3

4.3.4

The HNG-X Requirements that the HNG-X User Interface shall support are:
(a) the Functional Requirements; and
(b) the non-functional HNG-X Requirements for the HNG-X User Interface.

The functionality required to be supported by the HNG-X User Interface will be
derived from the Functional Requirements generated through the Requirements
Definition Process. This derived functionality will be an input to the process set
out in the CCD entitled "Establishing and Assuring the HNG-X User Interface"
(REQ/GEN/PRD/0001).

The non-functional HNG-X Requirements for the HNG-X User Interface will be
provided by Post Office after the date of signature of CCN1200 in accordance
with the CCD entitled “Establishing and Assuring the HNG-X User Interface”
(REQ/GEN/PRD/0001).

The HNG-X User Interface design will draw on best practice design from the retail
and banking industries as well as industry standards in graphical user interface
design. The Parties intend that any similarities between the style and graphical
realisation of the HNG-X User Interface and the user interface(s) of the
comparable Horizon Applications as may arise shall only arise as a matter of
coincidence through the proper operation of the Clean Room Rules.

5. REQUIREMENTS DEFINITION PROCESS

The Parties will follow the Requirements Definition Process.

6. DEALING WITH CHANGE

6.1 Changes to the Applicable Horizon Baseline

Changes to the Applicable Horizon Baseline will be dealt with as set out in paragraphs
3.1 and 3.2.

6.2 Changes to the Requirements Baseline

6.2.1

6.2.2

If a change to an HNG-X Requirement or an additional HNG-X Requirement is
notified in writing to Fujitsu Services after the date of signature of CCN1200 and
prior to the end of the Requirements Stage, it will be dealt with as part of the HNG-
X Programme Requirements Change Control Process.

If a change to an HNG-X Requirement or an additional HNG-X Requirement is
notified in writing to Fujitsu Services as a result of HNG-X Requirements
Assurance or HNG-X Solution Assurance, it will be dealt with as part of the HNG-
X Programme Requirements Change Control Process.

Schedule B6.1 Version 15.0

Page 6 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

6.2.3

6.2.4

6.2.5

Subject to paragraph 6.2.2, if a change to an HNG-X Requirement is notified in
writing to Fujitsu Services after the end of the Requirements Stage then, if that
change is:

(a) not the result of the User Interface Definition Process nor the Postal
Services Definition Process, and required in order to correct a deviation
of that HNG-X Requirement from the Business Equivalence Principles;
or

(b) the result of the Postal Services Definition Process and required in order
to correct a deviation of that HNG-X Requirement from the Postal
Services Assessment Guidelines,

it will be dealt with in accordance with the HNG-X Programme Requirements.
Change Control Process. Fujitsu Services shall not be entitled to withhold its
consent to the changes to the extent that they are required in order to correct the
deviation from the Business Equivalence Principles or the Postal Services
Assessment Guidelines (as the case may be).

All other changes or additions to HNG-X Requirements proposed after the final
version of the Requirements Baseline has been issued will be dealt with in
accordance with the Change Control Procedure.

As part of any changes to the Requirements Baseline, the Parties shall agree any
necessary changes to the HNG-X Acceptance Method(s) and HNG-X Acceptance
Criteria applicable to the relevant HNG-X Requirement.

6.3 Changes to the Solution Baseline

6.3.1

If achange to the Solution Baseline is notified in writing to Fujitsu Services within
the period of three months after the start of HNG-X Project Workstream X4 (HNG-
X Application Rollout) then, if that change is:

(a) not the result of the User Interface Definition Process nor the Postal
Services Definition Process, and required in order to correct a deviation
of the Solution Baseline from the Business Equivalence Principles; or

(b) the result of the Postal Services Definition Process and required in order
to correct a deviation of the Solution Baseline from the Postal Services
Assessment Guidelines,

the Parties will meet to agree whether the conditions in paragraph 6.3.1(a) or (b)
have been fulfilled, and if such conditions have been fulfilled:

(c) discuss and agree in good faith the steps required to correct a deviation
of the Solution Baseline from the Business Equivalence Principles or the
Postal Services Assessment Guidelines (as the case may be); or

(d) determine such other remedial steps as the Parties (acting reasonably)
shall agree; and

Schedule B6.1 Version 15.0

Page 7 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

such steps, once agreed, shall be documented in accordance with the Change
Control Procedure and Fujitsu Services shall not be entitled to withhold its
consent to the relevant CCN to the extent that it incorporates the steps in
question.

6.3.2 All changes to the Solution Baseline (other than those that fall within paragraph
6.3.1) will be dealt with in accordance with the Change Control Procedure.

6.3.3. The forum for reaching the agreements referred to in paragraphs 6.3.1(c) and
6.3.1(d) shall initially be the Post Office Design Authority and the Fujitsu Services
Design Authority but either Party may escalate any disagreement to a the
‘Programme Board’ (as referred to in Schedule A2) for Project HNG-X for
discussion and resolution.

7. ASSOCIATED DOCUMENTS,

71 The following CCDs are associated with this Schedule B6.1:

Document Reference Document Title

1. REQ/GEN/PRD/0001 Establishing and Assuring the HNG-X User
Interface

2. REQ/CUS/STG/0003 HNG-X Counter Reference Data Delivery
Strategy - Agreed Assumptions and Constraints

3. REQ/CUS/STG/0002 HNG-X Branch Exception Handling Strategy —
Agreed Assumptions and Constraints

4. REQ/CUS/BRS/0001 Postal Services Business and Operational
Context

5. REQ/CUS/STG/0004 HNG-X Training Strategy (CTO) — Agreed

Assumptions and Constraints

6. REQ/CUS/STG/0001 HNG-X Migration Strategy - Agreed Assumptions
and Constraints

7. ARC/SEC/ARC/0001 Security Constraints

7.2 The following CCDs are also associated with this Schedule B6.1, but only for the purpose
of describing (in the first table in Annex 2 to this Schedule) functionality within the
Applicable Horizon Baseline that will not be carried forward into the HNG-X System:

Document Reference Document Title

1. Removed by
CCN1648b

Schedule B6.1 Version 15.0
Page 8 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL
2. Removed by
CCN1648b
3. Not Used
4. Removed by
CCN1648b
5. Not Used
6. Removed by
CCN1648b
7. RS/FSP/003 Statements on Security Objectives and Methods
for the Protection of Siemens Metering Code and
Data
8. Removed by
CCN1648b
9. Not Used
10. I Not Used
11. I Removed _by
CCN1648b

7.3 There are no CRDs associated with this Schedule B6.1.

Schedule B6.1 Version 15.0

Page 9 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL
ANNEX 1
BUSINESS EQUIVALENCE GUIDELINES
1. It is intended that the Requirements Baseline will define, and the Business Capabilities

and Support Facilities will support, the operation of Post Office business processes in a
manner that achieves the same business outcomes for Post Office and their Clients and
achieves the same operational effect within a Branch as currently provided by the Existing
Functionality.

2. The level of definition in the Functional Requirements and/or the delivered Business
Capabilities and Support Facilities must ensure that:

24

2.2

2.3

2.4

25

the financial outcome resulting from the operation of a specific Transaction for the
Customer, Post Office, any affected Client(s), and any Other IT Supplier(s) is
identical to the equivalent Transaction carried out using the Existing Functionality;

the Post Office products that can be traded within a Branch are the same as those
defined in Post Office Reference Data (whether enabled or not) using the Existing
Functionality;

the Business Rules associated with any Business Capability are applied in the
same manner as those used with the equivalent Transaction carried out using the
Existing Functionality;

the Customer and Counter Clerk interactions that relate to the workflow
associated with a particular Use Case and delivered via the HNG-X User Interface
enable:

2.4.1 the same data to be captured using the same format and validation
criteria;

2.4.2 the same initiating Tokens and/or equivalent initiating events to be used;

24.3 equivalent information displays and capture methods via the counter
terminal; and

2.4.4 the same set of user tasks to be performed following an equivalent
logical workflow and enabling the same or, where agreed, alternative
equivalent operational procedures to be carried out,

in each case as compared with the Existing Functionality;

the outputs resulting from the completion of a Transaction are the same or
equivalent and have the same operational effect (in terms of form and occurrence)
as those resulting from the associated Transaction conducted using the Existing
Functionality. The types of outputs shall include:

2.5.1 any information exchange or generated data file which includes
interactions with hosted systems (e.g. PAF, POL-FS) and external

Schedule B6.1 Annex 1 Version 14.0

Page 10 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL
2.5.2
25.3
2.6

27

2.8

systems (e.g. LINK, DVLA), which shall be the same as that from the
Existing Functionality;

any printed item (e.g. Report, Branch receipt, other forms of Branch
produced collateral), which shall be equivalent to the Existing
Functionality; and

any data, produced or captured, that can be accessed, retrieved by, or
provided to, the Post Office, which shall be the same as that from the
Existing Functionality, provided that the meaning of the data and/or
associated Post Office processes has not changed as a result of the
introduction of the HNG-X System. This will be bounded by the scope of
any specific limitations agreed as part of the HNG-X Services;

the outcome of any aspect of Branch trading or operation results in the same state
of financial integrity and ability to audit as exists using the Existing Functionality;

the use and interpretation of Post Office Reference Data (in terms of its data
definitions and its use to invoke functionality) will remain the same. Any data
items or Reference Data capabilities currently unused within the Existing
Functionality will remain unused or suppressed as part of the HNG-X System
subject to agreement of Post Office; and

Users must be able to perceive and perform the functions provided via the
changed User Interface such that they can perform the same user tasks,
performing equivalent human and computer interactions.

Schedule B6.1 Annex 1 Version 14.0

Page 11 of 39

FUJ00234921
FUJ00234921
FUJ00234921
FUJ00234921

CONFIDENTIAL

ANNEX 2

AGREED CHANGES
1. EXCLUSIONS FROM HORIZON FUNCTIONALITY

The following table describes the functionality within the Applicable Horizon Baseline at
the date of signature of CCN1200 that will not be carried forward into the HNG-X System

# Excluded Description
Functionality

1 Session Transfer A facility that enables a Branch User to log-on at another counter
without having to log-off at their previous counter. This facility
will automatically log-out the Branch User at their previous
counter and move any current activity onto their new counter.
This facility is also known as “Session Mobility” or “Session
Migration”. This facility is not available during certain operations.

2 I Session Suspend A facility that enables a Branch User to ‘Suspend’ and
subsequently ‘Resume’ a desktop session. Only one session
can be suspended in this way. During the suspension the
Branch User is presented with a new main desktop menu and
may carry out any of the system functions (including serving
another customer) while the original session is suspended.
Each of the two sessions (the suspended and the current) can
be ‘toggled’ by selection of the ‘suspend/swap' button. The two
sessions will remain in existence until the user returns one of
the sessions to the ‘Desk Top’ and then swaps to the other
session. This facility is not available during certain operations.

3 I Watercard Watercard comprises a smart token processed as part of the
Automated Payments Service.

It is defined via the following former CCDs, since agreed to be
withdrawn by CCN1200: -

« SU/IFS/027 - Kent Meters/GEC Meters “Watercard”
Payment System Card Data Encryption Specification;

e SU/IFS/028 - GEC Meters Ltd - “Watercard” Budget
Prepayment System Transaction Terminal Outline
Requirements;

e SU/IFS/034 - POCL Token Technology Specification
GEC Watercard; and

Schedule B6.1 Annex 2 Version 14.0
Page 12 of 39
CONFIDENTIAL

FUJ00234921
FUJ00234921

# Excluded
Functionality

Description

4 Signature variants of
Banking transactions

Signature verification comprises one of the NB Customer
Verification methods and is referenced in: -

« BP/SPE/035 — NBS Definition - Section 5.7.3.1 - 2 and
34 bullet and items (b) and (c); and

e NB/SPE/003 — Network Banking: Counter Dialogue
Activity & Screen Flows in section 4.1.2 and then in: -

o Sections 4.3.1.1, 4.3.1.2 (Cash Withdrawal
transaction type 13 & 14 (with balance));

o Sections 4.3.3.1, 4.3.3.2 (Balance Enquiry
transaction type 11);

o Sections 4.3.4.1, 4.3.4.2 (Withdraw Limit
transaction type 15);

o Section 6.1.1 (Receipts and Reporting); and

o Section 6.2 (Receipt layouts).

5 Counter Clerk copy of
AP receipts

Horizon automatically produces a Counter Clerk (or Branch)
copy receipt for all Automated Payment transactions together
with the customer receipt.

Customer Receipts will continue to be produced on the HNG-X
System. The production of the Counter Clerk receipt will
continue for migrated existing ADC transactions but will cease
for Automated Payment transactions.

6 Bubble Help

Bubble Help comprises a facility that enables a Branch User to
display a short help text display associated with a desktop
button.

7 Quantum

Quantum comprises a smart token processed as part of the
Horizon Automated Payments Service.

It is defined via the following former CCDs, since agreed to be
withdrawn by CCN1200: -

e SU/IFS/024 - A Point of Sale Supporting the Quantum
Application Utilising the POCL Secure DLL;

* CR/SPE/023  - Automated Payments Client
Specification - Siemens Metering Ltd;

Schedule B6.1 Annex 2 Version 14.0

Page 13 of 39
FUJ00234921
FUJ00234921

CONFIDENTIAL
# Excluded Description
Functionality
8 POLO card Post Office Logon (POLO) allows an authorised Branch User to

functionality gain access to the Horizon counter system and is used in any of

the following circumstances:

when the system is first started after installation or after
a workstation has been replaced;

«when a workstation processor is switched back on after
being powered off or is restarted; and

e when the Branch Manager needs to restart the office
following the delivery of new security data.

The procedure involves the use of a memory card called a
“PMMC (PostMaster's Memory Card)" and a PIN (Personal
Identity Number comprising a_ string of alphanumeric

characters).

9 Mails Application The Mails Application is described in the former CCD entitled
“Mails Definition". (BP/SPE/042), since withdrawn by
CCN1294d.

10 I Talexus Talexus comprises a smart token processed as part of the
Automated Payment Service. Post Office's ability to deploy
Talexus via CCN 798 will not be carried forward to the HNG-X
System.

2. ADDITIONS TO HORIZON FUNCTIONALITY

The following table describes functionality that is new to the Applicable Horizon Baseline as at
the date of signature of CCN1200 that will be delivered by the HNG-X System.

Title Description

Foreign currency revaluation The calculation that is currently performed to
revalue foreign currency on hand shall be
automatically applied during the office
balancing process.

Postal Services As described in the CCD entitled “Postal
Services Business and Operational Context”
(REQ/CUS/BRS/0001).

Context Sensitive Help. A context sensitive help mechanism (to
replace the current 'Bubble Help’) will be
implemented which will be consistent with the

CCD entitled “HNG-X UI Style Guide”

Schedule B6.1 Annex 2 Version 14.0
Page 14 of 39
CONFIDENTIAL

Title

Description

(DES/APP/STD/0001)
withdrawn).

(subsequently

This will utilise agreed POL or FS reference
data to determine the access points from
which the Branch User may invoke relevant
help text. This help mechanism will support
the structuring of and access to different levels
of help text where more detailed help text is
specified.

The exact approach for the context sensitive
help mechanism, including appropriate
interface definitions to allow Post Office to
specify the help text and structure, will be
agreed as part of the detailed design work.
Note that it may be necessary for Post Office
to provide help text for the HNG-X System
separately to help text for Horizon during the
rollout of the HNG-X System (dual entry). This
will be dependent on the interface definition
agreed with Post Office.

Help Desk Calls.

The ability to log help desk calls via the
counter application.

3. AGREED CHANGES TO HORIZON FU!

at the date of signature of CCN1200 that will be

INCTIONALITY

The following table describes changes to functionality within the Applicable Horizon Baseline as

implemented in the HNG-X System.

# Title

Description

1 Report simplifications

Report consolidation for the HNG-X System
will be achieved through decoupling the call
for data about reports from the central
database, from the user production and
analysis of reports. Reports will be grouped
into a small number of categories, such as
“Counter Daily Report” and “Counter Weekly
Report”. A revised counter sequence will be
design to enable the user to work through the
report set, printing and cutting off as
appropriate.

Post Office confirms that this does not have an
adverse impact on branches as the process is

similar to present and it also provides a way

Schedule B6.1 Annex 2 Version 14.0
Page 15 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

Title

Description

for single counter position branches to be able
to exit to continue customer service if required.

Any consolidation and/or rationalisation of
reports on top of this solution would not
necessarily impact the load on the database
from report production as those reports will be
contained within the bundles of data called in
the one data call. However, it is recognised
that it would be good practice for Post Office
to consolidate and rationalise reports anyway
as a house-keeping exercise to improve
efficiency at the counter and reduce
consumables. This exercise will be carried out
in conjunction with the analysis of the
functional requirements. The Fujitsu Services
baseline assumption for contract is that the
following reports will be removed:

e Counter Daily
o APS Transaction Listing
o O/L Balance Enquiries
o O/L Cash Deposits
o O/L Cheque Deposits

o O/L Cash Withdrawals
(signature and PIN)

« Counter weekly
o O/L Balance Enquiries
o O/L Cash Deposits
o O/L Cheque Deposits

o O/L Cash Withdrawals
(signature and PIN)

Schedule B6.1 Annex 2 Version 14.0

Page 16 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL
# Title Description
2 Changes to the session settlement The HNG-X session settlement model will
mode!

change from Horizon as a consequence of the
on-line architecture, the classification of
transactions as either 'Recoverable' or
'Cancellable', and changes to the production
of some receipt printing.

The primary areas of difference are: -

* Transactions will be classed as either
‘Recoverable' or 'Cancellable’;

e the settlement process is now an on-
line dialogue supported by some new
Counter Clerk dialogues;

e certain receipts will now be printed
during the settlement process,
completing after session data is
secured at the Data Centre;

settlement transaction
sequence will handle transient time-
outs to the Data Centre. This will
comprise automatic retries and then
Counter Clerk managed dialogues
supporting ‘Retry’ and = ‘Cancel’
options;

* certain failure conditions will result in
the settlement process having to be
cancelled. New Counter Clerk
dialogues will manage this exception
process with respect to the settlement
of the 'Recoverable’ transactions and
the cancellation of the 'Cancellable'
transactions. A variant of the
Customer Session receipt for session
recovery will be produced. Following
the printing of the revised session
receipts, the Counter Clerk will be
logged off; and

e a new recovery process will be
initiated on subsequent log-on to the
original terminal. New Counter Clerk
dialogues will manage this recovery
process with respect to the final
outcome of the failed session.

* a new

be contained
‘HNG-X

Further details will
Working Document
Settlement Process’.

in the
Session

Schedule B6.1 Annex 2 Version 14.0
Page 17 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

# Title

Description

3 Changes to way various Exception
conditions are handed

As described in the CCD entitled “HNG-X
Branch Exception Handling Strategy — Agreed
Assumptions and Constraints”
(REQ/CUS/STG/0002).

4 Changes to the management and
distribution of POL Reference Data

As described in the CCD entitled “HNG-X
Counter Reference Data Delivery Strategy -
Agreed Assumptions and Constraints”
(REQ/CUS/STG/0003).

5 Training capability provided in the
Counter Training Offices

As described in Annex 4 of this Schedule.

6 Changes to Confirmation processing
model

Confirmation messages for online
transactions will only be harvested in batch
mode at end of day. This means that the
Transaction Enquiry Service will not receive
C2 messages in near real time, and
Streamline payment file(s) will only be
produced overnight.

7 PIN Pad required for Banking
Deposits

To protect against replay attacks, banking
deposit transactions will use a MAC generated
by the PIN Pad. This will require the presence
of a PIN Pad (a change from Horizon). For the
avoidance of doubt, this will not require a PIN
to be entered by the customer.

8 Change to End of Day

Branch end of day will be declared for all
branches at 19:00 each day. This will be the
same time for all Branches (i.e. there will be
no ability to have different Branches with
different end of day times). End of day will be
declared whether or not those Branches are
operating or connected to the Data Centre.

9 Ad-hoc transaction report for AP
PANs

The HNG-X System shall allow the production
of an ad-hoc transaction report containing the
PAN reference number from the AP token and
the AP sequence number, where they are
agreed to be part of the transaction and not
restricted for security Fujitsu
Services and Post Office will agree the exact
structure of this report during the design stage.

reasons.

Schedule B6.1 Annex 2 Version 14.0
Page 18 of 39

FUJ00234921
FUJ00234921
FUJ00234921
FUJ00234921

CONFIDENTIAL

ANNEX 3

SYSTEM CAPACITY AND PERFORMANCE REQUIREMENTS

1. The System Capacity and Performance Requirements as at the date of signature of
CCN1200 are contained in document “HNG-X System Capacity and Performance
Requirements” version 0.2 dated 15 August, 2006, which forms part of the HNG-X
Requirements Catalogue Draft at Contract.

2. For the purposes of the HNG-X Programme Requirements Change Control Process,
these Requirements are categorised as “Type A”.

3. All HNG-X Requirements are shown in tabular format with a unique identifier, HNG-X
Acceptance Methods and HNG-X Acceptance Criteria. In some cases these HNG-X
Requirements will be contained within textual information which gives a contextual setting.
This context is provided merely to help the reader and can contain:

3.1 glossary applicable to the HNG-X Requirements contained in this Annex;
3.2 chapter headings; and

3.3 explanatory text.

4. The Business Equivalence Principles do not apply to the System Capacity and
Performance Requirements or associated Service Levels, but it is accepted that the
performance characteristics of the HNG-X System counter applications and associated
infrastructure must be acceptable to the Post Office. This specific aspect of the Solution
Baseline will be assessed to determine that the HNG-X System counter performance
delivers equivalent or better performance characteristics to the Applicable Horizon
Baseline, based on the following principles:

44 Post Office and Fujitsu Services will jointly agree an assessment process that will:

(a) define and agree sets of representative Transaction types and a
measurement period;

(b) establish system component benchmark measurements for these
Transaction types on the Horizon system and on the HNG-X System
(taking account of any changed processes or UI characteristics that may
be present in the HNG-X Transaction); and

(c) allow Post Office to request that the set of Transaction types is
augmented (agreement to such requests not to be unreasonably
withheld by Fujitsu Services) if anomalous HNG-X Transaction
performance characteristics are identified prior to the commencement of
the HNG-X Project Workstream X4 (HNG-X Application Rollout).

4.2 Acceptance by Post Office of the HNG-X System counter performance will be
based on the average system component benchmark measurements for each of
the agreed sets of representative Transaction types for the HNG-X System being
no worse than the comparable measurements for each of the Transaction types

Schedule B6.1 Annex 3 Version 14.0
Page 19 of 39
FUJ00234921
FUJ00234921

CONFIDENTIAL

within the Applicable Horizon Baseline or where comparison is not applicable, to
their agreed design targets.

Schedule B6.1 Annex 3 Version 14.0
Page 20 of 39
FUJ00234921
FUJ00234921

CONFIDENTIAL
ANNEX 4
TRAINING REQUIREMENTS
1. The Training Requirements as at the date of signature of CCN1200 are contained in

document “HNG-X Training High Level Requirements” version 0.2 dated 15 August, 2006,
which forms part of the HNG-X Requirements Catalogue Draft at Contract.

2. For the purposes of the HNG-X Programme Requirements Change Control Process,
these HNG-X Requirements are categorised as “Type B”.

3. As described in Paragraph 4.1.2 of this Schedule, these HNG-X Requirements are subject
to the assumptions and constraints contained in the CCD entitled “HNG-X Training
Strategy (CTO) — Agreed Assumptions and Constraints” (REQ/CUS/STG/0004).

4. All HNG-X Requirements are shown in tabular format with a unique identifier, HNG-X
Acceptance Methods and HNG-X Acceptance Criteria. In some cases these HNG-X
Requirements will be contained within textual information which gives a contextual
setting. This context is provided merely to help the reader and can contain:

4.1 glossary applicable to the HNG-X Requirements contained in this Annex;
4.2 chapter headings; and

4.3 explanatory text.

Schedule B6.1 Annex 4 Version 14.0
Page 21 of 39
FUJ00234921
FUJ00234921

CONFIDENTIAL

ANNEX 5

OPERATIONAL AND SUPPORT SERVICE REQUIREMENTS

1. The Operational and Support Service Requirements as at the date of signature of
CCN1200 are contained in document “HNG-X Operational and Support Service
Requirements” version 0.2 dated 15 August, 2006, which forms part of the HNG-X
Requirements Catalogue Draft at Contract.

2. For the purposes of the HNG-X Programme Requirements Change Control Process,
these HNG-X Requirements are categorised as “Type A”.

3. All HNG-X Requirements are shown in tabular format with a unique identifier, HNG-X
Acceptance Methods and HNG-X Acceptance Criteria. In some cases these HNG-X
Requirements will be contained within textual information which gives a contextual
setting. This context is provided merely to help the reader and can contain:

3.1 glossary applicable to the HNG-X Requirements contained in this Annex;
3.2 chapter headings; and

3.3 explanatory text.

Schedule B6.1 Annex 5 Version 14.0
Page 22 of 39
CONFIDENTIAL

ANNEX 6

MIGRATION AND IMPLEMENTATION REQUIREMENTS

The Migration and Implementation Requirements as at the date of signature of CCN1200
are contained in document “HNG-X Migration and Implementation Requirements” version
0.2 dated 15 August, 2006, which forms part of the HNG-X Requirements Catalogue Draft
at Contract.

For the purposes of the HNG-X Programme Requirements Change Control Process,
these HNG-X Requirements are categorised as “Type A”.

As described in Paragraph 4.1.2 of this Schedule, these HNG-X Requirements are subject
to the assumptions and constraints contained in CCD entitled “HNG-X Migration Strategy
- Agreed Assumptions and Constraints” (REQ/CUS/STG/0001).

All HNG-X Requirements are shown in tabular format with a unique identifier, HNG-X
Acceptance Methods and HNG-X Acceptance Criteria. In some cases these HNG-X
Requirements will be contained within textual information which gives a contextual
setting. This context is provided merely to help the reader and can contain:

44 glossary applicable to the HNG-X Requirements contained in this Annex;
4.2 chapter headings; and

4.3 explanatory text.

Schedule B6.1 Annex 6 Version 14.0
Page 23 of 39

FUJ00234921

FUJ00234921
FUJ00234921
FUJ00234921

CONFIDENTIAL
ANNEX 7
DESIGN AND ARCHITECTURE REQUIREMENTS
1. The Design and Architecture Requirements as at the date of signature of CCN1200 are

contained in document “HNG-X Design and Architecture Requirements” version 0.2 dated
15 August, 2006, which forms part of the HNG-X Requirements Catalogue Draft at
Contract.

2. For the purposes of the HNG-X Programme Requirements Change Control Process,
these HNG-X Requirements are categorised as “Type A”.

3. All HNG-X Requirements are shown in tabular format with a unique identifier, HNG-X
Acceptance Methods and HNG-X Acceptance Criteria. In some cases these HNG-X
Requirements will be contained within textual information which gives a contextual
setting. This context is provided merely to help the reader and can contain:

3.1 glossary applicable to the HNG-X Requirements contained in this Annex;
3.2 chapter headings; and

3.3 explanatory text.

Schedule B6.1 Annex 7 Version 14.0
Page 24 of 39
FUJ00234921
FUJ00234921

CONFIDENTIAL
ANNEX 8
SECURITY REQUIREMENTS
1. The Security Requirements as at the date of signature of CCN1200 are contained in

document “HNG-X Security Requirements” version 0.2 dated 15 August, 2006, which
forms part of the HNG-X Requirements Catalogue Draft at Contract.

2. For the purposes of the HNG-X Programme Requirements Change Control Process,
these HNG-X Requirements are categorised as “Type A’.

3. As described in Paragraph 4.1.2 of this Schedule, these HNG-X Requirements are subject
to the assumptions and constraints contained in CCD entitled “Security Constraints”
(ARC/SEC/ARC/0001).

4. All HNG-X Requirements are shown in tabular format with a unique identifier, HNG-X

Acceptance Methods and HNG-X Acceptance Criteria. In some cases these HNG-X
Requirements will be contained within textual information which gives a contextual
setting. This context is provided merely to help the reader and can contain:

44 glossary applicable to the HNG-X Requirements contained in this Annex;
4.2 chapter headings; and

4.3 explanatory text.

Schedule B6.1 Annex 8 Version 14.0
Page 25 of 39
FUJ00234921
FUJ00234921

CONFIDENTIAL
ANNEX 9
DEVELOPMENT REQUIREMENTS
1. The Development Requirements as at the date of signature of CCN1200 are contained

in document “HNG-X Development Requirements” version 0.2 dated 15 August, 2006,
which forms part of the HNG-X Requirements Catalogue Draft at Contract.

2. For the purposes of the HNG-X Programme Requirements Change Control Process,
these HNG-X Requirements are categorised as “Type A’.

3. All HNG-X Requirements are shown in tabular format with a unique identifier, HNG-X
Acceptance Methods and HNG-X Acceptance Criteria. In some cases these HNG-X
Requirements will be contained within textual information which gives a contextual
setting. This context is provided merely to help the reader and can contain:

3.1 glossary applicable to the HNG-X Requirements contained in this Annex;
3.2 chapter headings; and

3.3 explanatory text.

Schedule B6.1 Annex 9 Version 14.0
Page 26 of 39
FUJ00234921
FUJ00234921

CONFIDENTIAL
ANNEX 10
TESTING REQUIREMENTS
1. The Testing Requirements as at the date of signature of CCN1200 are contained in

document “HNG-X Testing Requirements” version 0.2 dated 15 August, 2006, which
forms part of the HNG-X Requirements Catalogue Draft at Contract.

2. For the purposes of the HNG-X Programme Requirements Change Control Process,
these HNG-X Requirements are categorised as “Type A”.

3. All HNG-X Requirements are shown in tabular format with a unique identifier, HNG-X
Acceptance Methods and HNG-X Acceptance Criteria. In some cases these HNG-X
Requirements will be contained within textual information which gives a contextual
setting. This context is provided merely to help the reader and can contain:

3.1 glossary applicable to the HNG-X Requirements contained in this Annex;
3.2 chapter headings; and

3.3 explanatory text.

Schedule B6.1 Annex 10 Version 14.0
Page 27 of 39
FUJ00234921
FUJ00234921
CONFIDENTIAL

ANNEX 14
REQUIREMENTS DEFINITION PROCESS
PART 1 —- FUNCTIONAL REQUIREMENTS DEFINITION PROCESS
INTRODUCTION AND SCOPE

Project HNG-X will commence with the Requirements Stage, which includes specification
and assurance activities, and which will be directed by the Requirements Definition
Process.

Part 1 of this Annex 11 is concerned with the definition and assurance processes to
establish a baseline of Functional Requirements.

This process will focus on the specification of the business process and data requirements
of the Business Capabilities and Support Facilities. Any of the existing non-functional
HNG-X Requirements that relate to specific requirements, artefacts or capabilities will
also be applied at this stage.

HNG-X Requirements Assurance will be conducted as a joint activity comprising both
business content assurance and the inclusion of any agreed optimisation or improvement
opportunities that would facilitate solution design. Both these aspects of HNG-X
Requirements Assurance will involve Fujitsu Services and will occur progressively and
prior to the final issuing to Fujitsu Services of the Functional Requirements.

PRINCIPLES

The principles that will apply during the definition and assurance process, in particular
concerning the interchange of HNG-X Requirements artefacts between Post Office and
Fujitsu Services are as follows:

21 DOORS (as configured within Post Office for Project HNG-X) is the master
repository of all HNG-X Requirements;

2.2 the intention is to be able to compartmentalise the HNG-X Requirements so that
each group of HNG-X Requirements has its own life and own versioning;

2.3 functional Use Cases will be grouped into convenient business areas which will
be made available to Fujitsu Services at relevant points to enable early visibility
and a more interactive approach to solution design; and

2.4 to ensure integrity of the HNG-X Requirements as a whole set there will be a
number of assurance steps which begin at the start of a piece of work in each
business area and complete with the handover of a completed HNG-X
Requirements set. Fujitsu Services are fully involved in this approach from the
beginning of the process through to final baselining of the HNG-X Requirements
set, and will assist in optimising the overall Use Case model so that constraints
applicable to the existing Horizon architecture are not unnecessarily carried
forward into the HNG-X System.

Schedule B6.1 Annex 11 Version 14.0
Page 29 of 39

FUJ00234921

FUJ00234921
CONFIDENTIAL

3.1

3.2

41

4.2

REQUIREMENT ANALYSIS METHOD

Analyst teams from both Parties will progressively develop the Use Case specifications
required for each business area, initially assessing the proposed Use Case goals and
descriptions and the various source materials to determine their status and relevance.
The required business processes and logical operations will be described as Use Cases,
with each being developed through normal flow and then variant and exception paths with
interaction at key stages with the HNG-X Requirements Assurance process.

Certain Use Cases relate to functionality that Fujitsu Services has proposed will be
delivered by solution components that are retained from Horizon. These are classified as
“Retained Functionality’ Use Cases and it has been agreed that these Use Cases will
only require a minimum level of functional specification.

HNG-X REQUIREMENTS ASSURANCE
Introduction

HNG-X Requirements Assurance represents a significant and necessary stage in the
HNG-X solution lifecycle, providing the means by which Post Office and Fujitsu Services
can progressively gain confidence in the scope, capabilities and impact of the emerging
HNG-X Requirements and solution artefacts. The assurance role will involve both
business and functional content assurance and ‘solution design’ assurance. Fujitsu
Services will support Post Office in both of these activities — initially through the provision
of knowledgeable personnel to assist in minimising the risk of functional omission and
subsequently to work with Post Office to verify and improve various aspects of the
emergent solution, both in terms of solution optimisation and economic rationalisation of
HNG-X Requirements.

Assurance Steps
The approach is underpinned by a series of assurance steps which cover:

4.2.1. content assurance: gradually moving towards a series of fully dressed Use Cases
through a series of assurance stages which verify them on an incremental basis;

4.2.2 optimisation and completion:

(a) ensuring all Use Cases are up to date with all relevant Horizon or HNG-
X changes and are collectively consistent; and

(b) giving visibility of the HNG-X Requirements to Fujitsu Services in order
to obtain feedback from a solution perspective on any optimisation or
improvement opportunities. It is recognised that these HNG-X
Requirements are still subject to change and that any solution activities
based on this material may be impacted once the final Requirements
Baseline has been issued.

Schedule B6.1 Annex 11 Version 14.0
Page 30 of 39

FUJ00234921

FUJ00234921
CONFIDENTIAL

4.3

4.2.3 further Requirements Baseline: if the above process results in amendments to
the HNG-X Requirements, the Requirements Baseline will either be revised or re-
issued.

Roles
The assurance role will encompass the need to:

4.3.1. ensure compliance — by supporting the business analyst teams of both Parties in
following the Requirements Definition Process and their use of the underlying
tools and standards, and in producing deliverables that meet the defined quality
standards;

4.3.2 achieve assurance — by reviewing the business content of the HNG-X
Requirements artefacts for accuracy and completeness, and by enabling effective
dialogue, optimisation and handover activities with the Fujitsu Services Design
Authority;

4.3.3 ensure integrity and consistency — by applying ‘whole service’ and ‘cross service’
assessments of HNG-X Requirement definitions, shared or common
specifications, and the relationship between newly specified and retained
functionality; and

4.3.4 maintain the Requirements Baseline — by establishing processes for identifying
the various sources of change that will occur throughout Project HNG-X and
managing their application to the Requirements Baseline.

This participative approach will however recognise the overriding roles and
responsibilities of Post Office (in terms of HNG-X Requirements Assurance) and Fujitsu
Services (in terms of solution definition, build and implementation) in this process.

PART 2 - HNG-X REQUIREMENTS BASELINING PROCESS

An initial version of the full set of Functional Requirements will be provided to Fujitsu
Services as part of Post Office issuing an initial Requirements Baseline at the end of the
Requirements Stage. As HNG-X Requirements Assurance may not have been completed
at this point, further amendments to the initial Requirements Baseline may be required in
order to take account of amendments, additions or deletions to HNG-X Requirements as
a result of HNG-X Requirements Assurance. Where the overall impact of such changes
is significant, the Requirements Baseline shall be re-issued by Post Office. Where the
impact is minimal, there would be no need to re-issue the Requirements Baseline and
any amendments shall be dealt with in accordance with paragraph 6.2 of this Schedule
B6.1.

Individual HNG-X Requirements that are not produced as part of the Functional
Requirements Definition Process described in Annex 11 Part 1 may be baselined prior to
establishing the final Requirements Baseline. This approach will enable Fujitsu Services
to make design or solution decisions with more certainty where necessary. At the date of
signature of CCN1200, the HNG-X Requirements are as described in Annexes 3 to 10 to
this Schedule B6.1 and will be marked as baselined at version 0.2. HNG-X Requirements

Schedule B6.1 Annex 11 Version 14.0
Page 31 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

which become individually baselined after this date will be marked as such in DOORS
and formally handed over to Fujitsu Services ahead of the full HNG-X Requirements set.

For the avoidance of doubt, Fujitsu Services shall not be entitled to reject or refuse an
HNG-X Requirement that complies with the provisions of this Schedule B6.1 other than
in accordance with Clause 34.5.

PART 3 — NON-FUNCTIONAL HNG-X REQUIREMENTS RELATING TO THE USER
INTERFACE DEFINITION PROCESS

The non-functional HNG-X Requirements relating to the HNG-X User Interface will be
established and assured in accordance with the CCD entitled “Establishing and Assuring
the HNG-X User Interface” (REQ/GEN/PRD/0001).

For the purposes of the HNG-X Programme Requirements Change Control Process,
these HNG-X Requirements are categorised as "Type B".

PART 4 —- HNG-X REQUIREMENTS RELATING TO THE POSTAL SERVICES DEFINITION

PROCESS

The Functional Requirements relating to the Postal Services will be generated by
following the Functional Requirements Definition Process set out in Part 1 of this Annex
but will be established and assured as defined in the CCD entitled “Postal Services
Business and Operational Context” (REQ/CUS/BRS/0001) by following the Postal
Services Assessment Guidelines in place of the guidelines in Annex 1.

The non-functional HNG-X Requirements relating to the Postal Services will be
established and assured in accordance with the CCD entitled “Postal Services Business
and Operational Context” (REQ/CUS/BRS/0001).

PART 5 — HNG-X PROGRAMME REQUIREMENTS CHANGE CONTROL PROCESS
INTRODUCTION

The HNG-X Programme Requirements Change Control Process is owned by the Post
Office HNG-X Programme Manager and the Fujitsu Services' HNG-X Programme
Manager, and is intended as a mechanism which applies a discretionary level of control
to the scope of the HNG-X Requirements without invoking the Change Control Procedure

An HNG-X Programme Change Authority will be established with representation from the
Fujitsu Services' Design Authority and the Post Office Design Authority who will be
responsible for the initial impact assessment of proposed changes and for recommending
to the Post Office HNG-X Programme Manager and the Fujitsu Services' HNG-X
Programme Manager whether a change can be dealt with within their level of authority.
Final responsibility for this decision remains with the Post Office HNG-X Programme
Manager and the Fujitsu Services' HNG-X Programme Manager.

The treatment of a proposed change will differ depending on whether the HNG-X
Requirement to which the change is proposed has been baselined, has been baselined
at high level, or is still under development. These are categorised respectively as “Type

Schedule B6.1 Annex 11 Version 14.0
Page 32 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

21

A’, “Type B” and “Type C” HNG-X Requirements, with their treatment described in
paragraph 2 of this Part 5 of this Annex. New HNG-X Requirements are categorised as
“Type D”.

Subject to paragraph 1.5, the HNG-X Programme Requirements Change Control Process
will cease to operate after the end of the Requirements Stage, after which changes to
HNG-X Requirements will be dealt with through the Change Control Procedure.

After the end of the Requirements Stage, the HNG-X Programme Requirements Change
Control Process shall continue to apply to:

1.5.1 the management of changes or additions to the HNG-X Requirements as a result
of HNG-X Requirements Assurance or HNG-X Solution Assurance in accordance
with paragraph 6.2.2 of this Schedule;

1.5.2 the management of a deviation of a Postal Services Requirement from the Postal
Services Assessment Guidelines in accordance with paragraph 6.2.3(b) of this
Schedule;

1.5.3. for any HNG-X Requirement other than a Postal Services Requirement, the
management of a deviation from the Business Equivalence Principles in
accordance with paragraph 6.2.3(a) of this Schedule; and

1.5.4 for any HNG-X Requirement, the management of an inconsistency between that
HNG-X Requirement and (a) an HNG-X Assumption related to that HNG-X
Requirement (and set out or referred to in the same Annex to this Schedule as
that HNG-X Requirement) or (b) the HNG-X Assumption set out in Annex 12, in
accordance with paragraph 4.1.2 or 4.1.3 of this Schedule (as the case may be).

TREATMENT OF DIFFERENT TYPES OF HNG-X REQUIREMENTS
Non Baselined Functional Requirements (Requirement Type C)

2.1.1. Any Functional Requirement which has not been individually baselined and which
does not depart from the Business Equivalence Principles is regarded as under
development and is not subject to the Change Control Procedure or HNG-X
Programme Change Assessment.

2.1.2 Where the generation of a Functional Requirement deviates from the Business
Equivalence Principles (as recognised by the author of the HNG-X Requirement
or as identified during HNG-X Requirements Assurance) and is not the result of
an Agreed Change, an assessment will be made by the HNG-X Programme
Change Authority against the conditions for an Allowed Change as set out in
paragraph 4.2.3 of this Schedule B6.1 as follows:

(a) where the HNG-X Requirement is agreed as fulfilling the conditions of
an Allowed Change, the agreement will be logged by the HNG-X
Programme Change Authority as an Allowed Change and the HNG-X
Requirement may continue to be developed without recourse to the

Schedule B6.1 Annex 11 Version 14.0
Page 33 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL
Change Control Procedure or HNG-X Programme Change Assessment;
and
(b) where the HNG-X Requirement does not fulfil the conditions of an

Allowed Change, the HNG-X Requirement must be passed for HNG-X
Programme Change Assessment or reverted to a definition which
accords with the Business Equivalence Principles.

2.2 Requirements Baselined at High Level including Agreed Changes (Requirement
Type B)

2.2.1

HNG-X Requirements, including Agreed Changes, which are baselined at high
level may be described or elaborated in more detail within the scope of the high
level HNG-X Requirement without recourse to the Change Control Procedure or
HNG-X Programme Change Assessment. However, where the elaboration of the
HNG-X Requirement extends the scope (as recognised by the author of the HNG-
X Requirement or as identified during HNG-X Requirements Assurance or HNG-
X Solution Assurance, and which for Postal Services Requirements shall be
assessed against the scope defined in section 4 of the CCD entitled “Postal
Services Business and Operational Context” (REQ/CUS/BRS/0001) using the
Postal Services Assessment Guidelines), an assessment will be made by the
HNG-X Programme Change Authority as to whether the extension of scope fulfils
the conditions that it must have an acceptable cost, time, risk and resourcing
impact on Project HNG-X and appropriate actions will be taken as follows:

(a) where the extension of scope is agreed as fulfilling the above conditions,
the extension of scope will be adopted under the governance of the
HNG-X Programme Change Authority and the HNG-X Requirement or
Agreed Change may continue to be developed without recourse to the
Change Control Procedure or HNG-X Programme Change Assessment;
and

(b) where the extension to scope does not fulfil the above conditions, the
extension to scope must be passed for HNG-X Programme Change
Assessment or reverted to a definition within the scope of the higher
level HNG-X Requirement.

2.3 Baselined Requirements (Requirement Type A)

Once an HNG-X Requirement has been agreed and individually baselined, any proposed
change to that HNG-X Requirement will be passed for HNG-X Programme Change
Assessment. Following the formal handover of the final Requirements Baseline any
HNG-X Requirements which have been assessed as deviating from the Business
Equivalence Principles (in the case of all HNG-X Requirements other than Postal Services
Requirements) or the Postal Services Assessment Guidelines (in the case of Postal
Services Requirements) shall also be passed for HNG-X Programme Change
Assessment.

2.4 New Requirements (Requirement Type D)

Schedule B6.1 Annex 11 Version 14.0

Page 34 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

2.5

3.1

3.2

3.3

3.4

3.5

4.

New HNG-X Requirements will be initially assessed by the HNG-X Programme Change
Authority to determine whether they fall within the definition of an Allowed Change. When
the HNG-X Requirement is not assessed as an Allowed Change it will be passed for HNG-
X Programme Change Assessment. When the HNG-X Requirement is assessed as an
Allowed Change it will be processed as an HNG-X Requirement Type C in accordance
with paragraph 2.1 of Part 5 of this Annex.

Fujitsu Services may propose that any additional or new HNG-X Requirement be subject
to a caveat detailing any exceptions to full compliance in respect of that particular HNG-
X Requirement only (and not in respect of any HNG-X Requirement already forming part
of the HNG-X Requirements Catalogue) and the Parties shall, acting reasonably and in
good faith, agree whether to adopt that caveat in respect of that particular HNG-X
Requirement.

HNG-X PROGRAMME CHANGE ASSESSMENT

Proposed changes to HNG-X Requirements, new HNG-X Requirements and any
changes or additions to the non-functional HNG-X Requirements relating to the HNG-X
User Interface or Postal Services which are passed for HNG-X Programme Change
Assessment will be initially assessed by the HNG-X Programme Change Authority to
determine whether the change is likely to impact time or cost beyond the level of authority
of the Post Office HNG-X Programme Manager and the Fujitsu Services' HNG-X
Programme Manager, or whether there is likely to be any impact outside of Project HNG-
x.

Where the change will clearly exceed this authority or will clearly have an impact outside
the Project HNG-X, the change will be dealt with under the Change Control Procedure (or
agreed with the author to be rejected).

Where the change appears likely to have minimal impact such that, considered with other
proposed changes, it can be managed within the level of authority of the Post Office HNG-
X Programme Manager and the Fujitsu Services’ HNG-X Programme Manager and has
no impact external to the Project HNG-X, the change will be passed to the appropriate
team within Fujitsu Services or Post Office to undertake further impact assessment (under
the control of the HNG-X Programme Change Authority).

If the further impact assessment referred to in paragraph 3.3 of this Part 5 confirms the
initial assessment, the change will be approved and the HNG-X Requirement can be
updated accordingly, subject to the final approval of the Post Office HNG-X Programme
Manager and the Fujitsu Services’ HNG-X Programme Manager. Once approved, if the
change relates to a Functional Requirement, the change shall be deemed to be an Agreed
Change. The baselined status (as indicated by the Requirement Type A, B C or D) of the
HNG-X Requirement will not be changed by this process, but the version number of the
HNG-X Requirement will be updated accordingly.

If the further impact assessment referred to in paragraph 3.3 of this Part 5 rejects the
initial assessment, the change will be dealt with under the Change Control Procedure (or

agreed with the author to be rejected).

RECORDING OF CHANGES

Schedule B6.1 Annex 11 Version 14.0
Page 35 of 39

FUJ00234921
FUJ00234921
FUJ00234921
FUJ00234921

CONFIDENTIAL

All changes which are agreed as “Allowed Changes” or “Agreed Changes” shall be logged as
such by the HNG-X Programme Change Authority. This log shall initially be formed from the
information in Annex 2 to this Schedule as at the date of signature of CCN1200 and subsequently
maintained by the HNG-X Programme Change Authority throughout Project HNG-X.

Schedule B6.1 Annex 11 Version 14.0
Page 36 of 39
CONFIDENTIAL

ANNEX 12
GENERAL ASSUMPTION

Only one assumption has been identified as being of general application to the HNG-X
Requirements. This is stated below:

General Assumption 01

The existing Horizon Icon Design Service will not be continued for the HNG-X System. There will
be a limited set of icons agreed during the HNG-X User Interface design phase, which may be re-
used as appropriate in the HNG-X User Interface. Any proposed changes or additions to the
agreed set will be dealt with in accordance with the Change Control Procedure.

Schedule B6.1 Annex 12 Version 14.0
Page 37 of 39

FUJ00234921
FUJ00234921
CONFIDENTIAL

FUJ00234921

FUJ00234921

ANNEX 13

CHANGES DELIVERED (OR TO BE DELIVERED) AFTER RELEASE S92 AGREED AS
PART OF THE APPLICABLE HORIZON BASELINE

POL CR ref.

Change Work
Package ref.

Summary description

PSO_FSL_CRO0968_FS PWY_CWP_530 Receipt Template for Automation of
Travellers Cheques ADC Product
PSO_FSL_CR00680 PWY_CWP_525 Including figures for cash in pouches in

(Note: Subject to
being approved)

Flexible Planning input

PSO_FSL_CRO0956 PWY_CWP_520 Gift Voucher Shop Receipts

PSO_FSL_CRO0950_FSv2 I PWY_CWP_517 Generic Branch Receipt Template

PSO_FSL_CR00326 PWY_CWP_404 Provision of DR capability to connect
POLFS users to POLFS when NDC is not
available.

PSO_FSL_CR00925_FS PWY_CWP_508 Cessation of the BBC AP interfaces

PSO_FSL_CR00921v2 PWY_CWP_505 PostShop Receipt Template (applicable to
the Superstock Service from 1st April 2010)

PSO_FSL_CR0893 PWY_CWP_496 Implement changes to XI as identified in the
changed functional spec

PSO_FSL_CR00786 PWY_CWP_481 A &L Sequential Referencing onto ADC

PSO_FSL_CR00754 PWY_CWP_471 Shopping Basket Finance Integration
(Flowers and Travel Insurance)

PSO_FSL_CR00744 PWY_CWP_466 Transmit PDR data from Horizon to POLFS
and MI system.

PSO_FSL_CR00734 PWY_CWP_457 Amend Horizon to accept 5 digit item
numbers

POLCC_FSL__CR0077 PWY_CWP_453 BAU - New Barcode range for P6097
Labels

POLCC_FSL_CR0693 PWY_CWP_437 Removal of a line on the Despatch Report

PSO_FSL_CR00531 PWY_CWP_414 Quantity function in Smartpost to operate
when PAF is optional and not selected.

PSO_FSL_CR00584 PWY_CWP_410 New despatch report for existing client

PSO_FSL_CR00583 PWY_CWP_409 Country of destination on T& T message

Schedule B6.1 Annex 13 Version 14.0

Page 38 of 39
CONFIDENTIAL

FUJ00234921
FUJ00234921

POL CR ref.

Change Work
Package ref.

Summary description

POLCC_FSL_CR00547 PWY_CWP_393 New Algorithm Condition permissible in
Field Validation

PSO_FSL_CR00873 PWY_CWP_494 New AP-ADC Data Type - StackLookup

PSO_FSL_CR00781v2_FS I PWY_CWP_480 Mails Receipt changes

PSO_FSL_CR00756 PWY_CWP_474 Allow today's date to be used in selecting
the date range on the Office Weekly Sales
Report

PSO_FSL_CR00728 PWY_CWP_456 Cut Off facility for the Office Weekly
Postage Labels report

PSO_FSL_CR00727 PWY_CWP_455 Date Range for Daily Rem reports

POLCC_FSL_CR0073 PWY_CWP_439 Rejected Postage Label Report

POLCC_FSL_CRO071 PWY_CWP_423 Printing Retailer Logos on Retailer branded

Orders

Schedule B6.1 Annex 13 Version 14.0

Page 39 of 39