COMPUTER ENGINEERING - Middle East Technical … · COMPUTER ENGINEERING ALGORITHMIC TRADING SOFTWARE REQUIREMENTS SPECIFICATION ... algotrading, is the use of electronic platforms

COMPUTER ENGINEERING

ALGORITHMIC

TRADING

SOFTWARE REQUIREMENTS SPECIFICATION

Prepared by MoneyFellas :

ALİ ŞAVKAR 1819879

GÖKÇER YAPAR 1819648

MURAT TARIMER 1819556

ÖMER YAVUZ 1819655

DATE: 30.11.2014

I

CONTENTS

1. INTRODUCTION ...................................................................................... 1

1.1. PROBLEM DEFINITION ....................................................................... 1

1.2. PURPOSE ......................................................................................... 1

1.2.1 PURPOSE OF THE SOFTWARE REQUIREMENTS SPECIFICATION .......... 1

1.2.2 INTENDED AUDIENCE OF THE SOFTWARE REQUIREMENTS

SPECIFICATION ......................................................................................... 1

1.3 SCOPE .............................................................................................. 2

1.4. LITERATURE SURVEY......................................................................... 2

1.5. DEFINITIONS, ACRONYMS AND ABBREVIATIONS .................................. 6

1.6. REFERENCES .................................................................................... 7

1.7. OVERVIEW ....................................................................................... 8

2. OVERALL DESCRIPTION .......................................................................... 8

2.1. PRODUCT PERSPECTIVE ................................................................... 9

2.1.1. SYSTEM INTERFACES ................................................................. 9

2.1.2. USER INTERFACES .................................................................... 10

2.1.3 HARDWARE INTERFACES ............................................................ 11

2.1.4. SOFTWARE INTERFACES ............................................................ 11

2.1.5. COMMUNICATION INTERFACES ................................................... 12

2.1.6. MEMORY .................................................................................. 12

2.1.7. OPERATIONS ............................................................................ 12

2.1.8. SITE ADAPTATION REQUIREMENTS ............................................. 12

2.2. PRODUCT FUNCTIONS ..................................................................... 13

2.2.1. USER FUNCTIONS ..................................................................... 13

2.2.2. SYSTEM FUNCTIONS ................................................................. 14

2.3. CONSTRAINTS ................................................................................ 16

2.3.1. PROGRAMMING LANGUAGES ...................................................... 16

2.3.2. MEMORY MANAGEMENT ............................................................. 16

2.3.3. OPERATING SYSTEMS ................................................................ 17

2.3.4. HARDWARE LIMITATION ............................................................ 17

2.3.5. SECURITY AND RELIABILITY ....................................................... 17

2.4. ASSUMPTIONS AND DEPENDENCIES ................................................. 17

3. SPECIFIC REQUIREMENTS ..................................................................... 17

3.1. INTERFACE REQUIREMENTS ............................................................. 17

II

3.2. FUNCTIONAL REQUIREMENTS .......................................................... 18

3.2.1. USER FUNCTIONS ..................................................................... 18

3.2.1.1. LOGIN TO SYSTEM .............................................................. 18

3.2.1.2. DEFINE NEW TRADE ............................................................ 18

3.2.1.3. MANAGE PORTFOLIO ........................................................... 19

3.2.2. SYSTEM FUNCTIONS ................................................................. 19

3.2.2.1. GET MARKET DATA .............................................................. 19

3.2.2.2. ANALYZE SECURITIES ACCORDING TO TRADE STRATEGY ....... 19

3.2.2.3. CREATE TRADE ORDERS....................................................... 20

3.2.2.4. MANAGE TRADE ORDERS ..................................................... 20

3.3. NON-FUNCTIONAL REQUIREMENTS .................................................. 20

3.3.1. PERFORMANCE REQUIREMENTS .................................................. 20

3.3.2. DESIGN CONSTRAINTS .............................................................. 21

3.3.2.1. SCALABILITY ...................................................................... 21

3.3.2.1.1. DATA INPUT STREAMS MUST BE SCALABLE ...................... 21

3.3.2.1.2. THE DISTRIBUTED PROCESSING ENVIRONMENT MUST BE

SCALABLE .............................................................................................. 21

3.3.2.2. MODIFIABILITY .................................................................. 21

3.3.2.3. RELIABILITY ....................................................................... 22

3.3.2.3.1. DATA PREPROCESSING MUST BE DECOUPLED FROM DATA

FORMATTING AND CONTAINERS ................................................................ 22

3.3.2.3.2. TRANSACTIONS AND ORDERS MUST BE 100% RELIABLE .. 22

3.3.2.4. SECURITY ........................................................................... 22

3.3.2.4.1. ANY UNAUTHORIZED LOGIN OR DISPLAY REQUEST MUST BE

PREVENTED ............................................................................................. 22

3.3.2.4.2. INTELLECTUAL PROPERTY (IP) MUST BE SECURED ........... 23

3.3.2.5. MAINTAINABILITY ............................................................... 23

3.3.2.6. OTHER CONSTRAINTS .......................................................... 23

4. DATA MODEL AND DESCRIPTION ............................................................ 23

4.1. DATA DESCRIPTIONS ...................................................................... 23

4.1.1. DATA OBJECTS ......................................................................... 24

4.1.2. DATA DICTIONARY .................................................................... 26

5. BEHAVIOURAL MODEL AND DESCRIPTION ............................................... 26

5.1. DESCRIPTION FOR SOFTWARE BEHAVIOUR ....................................... 26

5.2. STATE TRANSITION DIAGRAMS ........................................................ 27

III

6. PLANNING ........................................................................................... 28

6.1. TEAM STRUCTURE ........................................................................... 28

6.2. ESTIMATION (BASIC SCHEDULE) ...................................................... 28

6.3. PROCESS MODEL ............................................................................ 29

7. CONCLUSION ....................................................................................... 29

