POL00031114
“FAX TRANSMISSION .
’ . . . BIRD & BIRD
. 90 Foner Lane
To:. . BA/POCL London ECHA IP
Atten\Ref: Gcorge McCorkell FaxNo:) 1
ce: - Paul Rich, POCL Fax No?!
Pat Kelsey, BA/POCL Fax No GRO
Andrew Davies, Project Mentors Fax No: ! Were
From: Hamish Sandison rnennsblckcom
Client: BA/POCL
AccountNo: BPOCL/001 ‘ Patears
Danis
Date: 18 December 1998 Ouen nas
TM Cook
Time: pd
Pith
Number of pages (including this page) : abe bevisieitaaal
: IRCWetey
- Note: This fax is intended for the named addressee only. It contains information which may be confidential and Dior
Which may also be privileged. Unless you are the named eddressec (or euthorisod to receive forthe addressec) Macdonald
you may not copy or use it, or disclose it to unyone else. If you have received it in error please notify us Omctone
immediately so that we can arrange for its retum. To do so, or if you have any queries, please telephone CW Res
ny POCinan
WR Sandon
Dita
R)Werd
Cm Contwate
~ NT denking
RM Bidet *
Sk Topping
Teateter
HE Person
VSA Crook
TROABenon
SSeannard
1K Banee
OCI Cok *
Morr
MR Hike
Chow
AiSonderion
a “Hae
IWasker
PRBromion
1D ewer
. FAReve
104
Pepary
NSP Blundett
Whence
. GRO
Corsghiants
ETC Ameld
SNLGutn
PyDim
RE Paweeee
Oxterwatdent
[C Office 2094 Avenut Louise, 1050 Brussels, Belgium Telephon Facaim
Hong Kong 20VF Printing House, 10 lee Houxc Street, Central, Hong Kong Telephone 4 GRO I * epoca setiatoe
P.001 B
18/12 '98 15:06 TX/RX NO.
POL00031114
POL00031114
18-DEC-1909 15:01 FROM BIRD & BIRD TO p.02-26 4
BIRD & BIRD
Our Ref 90 Fetter Lane
» London EC4A 1)P
Your Ref: . MEMORANDUM
Legally Privileged & Confidential
TO: George McCorkell, BA
4 Paul Rich, POCL
. Pat Kelsey, BA/POCL Programme
cc: Andrew Davies, Project Mentors (without encs)
FROM: Hamish Sandison, Bird & Bird ¢
DATE: 18 December 1998
RE: PROJECT MENTORS REPORT
wn
ra war 2
Ll. Further to my Memorandum dated December 8th, 1 attach the full report of the
work by Andrew Davies and his team on requirements analysis, This, is Alcshes « out the
brief update from Andrew which I sent you with my December Sh Memorandum. As
you will see, all three of Andrew’s team are (I quote from Andrew’s letter to me)
“deeply concerned that their findings show a serious problem with the way in which
ICL Pathway have developed the system, The impact of this is likely to be that there
will be failures to meet essential user requirements, causing. the need for extensive rée-
work before the system can be accepted and, potentially, operational problems The
System is rolled out.” . -
eee
2. As with previous reports, this report j is legally privileged on the basis that it
has been commissioned by us as the Joint Programme Lawyers. Accordingly, it
should be given the most limited possible circulation on a need to know basis.
3. Please do not hesitate to get in touch with me or with Andrew direct if you
have any questions or comments.
C :
2) [C Office 2094 Avenue Louise, 1050 Brussels, Belgium Telephone.
(CXTESTOR IN CoOrLE Hong Kong 20/F Printing Houte, 16 Ice Houte Strect, Ceniral, Hong
18/12 '98 15:06 TX/RX
ox
19 London
Web Page
wwwtwobieds.com
Partners
O Henge
Gteures
OM Gaphe ste
TM Cook
RNSot
icone
Penh
DW ayam-cook
SI Smah
iRcwntiey
OKere
Macdonald
OMCSiene
Cweees
PDQunan
MR S2n0KOn
Dilan
Ry ward
CM Ceosthmalte
1 Cention
RMBicherall
SK Tooning
TEC Taher
HE Peano
VSACwOR
TRU ASERON
JSvenad
CIR Barnet
DCJ Cook
IM Gynges
MRMae
GPowelt
Aj Sardenon
Wins,
IW Baker
PK eromnlow
1D Homer
Fame
1Siens
rcoaty
RH Burcrworth
NSPeetundelt
Consultants
RT CAmolt
SNLChatOn
F1Ds00
RE Fawtent
Det Walden?
snot a soticlioe
P.002 B
Project Mentors
Mr. Hamish Sandison
Partner
Bird & Bird
90 Fetter Lane
LONDON EC4A JP
Dear Hamish,
independent Consuitant Review of BAPOCL Payment Card programme
Privileged and confidential. Prepared in contemplation of litigation
Position paper on Requirements Analysis
We have new completed @ provisional version of our postion paper on requirerert
analysis, a copy of which I attach. We are of the opinion that the findings of this paper
gue serous concer thal the Payment Card System has been devaoped in > mente
Be eit S breach of the contract rating fo ‘he requirement in Clause 702 of 8
that creates ¢ Memento work fo ‘geod industry pracice’ and that the impact of 18
Autores aise be that the system wil rat be for purpose unless exensive fe-05%
is camied out before implementation, causing further J and additional investment by
Pathway and the Authorities. en
innate
‘Tne following paragraphs summarise the key conulusions from chapter 2 of the paper.
‘We nave performed @ requirements analysis fer BPS, which is predominantly a BA
eee emont. From our analysis we conclude that Pattway fave made no sferet ©
aerjertake requirements analysis in accordance with normal industry practice. This is
despite their having access to the SSR and subsequent requirements since Apri 1996.
eee fines work could, and should, have been done doing the demonstrator period
In more specific terms, we conclude that:
* DaSs's requirements were complete in scope at the time of contract signing, but
incomplete in dotall, as was only to be expected
. only at @ delaied level wore them gaps and contradictions ia the DSSS
understanding of their requirements;
. Pathway failed to satisfactorily enalyse the DSS's requirements during the
cmcurement process and a8 @ result significa ly underestimated the effort and tie
required to develop their solution:
* the period since contact signing Pathway nave failed fo salsfactonly analyse te
DSS's detaied requirements. ‘AS a resul they have designed and partially buit a
system without knowing whether it fully meets the DSS's requirements
Pathway have faled (0 emolay ‘gacd practice’ fechniques for establishing, dotaiee!
ts, in preach of Clause 702 of the Autnotities Agreement. None of Pathways
claims that requirements were poorly defined and / or have since been expanded to
‘Prajeca Mertars Unies
recincren en Engtend na BSE Regier Often 9 por High @teet These or
18/12 198 15:06 —-TX/RX NO.[GRO/
P.003
POL00031114
POL00031114
POL00031114
POL00031114
1G@-DEC~19e3 :o:g2 FROM BIPD 3 BIRD
Bar 2e
Project Mentors
necessitate an optimised solution are sustainable, indeed, the very examples they have eo
enea ade! weight to the case that they have failed to undertake selistactory
requirements analysis.
Our experience of systems where requirements have not been analysed satisfactorily is
that the system fails to meet the users’ needs. Ar effective acceptance test will identify
many such failings, necessitating considerable rework The result 8 @
cxteision of the time and cast required to complete the system and rol out. The
sitemative is to allow unacceptable processing * the operatonal environment, with
unpredictable and potentially damaging results.
in our opinion the failure to satisfactonly analyse the requirements for the Benefite
Payments System makes it untkely thal the users needs wil be met by the current
Pathway system’
We do not bolleve, from our understanding of other elements ‘of the complete Payment
Card System, that these other elements have been analysed using betler techniques
than for the Benefits Payment System, so there is @ concem that user needs for these
elements will also not be met by the current Pathway system. e
We would be grateful if you would pass these conclusions to the Authonties so that they
May consider their impact on the current deliberations.
Page 2
18/12 ‘98 15:08 —tx/Rx no.{GRO; P.008 ]
POL00031114
POL00031114
Eimaat oe Ista = STs ee {GRO} S
4
Privileged and confidential. Prepared in sgntempiation of ligation.
@
BIRD & BIRD
Project Mentors
P.005 ge
18/12 '98 15:06 TX/RX NOSIS
POL00031114
POL00031114
PRON BIeD & BIRD
> [GRO I
Privileged and confidential. Bird & Bird Prepared in comampiation of tnigation.
Expert review of BA/FOCL Payment Card Programme
PB BS
POSITION PAPER
Requirements Optimisation
Ref: AG2Z.0T V1.2 @
Status: Provisional
Prepared By. J Pimpernell / A Wing
Prepared On: 47 Dec 1998
Prepared by Proytet Mentors Lid, noting av dma wtractars te Bid & Bint, Balicitory
18/12 '98 15:06
P.O06 a
Privileged and confidential. Bird & Bird _ repatad in contemplation of Ragation.
Expert review of BAPOCL Payment Card Programme
Position paper - Requirements Optimisation
SEGTION
1, Introduction
Ad Background
1.2 Purpose of Document
1.3 Scope
Ll Structure of Document
2. Conclusions and Impacts
21 introduction
22 Conclusions
23 Impacts on the Programme to Daie
231 Introduction
22 u °
23.3 Estimating and Planning
23.4 Other Blements of the System
24 Impacts on the Programme in the Future
3. Approach
BL Assessment of Pathway “Examples”
43.2 Draft Requirements Analysis
4.3. Changes Found
3.4 Time Scale
4. Findings
4.1. Extended Verification Procedure
41.1 issue
4.1.2 Analysis
4.2 Foreign Enoashments
42.1 Issue
42.2 Analysis
43 BSS Reference Dato
434 leone
4.3.2 Apalysis
44 Contradictory and Misleading Requirements
44.1 Issue
442 Analysis
45 Change Control isswes
45.1 Issue
45.2 Analysis
PASE
~~
a whee an we
we
Sew vee ©
ea
we
”
ul
u
pb
R
Prepared by Project Mentors U0 ating as eub-s atractors fo Bird & Bird, Sofokore
18/12 *98 15:06 TX/RK NO
P.007
POL00031114
POL00031114
POL00031114
POL00031114
46-DEC~1999 19733 FROM BIRD 3 BIRD
rooT 1
Priviteged and confidential. Bird & Bird Prepared in contempiation of iaigation.
Expert review of BA/POCL Payment Card Programme
Position Paper - Requirements Optimisation
PDE
1 INTRODUCTION
44 Background
As part of the expert review of the BA/POCL Fayment Gard Programme, we have
reviewed ICL Pathway's undated paper of 53 pages entived “Selection of Examples
of Problems Facing Pathway As Set Out In ‘The Pathway Position Papor Dated
6 Mare: 1998". Their paper presents @ number of claims about changing and
undiear requirements.
Investigation of those claims required us to axamine the business requirements
expressed at the time of contract signing and compare them against the current
understanding of the DSS's requirements. We therefore reviewed decurnents from
both the Authorities and ICL Paihway which contained the definitions of those
requirements,
We were surprised to discover that ne detailed analysis of the requirements, an
essential process for successful {T development, appears to have heen performed.
To allow us to compare current requirements with the original requirements, the
review team therefore selected the Benefits Payment System (BPS) element of @
the system as @ sample, and assembled a draft requirements analysis.
This work was based on documents from both the Authorities and Pathway, ‘
together with very limited informal discussion with BA staff at Terminal House. qt
12 Purpose of Document
This paper sets out our findings from analysing the requirements from the BPS, in
terms af:
« identifying what approach Pathway adopted to establish the detailed business
requirements;
« considering the validity and merits of the claims mede by Pathway,
« assessing the probable past and future irapact of the approach adopted by
Pathway.
13° Scope
Effective business requirements analysis is needed to achieve a satisfactory,
comprehensive business design. This can then be used as the basis for the f
technical design of the high resilience, high volume system to deliver the required
service. We have not been able to consider whether the technical design process
has been conducted satisfactorily. aA
We have to date considered only the BPS system, Further work has recently Ca
started to perform @ similar assessment of the approach adopted for other sloments bo
af the system, such as EPOSS, Nevertheless our findings are, in our view,
sufficiently serious 4e-question the whole of Pathway's design process. i)
Prenated wy Preect Mentor Ud. acting a6 Rat AGF VS.2 ‘Date: 17 Geo 1908
sub-comactors to Bird & Bied, Sokotore Statue: P euizionst Page $
18/12 '98 15:06 TRARX Ni
P.008 I
' Boviteged and confidential. Bird & Bird Prepared in comemplation af itigation.
Expert review of BAIPOCL Payment Gard Programme
Position Paper - Requirements Optimisation
4.4 Structure of Document
in this paper we have set out
= the conclusions drawn from our analysis of fle requirements for @P$, together
with the impact we believe the tack of forma _fequirements analysis has had on
development to date and the consequences far the future;
« @ broad description of the approach we took jn developing our analysis of BPS
requirements;
* our findings with respect to the specific requirements related charges made by
Pathway.
in Appendix A, we give brief overview of the nature of requirements specification
and analysis
renee ee “» cs
ees tartan Saat’ * — SihatPtte ae
18/12 198 15:06 -TX/RK NO. gRO.
P.009
POL00031114
POL00031114
2A
22
POL00031114
as POL0003
seg iS:04 FROM BIRD & BIRD ee = 1414
Privileged and confidential. Bird & Bird Preparedin COMte MPAA Us wean: ® 20/26
Expert review of BAPOCL Payment Card Progeammne
Position Paper - Requirements Optimisation
CONCLUSIONS AND IMPACT: s
introduction
From the succeeding Chapters: of this paper it can be seen that we have performed
an initial requirements analysis of the BPS element of the system. We had expected
to base this on documents developed by Pathway showing 3 detailed analysis ot
the contracted business fequirernents. Such documents do ‘not appear to exist and
we had to base our analysis on the original and current business requirements.
At present, we_have no access to Pathway's internal documentation. and
consequenty_cannot tell for certain what Pathway have done in terms of
Tequirements analysis. HEwever, to documents Zoognisable as formal, oF indeed
informal, requirements analysis papers appear to have been passed {0 the
Authorities. 18 is. possible that formal analysis has been carried out by Pathway, but
we consider this unlikely from what we nave ‘seen and from the continuing problems
experienced in development of the syste.
Conclusions
ie must be remembered that So far we have only performed the requirements
analysis for BPS, whieh Is predorninanty @ BA system element However, from our
analysis we sconcude that Pathway made no attempt to undertake requirements
analysis in accordance with normal industry practice ‘This despite their having
access to the SSR and gubsaquent requireme nts since April 1996. Much of this
work could, and should, have been done during the demonstrator period.
in mare specific terms, we canckide that
» O88's requirements were complete in scope at the time of contract signing, but
incomplete in detail, as was only to be expected;
+ only at a dotailed level were there gaps and contradictions in the DSS's
understanding of their requirements; .
« Pathway faited to satisfactorily analyse ine DSS's requirements during the
procurement process and as @ result significantly underestimated the effart and
dime required to develop their solution;
« inthe period since contract signing Pathway have failed to satisfactorily analyse
the DSS's detailed requirements. Ag @ result they have designed and pactially
built a system without knowing whether tt fully meets the DSS's requirements;
* Pathway have failed to employ ‘good practice’ techniques for establishing
detailed requirements, in breach of Clause “02 of the Authorities Agreement.
None of Pathway's claims that requirements were poorly defined and for have since
peen expanded to necessitate an optimised solution are sustainable. indeed, the
very examples they have raised add weight (0 the case that they have failed to
undertake satisfactory requirements analysis.
Prepared by Project Mentors Lid, Rating as fet AALOTNES Date: 17 Oe 18s
gup-contractocs te Girt & Bled, Beietory ‘Stakes: Peeeioional wage S
18/12 198 15:06 —-TK/RX NO.
Fe
POLO
® Position Paper ~ Requirements Optimisation
Priviteged and confidential. Bird & Bird Prepared in scontempiation of tigation.
Expert review of BA/POCL Payment Card Programme
23 impacts on the Programme to Date
2.3.1 intreduciion
Without having completed an analysis of the business requirements set out in the
contract, Pathway can never have been in a position to understand the detail of the
those requirements. Without that detail it is not possible to develop 2 system Jevel
specification to bridge the gap between requirements and program specifications.
Without such a system specification itis very difficult to design programs jn a way
wdich ensures that all system fequiraments are fully catered for.
2.3.2 “Optimisation”
Failure to complete requirements analysis and the consequent lack of detailed
understanding of what is required is, we believe, ‘at the heart of Pathway's
complaints that the Authofities are “seeking to optimise the system’. What they see
as optimisations are in reality the detailing ‘of the business requirements which a
competent analysis would have identified:
« much more comprehensively,
+ much earlier in the project, giving all parties more opportunity to consider and
agree options:
= at a point where they could have been incorporated into a coherent design at
minimal cast.
23.3. Estimating and Planning
Requirements analysis & @ fundamental requirement for estimating the effort
required to develop software. The most accurate estimates can be produced from
program specifications, thamselves produced trom & system specification which is
itself derived from detailed requirements analysis. However, there are well
accepted tools, such as Function Point Analysis. which enable reasonable estimates
to be made fram the functions identified during requirements analysis. Without
estimates it is not possible to establish resource requirements nor to develop a
soundly based schedule.
2.3.4 Other Elements of the System
While we nave so far only completed work on the BPS system elament, we have
grave concems that the same lack of professional analysis will be apparent in other
areas as We come to review ther. This concem is supported by @ number of
release design documents to OCL While they have on occasion cited
intellectual Property Rights es @ reason for refusal, we sare becoming Pe
suspicious that the real reason is that the fight level of doc simply has
rettetr developed.
Of particular concem is the EPOSS system. We are informed that at & relatively
early stage Pathway wanted the ‘Authorities, principally POCL, to be Involved with
the design of this element. The plan was to use the Rapid Application Development
Prepared by Protect Mentone Lid. acting a Ref AALOT V2 Date: 17 Dee 1855
subcontractors te Ged & Bird, SaleRore Stalus: Frovsional Page 4
18/12 ‘98 15:06 TA/RK We
oa
> §
2a
P.O1l
POL00031114
POL00031114
48-DEC~1.999
POL00031114
POLO0031114
24
FROM BIRD 2 BIRD 1
Privieged and confidential. Bird & Bied Prepared in contemplation of figaton.
Expert review of BAPOCL Payment Card Programme
Position Paper - Requirements Optimisation
(RAD") methodology to design this system. This approach was started, Dut
discontinued after some months, when the Pathway staff member invotved left the
project. The suggestion to use RAD leads us fo believe that more traditional
methods have not been used, and since the RAD experiment was abandoned, we
have doubts whether any proper requirements analysis has been performed.
impacts on the Programme ie the Future
Our experience of systems where requirements have not been analysed
satisfactorily is that the system fails to meet the users’ needs. An effective
acceptance test will identify many such faifings necessitating considerable rework.
‘The result is @ significant extension of the time and coat required to complete the
system and roll it out. The alternative is to allow unacceptable processing in the
operational environment, with unpredictable anc potentially damaging results
In out opinion the fallure to satisfactorily analyxe the requirements for the Benefits
Payments System makes # unlikely that the users needs will be met by the current
Pathway system.
Proparns wy Project Meare Lid. acting #s Ref ALOFT Dates 17 Dee 1908
syenoniactors to Bid & Bind, Solicitors Stabe: Pari Page &
18/12 798 15:06
Privileged and confidential. Bird & Bird Prepared ie contemplation ‘at Rtigation.
Expert review of BAIPOCL Payment Card Programme
Position Paper - Requirements Optimisation
APPROACH
Assessment of Pathway “Examples”
Many of the examples quoted in Pathway's paper claim that initial definition of
requirements was ‘of poor quality. and / or that there fas been nit
expansion of those requirements. To assess the validity of those claims, Wo
needed to compare the requirements as defined at the award of cantract with the
current definition of those requirements.
Ag set out in Appendix A. requirements: analysis. ig the vital first step in tuming high
level business requirements into systems spetifications from which software can
successfully be developed. We had anticipated therefore that out comparison
would be between @ requirements analysis postcontract and the current version of
that analysis. We could find no evidence in either the Horizon library list or DSS
ibraries_of_sueh_ananalysis, Giscussions “Want USS stair ar Vemnmnal FOuUss.
Norcross and Longbenton failed to identify any unrecorded but relevant documents.
We therefore axamined the Pathway documents set out in Table 2.1 below, to
assess whether they in whole or in part could be considered as supporting
Requirements Anatysis.
Table 2.1- Pathway Documents Reviewed
‘Document
Fundional Specttication Version 6.0
SADD Version 4.0
Foreign Encaahments EHFSP 0009 Versions 4 and &
(CCNIA7—Supparting Dodumertation, CRGNICON1 17
CEN 068s T Gne Payment Receipt Gnd tne Signature Required for each
Transaction {PDA Change Request 80005)
bSGHEaIN < Resticted PO Indicator Operation
ZEN Beda - Ganirate Card Stop folewing CMS End of inierett
EERE enone Series High Level Design, SUMES001
POL00031114
POL00031114
Where detailed definition of requirements exists, il is distdbuted across the multiple
documents identified and defined usitg different techniques.
In the absence of formal requirements analysis specifications, we consimeted @
draft detailed analysi¢ against which we ‘could examine each Pathway claim.
Prepared wy Project Mentors Ud, acting a Ref, AALOT VE Date: 17 Des 1998
pub-contenctors te Bcd & Bied, Sobctore ‘Status: P evigional Page 6
18/12 '98 15:06 —-TK/RK NOJGRG!
18% NO-[GRoI
P.013 a
POL00031114
POL00031114
AG-DEC-1999 4g:05 FROM BIRD & BIRD Tet
Privileged and confidential. Bird & Bird Prepared in comempravion of tigation
Expert review of BA/POCL Payment Card Programme
Position Paper - Requirements Optimisation
3.2 Draft Requirements. Analysis
This work was based initially 09 the final version of te Authorities’ Statement of
Service Requirements CSSR"). This document was issued to potential suppliers, in
draft in December 1995. and as final version in April 1996. While not a
contractual document, in our view this ie a well produced and thorough document
which would have given any potential supplier the opportunity to gain 2 thorough
understanding af the system through analysis and questioning.
We used the SSR to draw up a Logical Data Model (Lom) and Data Plow
Diagrams (DFDs*}), both well understood tools. common to most formal analysis
methods. Apnendix A sets out a more detailed description of requirements analysis.
This provided us with @ detailed analysis of the original requirements.
Once the initial analysis was complete, we reviewed other available documents to
determine if these changed the analysis jn any significant way. The documents
reviewed at this stage were principally those produced by Pathway, although we
also considered a sumber of CAPS definition documents. Curing this second stage
we also produced definitions ‘of the principal tunctions. These are written using
indentations to show a logical structure, often described as structured English.
33 Changes Found
Once the requirements analysis was completed, we compared the LDMs and DFOs
based on the SSR with their equivatents derived from the current status, We found
no changes of any real subatanae, although, as would be expected:
« there was more detail in the later LOM, but noticeably only in terms of heir being
additional attributes to each of the data entities. There were no new data
entities: .
* the functionality (@s depicted In the DFDs) was fille changed, and in the main
such changes as there were reflected ine identification of processes to deal with
exception conditions.
identified one or two exception cases in terms of business process. While these
may fave been identified by Pathway and 2 or the BA, these cases are not
documented in he programme's technical library.
In our view, the changes found would have been identified by any reasonably
competent analyst following the methods we used or any of the major methods
widely avaiable. Given the SSR as background, and the litte time required, we @
consider much of the functional requirements analysis could have been completed
by suppliers before the contract was aveirded.
24 — Time Scale
Our analysis took four weeks effort from a single consultant, spread over & poriod of
two months. Research on other issues occupied he remainder of his time.
ty Project Mantors Uit.. acting Ret ARLOT VE Dates 17 Dee 1996
gub-contacios te Bid & Beg, Sofieiiaes Statues: Provisional Page 7
18/12 '98 15:06 TR/RK WN P.O14 Ez
POL00031114
POL00031114
Expert review of 8: CL Payment Card Programme
Position Paper - quirements Optimisation
irdl & Bird Prepares m comietigaasaas ws cesmee re
Requirements analysis is an fterativel task, which makes ¢ difficult to be precise
about the amount of tme spent gn each individual activity, However, 4n
approximate break down would be:
« initial (SSR) data model - 2 days
* Current data model - a further 3 42)
» DFDs- 1 week
* Structured English - 2 weeks
While acknowledging that the above re has so far only been completed for BPS,
we pelleve the small amount of Hme required suggests that the business
functionality of inis element of the je system is far from complex, ‘and can be
easily and rigorously modeled using standard tools.
Prepared by Project Mentors Ud. ecting * Ret, AA2O7 Vt Date: 17 Dec 1668
‘Stator: Preedcional Page 8
18/12 '98 15:06 TX/RX NO P.O15 a
18-DEC
I
POL00031114
POL00031114
44
BAA
4.2,
42.4
1S:@6 FROM BIRD 3 BIRD
Privileged and confidential. Bird & Bird Prepared in cont
Expert review of BAVPOCL Payment Gard Programme
Position Peper - Requirements Optimisation
FINDINGS
The Authorities have provided their own responses to the issues raised within the
Pathway paper, Of the 10 items presented in tha paper, the following are related to
OSS requirements:
* Extended Verification Procedure
« Foreign Encashment Rules
+ OSS Reference Data
» Contradictory and Misleading Requirements
« Change Control Issues
Extended Verification Procedure
Issue
The eary history of EVP requirements definigon ifustrates the Authoritios”
interference in design, and enhancement of the sontractuat requirements.”
Analysis.
Pathway’s statement of the issue says it all - “The contractual requirements for the
Extended Verification Procedure (EVP) are vague and fack sufficient definition for
Pathway to develop its golution....”. This being the case, why did Pathway fail to
take steps to establish the detailed requirements?
Foreign Encashments
issue
encashments which Pathway required to know in order to develop Benefit
Encashment Service (BES") functionality. The forsign encashment related
requirements are poonly defined and of fimited use. Pathway has been forced to
define foreign encashment business rules for the DSS. These difficulties have been
compounded by the PDA's failure fo properly manage this issue.”
Pathway's summary of what happened:
“The OSS's inconsistent approach fo its own business miles in this regard became
clear in the course of workshops dunng October 1996, Pathway produced a
document interpreting OSS foregn encashment rules in December 1996, after
which extensive comments have continued to be fecelved from the DSS and the
PDA, some canticting, suggesting semative ties. Version $ of Pathway's Forsign
Encashmant Paper is currently under review.”
repaend by Pract semen, Ud., acting a
‘subcontractors tg Bird & Bind, Salictors
Date: 17 Dee 1808
Page 9
18/12 198 15:06 TR/RK NOP P.016
GRO
LE
422
43
43.4
4.3.2
POL00031114
POL00031114
me
-
Privileged and confidential. Bird & Bird Preperedin comempiauon omar
Expert review of BAPOCL Paymunt Card Programme
Position Paper - Requirements Optimisation
Analysis
The toliowing obsecvatians can be made:
* As the Authorities nad fated to comprehensively express: their business mules,
why had Pathway not produced the detailed analysis that would have reveaied
the gap?
« Why did it take unt October 1996 to convene workshops 10 address foreign
encashments when the contract was signed an May of that year
+ Why did i take further 18 months to get to version 6 of the document that was
stil to be agreed? Only 4 relatively small plece af logic is. necessary to describe
the requirement. This does not require 18 montts work
DSS Reference Osta
issue
“Contractual requirements in rasponse of DSS Reference date are virtually non
existent. Pathway hes had to seek and reconelig extensive information in respect of
DSS reference Data from 3 omganisations (CAPS, ITSA and Glectronic Data
‘Systems (EDS)) in order to develop its solution. These organisations nave not
adopted a uniform or co-orainated epproach to ihe issue and Pathway has, in effect,
been carying out the DSS’ work ‘of analysis in this area. foformation has been
jacking, inconsistent between the 3 organisavons, and generally of poor quality.
This has involved Pathway in extensive anatytioal work not envisaged under
Analysis
it Pathway had performed the detailed data analysis, the ‘refarence’ entities would
nave beer identified and specifications established with OSS. Because the
definitions need to be: complete and precise, any Gaps would have been identified at
ser giage and appropiate steps taken to MINE OA (There ara sore 12 sets
of definitions passed by CAPS to PASICMS relating to business reference data. All
are identified in the data mode! and could have been defined in detail during the
anatysis).
‘The issue of ‘no single point of responsibility within the DSS. Responsibility wes
dispersed aorasé three organisations: CAPS, [TSA and EDS." Is probably valid.
However, the analysis would have allowed Pathway to say “this is the data, who is
supplying & ‘and in what form?"
Pathway fail to distinguish between the definition of data as against the specific
yalues the data can take eg. ‘Payee Role Description is a 20 character alpha
numeric attribute! and ‘Payee Role Description can take the values “Beneficiary,
“appointee” etc. The first is always important for specification and design. The
sesond i only important where sezcife values oF ranges of values are Identified in
Prepared by Project Mentor fic. acting a Ref, AGLOTVE2 ‘Date: 17 Dec 1995
sumcetrardors 16 Bid & Gied. Salcitors Status: Provisions Page 10
18/12 198 15:06 —-TK/RX NO GRO! P.017
POL00031114
1B-LEC-1998 16:67 FROM BIRD & BIRD fa POL00031114
Privileged and confidential. Bird & Bird Prepared in contempiation ‘gation. ptses
Expert review of BA/POCL Payment Card Programme
Position Paper - Requirements Optimisation
the detailed specification of the {T system e.g. if the Payee Role Description o
“Beneficiary” then do X else if the Payee Role Description ie ‘Appointes' then do Y".
& logical data model identifies which attributes are mandatory and which are
optional. Certain attributes in the reference date are optional. For Pathway to state
that ‘This only started fo become apparent in about August 1997 when Pathway
received test data” is in effect a I clear adinission of the failure to analyse
requirements satisfactorily.
44 Contradictary and Misleading Requirements
441 Issue
“a number of the Authorities contractyal requirements contradict other contractual
pequitements, orde not accurately describe what the authorities have subsequently
ariculated to be their requirements. For example, requirement 9429 states (het
whan @ customer is no longer fo be supported by the Card Management Senice
{CMS), an ‘end of interest’ notice will be sent to Pathway by the DSS. Pathway must
react to this aotioe by implementing a permanent card stop for that customer. This
potentially causes conflict with requirement 954 which requires that an ofd card be
reused when personal details are sent to Pathway for a customer against whom 6
there has been 4@ previous card stop. Reguiramnent 93472 also potentially conficts
with requirement 716 and the Service Interface Definition dated 9 February 1996.A
further example of conflict is the requirements relating to summarised receipts. in
each case, he conflicting requirements caust Pathways work programme to be
delayed and disrupted whilst the requirements are analysed and the position
clarified with tha PDA and the Authorities. The clifficulty is exacerbated by the PDAS
and the Authorities’ lack of appreciation of the consequences of attempting to apply,
atten ii-defined, operational rules ancl procedures used in the existing paper based
system to the new automated system.”
4.4.2 Analysis .
itis unavoidable that requirements expressed before analysis will contain gaps and
inconsistencies. This is a fundamental reason for performing the requirements
analysis at the earliest opportunity. if Pathway nad performed the analysis early in
the project, the contradictions would have surficed, ‘been resolved and design and
development work progressed without the disruption thay allege took place.
Pathway should have recognised that without the analysis there would be @ high
Fisk of design rework. g
Prepared by Prefect Montane Ud, acting 8 Rel: A4207 V2 Date: #7 Dae 1808
sub<ont te Bid & Bird, ‘Sclectors ‘Slahus: Provisional a
18/12 198 15:06
P.O1s @
ET
ie - POL00031114
. Privileged and confidential. Bird & Bird Prepared in contempiation of fiigation.
Expert review of BAIPOCL Payment Card Programme
Position Paper - Requirements Optimisation
45 Change Control issues 7
‘Three examples are quoted by Pathway: : . :
» Temporary Tokens & Casual Agents (CONT?) j “
» Unmatched Encashments I
« Continuation Receipts
However, each relates (0 the following primary issue raised by Pathway.
45.4 Issue
“The conduct of the Authonties ana the PDA in dealing with a number of change
contro! issues has often created significant proviems for Pathway. The Authorities’
lack of knowledge of their own roal requirements; conflict between the Authorities
and their requirements; an inconsistent approach by the Authorities to Pathway; the
PDA's failure fo properly manage the change control process; and prolonged
igtions between Pathway and the PDA over change control time, cost and
requirement issues have adversely affected Pathway's ability fo develop the
® solution, Pathway has been faced with extensve dolay, increased costs, abortive
work and re-worm,
45.2 Analysis
Change control is an essential component of an {T development. However, where
t are imprecise there is significant room for interpretation and change of
interpretation by the parties involved, A detalied requirements analysis will provide
the focus for discussion of those fequirements, with no room for different
interpretations. The fack of ‘such an analysis for the Card Programme provided
tertile ground for extended negotiations aver changes. ‘The requirements were Never
‘nailed to the floor.
As indicated elsewhere, this process of analysis could and should have been
started by Pathway during the procurement phase. To complain about the issue two
years later shows poor management and technical direction.
Prepared by Project Mentors Lut, acting 4s Ref AGOT VIZ Osteo: 17 Deo 1008
sub-contractors te Bird & Bird, Sokokors < Feeiaional Page 12
gE
18/12 198 15:06 TR/RX NO
P.O19 @
POL00031114
A8-—DEC-1998 45:@0 FROM BIRD 3. BIRD
Privileged and confidential Bird & Bird
Expert review of BA/POGL Payment Card Progeamine
Position Paper - Requirements Optimisation
1s aangeenrieste
APPENDICES
A REQUIREMENTS ANALYSIS
AY What are Business Requirements?
Most {T systems are built to support businesses and organisations in carrying out
Most 1 syste tare two main classes of people involved in instaling a new
system, Gusiness Specialists and IT Specialists. These hwo groups nave very
different seis of skills and knowledge.
« The business specialist understands what the business does, how it works and
what challeages are facing the organisation, They are business focused. Their
expertise in IT will seldom go beyond using a word processing package OF
spreadsheet.
+ The IT specialist designs, bulids and tests {T systems. Their particular area of
expertise is focused on computer software and hardware, ‘They may have some
knowladge of the particular business area in which they are working, however
they are not the experts. indeed, having completed one IT system they will often
develop another for 2 totally differant sppiicution,
This nas been tua since the earliest computer sysiems and 16 stil true today.
However, although they must work closely together, they have found it difficult to
communicate ideas, definitions and agreements about what the business objectives
are, and how the computer solution ‘wil meet the business needs. They might have
a common language, in say English, but each has their own extensive jargon. ‘They
use the same words to mean different things and have different words ta mean the
same thing. The opportunities tor misunderstanding are legion.
The early 19708 saw the first steps in establishing a standard set of activities and
techniques which could be followed by both groups and were thus @ means of
reaching 2 common understanding of the business requirement and the computer
solution. These have evolved over the years, however the fundamental approach
has not changed, nor have the basic techniques used during the process. ‘The steps
can be summarised as follows: :
4. Establish the business requirements;
2, Specify an IT solution which meets these requirements;
8. Develop the IT solution to the specification,
4. implement the (T solution within the business.
Like a production fine, the products of each uctiMty are input to the next activity.
Different mixes of siulis are required for eadts activity. For example, in activity 1
business knowledge is particularly important whereas in activity 3, specialist
exnertise in {Tis the primary need.
However, it is not just te sequence of steps that is important. During each stage,
specially developed techniques are used to establish shared understanding and
from that agreement on what the IT solution will do and how it will address the
business needs,
Premred by Project Mentors Uit., acting as Ret: AA2OT VIR Date: 17 Dec 1998
gaib-contractars 16 Bad & Bird, Solickors Staten: Peawisionst
18/12 '98 15:06 TK/RX NO. {GRO}
POL00031114
Priviteged and confidentist. Bird & Bird Prepared yn cormempiation of figation.
Expert review of BA/POCL Payment Card Programme
Position Paper - Requirements Optimisation
Identifying the Requirements
Statement of Requirements ~ 4
‘The first step will be to for the business 10 construct an agreed definition of the
scape and broad functionality of the required {T system. In the case of BAYPOCL
this was the SSR, which was later formalisad as the contract requirements
catalogue. Such documents can be used as a first Slee in specifying the 1T solution.
However, the level of detait supplied about business processes, business rules and
business data is not enough to allow he {T specialist to complete the specification
of the system to allow detailed design and davelopment to be performed A further
step of analysing the requirements is essential.
Analysis of Requirements
Three areas need to be addressed:
4. The information about tha business that needs to be held within the IT system
2 The business niles that have to be followed by the programs within the IT
system
3. The business events that will cause particular programs to be executed in the IT
system
The analysis needs to be performed by specialists skied in the use af particular
tools and techniques that have been developed specifically for this task. Two
techniques are particularly important
4. Logical Data Analysis - a technique used to produce @ complete and
unambiguous definition (the Logical Data Model) of all the business data that
is to be stored and manipulated within the new IT system.
2. Functional Analysis - @ process lo ensure that the business rules for
manipulating the business data ‘defines in the logical date model are also
complete and unambiguous,
Note that both forms of analysis are focusing on the business requirements and do
not address issues of how the (T system is to bre designed. Indeed, itis possible to
perform the two aclivilies without 4 view to implementing @ computer system at all.
However, it is offen appropriate to identify some constraints on the type of solution
being sought @.9. the system software needs to be the same as existing [T systems,
the ‘look and feel’ of the computer sereen! keyboard should be consistent with
company standards; for What period the system is to be ‘available’ each day. Such
requirements should pe kept clearly separated from the business requirements.
The final product of the analysis should be @ requirements trace which identifies
how every requirement in the requirements catslogue is embodied in the analysis.
Requirements Analysis Methods
A detailed requirements analysis will, at a minimum, contain the following:
+ Logical Data Model
« Data Fiow Diagrams
Prenared by Project Mentors Ud, scting #5 Rel: AALOT VE? Date: 17 Gee 1599
sub-contractort to Bed & Bird, Setctors Stalus: Feovisional
18/12 '98 15:06
P02
POL00031114
POL00031114
ise
POL00031114
LEC-1999 15789
FROW BIRD BIRD a
Privileged and confidertia'. Bird & Bird Prepared in aw
Expert ceview of BAPOCL Payment Card Programme
Position Paper - Requirements Optimisation
+ Functional Deseription in Structured English
« Constraints on design and operation
individual authors and commercial organisations Nave developed and sold named
methods. Some are no more than descripti in books, Others aro fully fledged
packages of documentation, sofiware tools and training packages. Some focus only
‘on the requirements analysis process. others cover the complete IT fife cyce from
strategy through te live support A list of some of these is presented In Appendix B.
However, even though the scope varies, they have similar underlying principles and
techniques when gansidering requirements analysis.
The UK govemiment's Central Computer and Telecommunications Agency (COTA)
recognised the importance of using appropriate methods. It employed LEMS to
enhance its LSDM method te develop SSADM - Structured System Analysis and
Design Method. This is now the standard method used by Government
departments. itis also very popular in industry with a wealth of people experiences
in its use.
Logical Data Model fLDM’}
this ig 6 complete and unambiguous definition of aif the business data that is to be
held within the computer system. i defines:
« the business objects of interest eg. Customer Authorised Payment,
Encashment. The general term for business. objects is ‘entity types
» the atinbutes of interest for each entity type @.g. for the Customer entity we will
want to record the customers NINO, surname, nominated post office etc. The
or is optional, whether it has a fixed range of values and what they are ¢.9. @
Customers Geographical Restriction Indicator may only have one of a small
number of values, each of which has & specific moaning. it is also essential to
gy which atirbute can be used to unicuely fdently & parsexisr instance of
an entily ¢.9. 4 Post Offies is ddentified by « FAD attribute, *
« whe aalaianchips which exist betwean entity types and the nature of Shee
relationships e.g. A Customer may be the beneficiary of one or more exe}! i
{ gore”
Authorised Payments, but en Authorised Payment must be for a single
Customer (as beneficiary). bw
This information is recorded within a Data Dictionary. i
Entity Relationship Diagrams are used to provide @ graphical representation of the
entities and the relationships between them. This is useful both for providing an
overview of the contents of the data dictionary, Dut also, and more importantly, as &
means of communication and agreement between business and IT specialists.
The Logical Data Model is the single most important product of the development
process if misunderstanding and delay is to be avoided.
Prepared by Projext Mentors Ud., cotng 3 Ret AALOT V2 Oste: 17 Geo 1698
subconracins 6 Dit & Bed, Goschare ‘Stohr; Frevicional
18/12 *98 15:06 TR/RK NOS
POL00031114
2. Data Flow Diagrams (OFDs")
The computer will need to support and implement selected business functions.
Fre oe ortness functions take data as input, perform some actions upon it and
deliver some results ¢.g. The Encash Payments business function might identify the
payments for 2 ‘selected customer, make the encashment, mark each payment as
‘encashed' and produce a receipt.
As their name suggests. DFDs describe how data flows between the various
business functions to be implemented in the computer system. it also identifies the
‘events’ on the boundary of the new system which will cause sometning fo be done
within the computer system e.g. 8 Post ‘Office has been temporarily closed. This
event needs to be fed te a function of the system to change the recorded status of
the Post Office to ‘temporarily dosed’.
The process of building the DFO allows common functions to be identified (.e.
things that are done for more than one reason) so that a single description of the
funcdion can be produced. Examination ‘of the data that flows between the functions
also helps identify any data that might have been missed in the Logical Date Model.
Where flows have a complex sequence of dala items, these will be described in
detail using structure diagrams.
(3 Functions Described in Structured English
A computer programmer needs a complete and unambiguous definition of the
business functions that are to be replicated in the computer programs. Narrative
descriptions are inadequate. Structured English {sometimes known 86
pseudo-code) allows for precise definitions that both business and IT specialists can
understand. A simple example might be:
if
The payment's firstepayment-due-date ys less than or equal to today
And
The payment's paymentexpiry-date s eguat {¢ or greater than today
Then
Encash the payment
End-if
The functional descriptions refer to the entity types and their attributes as identified
in the legical data model. This may be supplemented by fists ang tables, but the
Structured English is essential for unambiguous dafinition of business rules. hems
missing from the logical data mmadel are also identified during this activity.
4 Constraimns
The components of the requirements analysis described above are in business
terms only. Indeed, they could be praduced without consideration of the computer
solution. However, it is often the case that the business organisation already has IT
systems with which the new system is to communicate, or has standards for such
components as computer operating systems. These need to be clearly identified
and recorded so that the {T designers may take them into account when producing
the detailed design of their solution.
Braparad Dy Project Montara Lid, acting #S Ref. AAZOT VIZ Date: 17 Dee 1908
ausconiractors 10 Bid & Bird, Sobetors Gisluc: Freviewra
18/12 °98 15:06 TX/RX NO ‘GRO.
P.023
POL00031114
POL00031114
POL00031114
— POL00031114
To
IB-DEC-2998 15:10 FROM BIRD &
Privileged and canfisertial. Bird & Bird Prepared in contemplation of fitigation.
Expert review af BA/POCL Payment Card Programme
Pasition Paper - Requirements Optimisation
A3.5 Operational Characteristics
The business will identify minimum perfornance targets for the functions
imolemented in the new computer system e.g “The encashable payments for a
customer must be presented of the screen within 2 seconds ‘of the entry of the
customer's NINO", oF “Urgent Payments must be visible at the counter of the
nominated Post Office within 30 minutes of their presentation to PAS".
, ecting xe Ret A4207 V2 Date: 17 Geo 1908
ors Stuluo’ Provigwnal
18/12 '98 15:06 TK/RX NOZGROI P.024 B
Bid & Bird — Prepared in conmernpnsowe ws menor
Expert review of BAPOCL Payment Card Programme
Position Paper - Requirements Optimisation
2 DOCUMENT GONTROL
Bt Change History
Date Status Purpose
F512h808 ‘Drak I For reviaw by Project Mentors tan i
4721998 I Provisional I For presentation to Bird & Bid and
l Authorities
Version
44
4.2
Changes Forecast
None expected
Distribution
Project Mentors Pot.
Andrew Davies
Bird & Bird
Hamish Sandison
Benefits Agency
Glossary
Analysis
Defining the purpose, objectives, and requirements for the I
application.
Fhe translation of appicaton requirements into a particular
technological implementation,
Structured System Analysis and Design Method was developed
by the Government's Central Computer and Tel i iS
Agency (CCTA). SSADM version 4 was introduced in 1881; the
current version, 4.0, was most recently modified in the mi¢-90s,
SSADM provides a eystematic approach to analysis and design
of information technology (11) applications. itis the standard for
software development in all departments of the Govemment.
Design
SSADM
References
4. Selection of Exampies of Problems Facing Pathway as set out in Pathwey
Position Paper dated 6 March 4908
2 Structured Analysis and System Specification, Tom OeMarco, Yourdon Press,
Englewood Cliffs, NJ: 4979,
prepared by Project Mentors Ud. acting as Rel: Ac2O7VEZ Dane: 17 Dee 1988
uocantragon 7 GHG & Sid. Solctors: Statue: freweiona!
:
18/12 '98 15:06 TX/RX NO 'GROI
P.025
POL00031114
POL00031114
POL00031114
BE
1G-DEC-1988 45:10 FROM BIRD & BIRD =m POL00031114
Priviteged and confidential. Bird & Bird Prepared in contempiation of figation.
Expert review of BA/POCL. Payment Gard Programme
Position Paper - Requirements Optimisation
3. Structured Systems Analysis: Tools and Techniques, Chris Gane and Trish ®
Sarson, Prentice-Hall inc., Englewood Cliffs, NJ, 1979.
Modem Suuctured Analysis, Edward Yourdon, Yourdon Press Engiewood Cliffs,
NJ, 1988.
5. SSADM, CCTA
6 IEW, Emst & Young
7.
6.
*
Method 1, Andersen Consulting
_ 4 Front, Deloitte Consulting Group
Documents
[Bocument
GEBE io BASIONS dala interface Definitons and Validation Rules (Post Nite 2)
[SAPS to PASIOMS Codes Flies Definition (Release 3)
Preponed by Sryjact Mactars Lid, actieg oe Rat Ang.07 VIO Dale: 17 Ges 1906
exducortractors to Bird & Bird, Sofetors Staua Provisional
TOTAL P.26
18/12 ‘98 15:06 TK/RX NOLG
P.026 g
POL00031114
= POL00031114
B-LEC-19 25:37 FROM BIRD & BIPD
oo Bere a Cee tet a L-GRO, cas eh
@
MEMORANDUM
Legally Privileged & Confidential
Or George MeCorketl, BA
Paul Rich, POCL
Put Kelsey, RA/POCL Programme
uc: Andrew Davies, Projeet Mentors (wiitaut eacs}
FROM: Hamish Sandison, Bird & Bird 4
DATE: & Necember 1998 PY
RE: PROJECT MENTORS ee ©) :
3 Tuitach a shart apdate €om Andrew Davies which he asked me to draw 10
@ your attention 4s yoo will soc, his team have ducunented a hurtner specific failure
by ICL Pathway « Gllow good industry practice in meeting the Authoritios”
requirements. This may else have an opetationsl impact which you will win 10
wcoushler,
2, Andrew will be preparing a more detailed seport hy the end of next week, but i
thought that you should xec his summary immediacely
a ‘As with previous reports, this nipdate is legally privileged ox the axis that it
thas been commissioned by us as the Juiut Poogramme Lawyers. Accurdingly it
should be given the most limited possible cheulation on a nced to know basis.
4 Please do noi hedtate to get in touch with me or wills Andrew dircet if you
bave any questions or eouunents:
TOTAL. PF. G1
18/12 +98 15:40 TX/RX NO./GRO! P.001 @