Requirements and Quality Attributes

They may be given as constraints, that is, predefined decisions that may not change. They may be implied by user stories, making them functional requirements. They may be general desirable qualities in connection with business goals of stakeholders.

All of those are known as architecturally significant requirements. That is, requirements that strongly influence architecture choices. Characterizing those is the final step in our initial “understand phase”.

Constraints

Most come from stakeholders' goals. A few other ones are here to make my life as a developer easier on this project.

Origin	Constraint	Detail
Manager	Initial release must be ready by end of Q4 2018.
Manager	Must use free tools only.	As an illustrative project, it has no allocated budget.
Manager	Must be Open Source software	Project will be used to write articles on a website.
Manager	Must support at least two of Binance, Bitfinex, Bitstamp and Bittrex marketplaces.	Those are common and renowned marketplaces, good initial candidates to gain visibility.
Developer	Must run on Linux	Easier to develop and maintain, and no willingness to mess with Win32 oddities.
Developer	Must use only C/C++/Python/JavaScript for development	Best knowledge at this point in time, will make for more efficient development.
Developer	Must work in detached mode, as a background job with a controlling interface.	This follows the tradition of Unix modular architecture.

Influential functional requirements

An influential functional requirement is a requirement that has an impact on system architecture.

The point is not to recreate project's functional requirements. Rather, it is to identify key requirements that could make our architecture fail badly should we omit them in our design.

Usually, interactions with people or with external system are good candidates.

• Cryptomate shall gather real-time data from market data providers.

• Cryptomate shall react to data updates in real time, according to a predefined strategy:

  • Strategy shall be user-defined.
  • Strategy shall allow users to compose and test indicators arbitrarily.
  • Strategy shall be able to cross-analyze several markets.

• Cryptomate shall allow strategies to trigger market orders on trading platforms.

  • It shall be able to open orders, cancel orders and monitor order fill.
• Cryptomate shall send notifications on order fill, errors and user-defined strategy events.
• Cryptomate shall produce auditing tracks of its activity.

Quality attributes

A quality attribute describes visible properties of the solution and expectations of how well it performs its role.

As much as possible, we want to describe those quality attributes through scenarios, quantifying the characteristics of solution's response to specific stimuli.

There are many possible quality attributes. This section only includes the ones identified while establishing stakeholder's business goals. All items in this section either are taken straight from stakeholders' goals, or result from refining one of those goals into multiple scenarios.

Modifiability

Represents the cost of changing the product. In our case, it can be split into maintainability and testability.

Maintainability

Maintainability is the capacity of a system to be modified in order to fix defects, meet new requirements and manage technical debt.

Scenarios :

• User wants access to a new market data provider. ➤ Adding support should touch no existing code.
• User wants access to a new trading platform. ➤ Adding support should touch no existing code.
• User wants a new indicator module. ➤ Adding it should touch no existing code.
• User wants to send notifications to a new message broker. ➤ Adding support should touch no existing code.

Testability

Testability is the capacity of a system to facilitate the establishment of tests and check that validation criteria are met.

Scenarios :

• End user, in a normal environment, requests market data provider connectivity check. ➤ The test completes within 10s, with a full report of provider connectivity, including latest data time and last error, if any.
• End user, in a normal environment, requests a trading platform connectivity check. ➤ The test completes within 10s with a report, including platform response time, API key validity and last error, if any.
• Dev user, in a testing environment, performs integration tests. ➤ They are able to automatically control the system within 5 minutes and at the end of the test 95% coverage is achieved.
• Developers, in a testing environment, perform unit tests. ➤ They are able to automatically control the system within 5 minutes and at the end of the test 100% module coverage is achieved.

Run-time attributes

Performance

Performance is the ability of the system to achieve required functionality within time, space and cost constraints.

Scenarios :

Those assume consumer-grade hardware, with 100 active strategies. Current state examining at most one Cryptomate-provided indicator, and no throttling restrictions coming into play.

• New market data is received. ➤ The outgoing requests of any resulting order opening or cancelling directives, and any notification must be seen within 1 second of receiving the new data.
• Strategy management directives (such as enable / pause / resume…) are received. ➤ A confirmation or error must be sent back within 15 seconds.

Reliability

Reliability is the ability of the system to recognize the failure of an internal component and maintain its correctness (either by compensating the fault or reporting it).

Scenarios :

• The market data provider fails to provide meaningful, valid data. ➤ The system must send an error notification within 1 minute and close open positions depending on user settings.
• The trading platform fails to respond to Cryptomate requests. ➤ The system must send an error notification within 10 seconds.
• The notification service fails to respond to Cryptomate requests. ➤ The system, if so configured, must stop all running strategies and close open positions within 1 minute.

Availability

Availability characterizes system response to failures and the associated consequences.

Scenarios :

• Upon starting the system, strategies that were active when it was stopped, either gracefully or forcedly, should resume within one minute.
• The system should work reliably when receiving duplicate data, so market data redundancy can be implemented by fetching data over more than one physical link.

Scalability

Scalability is the ability of the system to handle an increasing amount of work. This includes the ability to accommodate additional resources.

• When adding new instances of the engine to implement horizontal scaling, they should share the inbound market data feeds.

Usability

Usability is the ability of the system to enable users to accomplish desired tasks in the most efficient / comfortable / … way.

I will leave this part out intentionally for now, we will come back to it when designing user interactions. As we have a constraint that the system is detached from any user interface, we should have a high level of decoupling, making the UX almost a separate project.

Security

Authenticity

Authenticity is the trust the system can have that data and messages are from the sender they claim to be from.

• When connecting to market data providers, the system must authenticate the remote end, and abort if it fails to do so. ➤ The event shall be logged.
• When receiving directives through its controlling interface, the system must authenticate the remote end and reject the directive if it fails to do so. ➤ The event shall be logged.
• When sending orders to trading platforms, the system must authenticate the remote end, and abort, not disclosing the order if it fails to authenticate. ➤ The event shall be logged.

Confidentiality

Confidentiality is the ability of the system to keep some information and services private.

• When writing strategy configuration, user credentials or system state to persistent storage, they must be encrypted so they remain private even on untrusted persistent storage.

Integrity

Integrity is the ability of the system to ensure information has not been corrupted or tampered with.

• When loading market data history, the system must check data integrity, and not use the history. ➤ The event shall be logged.
• When loading strategy configuration and state, the system must check their integrity, and abort loading if the check fails. ➤ The event shall be logged.

Audit-ability

Audit-ability is the capacity of the system to keep adequate records to support audits and investigations.

• If so configured, the system shall record every step taken by a strategy. Recorded data must include reason for taking the step and outcome of actions performed.

Conclusion

We now have a full view of what features and which quality attributes will have an impact on the architecture of our solution. At that point, we should consolidate all the knowledge gathered so far into an architecture-significant requirement workbook. This is a living document that we will update as we encounter new elements we missed in the initial design phase, hopefully as few as possible.

In the next post, we will use that knowledge to create a high-level architecture from common designs, possibly compositing them for our system.