8. SUPPORTING INFORMATION .................................................................. 30

8.1. INDEX ........................................................................................... 30

8.2. APPENDIXES .................................................................................. 30

IV

TABLES

TABLE 1 - ABBREVIATIONS, ACRONYMS OR DEFINITIONS .............................. 6

TABLE 2 - EXPLANATION OF SYSTEM MAIN STATES ...................................... 26

V

FIGURES

FIGURE 1 - ALGOTrader EXAMPLE SCREENSHOT ............................................ 2

FIGURE 2 - QUANTOPIAN EXAMPLE SCREENSHOT .......................................... 3

FIGURE 3 - BLOCK DIAGRAM OF THE SYSTEM ............................................... 9

FIGURE 4 - LOGIN SCREEN OF THE SYSTEM ................................................ 10

FIGURE 5 - MAIN SCREEN OF THE SYSTEM .................................................. 10

FIGURE 6 - NEW TRADE CREATION SCREEN OF THE SYSTEM ........................ 11

FIGURE 7 - LOGIN TO SYSTEM AND DEFINE NEW TRADE USE CASE DIAGRAM . 13

FIGURE 8 - MANAGE PORTFOLIO USE CASE DIAGRAM .................................. 14

FIGURE 9 - MANAGE TRADE ORDERS USE CASE DIAGRAM ............................ 15

FIGURE 10 - CREATE TRADE ORDERS USE CASE DIAGRAM .......................... 15

FIGURE 11 - GET MARKET DATA AND ANALYZE SECURITIES ACCORDING TO

TRADE STRATEGY USE CASE DIAGRAM ....................................................... 16

FIGURE 12 - CLASS DIAGRAM OF THE SYSTEM ............................................ 24

FIGURE 13 - STATE DIAGRAM OF THE SYSTEM ............................................ 27

FIGURE 14 - AGILE SOFTWARE DEVELOPMENT METHOD REPRESENTATION .... 29

ALGORITHMIC TRADING MoneyFellas

- 1 - Software Requirement Specification Version 1.o

1. INTRODUCTION

1.1. PROBLEM DEFINITION

Trading with traditional methods is not enough fast for modern finance

system. Great increase in data amount and computation powers of computers

force trading methods to keep up with contemporary circumstances. Therefore,

algorithmic trading become new and necessary, even compulsory, field in

intersection point of computer and finance worlds. Algorithmic trading, also called

algotrading, is the use of electronic platforms for entering trading orders with an

algorithm which executes pre-programmed trading instructions whose parameters

may include timing, price, or quantity of the order, or in many cases initiating the

order by automated computer programs.

1.2. PURPOSE

1.2.1 PURPOSE OF THE SOFTWARE REQUIREMENTS SPECIFICATION

The purpose of this document is to describe the architectural requirements

which will explain the specifications of system architecture for algorithmic trading.

With respect to the algorithmic trading systems, this document will describe

following properties:

Context of the system

Architectural scope of the system

Quality requirements of the project

Access and integration requirements of the project

Specification of the architectural constraints.

1.2.2. INTENDED AUDIENCE OF THE SOFTWARE REQUIREMENTS

SPECIFICATION

Investment banks, pension funds, mutual funds, and other buy-side

(investor-driven) institutional traders can use software product of this project.

Actually, anyone who wants to evaluate his/her investment can take advantage of

the project. Stock exchange is considered as primary marketplace, especially BIST.



1.3. SCOPE

The name of the software product is AlgorithmicTrader. This product uses

computational algorithms to make trading decisions, submit orders and guide the

orders after submission. Software is considered to have two kind of analysis which

are making decision instantly (HFT) and making decision at the end of the trading

day to give proposals. The software product is aimed to complete whole trading

transactions such as buy or sell securities. During operating of algorithms, the

software records analysis of all profits and losses, logs of each transaction and the

monitoring of successive, outstanding or unfilled orders into the database.

1.4. LITERATURE SURVEY

There are some projects which are similar to our project. However, we will

mention from two most popular ones. Firstly, there is a platform named as

ALGOTrader. AlgoTrader is a Java-based algorithmic trading platform that enables

trading firms to rapidly develop, simulate, deploy and automate any quantitative

trading strategy for any market. It gives users flexible control of high-speed, fact-

based trading for consistent, good results. Detail information can be reached by

clicking http://doc.algotrader.ch/html/index.html link[16].

FIGURE 1: ALGOTrader EXAMPLE SCREENSHOT

http://doc.algotrader.ch/html/index.html



Secondly, there is a platform named as Quantopian. Quantopian is an algorithmic

trading platform in browser. Write (or clone) an algorithm; test it against 12 years

of US stock data; paper trade it against live data; and then trade the algorithm

through your brokerage account. Quantopian also hosts a community where

members can ask for help, share ideas, discuss code, and share data. Members

can learn from each other and work collaboratively. Quantopian's community and

back tester is free for everyone to use. There will be a charge for connecting the

algorithm to the brokerage. Pricing isn't finalized, but they are considering a flat

monthly fee. You own your algorithms. Algorithms are kept secret. This is different

than our project because Quantopian is just a framework that distinct algorithms

can be integrated to[17].

FIGURE 2: QUANTOPIAN EXAMPLE SCREENSHOT

Generally, source codes of these type of projects are closed. The ones with

open source code are implemented by python, licenses are problematic or

incompatible with our project idea. Therefore, these type of projects are not

enough information source for our project.

The Financial Information Exchange (FIX) Protocol is a message standard

developed to facilitate the electronic exchange of information related to securities

transactions. It is intended for use between trading partners wishing to automate

communications. The electronic communication protocol initiated in 1992 for

international real-time exchange of information related to the securities

transactions and markets. The FIX Trading Community is the non-profit, industry-

driven standards body with the mission to address the business and regulatory

http://www.fixprotocol.org/

