Application Requirements

Here will be the different requirements in no particular order, just to remind what has to be done and how once I took the decision.

Column views:

The application will show the following fields by default in realtime view or in historical view:

  1. Group of the stock
  2. Name of the stock.
  3. Value of the last operation done.
  4. Value - Open diff (%)
  5. Value - Previous day diff (%)
  6. Bid Volume
  7. Bid
  8. Ask 
  9. Ask Volume
  10. Bid - Ask difference (%)
  11. Max value
  12. Min value
  13. Last Volume
  14. Total Volume
  15. Last Operation
  16. Max - Open diff (%)
  17. Min - Open diff (%)
  18. Open price
  19. Previous day price
  20. Current market status (Red: Closed, Light Green: Opening, Green: Open, Orange: Closing)

The application will have the following optional fields, it will be possible to show or hide all of them and the settings will be retained between executions, the difference between optional fields or not is that optionals will be hidden by default:

  1. Max Time
  2. Min Time
  3. Bid difference - Value
  4. Bid difference - Value (%)
  5. Ask difference - Value
  6. Ask difference - Value (%)
  7. Bid - Ask gap
  8. Value - Open diff
  9. Value - Previous day diff

The columns will have some options like if they are visible or not, their order, if they notify change with an animation or not, if they show an arrow indicating the current tendency  of the value. The options will be persisted between executions. Editing the column order directly in the application will modify the settings.

Only one set of settings will configure all the app columns (Real Time & Historical)

Data update:

All data should be taken from the providers without user interaction. If new stocks are added / removed from a group everything should be updated automatically.

When a future arrives to its expiry date it will be ignored (no more updates) but won't be removed from the viewer until the next group initialization. In the future has to be considered what to do with the new futures model.

It has to be considered how fees and stock times will be taken. Looks like this can not be easily taken from the providers.

Data acquisition:

Data should be acquired as fast as possible, to do this the system must query to the selected provider with a multithread system that best fit the selected provider. The accessors should not be queried for data when the markets are closed to save bandwidth.

To simplify the application the data acquisition system will stop on holidays only if all the read markets are closed. There will be static data that will contain the days when all the markets are closed.


The UI must adapt to its content and allow different font sizes, different dpi  settings and localization. No fixed sizes must be coded into the windows.

Historical View

It will show all the days containing data and won't let select days without it. The viewer will have a slider to move the time of the day that the viewer shows and a play button (with a multiplier selector) to simulate the time passing.


Strategies will be user created and thus there cannot be references to them on other parts of the application. Strategy dlls must provide everything required to make them work, for example the menu entries or the toolbar buttons must be included in the strategy dll.

At the beginning we thought that the execution of a strategy had to generate a human readable report with all the relevant information of the result. As there is no need to have the information on a document and this limits its possibilities the result will be presented to the end user with a custom control as this way we will be able include more  visual indicators.  The following fields are required to be in the summary of the result:

  1. Days considered on the test
  2. List of all the operations done
  3. Main indicators of the result:
    1. Final result
    2. Total operations
    3. Average per operation
    4. Max winner operation
    5. Max loser operation
    6. Worst loss
    7. Best win
    8. Required money
    9. % over the required money.
  4. A small chart with the day lastvalue and the operations done.
  5. A calendar for each month with the day in red if the average result was a loss or in green if it was a win.

The initial idea (as the strategies take some time to complete) was to store the results on the database to be able to see them again without executing the strategy. Now we see that this makes no sense as the strategies code usually changes over time and the stored real time information changes too.

Something has to be saved to be able to remember the results with certain parameter values but maybe it's enough to store the execute date, the settings and the total result.

Realtime strategies:

Realtime strategies will analyze incoming data based on certain parameters and will generate orders to buy and sell that will be placed on the real market.

The application must support more than one strategy being executed in realtime at the same time.

The realtime strategies must have a way to allow starting them with operations in course. Something like the user setting the current state of the engine.

The plugin can be the same as the one used for historical testing or can be a different one. This has to be decided. Decission: finally we will keep the engine the same for historical and for real-time, this way we can have the engine tested before setting it to work with real-time data.

The plugin has to be testable without sending real messages to the provider. There will be a simulation mode that will not send real orders to the market.

It has to provide realtime information about its execution (at least about its current state, it's not clear if we will show more information here or will rely on the historical plugin, probably here will be different information too).

It has to store into the database at least the start & stop time of the plugin and the operations executed.

Real-time plugins must track wherever the accessor is connected or not to avoid putting orders while the accessor is not connected. Orders are not retried on purpose to avoid multiple order placement, plugins with errors will halt its own execution and notify about the error condition. Human interaction will be required to fix what's wrong and to set the plugin into the right state again.


Charts will allow us to see in a graphical way the evolution of the price of an stock (in realtime or consulting historical data). The layout of the chart screen will be the following one:

At the meantime the layout is the following one but in the future it should be like the initial concept:

There will be tree ways to reach the chart window:

  1. There will be an option on the toolbar and on the menu to go to the chart view. The toolbar will have an special section to handle the chart window (and maybe a menu too?)
    • That section will allow us to select between realtime view or historical view, to select the stock to display and the date to be displayed if we are not on realtime mode.
    • It will allow us to add different series / indicators to the different panels of the charts. Pressing a button we will be able to select indicators from a list and configure the color, the name, the destination panel and the indicator parameters (if any).
  2. Right clicking on a realtime stock will take us to the chart window in realtime mode loading the data for the selected stock.
  3. Right clicking on a historical stock will take us to the chart window in historical mode loading the data of the selected stock on the selected day.

The Main Chart will contain all the series that has an Y ouptut equivalent to the value of the stock. The Indicators 1 will contain series consisting on indicators (values that go from 0 - 100). The Indicators 2 / Volume will contain all the series related with the Volume and the Vol / Value window will contain specifically the series that show how the volume is related with the value.

Remaining features to be added to the Charts:

  1. Annotations: to be able to draw lines on the chart. These lines shouldn't be modified by Zooms or Pans.
  2. Create custom axes so they are always visible and paint in green positive values and in red negative ones.
  3. Add a color picker to the options dialog.
  4. Context menu to go from a stock to its chart.
  5. Filter: code a custom filter that do not paint more than one point per pixel and removes points outside the current window.

Last edited Feb 18, 2013 at 10:03 AM by somos, version 28


No comments yet.