POL00038829
POL00038829
POL00038829
POL00038829
80d @TvO “ON XU/XL SS:9T 86, cT/e2
ay
POL00038829
Biep 2 BIeD — POL00038829
SW Taasen ene
&
MEMORANBREM
Legally Briciisued & Coufidential
1: Geovus MeCerkell, BA
Paul Rich, POCL
Pat Kelsey, 1A/POUL Programme
OCs andrew Davics. Project Mentors (wktheut encs)
FROM: Hamish Sandivon, Bird & Bird a
DATE: 8 Recember 1998 ©) pY
RE: PROJECT MENTORS undis
3 Latach a short updote from Andiew Dacies whiek he asked me ta draw
your attention. As you wil sou, his tau have “Jocumeuted & farinar Specific faihure
by ICL Pathway ws Sollow good industy praodew in mutiny the Autboritics’
requircmasnts, This may aise Lave an operational Prpaet which pou will wists 1
nosh at.
PS Andrew wilt be preparing: a mate detalied epost hy the end ot next week, bot f
shougat that you shanstA see nis somiRty fevemnedtacacly
4 as with previous mpuits, this npdade ts legally, privileged an the hans that it
tus been commmmaoioned by us as the Teun! Pregame Layer Avandingty. #
should be given ihe most Henited ponsible vhoulation nn a ned to know basis
ds Aastra direct if you
a Please do vo. kawitone to get in touch with me ore
pave any questions or consents
18/12 "98 15:40 TR/RX NO. 2999 P.Ob1 ij
POL00038829
POL00038829
FROM BIRD BERL Fy
FAX TRANSMISSION
BIRD & BIRD
To: BA/POCL
Atten\Ref George McCorkell
cet Paul Rich, POCL
Pat Kelsey, BA/POCL
Andrew Davies, Project Mentors
From: Hamish Sandison
Client BA/POCL
Account No: BPOCL/OO1
Date: 18 December 1998
Time:
Number of pages (including this pane): lke
Note: This fie is intended for the named nedressec anly, It canttins information which ‘may be confidential and
Which may also be privileged. Unless you wre the named addressee (or authorised to receive for the addressec}
you may HOt copy oF use i or disclose i to anyone else, if you fave received it in emer please notity us
immediately so that we ean arrange for its rctorm, To do so, or {you have any queries, please telephone O17)
41S 6000,
Message:
Please see attached,
EC OMe 188s Keer Louise, OSG Buds, Belgarn Telephone +222-604 3616 Fataimnle 4322-686 2406
‘on Nog 20/F Printing Mouse, 28 i Mone Semes, Cents, Hang Kong, Telephone +1132-2530 0960 Facsimile $882.3523 3136
18/12 '98 15:06 TR/RX NO. 2998
9.8226
80 Fotsce Lane
tendon £44 1
el
$44 171415 BOOB
‘elew
28885 Bacls @
ox
119 London
Web Page
srew Rwobixts.com
Paanre
Diners
et cams
Om captieaie
Tot Conk
reson
Petes
Psnwth
OW byamCaok
CIM Seth
FRC Wittey
ake
Sb raged
eee ame
Cw Recs
PE Cinan
He Sanden
eves
1 Ward
Can Cemrwate
NT jonine
RM Bicheritalt
Be Pop
YES tater
2 rasson
WEA Give
146 Aen
art
Cie hana
OC} Oak
Sm Cet
468 Hike
CPt
HV fomfonae
wa tia
EW Rake
PA Browrow
1D eherter
ad
PE Day
i Banerwcn,
NSP Blurtit
AW fine
Comeutants
TC ames
EN £ Chote
P53 Bien
2 rawness
Cem wats
tok 8 stereo
P.001 I I
POL00038829
: POL00038829
.PB-DEC<1990 18701 FROM BIRD & BIRD TO 87769961 é
BIRD & BIRD
Our Rel: 90 Fetece Lane
Landon EC4A 116
Your Ret MEMORANDUM +44 171-415 6000
Legally Privileged & Confidential ;
TO: George McCorkell, BA
Paul Rich, POCL
Pat Kelsey, BA/POCL Programme
ce: Andrew Davies, Project Mentors (without encs)
FROM: Hamish Sandison, Bird & Bird f
Partners
DATE: 18 December 1998 D Harses
Gt camos
Om Coybmsie
RE: PROJECT MENTORS REPORT ye
“1 Chiari:
sion
OW Byamdnok
Spee tnat
1. Further to my Memorandum dated December 8th, I attach the full report ofthe 7"
work by Andrew Davies and his team on requirements analysis. This fleshes out the yb
brief update from Andrew which I sent you with my December 8th Memorandum. As pirate
you will see, all three of Andrew’s team are {I quote from Andrew’s letter to me) Sines’
Eee
“deeply concerned that their findings show a serious problem with the way in which eae Cosette
NF jessie
ICL Pathway have developed the system, The impact of this is likely to be that there aM Bist
Sx Tomei
will be failures to meet essential user requirements, causing the need for extensive re- acd
work before the system can be accepted and, potentially, operational problems if the venta
Sens
C1 Rsame
DC} Cor
144 Cygne
q As with previous reports, this report 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 cireulation on a need to know basis. ovate
ean:
3. Please do not hesitate to get in touch with me or with Andrew direct if you eeou
RM Butera
have any questions or comments. NSP elndett
system is roiled out.”
Constants
Ere amold
SNL Chation
Fi Deon
1 RS Fawcett
f Bethe Wale
EC Office 2084 Averue Louise, 1050 Brunoels, Belgium Telephone +323-642 2616 Eacsianile 4322-644 3485,
memeronisfearx Hong Kong 20 Printing Mouse, 18 toe House Sweet, Cantal, Hong Kang Telephooe +852-2530 2960 Facsimile 4852-2523 3138 ‘nat « soticmae
18/12 '98 15:06 TX/RK NO. 2998 P.002 @
POL00038829
POL00038829
TO SP ?HSRER
December 17, 1998
Mr. Hamish Sandison
Partner
Bird & Bird
96 Fetter Lane
LONDON EC4A 1JP
Dear Hamish,
independent Gonsuttant Review of BAPOCL Payment Card programme
Privileged and confidential, Prepared int contemplation of litigation
Position paper on Requirements Analysié
We have now completed & provisional version cf our position paper on requirements
analysis, a copy of which I atiach. We are of the opinion that the findings of this paper
give serious concem that the Payment Card System has been developed in a manner
trot creates a breach of the contract relating to the requirement in Clause 702 of the
Authorities Agreement to work to ‘good industry practice’ and that the impact of the
breach is fkely to be that the system will not be Rt for purpose unless extensive re-work
is cared out before implementation, causing further delay and additional investment by
Pathway and the Authorities,
The following paragraphs summarise the key conclusions from chapter 2 of the paper:
"We nave performed a requirements analysis fer BPS, which is predominantly a BA
system element, From our analysis we conclude that Pathway have made no attempt to
undertake requirements analysis in accordance with normal industry practice. This is
despite their having access to the SSR and subsequent requirements since April 1996.
Much of this work coud, and should, have been cone during the demonstrator period.
in more specific terms, we conclude that:
. DSS's requirements were complete in scope et the time of cantract signing, but
incomplete in detal, as was only fo be expected;
« only af @ detailed jevel were there gaps and contradictions in the OSS's
« Pathway failed to satisfactory enatyse the DSS's requirements during the
procurement process and as @ result significantly underestimated the effort and time
sequired to develop their solution;
* in the pedod since contract signing Pathway cave failed to satistactonly analyse the
OSS's detailed requirements. AS a result they have designed end partially built a
system without knowing wheinerit fully meets the DSS's requirements.
Pathway have failed to employ good praction’ techniques for establishing detailed
requirements, in broach of Clause 702 of the Autnorities Agreement. None of Pathways
claims thet requirements were poorly defined and ¢ or have since been expanded to
Pregeet Mertece tie ded
Registered tn England na 2390018 Kegetered Offre 30 Upper High Eioeet Thane Oven
18/12 "98 15:06 TR/RX NO. 2998
PLB
P.003 @
POL00038829
POL00038829
S9G 15:02 FROM BIRD 3 BIRD Sra mrrrcne
‘Project Mentors, December 17, 1998
necessitate an optimized solution are sustainable, lndeed, the very examples they have
mised add weight fo the case thaf they have failed fo undertake satisfactory
Our experience of systems where requirements heave not been analysed satisfactorily is
that the system fails fo mwet the users’ needs. Ar effective acceptance test will identify
many such failings, necessitating considerable rework. The result is a
‘extension of the fime and cast required to complete tho system and roll it out. The
altemalive is fo allow unacceptable processing in the operational environment, with
unpredictable and potentially damaging resutts.
fn our opinion the fajure to satisfactorily analyse the requirements for the Benefits
Payments System makes it unlikely that the usec needs wil be met by the cument
Pathway system.
We do not believe, from our understanding of other elements of the complete Payment
Card System, that these other elements have been analysed using better techniques
than for the Benefits Payment System, $0 there is a concem that user needs for these
elements will also not be met by the current Pathway system.
We would be grateful f you woad pass these conclusions to the Authorities so that they
may consider their impact on the current delibarations.
Professor Andrew Davies
Director
Page?
18/12 ‘98 15:06 TX/RX NO. 2998
P.O04
P0826
POL00038829
POL00038829
1E-DEC ~1 9S
Sear
Privileged and
BIRD 9 BIRD
ya geeeoaba
confidential. Prepared in zontempiatian of litigation.
18/12 (98 15:06
BIRD & BIRD
Project Mentors
TX/RX NO. 2998
P.005 ee
POL00038829
TES IT st - POL00038829
re STs co
Privileged and confidential, ‘Bird & Bird Prepared in comampiation of iRigation.
Expert review of BAPOCL Payment Card Programme
POSITION PAPER
Requirements Optimisation
Ref: A42.07 V4.2
Status: Provisional
Prepared By: J Pimpernel / A Wing
Prepared On: 17 Dec 1998
Prepared by Propect Marte Lach, acting we endhre wetractore to Bie i Gand. GoficKore
18/12 "98 15:06 TX/RX NO. 2998 P.O006 I
POL00038829
sess POL00038829
28-DEC FROM HISD & BIRD io &
aes: PP ate
Privileged and cantidentiat. Bird & Bird Prepared in comempiation ‘of fugation.
Expert review of BAPOCL Payment Card Programme
Position paper - Requirements Optimisation
SECTION PAGE
L. Eetredaction 4
LL Background 1
12. Purpose of Document i
13 Scope !
1d Structure of Document 2
2. Conclusions and Impacts 3
24 Intradvetion 4
2.2 Conelustons 3s
La Impacts on the Programme 70 Daie @
2.3.1 Introduction a
2.3.2 “Optimisation” 4
2.3.3 Bstimating and Planning 4
224 Other Elements of the System. 4
a4 Impacts on the Programme in the Puture $
3. Approsch 6
3.1 Assessment of Pathway “Examples” €
3.2. Draft Requirements Analysis 7
3.3 Changes Found 7
3.4 Time Seale Ef
4. Bindings 9
4.1 Extended Verification Procedure 9
al. iasue e
4.1.2 Analysis 3
4.2 Foreign Encashmenis “3
421 Issue 9
422 Analysis io
43 DSS Reference Data i
ast tase w
43.2 Analysis 1»
4.4 Contradictory and Misleading Requirements rea
44a. tesue ub
442 Analysis nu
45 Change Control issues 42
45.4 issue ce
4.52 Analysis 12
: ‘Prenared by Project Mentor 136, aetinwg as gxtec actrectors t0 Bird & Blic, Sofeiors
18/12 '98 15:06 TX/RX NO. 2998 P.O07 @
POL00038829
POL00038829
ISTECTaeS Tes FR Bina = BIRT ca pip any SN Sy
1.
14
12
13
Privileged and confidential. ‘Bird & Bird Prepared in contemplation of figation.
Expert review of BAIPOCL Payment Card Programme
Position Paper - Requirements Optimisation
INTRODUCTION
Background
As part of the expert review of the BA/POCL Fayment Card Programme, we have
reviewed ICL Pathway’s undated paper of 53 pages entitled “Selection of Examples
of Problems Facing Pathway As Set Out In The Pathway Position Paper Dated
6 March: 1998". ‘Their paper presents @ number of claims about changing and
undlear requirements.
Investigatian of those ciaims required us to uxamine the business requirements
expressed at the tims of contract signing and compare them against the current
understanding of the DSS's requirements. We therefore reviewed documents from
both the Authorities and ICL Pathway which contained the definitions of those
requirements.
We were surprised to discover that no detalied analysis of the requirements, an
essential process for successful [T developmert, appears to have been performed.
To allow us to compare current requirements with the original requirements, the
review team therefore selected the Benefits Payment System CBPS"} element of
the system as a sampic, and assembled a draft requiremants analysis.
This work was based on documents from both the Authorities and Pathway,
together with vary limited informal discussion with BA staff at Terminal House.
Purpose of Document
This paper sets out our findings from analysing the requirements from the BPS, in
terms of:
+ identifying what approach Pathway adopted to establish the detailed business
requirements,
* considering the validity and merits of the clains made by Pathway;
« assessing the probable past and future irepact of the approach adopted by
Pathway.
Scope
Effective business requirements analysis is needed to achieve a satisfactory,
comprehensive business design. This can then be used as the basis for the
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
nas been conducted satistactorily.
We have to date considered only the BPS system. Further work has recently
started to perform @ similar assessment ‘of the upproach adopted for other elements
of the system, such as EPOSS. Neverthelass our findings are, in our view,
sufficiently serious to bring into question the whole of Pathway's design process.
Preciaced oy Proect Montore Ld, acting ae Ret Ag OT I2 Ota: 17 Bec 1908
subcomtracton: te Bird & Bird, Solicitors Statue: © wvisiona! Page 1
18/12 198 15:06 TH/RX NO. 2998
ES
P,O08
POL00038829
POL00038829
1Q-DEC-1900 15:04 FROM
14
BIRD & BIRD wo 9
M4
Prviteged and contidential. Bird & Bird Prepared in contemplation af Inigation.
Expert review of GA/POCL Paymunt Card Programme
Position Paper - Requirements Optimisation
—— a st
Structure of Document
In this paper we have setout
« the conctusions drawn from our analysis of the requirements for PS, together
with the impact we believe the fack of forma requirements analysis has had on
development to date and the consequences: for the future;
« abroad description of the approach we took in developing our analysis of BPS
requirements,
«© our findings with respect to the specific requirements related charges made by
Pathway.
in Appendix A, we pive a brief overview of the nature of requirements specification
and analysis.
Prepared by Project Mentere 16.
aub-cantenctors to Bird & Bind, Solietore Sistas: Peodsanat
18/12 '98 15:06 TX/RX WO. 2998
» ating a8 fat: AALOT VED Date: 17 Bee 1908
‘Page 7
P.009
DA ity
TS POL00038829
B-DEC-198@ 1570 sare re POL
FROY BIRD & BIRD crmeemmaren =a 00038829
Privileged and confidential. > Bird & Bird Prepared in contemipiauion o wewesnry Be. a-26
a4
22
Expert review of BAPOCL Payment Card Programme
Position Paper - Requirements Optimisation
ed
CONCLUSIONS AND IMPACTS
introduction
From the succeeding Chapters of this paper it can be seen that we have performed
an initial requirements analysis of the BPS elemunt of the systam. We had expected
to base this on documents developed by Pathway showing 3 detailed analysis ot
the contracted business fequiremants Such documents do not appear to est 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
consequently cannot tell for certain what Pathway have done in terms of
requirements analysis. However, 10 documents recognisable as formal, or indeed
informal, requirements analysis papers appeer to have been passed 10 the
Authorities. 11s. possible thet format analysis has been carried out by Pathway, but
we consider this unlikely from what we have seen and from the continuing problems
experienced in development of the system.
Conclusions
it must be remembered that so far we have ‘only performed the requirements
anatysis for BPS. which is predominantly @ BA system giement. However, from our
analysis we conclude that Pathway made no attempt to undenake requirements
analysis in accordance with nommal industry practice. This despite thelr having
access to the SSR and subsequent requirements since Apfil 1996. Much of this
work could, and should, have been done duting the demonstrator peried.
in more specific terms, we conclude that:
« DS's requirements were complete in scape at the ame of contract signing, but
incomplete in detail, as was only to be expected;
= only at a dotuiled level were there gaps and contradictions in the DSS's
understanding of their requirements;
« Pathway failed to satisfactorily analyse the DSSs requirements during the
procurement process ‘and as a result significantly underestimated the effort and
fime required to develop their solution:
«in the period since contract signing Pathway have failed to satisfactorily analyse
the DSS's detailed requirements. ‘Ag a resull they have designed and partially
built a system without knowing whether fuly meets the DS's i
» Pathway have failed to emplay ‘good practice’ techniques for establishing
detailed requirements, in breach of Clause “02 of the Authorities Agreemant.
None of Pathway's aims that requirements were: poorly defined and for have since
been expanded to necessitate on optimised solution are guetainable. indeed, the
very examples they have raised add weight to the case that mney have failed to
undertake satisfactory requirements analysis.
Prepared by Project Mentors Ud. a6tng ae Rel AALOTMAD ‘Date: 17 Dec 1098
sub-contractors 6 Bea & Bled, Geleltors Gtaas: Previaionat Page S
18/12 '98 15:06 TX/RX NO. 2998
P.O10
POL00038829
POL00038829
23
2.3.4
2.3.2
283
23.4
*1G-DEC-1988 AS G4 FROM BIRD 2 BIRD Te
Privileged and confidential. Bied & Bird Prepared in comternpiation of itigation.
Expert review of BAIPOCL Payment Card Programme
Position Paper ~ Requirements Optimisation
Impacts on the Programme to Date
inveduction
Withoul having completed an analysis of the business requirements set out is the
contract, Pathway can naver have been in a position to understand the detail of the
those requirements. Without that detail it is not possible to develop a system level
specification to bridge the gap between requirements and program specifications.
Without such 4 system specification & ig very difficult to design programs in a way
which ensures that all system requirements ere fully catered for.
“Opumisation"
Failure {o complete requirements analysis ana the consequent lack of detalles
understanding of what is required is, we believe, ai the heart of Pathway's
complaints that the Authorities are “seeking to optimise the system’. What they see
as optimisations are in realty the detailing of che business requirements which @
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 cost.
Estimating and Planning
Requirements analysis is 4 fundamental requirement for estimating the effort
required to develop software. ‘The most accurate estimates can be produced from
program specifications, themselves produced trom 4 system specification which is
lise’ derived from detailed requirements analysis, However, there are well
accepted tools, such a8 Function Point Analysis. which enable reasonable estimates
to be made from the functions identified during requirements analysis. Without
astimates it is not possible to establish resource requirements nor to develop @
soundly based schedule.
‘Other Elements of the System
While we have so far only completed work on the BPS system element, we have
professional analysis will be apparent in other
areas as we come fo review tham. This concem is supported by a number of
interviews with Authorities’ staff, from which it is apparent that Palfway are logtne to
release design decuments to BAPOCL. While they have on oeeasion cited
intellectual Property Rights as a reason for refusal, we are becoming increasingly
suspicious that the real reason is Urat the right level of documentation simply has
not been developed.
Of particular concem is the EPOSS system. We ave informed that at 4 relatively
early stage Pathway wanted tho ‘Authorities, principally POCL, to be involved with
the design of this element. The plan was to use the Rapid Application Development
Prepaced ty Project Mentors Uc. acting as Ret AMLO7 SEZ Date: 17 ee 1998
subcontractors te Bind & Bits, Golidore Btalus: Poortzionat Page 4
18/12 '98 15:06 TR/RX NO. 2998
P.O1l
Te bee toee, Torus ot pie Se
POL00038829
24
To oy
Priviioged and confidential. Bird & Bird Prepared in contemplation of tigation.
Expert review of BAPOCL Payment Card Programme
Position Paper - Requirements Optimisation
1D") methodology to design this system. Ths approach was: started, out
discontinued after some months, when the Pathway staff member involved left the
project. The suggestion to use RAD ieads us to 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 in the Future
Our experience of systeme where requirements Nave not been analysed
satisfactorily is that the system falls fo meet the users’ needs An effective
acceptance test will identify many such failings necessitating considerable rework.
The result is a significant extension of the time and cost 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 our opinion the failure to satisfactorily analyse the requirements for tha Benelits
Payments System makes ‘unlikely that the users needs will be met by the current
Pathway system,
Prepared py Project Menara Lid, acting #6 Ret Aaco7 v2 Oute: 17 Dee 1900
subcontractors to Bied & Bird, Solitons Stato: Peovisional Page 5
18/12 ‘98 15:06 TRARX WO. 2998
P.O12
POL00038829
Pr he ae
POL00038829
POL00038829
34
FROM BE
wo & BIRD ro 9776861
Priviteged and confidential. Aird & Bird Prepared in contemplation of litigation.
Expert review of BAPPOGCL 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
Many ante was of peor quality, and / of that there, es, Been, eu
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 anatysit. is the vital first step in tuming high
level business requirements into systems speuifications from which software can
sucoesstully be developed. We had anticipated therefore that our comparison
would be between 3 requirements analysis post-contract and the current version of
that analysis, We could find no evidence in either the Horizon library list or OSS
fbraries of such an analysis. Discussions wih OSS staff at Terminal Hause,
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
agsess whether they in whole of jn part could be considered as supporting
Requirements Analysis.
Table 2.12! Pathway Documents Reviewed
Document =I
Foncional Specification Version 6.0
SADD Version 40 .
Foreign Encashments CRIFSP 10009 Versions 4 and &
CENT - Supporting Documentation, CRIONICENT17
CEN BOS ~ Gre Payment Receipt and Cine Signature Required for each
‘Transaction (POA Change Request 80005)
CEN 226 - Restricted PO indicator Operation
GCN 204a - Generate Card Stop following CMS End of interest
ERPS Access Service High Level Design, SUIESI001
Where detailed definition of requirements exists, it is distributed across the multiple
documents identified and defined using different gechniques.
In the absence of formal requirements analysis specifications, we consincted @
draft detailed analysi¢ againet which we could examine each Pathway cial,
Pronered ny Project Mentors Lic. acting 2¢ Reh AQLOT VIS Date: 17 Dec 1085
sub-contractors te Bind & Bird, Solicitors ‘Statue: F evicional Page 6
18/12 198 15:06 TR/RX NO. 2998
P.013
POL00038829
POL00038829
1S-LEC-199 15:05 FROM BIRD & BIRD
32
33
34
TO SP 763961
Privileged and confidential. Bird & Bird Prepared in comtempration oF gation
Expert review of BA/POCL Payment Card Programme
Position Paper - Requirentents Optimisation
Draft Requirements Analysis
This work was based inifiaily on the final version of the 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 @
contractual document, in our view this is a well produced and thorough document
which would have given any potential supplier the opportunity to gain a thorough
understanding af the system through analysis and questioning.
We used the SSR to draw up a Logical Deta Model (LOM) and Data Flow
Diagrams (DFDs*), both welt understood tools common to most formal analysis
methads. Appendix 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 in any significant way. The documents
reviewed at this stage were principally those produced by Pathway. although we
‘also considered a number of CAPS definition documents. uring this second stage
we also produces definitions of the principal tunctions, These are written using
indentations to show a logical structure, offen degoribed as structured English.
Changes Found
‘Once the requirements analysis was completed. we compared the LDMs and DFDs
based on the SSR with their equivalents derived from the current status, We found
no changes of any real substance, although, as would be expected:
» there was more detail in the later LOM, but noticeably only in terms of their being
additional attributes to each of the data entites. There were no new data
entities;
* the functionality (es depicted In the OF Ds) was litte changed, and in the main
such changes as there were reflacted the identification of processes to deal with
exception conditions.
it is of interest to note that, without attampting (0, the process aiso
jaentified one of two exception cases in terns of business process, While these
Tay have been identified hy Pathway and ‘ of the BA, these cases are nol
documented in the programme's technical library.
in our view, the changes found would have been identified by any reasonably
competent analyst following te methods we used or any of the major methods
widely available. Given the SSR as background, and the little time tequired, we
consider much of the functional requirements unalysis could have been completed
by suppliers before the contract was awarded.
Time Scale
Our analysis took four weeks effort from a singla consultant, spread over a pariod of
two months. Research on other issues occupied the remainder of his time.
Proparnd by Project Mentors Lic. acting 86 Rat ARLOT MI Date: 17 Das 1908
xud-contractors fo Bad & Ged, Sobeitars ‘Status: Prowsional Page 7
18/12 '98 15:06 TX/RX NO.2998
P.O
B,1ae
POL00038829
POL00038829
co 16:06 FROW BIRD & RIED te ghee
OG Ore sed
Priviteged and confidential. Bird & Bird — Prepared i conunainue ve perme
Expert review of BAP Payrunt Gard Programme
Position Paper - Requirements Optimisation
' Sa
Requirements analysis is an herativel task, which makes i difficult to be precise
about the amount of time spent 9 each individual activity, However, 8n
approximate break down wauld be:
« Initial (SSR) data model - 2 days
« Current data model - a further 3 days
« OFDs- 1 week t
« Structured English - 2 weeks I
While acknowledging thal the abave dork has so far only been completed for BPS,
we believe the smati amount of time requires suggests that the business
functionality of this element of the ole system is fac from complex, and can be
easily and rigorously modelled using standard tools.
Prepared by Project Mentone Lid., acting * Ret, AaLO7 VE2 Bate: 17 Dec 1666
seutpeonracters to Bind & Bird, Sobctors ‘State? Pravicional Page @
18/12 '98 15:06 TR/RK NO. 2998 P.015 @
POL00038829
POL00038829
al
4.44
424
Privileged and confidential.” ‘ Bird & Gird Prepared in comempiation of igation.
Expert review of BASPOCL Payment Card Programme
Position Paper - Requirements Optimisation
FINDINGS
‘The Authorities have provided their own responses to the issues raised within the
Pathway paper. Of the 10 items presented in the paper, he following are related to
OSS requirements:
«Extended Verification Procedure
* Foreign Eneashment Rules
« DSS Reference Data
« Contradictory and Misleading Requirements
« Change Control issues
Extended Verification Provedure
issue
The early history of EVP requirements definition ifustrates the Authorities”
interference in design, and enhancement of the contractual requirements.”
Analysis
Pathway's siatement of the issue says it all - “he contractual requirements for the
Extended Verification Procedure (EVP) are vaiue and lack sufficient definition for
Pathway to develop its solution....". This being the case, why did Pathway fall to
take steps to estaplish the detalied requirements?
Foreign Encashments
issue
*The Authorities failed to comprehensively express their business rules for foreign
encashments which Pathway required to know in onier to develop Benefit
Cee ee Service BES") functionality, The foreign encashment rolaled
requirements are poory defined and of fmited use. Pathway has been forced to
Gokine foreign encashment business rules for the DSS. These difficulties have beer
compounded by the PDA's failure to property manage this issue.”
Pathway's summary of what happened:
“The DSS's inconsistent approach to ts own business aules in this regard became
clear in the course of workshops during October 1996. Pathway produced @
document interpreting DSS foreign encashment rules in December 1996, after
which extensive comments have continued 10 be recelved from the DSS and the
PDA, some conflicting. suggesting atlemative rules. Version 5 oF Pathway's Foreign
Encashment Paper is ‘currently under review.”
Prageted by Pract Mentors Lid. scling 93 Ret ALOT? Date: 17 Ore 1298
gub-contrantors to Bird & Ged, Selictiors ‘Status: P eviaions Page o
18/12 198 15:06 TX/RK NO. 2998
P.016
POL00038829
POL00038829
B98 19706
PROM BIRD 3 RISD 6.
Privileged and confidential. Bird & Bird Prapared in contemplalan ot mrysivr ae are
Expert review of BAPOCL Payment Card Programme
Position Paper - Requirements Optimisation
42.2 Analysis
The following observations can be made:
+ aS the Authorities had failed to comprenensively express their business fules,
why had Pathway not produced we detailes analysis that would have revealed
the gap?
« Why did it take until October 1896 to convene workshops to address foreign
encashments when the contract was signed May of that year
+ Why did it take @ further 48 months to get to version § of the document ial was
stil to be agreed? Only 2 relatively smail piece of logic is necessary (0 describe
the requirement. This does not require 18 months: work.
43 DSS Reference Data
43.5 issue
“Contractual requirements in response of OSS Reference data are virtually non
existent, Pothway has had to seek and reconcia extensive information in respect of
DSS reference Data from 3 omanisations (CAPS, (TSA and Blectronic Data
Systems (EDS) in order to develop ifs solution. These organisations have not
adopted a uniform or co-ordinated ‘approach to the issue and Pathway has, in effect,
been canying oul the DSS’ work of analysis in this area. Information has been
lacking, inconsistent between the 3 organisatvons, and generally of poor quality,
This has involved Pathway in extensive analytical work not envisaged under the
Related Agreements, abortive work and rework, involving cost and delay. The
43.2 Analysis
it Pathway had performed the detalled data analysis, the ‘geference’ entities would
have been Identified and specifications established with OSS, Because the
definitions need to be complete and precise, any gape would have beon identified at
fn early stage and appropriate steps taken fo fil the Gaps. (There are some 12 sets
of definitions passed by CAPS to PASICMS relating to business reference data. A
are Kemet Pao data model and could have been defined in detail dung the
is).
‘tne issue of ‘no single point of responsibilty withia the DSS. Responsibility was
dispersed aoress three organisations: CAPS, (TSA and EDS.’ is probably valid,
However, the analysis would have allowed Patnway to say “this is the data, who is
supplying it and in what form?”.
Pathway fail to distinguish between the definition of data as against the specific
values the data can take ¢.9. ‘Payee Role Nescription is a 20 character alpha
numeric attribute’ and “Payee Role Description can take the valves “Beneficiary”,
“Appoi ‘etc, The first is always important for specification and design. The
second it only important where specific values or ranges of values are identified in
prepared by Project Manture Lic, acting > Ret, AMLOTVI.2 Date: 17 Deo 1936
sumcneracints to Bid & Bled, Sailctors Status: Provisional Page 19
18/12 °98 15:06 TX/RK NO. 2998 P.O1? B
TTE=T
a a er ITE -
POL00038829
44
444
say
peviteged and confident. «Bird & Bird Prepared in contemplation of ldigaton.
Expert review ef BAPOCL Payment Card Programme
Pasition Paper - Requiremeats Optimisation
the detailed specification of the IT system eg. if the Payee Role Description is
“Beneficiary” then do X else if the Payee Role Dascription is ‘Appointed’ then do ae
A 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 startod fo become apparent in about August 1997 when Pathway
received test data” is in effect a clear admission of the failure to analyse
requirements satisfactorily.
Contradictory and Wisteading Requirements
Issue
“4 number of the Authaties contractual requirements contradict other contractual
requirements, or do not accurately describe what (he authorities have subsequently
articulated to be their requirements. For example, requirement 94373 states that
whan a customer is no longer fo be supported by the Cont Management Service
{CMS), an ‘end of intorast’ notice will be sent to Pathway by the DSS. Pathway must
react to this notice by implementing a permanent card stop jor that customer. This
there has been @ previous card stop. Requirement 34/3 also potentially confiets
with requirement 716 and the Senice Intertace Definition dated 9 Fobruary 1996. A
further example of conflict is the requiraments relating to summarised receipts. In
each case, the conflicting requirements cause Pathways work programme to be
clarified with the PRA and the Authonities. The difficulty 1s exacerbated by the PDA's
and the Authorities’ lack of appreciation of the consequences of attempting to apply,
offen ii-defined, operational rules and procedures used in the existing paper based
system to the new aufomated system.”
4.4.2. Analysis
itis unavoidable that requirements expressed Lefore analysis will contain gaps and
inconsistencies. This is a fundamental reason tor performing the requirements
analysis at the earliest opportunity. If Pathway had performed the analysis earty in
analyst he Ctimoacaions would have surfaced, been resolved on Serge
work progressed without the disruption they allege took place.
development pave eecognised that without the antysi there would Be & PGP
fisk of design re-work.
prepared by Prqect Monters itd. acting 96 Rel, Aa 207 VAR Date: 17 Dee 1888
a 16 Bird & Bied, Solckors ‘Siatus: Provisions: Page 1
18/12 "98 15:06 TX/RK NO. 2998 P.O18
POL00038829
POL00038829
POL00038829
ASHG? FROM Bei wate Be Pe owes
Privileged and confidential Bird & Bird Prepared in contemplation of Rigation.
Expert review of BAPOCL Payment Card Programme
Position Paper - Requirements Optimisation
45 Ghange Control Issues
Three examples are quoted by Pathway:
« Temporary Tokens & Casual Agents (CCN117)
» Unmatched Encashments
* Continuation Receipts
However, each relates to the following primary issue raised by Pathway.
45.4 Issue
“The conduct of the Authonties and the PDA in dealing with a number of change
control issues has often created significant prosiems for Pathway. The Authorities’
lack of knowledge of their own real requirements, conflict between the Authorities
and their requiremants; an inconsistent approach by the Authorities to Pathway; the
PDA's failure to properly manage the change control process; and prolonged
negotiations between Pathway and the PDA over change contro! time, cost and
requirement issues have adversely affected Pattway's ability to develop ihe
solution, Pathway has been faced with extens've delay, increased costs, abortive
work and rework,
45.2 Analysis
Change control is an essential component of an (T development. However, where
requirements are imprecise there iS significant mom for interpretation and change of
interpretation by the parties involved, A detaiied requirements analysis will provide
the focus for discussion of those requirements, with mo room for different
interpretations. The lack of such an analysis for the Card Programme provided
tertile ground for extended negotiations over changes. ‘The requirements were never
‘nailed to the floor.
As indicated elsewhere, this process ‘ef 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 Ud, acting 6s AALOTVEZ ele: 17 Dec 108
wubconiraciors to Bird & Bird, Sevedors Satu: Prewisional Page 12
18/12 198 15:06 TR/RX NO. 2998 P.O19 [i
Ba 5 maha ee
POL00038829
Privileged and confidential. Bira BBird Prepared YO COMTEMPRSUUt! se: munwannes ss
Expert review of BA/POCL Payment Card Programme
Position Paper - Requirements Optimisation
APPENDICES:
A
At
REQUIREMENTS ANALYSIS
‘What are Business Requirements?
Most IT systems are built to support businesses and organisations in carrying out
their aims. There are two main classes of peuple involved in installing a new IT
system, Gusiness Specialists and {T Specialists. These two groups fave very
different sets of skilis and knowledge.
« The business specialist understands what the business does, how it works and
what challenges are facing the organisation. They are business focused. Their
expertise in IT will seldom 9° beyond using @ word processing package Of
spteadshest.
+ The IT specialist designs, bulids and tests IT systems. Their particular area of
exportise is focused on computer ‘sofware and hardware, They may have some
knowiedge of the particular business area in which they are working, however
they are not he experts. indeed, having completed one IT system they will ofter:
develop another for 6 totally different appiication,
This nas been tue since the earliest computer systems and ig stil true today.
However, although they must ‘work clasaly tegather, they have found i difficult te
communicate ideas, definitions and agreements about what the business objectives
are, and how the computer solution will 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 te mean the
same thing. The opportunities for misunderstanding are legion.
The early 19706 saw the first steps in establishing a standard set of activities and
techniques which could be followed by both groups and were thos a means of
reaching a 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;
4. Develop the IT solution to the specification:
4. Implement the IT solution within the business.
Like a production fine, tne products of each uctivty are input to the next activity.
Different mixes of skills ore required for eact: activity. For example, iin activity 1
business knowledge is particularly important whereas in activity 3, specialist
‘expertise in (T is the primary need,
However, it is not just the sequence of steps that is important. During each slage,
specially developed techniques are used to establish shared understanding and
from that agreement on what the iT solution will do and how it wil address the
business needs.
Prepared by Projact Monta Ut, acting #¢ Ref: AGLO7 VLR Date: 17 Dac 1898
to fied & Bid. Sobckors Status: Feovisional
18/12 *98 15:06 TR/RK NO. 2998
P.020
POL00038829
POL00038829
POL00038829
1O-REC“199G 15:88 FROM BIND & BIRD 10 Sebentiey
i FPG. Pet
Privileged and confidential. Bird & Bird = Prepares in cornemplation of thigation.
Expert ceview of BAPOCL Payment Card Programme
Position Paper - Requirements Optimisation
ate
A2 Identifying the Requirements
A214 Statement of Requirements
‘the first step will be to for the business to construct an agreed definition of the
scope and broad functionality of the required {T system. yn the case of BA/POCL
this was the SSR, which was later formalised as the contract requirements
catalogue. Such documents ean be used as a fist step in specifying the IT sokution.
However, the level of detail supplied about business processes, business rules and
business data is not enough to aflow the iT specialist to complete the specification
of the system te allow detailed design and development to be performed. A further
step of analysing the requirements is essential.
A22 Analysis of Requirements
Three areas need to be addressed:
4. The information about the business that needs to be held within the [T system
2. The business rules that have to be followed by the programs within the IT
system
3. The business events that will cause partioula programs to be executed in the IT
system
The analysis needs to be performed by specitists skilled in the use of particuter
fools and techniques that have been devaioped specifically for this task. Two
techniques are particularly important:
1. Logical Date Analysis - a technique used to produce & complete and
unambiguous definition {the Logicat Oata Model) of all the business data that
is to be stored and manipulated within the new IT system.
2. Functional Analysis - @ process to ensure that the business rules for
manipulating the business data defined in the logical data mode! are aiso
complete and unambiguous.
Note that both forms of analysis are focusing on the business requirements and do
not address issues of how the IT system js fo he designed. Indeed, itis possible to
perform the two aclivities without a view to implementing @ computer system af ail,
However, ‘Lit often appropriate to identify some constraints on the hype of solution
being sought €.9. the system software needs to be the same as existing fT aystems:
the Fea fect of the computer sereen/ keyboard should be consistent wit)
company standards; for What period the systent is to be ‘available’ each day. Such
requirements should be kept clearly separated trom the business requirements.
The final product of the analysis should be 2 requirements trace which identties
how every requirement in the requirements catsdague is embodied in the analysis.
AS Requirements Analysis Methods
A detailed requirements analysis will, at a mininwmn, contain the following:
» Logical Data Model
« Rata Flow Diagrams
Preaarea by Project Mentore Unt, acting es Raf ASLO? VED Date: 17 Bec 1850
sub-contractors 10 8 ges
18/12 '98 15:06 TR/RX NO. 2998 P.O21 @
POL00038829
POL00038829
Tae as
1e-Dec-i9ee iSGS FROWN BieD 3 BIRD
Fras
peviteged and confidentiat. “Bird & Bird Preparegin Aiea
Expert ceview of BA/POCL Payment Card Programme
Position Paper « Requirements Optimisation
a eeemeatc t
~ Functional Description in Structured English
ABA
« Constraints on design and operation
Individual authors and commercial organisations nave developed and sold named
methods. Some are no more than
descriptions in books. Others are fully fedgad
packages of documemiation, software tools and training packages. Some focus only
‘on the requirements analysis process, others cover fhe compl
ete [T life cycle from
strategy through to live support. A fist of some of these is presented in Appendix B.
However, ever though the scope varies, they have similar underlying principles and
techniques when ca
ments analysis.
The UK govermment’s Central Computer and Jelecommunications Agency (CCTA)
recognised the importance of vsing appropriate mathods. it employed LEMS to
enhance its LSOM method to develop 'SSADM - Structured System Analysis and
Oesign Method. This is now
the standard method used by Government
departments, It is also very popular in industty with a wealth of people experienced
in its use.
Logical Data Modal cLom’)
‘this is a complete and unambiguous definition of afl ine business data that is to be
held within the computer system. {t defines:
« the business objects
of interest @.9-
Customer, Authorised Payment
Encashment. The general term for business. objects is ‘entity types’
«the attributes of interest for each entity (yeu: e.g, for he Customer entity ve will
want to record the customer's
NINO, surraute. nominated post office atc. The
definition for each attribute will be ata detaited fevel. The type of attnbute -
numeric, alpha-numeric, etc,, the maximum
length, wheter it must have & value
‘or is optional, whether it has a fixed range of values and what they ere €.g. @
Customers Geograpnical Restriction indicator may only have
one of a smal
number of values, each of which has a spscific meaning. itis also essential to
= of values oe ian be used to unicuely Wdontly # paréeular Insianes
an entily 2.9, a Post Office is identified by « FAD attribute.
relationships 9:
‘Gustomer (as beneficiary).
This information is recorded within
& Customer may be
Authorised Payments, but an
betwean entity types and the nature of those
the beneficiary af one or more
Authorised Payment must be for a single
a Data Dictionary.
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, put also, and more importantly, a #
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 rmigunderstanding and delay is to be avoided.
prepared by Project Mentors Lid, ecting 6
fupcermmaciars 10 Bint & eet, Goickors
18/12 '98 15:06
Ret AsZ07 V2 Date: 17 Cec 1968
‘Statice: F rovteional
TX/RX NO. 2998 P.022
POL00038829
ABQ
ABS
ASA
MS 1STUS FRU BER x BIKL ve Oe
Privileged and confidential. Bird & Bird Prepares tr commengeon
Expert review of BA/POCL Payment Card Programme
Position Paper - Requirements Optimisation
Data Flow Diagrams COFDS")
The computer will need to support and implement selected business functions.
‘These business functions take data as inout, perform some actions upon itt and
deliver some results €.9. THe Encash Payments business function qnight identify the
payments for a selected customer, make the encashment. mark each payment as
tencashed’ and produce a receipt.
As their name suggests, OFDs 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 systern which will cause something to be done
within the computer system ¢.g. & Post Office has been temporarily closed. This
event needs to be fed to a function of the system to change the recorded status of
the Post Office to ‘temporarily dosed’.
The process of ouilding the DFD allows cominon functions to be identified (ie.
things that are done for more than one reason) 5° that a single description of the
function 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 Data Model.
Where flows hava a complex sequence of daia ems, these wil be described in
detail using structure diagrams.
A compuler programmer needs a complete and unambiguous definition of the
business functions that are to be replicated in the comouter programs. Narrative
descriptions are inadequate, Structured English {sometimes known «8S.
pseudo-code) allows for precise definitions that both business and [T specialists can
understand. A simple example might be:
¥
The payment’s first-payment-due-date Is less than or equal to today
And
The payments payment-expiry-date 15 equal to or greater than today
Thea
Encash the payment
End-if
‘The functional descriptions refer to the entity types and thelr attributes as identified
in the logical data model. This may be supplemented by fists and tabtes, but the
Syuctured Englisn ts essential for unambiguous dafinition of business rules. tenis
missing from the logical date madel are also identified during this activity
‘The components of the requirements analysis described above are in business
terms only. Indeed, they could be produced without consideration of the computer
solution, However, it is often the case that the pusiness organisation already has IT
systems with which the new system fs te communicate, or has standards for such
companents as computer operating systems. These need io be clearly identified
and recorded so that the IT designers may take them into account when producing
the detailed design of their soltion.
Prepared by Project Mentors Lid. acting 5 Rat: AAZO? VIZ fate: 17 Ber 1908
sup.conuraciors 0 Bins & Girt, Sobetors Salar: f eescronat
18/12 '98 15:06 TX/RK NO. 2998
P.023
POL00038829
POL00038829
POL00038829
1E-DEC~1998 15310 FROM IRD & BIRD
ASS
TO eet
Privileged and confidentiat. «Bird & Bird Prepared in contemplation of tigation.
Expert review af BA/POCL Payment Card Programme
Pasition Paper - Requiremeats Optimisation
Operational Characteristics
The pusiness will identify minimum peronnance targets for the functions
imolemented in the new computer system 9 "The encashable payments for 4
customer must be presented on the screen within 2 seconds of the entry of the
customers NINO”, oF “Urgent Payments must be visible at the counter of the
nominated Post Office within 30 minutes of their presentation to PAS".
Prepared ty Projcol Maniore Lid, Song 2¢ Rat ASLO? 2 Date 17 Deo 1868
tub-coniractors 10 Bird & Bird. Sobewors Btalua’ Provional
18/12 ‘98 15:06 TX/RX NO. 2998
P0286
POL00038829
POL00038829
2O-DEC-1998 19140 FROM BIRD & BIRD Jo Geieeae
Priviioged and confidential. Bird & Bird Prepare ca COtmerigARoaN UE spans: Pe atoraite
Expert review of BA/POCL Payment Card Programme
Pasition Paper - Requirements Optimisation
B DOCUMENT CONTROL
Bi Change History
(Wersion Bata Status Purpose
Ea} <EAaHOGE I Draft I For review by Project Mentors team.
Ta I V7AZHSSE I Provisional For presentation to Bird & Bid and
/ Authorities
B2 Changes Forecast
None expected
83 Distibutian
Project Mentors I Bird & Bird Benefits Agency POCL
Andrew Davies Hamist Sandison /
B4 Glossary
[Analysis Defining the “purpose, Gbjpctives, and requirements for the
application.
Design Fhe translation of application requirements into a particular
technological implementation.
SSAOM Swuctired System Analysis and Design Method was developed
by the Govemment's Central Computer and Talecommimications
Agency (CCTA). SSADM version 1 was introduced in 9987; the
current version, 4.0, was most recently modified in the mid-90s.
SSADM provides a systematic approach to analysis and design
of information technology ((1) applications. itis the standard for
BS References
4. Selection of Exampies of Problems Facing Pathway as set ‘out in Patnwey
Position Paper dated 6 March 4988
2 Structured Analysis and System Specification, Tom DeMarco, Yourdon Press,
Englewood Ciilfs, NJ: 1973.
Prepared by Project Mentors Ud. acting 43 Rot. Ax 207 VES Date: 17 Dec 1996
suDcontncery 1 Rie & Bard Softens ‘Bhatia: Creseionat
18/12 ‘$8 15:06 TR/RX NO. 2998 P.O25 I I
POL00038829
POL00038829
“28-DEC-1998 15:10 FROM. BIRD & BIRD
S é TO 97763961 ee
< Privileged and confidential. Bird & Bird Prepared in contemplation of tigation.
Expert review of BA/POCL Payment Card Programme
Position Paper - Requirements Optimisation i
4. Structured Systems Analysis: Tools and Techniques, Chris Gane and Trish
Sarson, Prentice-Hall Inc., Englewood Cliffs, NJ, 1979.
4, Modem Structured Analysis, Edward Yourdon, Yourdon Press Engiewood Cliffs,
Nui, 1889.
SSAOM, CCTA I
IEW, Emst & Young
Method 1. Anderson Consulting
4 Front, Deloitte Consulting Group
Pn ow
Document
GAPS to PAS/GMS dala Inierface Definitions aod Validation Ruies (Post Nie 2)
[GABE to PASIGMS Codes Files Definition (Release 3)
BS Documents I
Preporad by Project Mentone Lid. cling of Rat As2.07 V1.2 ate; 17 Cec 1908
Eiereractes We Bird Bled Bofckars Statue: /rovigional
TOTAL P26
18/12 °98 15:06 TX/RK NO. 2998 P.026 g