http://en.wikipedia.org/wiki/Communications_protocol

http://en.wikipedia.org/wiki/Security_%28finance%29

http://www.fixtradingcommunity.org/



issues impacting multi-asset trading across the global financial markets through

the increased use of standards, including the FIX Protocol messaging language,

delivering operational efficiency, increased transparency, and reduced costs and

risk for all market participants[7].

There are some available open source FIX protocol libraries that can be

integrated to our software. QuickFIX and fix8 are the most popular frameworks.

QuickFIX is a free and open source implementation of the FIX protocol. C++,

python and ruby implemented versions are available but we will use C++ version

in our project[12]. Other framework Fix8 is an open source C++ development toolkit

and runtime engine designed to provide FIX connectivity to user land applications.

Fix8 provides an API and framework that you can quickly develop a FIX interface

on. Fix8 is flexible enough to work with any standard FIX version or custom variant.

Fix8 is a member of the Fix Trading Community[13].

The QuantLib project is aimed at providing a comprehensive software

framework for quantitative finance. QuantLib is a free/open-source library for

modeling, trading, and risk management in real-life. QuantLib is written in C++

with a clean object model. It is a cross-platform free/open-source tool for

derivatives and financial engineering. Finance is an area where well-written open

source projects could make a tremendous difference. QuantLib is such an open

source project[14].

JavaFX is a set of graphics and media packages that enables developers to

design, create, test, debug, and deploy rich client applications that operate

consistently across diverse platforms. JavaFX is intended to replace Swing as the

standard GUI library for Java SE, but both will be included for the foreseeable

future. The current release has support for desktop computers and web browsers

on Windows, Linux, and Mac OS X. We will implement GUI of the software by using

JavaFX[15].

MongoDB is a document oriented database that provides high performance,

high availability, and easy scalability. MongoDB is designed with two central design

parameters. First key lookups should be very fast. Second is that operations should

be atomic at the row level and should not span records[10]. This allows the database

to be searched very effectively since no operation should span multiple machines

and in turn this allows them to build scale out architectures. These databases are

built for very write heavy workloads and to be able to have fast key lookups to

render webpages. Therefore, MongoDB is the best choice for our project.

http://www.fixprotocol.org/

http://www.fix8.org/index.html



http://www.gnu.org/philosophy/free-sw.html

http://www.opensource.org/

http://en.wikipedia.org/wiki/Swing_%28Java%29

http://en.wikipedia.org/wiki/Graphical_User_Interface

http://en.wikipedia.org/wiki/Java_Platform,_Standard_Edition

http://en.wikipedia.org/wiki/Desktop_computer

http://en.wikipedia.org/wiki/Web_browser



To take correct and reliable results from analysis of market data, we will use

some genetic algorithms which are binary option and bond option. Short

explanations about genetic algorithms, binary and bond option can be given as

follows:

What Are Genetic Algorithms ?

Genetic algorithms (GAs) are problem solving methods (or heuristics) that

mimic the process of natural evolution. Unlike artificial neural networks (ANNs),

designed to function like neurons in the brain, these algorithms utilize the concepts

of natural selection to determine the best solution for a problem. As a result, GAs

are commonly used as optimizers that adjust parameters to minimize or maximize

some feedback measure, which can then be used independently or in the

construction of an ANN[4].

Binary Option

In finance, a binary option is a type of option in which the payoff can take

only two possible outcomes, either some fixed monetary amount of some asset or

nothing at all (in contrast to ordinary financial options that typically have a

continuous spectrum of payoff). The two main types of binary options are the cash-

or-nothing binary option and the asset-or-nothing binary option. The cash-or-

nothing binary option pays some fixed amount of cash if the option expires in-the-

money while the asset-or-nothing pays the value of the underlying security. They

are also called all-or-nothing options, digital options (more common in

forex/interest rate markets), and fixed return options (FROs) (on the American

Stock Exchange). For example, a purchase is made of a binary cash-or-nothing

call option on XYZ Corp's stock struck at $100 with a binary payoff of $1,000.

Then, if at the future maturity date, the stock is trading at above $100, $1,000 is

received. If the stock is trading below $100, no money is received. And if the stock

is trading at $100, the money is returned to the purchaser[5].

Bond Option

A buyer of a bond call option is expecting a decline in interest rates and an

increase in bond prices. The buyer of a put bond option is expecting an increase in

interest rates and a decrease in bond prices. Generally, one buys a call option on

the bond if one believes that interest rates will fall, causing an increase in bond

prices. Likewise, one buys the put option if one believes that the opposite will be

the case. One result of trading in a bond option, is that the price of the underlying

http://www.investopedia.com/terms/n/neuralnetwork.asp

http://www.investopedia.com/terms/a/algorithm.asp

http://en.wikipedia.org/wiki/Finance

http://en.wikipedia.org/wiki/Option_%28finance%29

http://en.wikipedia.org/wiki/Asset

http://en.wikipedia.org/wiki/American_Stock_Exchange

http://en.wikipedia.org/wiki/American_Stock_Exchange

http://en.wikipedia.org/wiki/Maturity_date

http://en.wikipedia.org/wiki/Call_option

http://en.wikipedia.org/wiki/Interest_rate

http://en.wikipedia.org/wiki/Put_option



bond is "locked in" for the term of the contract, thereby reducing the credit risk

associated with fluctuations in the bond price[9].

1.5. DEFINITIONS, ACRONYMS AND ABBREVIATIONS

ABBREVIATION,

ACRONYM OR

DEFINITION

EXPLANATION

Asset An economic resource

BIST

The sole exchange entity of Turkey combining the

former Istanbul Stock Exchange (ISE) (stanbul Menkul Kıymetler Borsası, IMKB), the Istanbul Gold

Exchange(İstanbul Altın Borsası, İAB) and the

Derivatives Exchange of Turkey(Vadeli İşlem Opsiyon Borsası,VOB) under one umbrella.

