1. Author: Panna Visani (2015)
Adept Change Management
Presentation for
A leading provider of Payment Services in
the UK(Confidential)

2. The Question
We would like you to give a presentation on the aspects detailed below. In this
presentation you should include any assumptions made and alternatives considered.
The assessment will be of the approach taken rather than the factual correctness of
the business understanding.
An economic region currently has a three day clearing and settlement payment
management system. This processes up to 50 million payment transactions a day.
Their wish is to move to a real time clearing approach.
Abc Ltd has a solution which is thought to meet most of the requirements.

3. Overview
A solution by Abc Ltd may fit the requirements.
How do we understand & analyse the requirements ?
How do we make sure that requirements are not missed ?
Context diagram – present a high Level view of the real-time
systems
Key differences to a Non-real-time system
How to validate requirements working with Solutions
Architecture
Risks & Considerations of the approach taken

4. The Approach - Overview
Strategic Analysis
Business Analysis/Benefit
case
Systems
Analysis/Landscape
Requirements
Engineering
Solution
Developme
nt
Manage
Change
Context Overview
(Brief)
•KEY SENIOR STAKEHOLDERS
•PESTLE
•SWOT
•Interviews, Surveys, Research
Etc
P.I.D.
Business Case (ROI)
•Quantitative Benefits
•Qualitative Benefits
•Opportunity costs
•Risks / Issues
•Existing PAIN points
•AGREE Scope of Change
HL Requirements, HL Solution
Design. Validate Fit (GAPS)
Check Business Case
• HL Requirement ELICITATION
•FUNCTIONAL, NF,
• General Project, Legal, Compliance, etc)
•Technical
•Key STAKEHOLDERS - Baseline Requirements.
•Confirm Feasibility in terms of TECHNICAL (HL
Solution); FINANCIAL (Business Case) &
•GAP Analysis
HL to GOOD detailed
Requirements
•Specific, Clear, Complete, Consistent, Testable,
Relevant, Owned, Achievable, Prioritised
•Interviews, Workshops, Documents, Data
Modelling, Use-case modelling, Systems
Modelling.
Iterative Agile
Dev, Test, Deliver & Ratified
with User Involvement
•Team responsibility – includes Users, Dev,
Analyst, Designers, Architects.
•Working proto-types/ models.
•Design. Dev, Test & Deliver progressively to
a set number of drops
Business
Architect
Solution
Architect
Business
Analyst
(Product
Owner)
Dev &
Test teams

5. The Approach – Hybrid Methodology
Context Overview
(Brief)
•KEY SENIOR STAKEHOLDERS
•PESTLE
•SWOT
•Interviews, Surveys, Research
Etc
P.I.D.
Business Case (ROI)
•Quantitative Benefits
•Qualitative Benefits
•Opportunity costs
•Risks / Issues
•Existing PAIN points
•AGREE Scope of Change
HL Requirements, HL Solution
Design. Validate Fit (GAPS)
Check Business Case
• HL Requirement ELICITATION
•FUNCTIONAL, NF,
• General Project, Legal, Compliance, etc)
•Technical
•Key STAKEHOLDERS - Baseline Requirements.
•Confirm Feasibility in terms of TECHNICAL (HL
Solution); FINANCIAL (Business Case) &
•GAP Analysis
HL to GOOD detailed
Requirements
•Specific, Clear, Complete, Consistent, Testable,
Relevant, Owned, Achievable, Prioritised
•Interviews, Workshops, Documents, Data
Modelling, Use-case modelling, Systems
Modelling.
Iterative Agile
Dev, Test, Deliver & Ratified
with User Involvement
•Team responsibility – includes Users, Dev,
Analyst, Designers, Architects.
•Working proto-types/ models.
•Design. Dev, Test & Deliver progressively to
a set number of drops
Waterfall
SPRINT
SPRINT
SPRINT
SPRINT

6. Assumptions: Context – Strategic Analysis
The Payments Eco-system in question comprises of the following entities:
A Central Bank
Commercial Banks
A Financial Regulator
Automated Clearing House (ACH)
There is growth in E-Commerce and improvements in Logistics allowing retailers to
offer same day & Next day delivery.
The regulator is seeking payment services that offer greater end-user protection and
with a faster cycle, to accelerate the growth of this economy. Also, by modernising
the payment system, it seeks to attract foreign investments, which in turn drives
economic growth.
The government wishes to instil a formal economy to ensure less cash is used, and
thereby benefit from related taxes.

7. Assumptions: SWOT Analysis
Strengths
 Has a Cheque Clearing Payments System (?)
 Has an electronic Payments System (RTGS)
controlled by a Central Bank ?
 Has regulatory bodies & policies
 Has ATMs ?
Weaknesses
 Clearing system takes 3 days
 RTGS is only for Low Volume, High Value
inter-bank settlement
Opportunities - To move to
 Real Time Person-to-Person Payments
 Real Time Business to Business Payments
 Real Time Credit-Card settlement processing
 Improve Access to Alternative Payment
