Assignment 1 - Solution Architecture Definition

Systems Architecture
Assignment 1: Solution Architecture Definition
Template
Version: 1.02 Issued: Status: Document ID:
Internal Use Only

ISYS1088-89: SYSTEMS ARCHITECTURE
Document control
Title Assignment 1 - Solution Architecture Definition
Contact(s) for inquiries and proposed changes
For information regarding this document or if you have any questions or suggestions regarding the content, please contact
the following:
Name Title
Change history
Version Date Revised by Brief outline of changes
1.00 22 February 2019 <Your name here> Initial version
Approval or Sign off
Name Title
ASSIGNMENT 1: SOLUTION ARCHITECTURE DEFINITION Page 2 of 25

ISYS1088-89: SYSTEMS ARCHITECTURE
Table of Contents
1 Introduction...................................................................................................................................4
1.1 Purpose of this document....................................................................................................4
1.2 List of acronyms...................................................................................................................4
1.3 References and related documents......................................................................................4
2 Overview of requirements.............................................................................................................5
2.1 Summary of functional requirements..................................................................................5
2.2 Summary of non-functional requirements...........................................................................5
2.3 Out of scope statements......................................................................................................6
3 Users, Actors and System Context.................................................................................................7
3.1 Human users, actors and their location................................................................................7
3.2 System users (Non-human users).........................................................................................7
4 Architecture overview...................................................................................................................8
5 Functional viewpoint: Component model...................................................................................11
5.1 Component relationship diagram.......................................................................................11
5.2 Interaction diagrams..........................................................................................................13
5.3 Component interfaces........................................................................................................15
6 Deployment (Operational) Viewpoint..........................................................................................16
6.1 Logical Locations View........................................................................................................16
6.2 Deployment Unit View.......................................................................................................17
6.3 Logical Operational View....................................................................................................17
6.4 Physical Operational View..................................................................................................18
6.4.1 Location: <Location 1>..................................................................................................20
6.4.2 Location: <Location 2>..................................................................................................20
7 Architectural change cases..........................................................................................................21
8 Assumptions................................................................................................................................22
ASSIGNMENT 1: SOLUTION ARCHITECTURE DEFINITION Page 3 of 25

ISYS1088-89: SYSTEMS ARCHITECTURE
1 Introduction
1.1 Purpose of this document
This document presents the Solution Architecture Definition for the ACME Business Banking Online
System. It elaborates on the core architectural viewpoints:
 Requirements viewpoint
 Functional viewpoint (component model)
 Operational viewpoint
It presents the Assignment 1 submission for the RMIT ISYS1088-89 course.
1.2 List of acronyms
Table 1: List of acronyms
Acronyms Descriptions
BBO Business Banking Online
1.3 References and related documents
Table 2: References and related documents
No ID Document title Version
[1] Assignment 1 spec
[2] Case Study Specification Document
ASSIGNMENT 1: SOLUTION ARCHITECTURE DEFINITION Page 4 of 25

ISYS1088-89: SYSTEMS ARCHITECTURE
2 Overview of requirements
2.1 Summary of functional requirements
<Present here your concise summary of Functional Requirements. Keep it under 2 pages>
Functional requirements of a software are the necessary functions that the software is designed to
do. The new banking software is designed to do banking functions, hence these functions are the
functional requirements for the software. The functional requirements for the software are:
1. The software must allow the customers to view their accounts, look up transactions, do
different payments and download their account statements.
2. The software must allow the customers to send their payment instructions as a batch for
execution as a single batch.
3. The software should also run on the mobile platform providing all the functions it provides in
the desktop versions.
4. The software should also support customer service feature over the phone. The customers
will be able to enquire about specific transactions through it.
5. It should be able to manage and display all the transactions done by the user from start to
end.
6. The software should enable the users to make all types of payments online that are
supported by the bank.
7. The software should be able to create and arrange payment schedules of the customers and
execute them on time.
8. The software must allow the user to login into their accounts using username and password.
9. The user should be able to view his account transaction history page when clicking on
homepage and create payment instruction like adding payment instruction details.
10. The software must allow the user to access their payee address book and perform add, edit
and delete operations.
11. The software must allow the user to access their statements, past payments, pending
payments, favourite payments, account information and interest tax summary.
12. The software should let the payment approvers view the payment details in their
dashboards and allow them to approve or decline the payment.
13. The software must allow the limit approvers to view the limit details in their dashboards and
allow them to approve or decline the payment limits.
2.2 Summary of conflicting requirements and affected stakeholders
Conflicting requirements emerge when a stakeholder asks for two requirements from a system at
the same time or two stakeholders disagreeing over the best course for the project completion. In
our case study, the ACME BBO system’s main function is to allow the customers to do bank jobs via
the software using a server. For example, two stakeholder groups like the management and the IT
division may disagree on the best way to procure server services for their application. The IT division
may ask for a new in-house server to be established for easy use and access, while the management
to save costs might want to outsource the services to another company. This creates a conflict
ASSIGNMENT 1: SOLUTION ARCHITECTURE DEFINITION Page 5 of 25

ISYS1088-89: SYSTEMS ARCHITECTURE
between the two groups. The affected stakeholders here are the bank’s employees. This can be
resolved by doing a cost and benefit analysis and adopting the best-suited method. This will then
resolve the conflict.
2.3 Summary of non-functional requirements
The non-functional requirements of the new software are:
1. The software must be completed in nine months’ time and presented to the customers.
2. The software will need the help from external IT Service Provider Company for its full
development and design.
3. The software will also need assistance from the external RMIT business consultant team
to estimate and devise the software development requirements and develop the BBO
frontend.
4. The software will need help from ACME bank team for the development of its banking
features.
5. The software’s payment handling services will be provided by the SWIFT payment
gateway company.
6. The software should be able to handle expected 3000 customers per year, 2000 users
accessing the BBO at the same time and 60-70 lakhs transactions per day for the first
year.
7. The software or the application should be available 24 x 7 to the customers, so that they
can perform a transaction anytime anywhere.
Table 3 presents a high-level view of key architecturally significant non-functional requirements
(NFRs).
Table 3: High level view of non-functional requirements
No NFR Value or Description
Static volumetrics (24 months)
1. Customers growth per year 3000
2. Users accessing BBO simultaneously 2000
3. Transactions per day 6000000-7000000
Dynamic volumetrics (24 months)
4.
5.
Availability, reliability, recovery objectives
6. Time the software is available to the customers 24 hours x 7 days
7. Reliability for the mainframe components 99%
8. Reliability for the non-mainframe components 95% to 99%
ASSIGNMENT 1: SOLUTION ARCHITECTURE DEFINITION Page 6 of 25