Database A collection of related data

Database Query A piece of code (a query) that is sent to a database in

order to get information back from the database.

DBMS A software package/system to facilitate the creation

and maintenance of a computerized database

Financial transaction

An agreement, communication, or movement carried out between a buyer and a seller to exchange an asset

for payment.

FIX Protocol An electronic communications protocol for international

real-time exchange of information related to the securities transactions and markets.

GUI Graphical User Interface

IEEE Institute of Electrical and Electronics Engineers

Portfolio A financial term denoting a collection of investments

held by an investment company, hedge fund, financial institution or individual.

Security A tradable financial asset of any kind

Stock A type of security that signifies ownership in a

corporation and represents a claim on part of the corporation's assets and earnings.

Trade An exchange of a security (stocks, bonds,

commodities, currencies, derivatives or any valuable financial instrument) for “cash"

Option A contract that gives the buyer the right, but not the obligation, to buy or sell an underlying asset at a

specific price on or before a certain date

UML Unified Modelling Language

TABLE 1: ABBREVIATIONS, ACRONYMS OR DEFINITIONS

http://en.wikipedia.org/wiki/Credit_risk



1.6. REFERENCES

The resources listed below are references used in requirement analysis:

IEEE Standard Documents:

[1] IEEE. IEEE STD 830-1998 IEEE Recommended Practice for Software

Requirements Specifications. IEEE Computer Society, 1998.

[2] StarUML 5.0 User Guide. (2005). Retrieved from

http://staruml.sourceforge.net/docs/user-guide(en)/toc.html

[3] Hull, J. (2009). Options, futures, and other derivatives; seventh edition (7th

edition). Upper Saddle River, N.J.: Prentice Hall.

[4] Using Genetic Algorithms To Forecast Financial Markets. (n.d.). Retrieved

November 30, 2014, from http://www.investopedia.com/articles/financial-

theory/11/using-genetic-algorithms-forecast-financial-markets.asp

[5] Binary option. (2014, November 29). Retrieved November 30, 2014, from

http://en.wikipedia.org/wiki/Binary_option

[6] RELEASE: Fraudadv_binaryoptions. (n.d.). Retrieved November 30, 2014,

from http://www.cftc.gov/PressRoom/PressReleases/fraudadv_binaryoptions

[7] FIX Trading Community. (n.d.). Retrieved November 30, 2014, from


[8] Bond option. (2014, November 29). Retrieved November 30, 2014, from

http://en.wikipedia.org/wiki/Bond_option

[9] Bond Option Definition | Investopedia. (n.d.). Retrieved November 30,

2014, from http://www.investopedia.com/terms/b/bondoption.asp

[10] Agile and Scalable. (n.d.). Retrieved November 30, 2014, from

http://www.mongodb.org/

[11] FIX Protokolü Sıkça Sorulan Sorular. (2014, November 30). Retrieved

November 30, 2014, from

http://borsaistanbul.com/uyeozel/SoftwareAndDocuments/pay-

piyasalari/fixsss

[12] QuickFIX. (n.d.). Retrieved November 30, 2014, from

http://www.quickfixengine.org/

[13] High performance FIX protocol apps with fix8 (n.d.). Retrieved November

30, 2014, from http://www.fix8.org/

[14] QuantLib: A free/open-source library for quantitative finance. (n.d.).

Retrieved November 30, 2014 from http://quantlib.org/index.shtml

http://staruml.sourceforge.net/docs/user-guide(en)/toc.html

http://www.investopedia.com/articles/financial-theory/11/using-genetic-algorithms-forecast-financial-markets.asp

http://www.investopedia.com/articles/financial-theory/11/using-genetic-algorithms-forecast-financial-markets.asp

http://en.wikipedia.org/wiki/Binary_option

http://www.cftc.gov/PressRoom/PressReleases/fraudadv_binaryoptions


http://en.wikipedia.org/wiki/Bond_option

http://www.investopedia.com/terms/b/bondoption.asp

http://www.mongodb.org/

http://borsaistanbul.com/uyeozel/SoftwareAndDocuments/pay-piyasalari/fixsss

http://borsaistanbul.com/uyeozel/SoftwareAndDocuments/pay-piyasalari/fixsss

http://www.quickfixengine.org/

http://www.fix8.org/

http://quantlib.org/index.shtml



[15] JavaFX 2 Certified System Configurations. (n.d.). Retrieved November 30,

2014, from

http://www.oracle.com/technetwork/java/javafx/downloads/supportedconfigu

rations-1506746.html

[16] AlgoTrades - Algorithmic Trading Strategies - Algo Trading - Futures

Trading System - Trading Algorithms - Automated Trading Systems -

Quantitative Trading Strategies. (n.d.). Retrieved November 30, 2014, from

http://www.algotrades.net/

[17] Quantopian | Algorithmic Investing | Algorithmic Trading. (n.d.). Retrieved

November 30, 2014, from https://www.quantopian.com/

1.7. OVERVIEW

Next chapter, Overall Description section, of this SRS document gives an

overview of the functionality of the software product. It describes informal

requirements and is used to establish a context for the technical requirements

specification in the next chapter. Third chapter, Specific Requirements section, is

written primarily for developers and testers. It includes whole detailed

requirements which describe functionality details of the software using technical

terms and notions. Fourth section, Data Model and Description section, explains

information domain for the software. Fifth section, Behavioral Model and

Description section, introduces behavior of the software in a detailed way. Sixth

section, Planning section, includes three subsections which are team structure,

basic schedule and process model. Seventh section is Conclusion section. Lastly,

Supporting Information section contains Table of contents, Index and Appendixes

that enable the SRS to be used easily.

2. OVERALL DESCRIPTION

In this chapter of the SRS document, general causes affecting the software

product and the requirements of it are explained. This chapter is a background for

the detailed requirements in the third chapter of this document. This section will