Service Providers, increase competition &
reduce costs
Threats
 Expected growth of E-Commerce, Credit
Card payments & M-Commerce (use of
Smart Phones)
 Disruptive Technologies
 Consumer behaviour & expectations

8. WE WILL ASSUME THAT A BUSINESS CASE HAS BEEN BUILT, AND CONFIRMS THE FOLLOWING
The CENTRAL BANK & LEGISLATION ARE DRIVING THE NEED FOR THIS CHANGE
The Objective is for a Real Time Payments system to provide the following:
Assumptions: Business Case
• Payers experience is as easy as with Cash
Speed, Convenience
• Payment accessible anywhere, without need for Brank
or ATMUbiquity
• Privacy & integrity of individual must be guaranteed
Safety

9. A Real Time Payments Model:
Remitting Customer
Beneficiary
Customer
SENDING BANK RECEIVING BANK
CENTRALISED INFRASTRUCTURE
(FASTER PAYMENTS SYSTEM)
CENTRAL BANK
1
2
3
5 4
6
7 8
SECONDS
MESSAGING
AT INDIVIDUAL
TRANSACTION LEVEL

10. A Traditional Clearing (Non-RT) Payments Model:
Remitting Customer
Beneficiary
Customer
SENDING BANK RECEIVING BANK
CENTRAL BANK (DNS)
1
2
3
AUTOMATED
CLEARING HOUSE 4 ONLY
NET BALANCE IS
SETTLED BETWEEN
BANKS
End Of Day
BATCHED
Transactions
DAYS
5

11. Key Differences to Non RT:
 Handling of transactions in a Non-batched manner.
Clearing is still a Separate Step to Authorisation & Settlement. But, with Real-time
payments, there is NO DELAY before a Payee’s Bank has access to the funds and can
make them available to the Payee.
Faster Payments through a Real-Time Payments Service separates the Settlement
stage clearly from the Clearing, since in most cases the ‘Payer’ and ‘Payee’ are not
concerned with when the Banks settle their own accounts.
TIME (DAYS)
TIME (SECONDS) ………………END OF DAY
AUTH
AUTH
CLEARED
CLEARING
SETTLE
SETTLE

12. Ensure GOOD requirements –by meeting these criteria:
 An Owner – Ensure the requirement is justifiable, and traceable
A Priority (MoSCoW) – Ensure the requirement is relevant, and necessary (has value)
 Is Consistent (internally & with other requirements)
Is Testable – What are the ‘Success Criteria’ ? (SMART)
Is Clear, Unambiguous and not generalised (Specific).
Is Complete !
The High Level Requirements need to be sufficiently detailed to allow Solutions
Architect to generate a High Level design. It should also be possible to walk through
this document with appropriate stakeholders to validate these requirements.
High Level Requirements – User Stories

13. For Each High Level Requirement...apply techniques
Who
What
WhyWhen
Where
FUNCTIONAL
NON-FUNCTIONAL
TECHNICAL
GENERAL
AndCategorise, toensurecompleteness

14. Gov
Central
Bank
End User
Regulators
Settlement
Payment
Service
Provider
Merchant
Banks
Banks
Building
Soc.
Consumer
Groups
Technology
Providers
E.g. Who?
ENSURE REQUIREMENTS ARE COMPLETE BY ENGAGING THE RELEVANT STAKEHODLERS
Identify key Stakeholders, Actors, Users, Internal, External

15. With Solutions Architects, develop a documented & logical model of the
proposed solution based on the high level requirements.
BA to act as the Product Owner – Agile – as proxy for the stakeholder
group.
Reference HL requirements as ‘Product Back-log’
Prepare Plan of time-boxed Sprints for groups of related functionality to
be delivered & reviewed with the assigned user groups.
Reference MoSCoW priorities of HL requirements to optimise effort/time
During Sprint Planning - As detailed requirements are elicited, Validate
High Level requirements, and split EPICs further as required.
Detailed stories should be elicited within each sprint with User review
Validate Requirements – User engagement

16. Key elements
- Requirements Catalogue (Product Backlog)
- ‘Modelling’ techniques – run work-shops to identify gaps.
- Use-cases and data-models
- User Stories, Epics
- Prototyping; review of functionality at the end of each sprint.
- Adjust requirements with feedback
- Build the actual solution incrementally, getting it verified along the way.
Validate Requirements – User engagement

17. Not pure Agile. Hybrid approach has some loss of flexibility by working
to fixed deadlines, cost forecasting and risk assessments.
The best of waterfall - retains the clarity of scope, and dependency
tracking.
May allow for effective delivery of Software in Agile fashion, while
allowing product owners and hardware development to follow a
traditional approach.
Requires tight collaboration – it ensures teams can define requirements,
and still adapt to changing requirements, allowing feedback from both
the waterfall & agile sides of the team, allowing for continuous delivery.
Best suited for re-use of software – similar products, and quick turn-
around.
Risk of losing control of the Product Backlog; mitigate by using software
with ‘version release planning’ features.
Risks, Considerations for Water-fall/Agile hybrid