be classified as five subsections, as follows:

http://www.oracle.com/technetwork/java/javafx/downloads/supportedconfigurations-1506746.html

http://www.oracle.com/technetwork/java/javafx/downloads/supportedconfigurations-1506746.html

http://www.algotrades.net/



2.1. PRODUCT PERSPECTIVE

AlgorithmicTrader is a trading platform that enables end-users to easily

manage their money thanks to advantages of the software such as developed

trading algorithms and strategies, making good trading decisions in such a time

consuming work, decreasing emotional impact of the trading and keeping up with

other traders or companies. In addition to this, machine learning is considered to

take part in algorithms running in AlgorithmicTrader. These algorithms will be tried

to be chosen from the most efficient and fast ones. The software product is aimed

to support cross-platforms, i.e. Mac OS X, Windows and Linux Ubuntu. In

development process, Java technologies and C++ code development

environments will be used with several required libraries and APIs as it is explained

below.

FIGURE 3: BLOCK DIAGRAM OF THE SYSTEM

2.1.1. SYSTEM INTERFACES

AlgoritmicTrader operates independently from platform and any other

program, the software has only system interface with the operating system which

connected invisibly by means of C++ and Java libraries.



2.1.2. USER INTERFACES

FIGURE 4: LOGIN SCREEN OF THE SYSTEM

FIGURE 5: MAIN SCREEN OF THE SYSTEM



FIGURE 6: NEW TRADE CREATION SCREEN OF THE SYSTEM

2.1.3 HARDWARE INTERFACES

AlgorithmicTrader must operate over network to fulfill FIX protocol

requirements and to receive or send financial data from/to BIST. Besides, cabled

internet connection is highly recommended rather than wireless connection. This

is because AlgorthmicTrader requires the highest network connection speed to be

able to complete transactions in most efficient and fast way. Therefore, computers

with the fastest processors and cabled internet connection which has high

bandwidth, as much as possible, is strongly recommended.

2.1.4. SOFTWARE INTERFACES

AlgorithmicTrader and its all subsystems are desktop base applications;

therefore, the software is expected to operate at Windows 7 and upper versions

(Windows 8 and 8.1) of Microsoft Windows operating system initially. After

completing Microsoft Windows version, the software will be integrated to Linux

Ubuntu 12.04 LTS and upper versions of Ubuntu and Mac OS X 10.8 and upper

versions of Mac OS. The source code are aimed to have a single copy to operate

on all targeted operating systems and their versions. If this is not possible, this



aim will be get closer by the least modifications on source code versions running

different operating systems.

Java Runtime Environment (JRE), version 1.6 or later, is required for java

source code of the software which is used in GUI part. This part is compatible with

all three operating systems. Server side will be implemented with C++; therefore,

this part is required to be managed by taking into consideration the differences

between operating systems and their versions.

MongoDB is an open-source document database, and the leading NoSQL

database written in C++. This database management system will be used to save

records of whole profits and losses and all successive and failed transactions.

JavaFX software platform will be used to create graphical user interface of

the software.

2.1.5. COMMUNICATION INTERFACES

Sockets will be used to create communication between client-side (java) and

server-side (C++). In addition to this, Transmission control protocol (TCP) and

Financial information exchange (FIX) protocol will be used to take data from stock

market to program server and vice versa.

2.1.6. MEMORY

The system deals with amount of large data so, the required memory need

to be considerable size, at least 1GB. This memory limit can change according to

chosen trading strategy and operating duration of the software.

2.1.7. OPERATIONS

After desired trading options are chosen, there will be one interaction chance

between user and system that is cancelling of trade. Other than this, user can just

monitor the graphics of open and close trades and display portfolio information.

2.1.8. SITE ADAPTATION REQUIREMENTS

MongoDB should be installed and operational on the server side. Java

Runtime Environment, version 1.6 or later, should be installed and operational on

the server side.



2.2. PRODUCT FUNCTIONS

2.2.1. USER FUNCTIONS

The software will perform following user functions:

Login to system

Define new trade

Manage portfolio

FIGURE 7: LOGIN TO SYSTEM AND DEFINE NEW TRADE USE CASE DIAGRAM



FIGURE 8: MANAGE PORTFOLIO USE CASE DIAGRAM

2.2.2. SYSTEM FUNCTIONS

The software will perform following system functions:

Get market data

Analyze securities according to trade strategy

Create trade orders

Manage trade orders



FIGURE 9: MANAGE TRADE ORDERS USE CASE DIAGRAM

FIGURE 10: CREATE TRADE ORDERS USE CASE DIAGRAM



FIGURE 11: GET MARKET DATA AND ANALYZE SECURITIES ACCORDING TO

TRADE STRATEGY USE CASE DIAGRAM

2.3. CONSTRAINTS

2.3.1. PROGRAMMING LANGUAGES

Java, C++ and JavaFX will be used in development of the software.

2.3.2. MEMORY MANAGEMENT

Data which will be handled by the software is excessively great; therefore,

developers should take care of efficient memory management. Also, developers

should be pay attention to memory leaks since C++ does not have a garbage

collector. Developers should call garbage collector built-in function of java if they

realize excessive memory allocation exists.



2.3.3. OPERATING SYSTEMS

The software product is aimed to run on three different operating system

which are Microsoft Windows, Linux Ubuntu and Mac OS X; therefore, developers

should be aware of coding characteristics of all three platforms.

2.3.4. HARDWARE LIMITATION

Final software product should be fast and use memory efficiently, as much

as possible. Therefore, high performance CPUs should be preferred and maximum

effort should spend for memory management.

2.3.5. SECURITY AND RELIABILITY

Security of user login authentication should be provided by main server.

Also, sent and received data should be protected from any kind of third party user

or software.

Reliability of data communication should be provided by TCP/IP/FIX.

2.4. ASSUMPTIONS AND DEPENDENCIES

The software assumes that structure of received data through FIX protocol

is certain. Besides, the software should have capable of handling each received

data without missing.

Poor performance of the dependency systems such as hardware or software

system of computer could impact upon the performance of proposed algorithmic

trading system. A non-exhaustive list of dependencies is shown below.

Risk management systems

Order management systems

Telecommunications networks and ISP’s

Accounting system

3. SPECIFIC REQUIREMENTS

Requirements can be analyzed in three parts as interface requirements,

functional requirements and non-functional requirements.

3.1. INTERFACE REQUIREMENTS

Login Screen : This screen will be displayed after user runs the application.



Main Screen : If login authentication is successful, this screen will be

opened. This screen includes portfolio information of the user, clock, date,

open trades, graphic of selected open trade and new trade button.

New Trade Screen : Necessary fields which are sort of trade, size, expiration

date, maximum profit amount, maximum loss amount and strategy

selection will be shown on screen. Also start button will take place on screen.

User is expected to fulfill these fields according to his/her trading choices

and start the trade.

3.2. FUNCTIONAL REQUIREMENTS

This subsection is a description of each major software function explained in

2.2. Product Functions, along with data flow and requirements of the function.

3.2.1. USER FUNCTIONS

3.2.1.1. LOGIN TO SYSTEM

When user starts the application, he/she sees login screen first. User is

expected to enter username and password. Login is successfully completed if

username and password are matched with the ones in database.

3.2.1.2. DEFINE NEW TRADE

After successful login, user can create new trade by using new trade button.

User should fill six necessary fields to be able to complete new trade creation

operation. First field is trade type, it shows which stock market trading area will

be interested in. Dollar, golden, natural gas can be examples of stock market

trading area. Second field is size, it takes how much money will be invested for

the trade. Third field is expiration date, it shows how long trade will be active. Note

that user can cancel the any trade whenever he/she wants. Fourth field is

maximum profit bound, it defines the maximum profit amount. When this amount

is reached, trade is terminated automatically. Fifth field is maximum loss bound,

it defines the maximum loss amount. When this amount is reached, trade is

terminated automatically. This property of the software enable user to prevent

huge amount of loss in unexpected conditions. Last field is selection of strategy, it

determines which strategy will be used during trading. Strategies include some

constraints during evaluation of user’s investment in stock exchange. For example,



there may be a strategy which operates by monitoring petrol price in stock

exchange. According to petrol price, it creates sell/buy orders. Another example

can be inverse correlation between the U.S. dollar and golden in finance. As the

U.S. dollar depreciates against major currencies, gold is generally perceived to rise

and as the U.S. dollar appreciates, gold declines in prices. As soon as the software

sees any correlated instrument rise, it immediately sells the counterpart. Thanks

to this property, the software guarantees that there will be no loss.

User is expected to fill all these six fields. Note that if a field is leaved as

unselected or unfilled, default value is assigned for that field. Finally, user can

press start button to complete new trade operation and initiate the created trade.

3.2.1.3. MANAGE PORTFOLIO

User can manage his/her capital by adding new capital or removing old

capital. He/she can list the active open trades, calculate profit/loss amount of them

and add new trades or cancel active ones. Besides, user can list close trades,

calculate profit/loss values of them.

User can display graphically current status of any open trades when he/she

clicks related trade from open trades menu of main screen. Besides, user can

display detailed information about selected trade when clicked right button of

mouse.

3.2.2. SYSTEM FUNCTIONS

3.2.2.1. GET MARKET DATA

Market data is received instantly from stock market via FIX protocol.

3.2.2.2. ANALYZE SECURITIES ACCORDING TO TRADE STRATEGY

Each trade has certain constraints such as strategy, maximum loss bound.

Market data are received according to specified trade type. Upon getting certain

market data, these market data and constraints of the trade are evaluated in an

algorithm. Note that this algorithm is determined based upon the strategy of trade.

At the end of evaluation in algorithm, there are three possible results. First of all,

software can decide to sell securities according to analysis. Secondly, software can

decide to do nothing because of there is no benefit of sell/buy of securities. Finally,

software can decide to buy new securities due to expected rise in future.



3.2.2.3. CREATE TRADE ORDERS

According to analysis of market data based upon trade constraints, there

will be created a trade order. Trade order can be sell or buy securities and they

can have two types which are pending and post. Note that status of trade order is

pending, initially.

3.2.2.4. MANAGE TRADE ORDERS

After trade order is created with pending status, there are three steps which

are receive, validate and confirm order. If these steps are completed successfully,

the status of pending order becomes post. After post order is created, it is sent to

market exchange via FIX protocol. A response is expected from stock market. If

response is positive and order type is buy, capital of user decreases and specified

securities of user increases. If response is positive and order type is sell, capital of

user increases and specified securities of user decreases. If response is not

positive, there is no action. These all communication messages between stock

exchange system and the software via FIX protocol, is recorded in related array

locations during run time memory. All actions such as transactions, sent and

received messages etc. made in program are recorded instantly to database as

logs. Any kind of detailed information about system and operations can be found

by tracing logs in database.

3.3. NON-FUNCTIONAL REQUIREMENTS

3.3.1. PERFORMANCE REQUIREMENTS

Trading software architecture needs to achieve a very high degree of

performance. This would largely depend on the holding periods in the trading

strategies being used by the data analysis in algorithm. This is because processed

data amount and algorithm types differs according to trade constraints. The aim

of the software is to send faster buy/sell requests than other opponent buy/sell

requests.

The software requires to handle big amount of data in possible shortest

time while running of algorithms. For this reason, software uses huge amount of

memory. These above explained reasons can be summarized in first two entries,

and alternative performance necessities can be mentioned as following entries:

Extremely high speed CPUs are required.



High capacity of RAM (at least 4GB) is required.

Cables which are fiber optic and network connection with high bandwidth

are required.

There will be only one user in one working application.

User can start trades as many as he/she wants. (multithreading)

Software should update graphic of selected trade for each 0.5 second.

Logs should be recorded to database for each action during execution of

program. Note that no action should be missed even if failure.

3.3.2. DESIGN CONSTRAINTS

3.3.2.1. SCALABILITY

The architecture needs to be scalable in a number of different areas. This is

because the rate at which financial markets change means that the trading

activities of the institution could vary wildly from year to year. A system that is

able to support this changing landscape must be scalable.

3.3.2.1.1. DATA INPUT STREAMS MUST BE SCALABLE

The number of data inputs streams must be scalable so as to support:

1. Additional securities markets being added e.g. Stocks, Bonds etc.

2. Additional exchanges being added e.g. Nasdaq, NYSE, BSE, JSE, etc.

3.3.2.1.2. THE DISTRIBUTED PROCESSING ENVIRONMENT MUST BE

SCALABLE

The processing environment needs to be scalable to support an increased

scope in trading activities as well as an increased scope in the data being used to

inform those trading activities. This would be required from the buy/sell side

institution.

3.3.2.2. MODIFIABILITY

Business logic for trading strategies must be modifiable. Maximizing the

ease with which new algorithmic trading strategies can be added to the system

represents a competitive advantage. The processors interpret whatever strategy

they are presented and analyze the data they received according to that strategy.



This allows the organization to adapt faster to changing market conditions and

increase revenues as a result.

3.3.2.3. RELIABILITY

3.3.2.3.1. DATA PREPROCESSING MUST BE DECOUPLED FROM DATA

FORMATTING AND CONTAINERS

The data coming into the algorithmic trading system needs to be of the

highest quality as this directly impacts the reliability and accuracy of the output

produced. One risk which is introduced when the system design is tightly coupled

to the format in which data arrives, is that when that formatting changes, the

system implementation breaks. In order to avoid this risk and improve the

reliability of the system outputs, an architectural requirement is that the data be

loosely coupled from the implementation of the data preprocessor(s).

3.3.2.3.2. TRANSACTIONS AND ORDERS MUST BE 100% RELIABLE

Because algorithmic trading systems deal with large sums of money while doing

the trading, the orders should check meticulously. After this careful check, orders

can be sent to the stock exchange system. Test cases with known inputs and

expected outputs should be regularly run through the system so as to establish

the reliability of the services provided. Besides, the software should display

informative error messages when any system failure occurs.

Reliable software development platforms should be used during development and

maintenance phases of the project. Maximum Mean-Time-To-Failure value should

be aimed for the system, in other words, there should be minimum failure rate.

3.3.2.4. SECURITY

3.3.2.4.1. ANY UNAUTHORIZED LOGIN OR DISPLAY REQUEST MUST BE

PREVENTED

User’s portfolio, transaction, trade or any other information must not be

accessed other than himself/herself. Any unpermitted login or show request of any

information must be prevented.



3.3.2.4.2. INTELLECTUAL PROPERTY (IP) MUST BE SECURED

Because of the sensitivity and confidential nature of proprietary trading

firms’ algorithms, appropriate logical and infrastructural security controls

surrounding should be implemented as a part of the system architecture.

3.3.2.5. MAINTAINABILITY

During development phase of this project, new requirements can be added;

likewise, change management can be used in development phase. When changes

are applied to the system, these changes should be linked to software change

request and should be traced under version control system. Complexity of the

system should be decreased by using object oriented design, interfaces and

modules. This also makes debug easy in maintenance phase of the project. All

used software development design patterns during development of the project

should be documented well.

3.3.2.6. OTHER CONSTRAINTS

GUI of software will be implemented with JavaFX and Java, other parts will

be implemented with C++.

Software is aimed to operate at Windows 7 and upper versions (Windows 8

and 8.1), Linux Ubuntu 12.04 LTS and upper versions, and Mac OS X 10.8

and upper versions.

System is expected to be available for open hours of stock exchange at

least. In case of failure, the software should be able to recover all system

information by tracing recorded logs in database when the abortion occurs.

Software require client installation; therefore, JRE and operating system

necessities should be specified clearly for unproblematic installation.

4. DATA MODEL AND DESCRIPTION

This section describes information domain for the software.

4.1. DATA DESCRIPTIONS

Data objects that will be managed/manipulated by the software are

described in this section.



4.1.1. DATA OBJECTS

There are seven namespaces (packages) which are Communication,

Strategy, Users, Trades, Repository, Database and GUI. These namespaces include

logically related classes and they can be extended to include more classes during

software development. An analysis level class diagram is presented below. The

purpose is to introduce the objects that the system is required to have

representations for.

FIGURE 12: CLASS DIAGRAM OF THE SYSTEM



The brief explanations about the classes are shown as below:

FIX : This class contains the message to be sent or get from the stock

exchange. It has two methods to accomplish to send/receive messages

to/from BIST.

Account : This class includes name, surname, password, username, email

address and user id of user who is actively uses the system.

FIXDATA : This class consists of stock market information which is updated

frequently. To update itself, a FIX class instance from Communication

namespace is created. It gets market data through this FIX class instance

by sending appropriate FIX request. Also, all status of responses taken from

stock exchange is dumped to database as logs.

AlgoController : This is an abstract class. There are various algorithms which

inherit from this abstract class. According to chosen trade’s strategy, it is

determined which algorithm should be run in chooseBestAlgorithm method

of this class.

DBController : There is a static connection variable that enables the system

to access to the database. This connection is established once when the

main screen is opened and it is closed when the application is closed. There

is another method which verifies the user’s password and username is

recorded in database. Each trade is recorded to the database when it is

started by user. This property provides the system to reach easily all trades

information of related user. Besides, all transactions’ status information are

saved to database as logs. Note that each log record shall be saved to

database even in case of failure.

Trade : This class includes sort of trade, expiration date, size, maximum

profit amount, maximum loss amount and strategy of the instance. When

each trade is started, a thread is created in constructor of this class instance.

This thread is executed based upon runTransaction method of this Trade

class. In this execution, market data and trade’s parameters are evaluated

in best suitable algorithm and a buy, sell or do nothing decision is made.

Each starting trade information is recorded to the database as log.

TradeOrder : This class is responsible for creating FIX message to be sent

to the stock exchange according to the decision made after execution of

algorithm. Also, it has a method which receives FIX message to be sent,



verifies the message. If message verification is successful, it is sent to stock

market through methods of FIX class instance.

Display : This is an abstract class which is used to design interfaces of the

software. LoginScreen and MainScreen classes inherit from this class.

LoginScreen class draws login panel, and MainScreen draws core panel of

the software which displays all fields showed in section 2.1.2 USER

INTERFACES of this SRS document.

DisplayRunner : This class can be considered as brain class of the software.

It calls methods to draw LoginScreen, MainScreen and to update graphics

taking place in MainScreen. Also it has methods to provide user to sign in

and to start a new trade. Note that main method exists in this class;

therefore, the software will be started by this class.

4.1.2. DATA DICTIONARY

Stock exchange and stock market terms refers to same meaning and these

terms are used to represent BIST in this project.

5. BEHAVIOURAL MODEL AND DESCRIPTION

This section presents a description of the behavior of the software.

5.1. DESCRIPTION FOR SOFTWARE BEHAVIOUR

Major events and states can be described as following table.

STATE EXPLANATION

Login The user will login to the system.

MainScreen The system will show MainScreen which includes clock, date, user portfolio, open trades and profit/loss charts to user.

NewTrade The user will create new trade.

Logout The user will exit from the application.

Make trading decisions

The system will make trading decisions such as sell/buy securities after analyzing the stock market data according to

trading strategy.

Get market data The system will get stock market data in order to analyze the securities for making trading decisions.

Select securities to buy/sell

After the analysis of market data, the system will select

securities that will be sold or bought.

Create buy/sell orders

The system will create trade order to buy or sell selecting securities.



Send trade order to stock market

The system send a message to the stock market via FIX protocol according to user's request.

Analyze securities against trading

strategy

The system analyzes the market data based upon trading choices and makes a decision to be followed as next move.

Add open trade The system will add created trade to open trade list in MainScreen after confirmed order.

Specify trade type The user will select trade type according to own trade choice.

Trade value The user will specify quantity of securities which will sell or buy.

Expiration date The user will determine deadline of the trade.

Strategy The user will choose a strategy owing to his/her decision.

Calculate profit/loss The system will calculate total profits or losses of user from all trades.

Show chart The system will show profit/loss chart of selected trade in Open Trade List in MainScreen.

List open trades The system will show all trades of user in MainScreen.

Select open trade The user will select one of his/her own active trades. TABLE 2: EXPLANATION OF SYSTEM MAIN STATES

5.2. STATE TRANSITION DIAGRAMS

Overall behavior of the system can be depicted as following diagram.

FIGURE 13: STATE DIAGRAM OF THE SYSTEM



6. PLANNING

6.1. TEAM STRUCTURE

There shall be four developers in the team. All team members have main

focus points but they will work on every stage of development, if it is necessary.

There will be two different stages for system design, which are developing

prototype and delivering end product. For prototype phase of development, three

developers shall work on server side and one developer shall work on client side.

Initially the software prototype will be available only as desktop application if this

step is achieved successfully web version can be developed. For delivering end

product phase, two developers shall work on server side, one developer shall work

on client side and three developers shall work on developing required algorithms

for software.

6.2. ESTIMATION (BASIC SCHEDULE)

This is the weekly basic schedule of the project starting from the first SRS

Document.

0 - 1 Week : Team management and project selection.

1 - 3 Week : Searching required information from related internet source pages

and source books to understand system execution and design.

3 - 5 Week : Finishing search and starting to design of the system for server

side.

5 - 6 Week : Finishing system design for client side and starting implementation

of server side.

6 - 7 Week : Preparation and writing of software requirements specification.

8 - 11 Week : Finishing both client and server side demos and starting to test the

system. Also starting to bug fixing in same time with testing.

11 - 12 Week : Preparation and writing of software design descriptions.

12 - 13 Week : Finishing all current bug fixes.

13 - 14 Week : Presentation of the application and taking feedback and starting

to add/remove.

14 - 15 Week : Finishing demos. Also starting to improve C++ server and search

proper algorithms.

15 - 19 Week : Finishing algorithm searches and starting to implement them on

system.



19 - 22 Week : Finishing implementation and starting to bug fix of analyzed data

results from algorithms.

22 - 24 Week : Finishing bugs on algorithms working logic and starting to testing

server and client sides.

24 - 25 Week : Beginning to bug fixes of server and client side. Continue to test

process of them and fix new bugs.

26 - 27 Week : Fixing all bugs.

28. Week : Delivering the project

6.3. PROCESS MODEL

At the beginning of project we were told that we will be following agile

software development methodology. In the milestones we will get feedback about

what we did week by week and we will try to stand by our planning as long as

possible.

FIGURE 14: AGILE SOFTWARE DEVELOPMENT METHOD REPRESENTATION

7. CONCLUSION

Algorithmic trading system architectures are complicated because of the

strict quality requirements of the system. Also, the wide range of regulatory and

compliance requirements which manage automated trading makes the design of

this software harder. Because of these complexities, careful attention should be

paid to the design and implementation of the system architecture. This software

requirements specification document has been created through the help of various

researches. In this document, the general information about product description,

data elements that the product deals with, specific requirements like product's



interfaces and the functions that will be implemented are provided. However, some

specifications are prone to be changed in the future.

8. SUPPORTING INFORMATION

8.1. INDEX

No index is available.

8.2. APPENDIXES

No appendix is available.